Hi folks, We have known for some time that Apache Ivy hasn't had much attention for a while (that has changed a little recently in terms of a few fixes, thanks to Eric and others, but not so much in terms of releases). There has been discussion about looking at alternatives with Apache Maven Resolver one of the candidates. I have created an issue and PR which provide a proof of concept.
https://issues.apache.org/jira/browse/GROOVY-11871 https://github.com/apache/groovy/pull/2140 At the moment, you need to have the groovy-grapes-maven module available (it's currently part of the standard install) and then you set the system property: -Dgroovy.grape.impl=groovy.grape.maven.GrapeMaven Otherwise the default is the standard groovy.grape.GrapeIvy implementation. It is nearly complete with just a few things that might need attention: * Logging for GrapeMaven is just done using logback config files (the defaults aren't too bad if no such file exists) but we might want to add programmatic configuration of that to avoid the extra config. * I am currently using maven-resolver-provider:4.0.0-rc-5. We often want final releases of dependencies but this is close to final and Groovy 6 won't be final for a little while anyway. * Maven doesn't have the same concept of "conf" as Ivy. It does have "scope" but the two don't exactly coincide. * There could be subtle differences between the actual artifacts selected. I have tried to match Ivy semantics as closely as possible but maybe I haven't tested all cases as of yet. But, otherwise the test suites pass when swapping between the implementations. We have numerous options to roll this out. First is a decision around which implementations to include. Should we leave GrapeIvy as the default, making GrapeMaven optional? Or make GrapeMaven the default. Or just swap and treat Ivy vs Maven Resolver as being an implementation detail. And do we do the same for 6 and 7. Assuming we provide both and set GrapeIvy as the default in Groovy 6, we could reverse the default in 7 for instance. Next we have a choice around how to invoke. We can have both classes and use the system property (as per the current proof of concept). The intention isn't for people to have two Grape systems they can freely swap between but rather to pick one or the other. Alternatively, we could use a service loader mechanism. We could put the current GrapeIvy implementation into a groovy-grape-ivy module. Then folks could pick one or the other. This would also prevent either from being selected when grapes aren't needed, effectively locking down that functionality. We have options regarding whether to fail or select the first one if both are on the classpath. Anyway, thoughts welcome, as is any feedback from trying it out. Cheers, Paul.
