groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keegan Witt <>
Subject Re: Maven coordinates going forward
Date Fri, 31 Mar 2017 02:23:55 GMT
That's a good point.  It could cause some issues for Groovy as a transitive
dependency, but doing a global exclude in Maven is fairly easy to do.

On Tue, Mar 28, 2017 at 1:42 PM, C├ędric Champeau <>

> One thing one has to consider when changing Maven coordinates, is...
> Maven. Despite being a build tool, it does a fairly poor job when
> coordinates change. In particular, think of conflict resolution. What
> should it decide if A depends on org.codehaus.groovy:2.4.10 and B depends
> on org.apache.groovy:groovy-all:3.0? Maven is pretty bad at this. We have
> strategies to deal with this in Gradle (dependency substitution), but it
> will imply that projects could find different artifacts on classpath in the
> future, for a dependency on Groovy.
> That said, I'm open to changing the coordinates. I would do this for the
> "breaking" version of Groovy, whatever it is, but not before. Which means,
> the same version as the one we change package names.
> 2017-03-28 19:03 GMT+02:00 Keegan Witt <>:
>> I'm +1 on Maven coordinate change.  That should be fairly low impact.
>> I agree package renames should be taken on a case-by-case basis.
>> Offhand, the two biggest things that come to mind are custom ASTs, and the
>> compilation bits.  For the former, I'd think it shouldn't be any worse than
>> the groovy.transforms move.  For the latter, it might make sense to wait to
>> rename that package until the compilation is decoupled from the core.
>> On Tue, Mar 28, 2017 at 9:36 AM, Jochen Theodorou <>
>> wrote:
>>> On 27.03.2017 22:14, Wilson MacGyver wrote:
>>>> as I recall, there are also rules about jigsaw not allowing same package
>>>> path from multiple modules. It's not till java 9, but that maybe a
>>>> concern.
>>> That is right, yes... it is only a problem for Groovy as named or
>>> automatic module though. As long as Groovy stays in the
>>> classpath/annonymous module variant, there is no such problem with multiple
>>> jars, as long as the overlapping package names are all from the
>>> classpath/annonymous module
>>> bye Jochen

View raw message