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 <bezjak.m...@gmail.com> 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" <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 >>> >> >> > >
