2017-01-06 15:33 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>: > 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. > > Both options are valid but I think you had a good point and it can be API intrusive
> 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? > > Yes, if you don't remove the snapshot copy from ~/.groovy/grapes/ then you use the last resolved one which is likely outdated with maven repo. > - 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/openej >> b-loader/src/main/java/org/apache/openejb/loader/provisin >> ing/MavenResolver.java >> and >> https://github.com/apache/tomee/blob/master/container/openej >> b-loader/src/main/java/org/apache/openejb/loader/provisin >> ing/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 > > Agree, I only know aether (or its forks) which are far from 400 LOC but alternatives welcomed as well if they exist > bye Jochen > >
