IMO we should be looking to create a JARJARed version of Aether and removing Ivy all together
Ivy is broken fundamentally in numerous ways and is no longer developed and maintained. I cannot recommend that anyone uses @Grab currently because it breaks down in pretty much any real world scenarios. There is an Aether implementation as part of Spring Boot https://github.com/spring-projects/spring-boot/blob/master/spring-boot-cli/src/main/java/org/springframework/boot/cli/compiler/grape/AetherGrapeEngine.java That should be merged into Groovy. The only downside is that Aether is several jars rather than just a single one as is the case with Ivy. For this we would need to create a JARJAR'ed version of those dependencies. Cheers On Fri, Jan 20, 2017 at 11:42 PM, Sergei Egorov <bsid...@gmail.com> wrote: > FYI https://github.com/igor-suhorukov/mvn-classloader > > On Tue, Jan 10, 2017 at 11:43 AM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: >> >> Hmm, ibiblio (localm2 in grapesConfig.xml) has >> setChangingPattern(".*-SNAPSHOT"); so should have worked OOTB....but >> >> org.apache.ivy.plugins.resolver.ChainResolver#getDependency checks the ivy >> (default) cache before using resolvers so resolvers are basically skipped >> and even the localm2 good behavior is ignored cause in >> org.apache.ivy.plugins.resolver.BasicResolver#getDependency >> shouldReturnResolvedModule() makes it bypassed >> >> Looks like a bug in ivy, wdyt? Adding in this test a changing pattern test >> (String.valueOf(dd.getAttribute("revision")).matches(getChangingPattern())) >> would make it working. >> >> Of course this is doable in groovy but should probably be reported to ivy. >> >> Wdyt? >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory >> >> 2017-01-10 10:10 GMT+01:00 Paul King <pa...@asert.com.au>: >>> >>> Perhaps something can be done but some people use snapshots without >>> any timestamps. As long as that didn't break. I think years ago it >>> became a lot slower in that scenario if we auto set 'changing'. Not >>> sure if that is the case any longer. >>> >>> Cheers, Paul. >>> >>> On Tue, Jan 10, 2017 at 6:48 PM, Romain Manni-Bucau >>> <rmannibu...@gmail.com> wrote: >>> > Ok, imported the project and...discovered changing() :). Think it can >>> > solve >>> > the issue for now. Then the remaining question is the duplication of >>> > the >>> > repo but guess I can live with it for now. In GrapeIvy do we want to >>> > move >>> > >>> > boolean changing = deps.containsKey('changing') ? deps.changing : >>> > false >>> > >>> > to >>> > >>> > boolean changing = deps.containsKey('changing') ? deps.changing || >>> > version.endsWith('-SNAPSHOT') : false >>> > >>> > >>> > ? >>> > >>> > Not an issue if not, would just makes maven standard better integrated >>> > with >>> > the pitfall of having changing value forced (so less obvious). >>> > >>> > wdyt? >>> > >>> > Romain Manni-Bucau >>> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory >>> > >>> > 2017-01-10 1:36 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>: >>> >> >>> >> well... contributions are welcome ;) >>> >> >>> >> On 06.01.2017 15:36, Romain Manni-Bucau wrote: >>> >>> >>> >>> >>> >>> >>> >>> 2017-01-06 15:33 GMT+01:00 Jochen Theodorou <blackd...@gmx.org >>> >>> <mailto: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/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/MavenResolver.java >>> >>> >>> >>> >>> >>> <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 >>> >>> >>> >>> >>> >>> <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 >>> >>> >>> >>> >>> >>> Agree, I only know aether (or its forks) which are far from 400 LOC >>> >>> but >>> >>> alternatives welcomed as well if they exist >>> >>> >>> >>> bye Jochen >>> >>> >>> >>> >>> >> >>> > >> >> > -- Graeme Rocher
