groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Maven coordinates going forward
Date Fri, 31 Mar 2017 04:21:52 GMT
I’m a bit OCD and it makes little sense to continue developing against coordinates and packages
with a naming scheme that represents a defunct brand/organization.

So I vote for a coordinate change.

If the coordinate changes, then the package naming should change too in my opinion. This solves
any transitive dependency clashes since my project could import apache packages and any transitive
dependencies can continue to depend on and use the old codehaus packages.

Then put the old codehaus branded branches/versions in maintenance and do all new development
against the new coordinate and package structure.

Is this not the whole point of releasing versioned binaries?  It just means a couple of extra
steps when I upgrade.  First, change the coordinates (group + version instead of just the
version) and a quick refactor of my imports.  Every modern IDE makes this easy.

<off to take my OCD meds> 😊

Sent from Mail for Windows 10

From: Keegan Witt
Sent: Thursday, March 30, 2017 8:24 PM
Subject: Re: Maven coordinates going forward

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 <> 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

bye Jochen

View raw message