groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <>
Subject RE: Maven coordinates going forward
Date Mon, 27 Mar 2017 19:03:21 GMT
I don't know if it was totally clear from my previous mails, but I agree on not changing the
package names, unless breaking changes are required and the package names need to change to
preserve the ability of Groovy 1.x/2.x code to co-exist, avoiding the "Python 3 Effect". If
the only breaking change would be the package change, then there's no sense to change the
name just to change the name.

I think it is OK to change the Maven coordinates in any case. While it is used sometimes as
a starting point to look at a class and try to figure out what library it comes from based
on matching the package name to the group ID, that's not a common operation and modern IDEs
(and can easily answer the question if needed. The only drawback to changing
Maven coordinates is it might make it harder for people to know there is a newer package,
that is, to search for upgrades we check for more recent versions of current dependencies.
However, with a project as big as Groovy I think it will be clear when Groovy 3 comes out
that users will know.


From: Keith Suderman []
Sent: Monday, March 27, 2017 2:49 PM
Subject: Re: Maven coordinates going forward

+1 for changing Maven coordinates.

-1 for changing package names.  Sure, new code can use the new package names, but changing
existing packages is just breaking changes for the sake of breaking things with no real benefit.
 I hope the Groovy team tries to break as little as possible to avoid the "Python3 Effect",
whether real or imagined.

Having said that, how much public facing code is in org.codehaus.groovy packages?  I don't
think I've typed "import org.codehaus.groovy..." in my life, but IntelliJ may have inserted
a few for me.


On Mar 27, 2017, at 2:20 PM, Jochen Theodorou <<>>

On 27.03.2017 20:08, Winnebeck, Jason wrote:

The key thing in my mind is that you can't make a change that breaks
100% of libraries at one time without fracturing the community or at
least introducing a major hindrance to upgrade that will mean
maintaining 2.x series for a very long time. Even if the upgrade
process is as easy as a recompile, there are a lot of published
libraries no longer maintained. Even for the ones that are
maintained, there are people who might not want to be forced to
upgrade every library. I'm not a Grails user, but my impression is
that the framework relies on a lot of plugins and is one of the (if
not the most) active Groovy communities and I have a hard time
envisioning how that upgrade path will take. You'd have to maintain
Groovy 2 and Groovy 3 versions of each plugin, and to upgrade you'd
have to upgrade everything at one time to the (most likely) latest

What is the possibility that the package names are changed, the
parser, metaprogramming model, etc. that all break in Groovy 3
change, but yet still have a compatibility JAR implementing the
minimal Groovy 2.x classes in a way that allows interoperability with
Groovy 3 code? Theoretically at a worst case, Groovy 3 should be able
to view Groovy 2 classes the same way as any other Java class. I
think many concerns would be lifted if Groovy 2 and 3 could co-exist
at the same time, allowing you to upgrade incrementally.

If you see the new metaprogramming model as chance, then it would make sense to implement
that in the new packages instead of transferring old and to be deprecated classes. The goal
would the to be able to run old and new system at the same time, where the Groovy 1.x/2.x
classes would use Groovy 3.x/4.x classes as implementation.

The problem with this approach is simply manpower and of course some conceptual problems still
to be solved.

bye Jochen

Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY<>

This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.

View raw message