groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Suderman <suder...@anc.org>
Subject Re: Maven coordinates going forward
Date Wed, 29 Mar 2017 19:42:40 GMT
Given Cédric's email and recent comments I think I have been convinced to change my vote to
a -1 for changing Maven coordinates or package names.

Is there a compelling technical argument for either change?  Going by the old adage, "if it
ain't broke don't fix it", what exactly is being "fixed"?  It seems most arguments in favour
are political/aesthetic and not technical in nature.

Besides, think of using org.codehaus.groovy as paying homage to Groovy's long and storied
history. ;-)

Keith

> On Mar 29, 2017, at 5:08 AM, Miro Bezjak <bezjak.miro@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.champeau@gmail.com <mailto:cedric.champeau@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 <keeganwitt@gmail.com <mailto:keeganwitt@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 <blackdrag@gmx.org <mailto:blackdrag@gmx.org>>
wrote:
> 
> On 27.03.2017 22 <tel:27.03.2017%2022>: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
> 
> 
> 

----------------------
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suderman@cs.vassar.edu





Mime
View raw message