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 <cedric.champ...@gmail.com> 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 <keeganw...@gmail.com>: > >> 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 <blackd...@gmx.org> >> 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 >>> >> >> >