groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Hickey <>
Subject Re: Maven coordinates going forward
Date Wed, 29 Mar 2017 18:18:00 GMT
The transitive dependency problem is also challenge for non-open source,
internally developed enterprise applications as well. I'm having a hard
time seeing how this "should be fairly low impact."

I agree with: "I would do this for the "breaking" version of Groovy,
whatever it is, but not before."

On Wed, Mar 29, 2017 at 4:08 AM, Miro Bezjak <> wrote:

> -1 for both maven coordinates and package change. Please don't break
> backwards compatibility. Maybe I'm missing something but I see no good
> reason for either change.
> As others have mentioned, there is a lot of unmaintained code that would
> stop working as a result of a package change. So in my opinion, pros would
> need to be greater than the fact that the whole groovy ecosystem can
> suddenly do less than before the change.
> As for maven coordinates, please see Cédric's mail. Again, pros do not
> outweigh the cons in my opinion. Dependecy resolution conflict problem that
> doesn't exist if maven coordinates stay the same.
> Just my 2 cents.
> On Mar 28, 2017 7:42 PM, "Cédric Champeau" <>
> wrote:
> 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