On 06.01.2017 15:00, Romain Manni-Bucau wrote:
[...]
Means SNAPSHOT patterns needs to be identified (likely a flag in the
@Grab(snapshot=true)?) and groovy should clean up the artifacts before
resolving to avoid to let ivy mess up its repo.
which means it is more than just a change in the configuration file.
For maven based artifact
it also means you run copies instead of maven repository ones which is
leading to unexpected runtime sometimes.
can you explain a bit more? you mean the local ivy repo with copy?
- what kind of SPI groovy would use (ATM GrapeEngine lookup is quite
hardcoded): do we want a config in groovy installation + system
property?
would someone want to define the engine as part of the annotation or
should this be automatic in the background? We could also think of
using the Java service provider interface logic - of course then we
have to think about what to do if multiple engines are there
sounds good in @Grab with probably a default globally settable in the
script.
yes I think we can do that
- if we want another engine: how do we manage dependencies? do we
isolate them from groovy libs?
they should be optional for the delivery.... and in the light of
that I think depending on spring-boot-cli is an option
Alternative is to implement it in groovy without maven in a light
fashion, with
https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/MavenResolver.java
and
https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/HttpResolver.java
you can resolve most of maven artifacts. This code needs to be reworked
on its config side cause it is specific to tomee but my point is in <
400 LOC you can get a maven resolver you own and therefore supporting
snapshots is very doable there.
I would prefer depending on something existing, but 400 LOC is not much
and if that goes without further dependencies... well then we should
consider doing that
bye Jochen
