You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Paul King <pa...@asert.com.au> on 2017/03/27 13:57:20 UTC
Maven coordinates going forward
Hi, it's still a little while away but we'll soon begin the work on
what will be called Groovy 3 or Groovy 4 - the exact version number is
potentially up for further debate depending on how other upcoming
Parrot back port work pans out but we are not asking for feedback on
that right now.
This new version of Groovy will have the new Parrot parser merged.
We're also planning to require JDK8 and it might have some other
breaking changes depending on how things pan out. There has been
discussion in the past that Apache Groovy might (should?) change the
Maven coordinates to have group org.apache.groovy rather than
org.codehaus.groovy. Previously we have spoken about not doing that
before some major release point. The Groovy team is now interested in
your feedback as to whether this new version might be the right time
to make that change.
Obviously, we'll need to publicise the change to make sure people can
find the new versions but we are particularly interested in feedback
on whether anyone would be adversely affected by such a change.
Comments welcome,
Cheers, Paul.
Re: Maven coordinates going forward
Posted by Paul Moore <p....@gmail.com>.
On 27 March 2017 at 19:49, Keith Suderman <su...@anc.org> wrote:
> +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.
As a Python dev, who's just started working with Groovy for some work
projects, I hope people don't mind me adding my opinion here.
I think you're right. The Python problems were largely because we
broke people's source code (that was a deliberate choice, 2-3 was
always intended as a backward compatibility breaking change, but in
hindsight I think the view is that we won't ever take that approach
again). So the package name change would be a similar compatibility
break for Groovy and you should consider carefully whether the
benefits justify it. From what I've seen of Groovy code, the package
names are needed relatively infrequently, so it's possible that the
breakage would be limited - but what's the benefit? Python's
experience is that simply "tidying up" is pretty risky as a
justification...
I'm not familiar enough with Java's packaging ecosystem and Maven to
know what the impact of changing the Maven coordinates would be, so
I'll say nothing on that one.
I know very little about the Groovy or Java communities, though. Their
tolerance for change is likely very different from the Python
community's (both for better and worse) so I'd rely more on your sense
of what your users will think than on what happened with Python.
Hope this helps,
Paul
Re: Maven coordinates going forward
Posted by Péter Gergely Horváth <pe...@gmail.com>.
Hi All,
I think it would make sense to change Maven coordinates to *org.groovy-lang* to
reflect the main Groovy website address (http://groovy-lang.org/), just
like Scala does with "org.scala-lang" referring to http://scala-lang.org.
I believe changing any package name would open Pandora's box of troubles,
and would hurt the adoption and future of Groovy. Maybe, a potential
work-around could be having an *optional* "backwards compatibility"
dependency JAR, which could simply delegate calls to the new package
structure from the legacy org.codehaus.groovy world to the new packages,
with all legacy package classes being annotated as deprecated. However, I
do not think it is worth the effort: Oracle JDK still uses "sun." and
"com.sun." package names internally: I don't think we have to eradicate the
past.
That being said, I do support changing Maven coordinates to
*org.groovy-lang *but I am strongly against touching the existing package
structure.
Cheers,
Peter
On Tue, Mar 28, 2017 at 6:48 AM, Guillaume Laforge <gl...@gmail.com>
wrote:
> It is also indeed a problem, which will lead us to move some classes
> around, from a package to another.
>
> On Mon, Mar 27, 2017 at 10:14 PM, Wilson MacGyver <wm...@gmail.com>
> 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.
>>
>> On Mon, Mar 27, 2017 at 3:28 PM, Guillaume Laforge <gl...@gmail.com>
>> wrote:
>>
>>> Just an added note on the topic of potential package name changes.
>>>
>>> In the past, we've had to move some AST transformations from groovy.lang
>>> to groovy.transforms, and we managed to make that transition without too
>>> much harm.
>>> Similarly to what we did on that occasion, we could offer a
>>> compatibility module that would just delegate classes from old packages to
>>> classes of the new packages. And once you've had the time to make the
>>> migration, you'd just remove the compatibility module.
>>> We could also have more complex solutions involving bytecode rewriting.
>>>
>>> But at some point, it'll really look ridiculous to still have
>>> org.codehaus here and there, although codehaus' already been long gone
>>> already.
>>>
>>> So package name changes are not all black'n white.
>>> There are possible shades of gray :-)
>>>
>>> Guillaume
>>>
>>>
>>> On Mon, Mar 27, 2017 at 9:03 PM, Winnebeck, Jason <
>>> Jason.Winnebeck@windstream.com> wrote:
>>>
>>>> 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
>>>> search.maven.org) 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.
>>>>
>>>>
>>>>
>>>> Jason
>>>>
>>>>
>>>>
>>>> *From:* Keith Suderman [mailto:suderman@anc.org]
>>>> *Sent:* Monday, March 27, 2017 2:49 PM
>>>> *To:* users@groovy.apache.org
>>>> *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.
>>>>
>>>>
>>>>
>>>> Keith
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mar 27, 2017, at 2:20 PM, Jochen Theodorou <bl...@gmx.org>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> 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
>>>> version.
>>>>
>>>> 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
>>>>
>>>> suderman@cs.vassar.edu
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Apache Groovy committer & PMC Vice-President
>>> Developer Advocate @ Google Cloud Platform
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>
>>
>>
>>
>> --
>> Omnem crede diem tibi diluxisse supremum.
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
Re: Maven coordinates going forward
Posted by Guillaume Laforge <gl...@gmail.com>.
It is also indeed a problem, which will lead us to move some classes
around, from a package to another.
On Mon, Mar 27, 2017 at 10:14 PM, Wilson MacGyver <wm...@gmail.com>
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.
>
> On Mon, Mar 27, 2017 at 3:28 PM, Guillaume Laforge <gl...@gmail.com>
> wrote:
>
>> Just an added note on the topic of potential package name changes.
>>
>> In the past, we've had to move some AST transformations from groovy.lang
>> to groovy.transforms, and we managed to make that transition without too
>> much harm.
>> Similarly to what we did on that occasion, we could offer a compatibility
>> module that would just delegate classes from old packages to classes of the
>> new packages. And once you've had the time to make the migration, you'd
>> just remove the compatibility module.
>> We could also have more complex solutions involving bytecode rewriting.
>>
>> But at some point, it'll really look ridiculous to still have
>> org.codehaus here and there, although codehaus' already been long gone
>> already.
>>
>> So package name changes are not all black'n white.
>> There are possible shades of gray :-)
>>
>> Guillaume
>>
>>
>> On Mon, Mar 27, 2017 at 9:03 PM, Winnebeck, Jason <
>> Jason.Winnebeck@windstream.com> wrote:
>>
>>> 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
>>> search.maven.org) 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.
>>>
>>>
>>>
>>> Jason
>>>
>>>
>>>
>>> *From:* Keith Suderman [mailto:suderman@anc.org]
>>> *Sent:* Monday, March 27, 2017 2:49 PM
>>> *To:* users@groovy.apache.org
>>> *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.
>>>
>>>
>>>
>>> Keith
>>>
>>>
>>>
>>>
>>>
>>> On Mar 27, 2017, at 2:20 PM, Jochen Theodorou <bl...@gmx.org> wrote:
>>>
>>>
>>>
>>> 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
>>> version.
>>>
>>> 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
>>>
>>> suderman@cs.vassar.edu
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>
>
>
> --
> Omnem crede diem tibi diluxisse supremum.
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Maven coordinates going forward
Posted by Paul King <pa...@asert.com.au>.
Thanks everyone for the feedback. I was mostly interested in feedback on
the maven coordinates rather than package names, but it was good to get
views on both. We have already started creating new classes using the
org.apache package prefix rather than org.codehaus and I presume that we
can continue doing that for now. But we haven't reached the point where we
have parallel Groovy2/3 versions (or whatever version numbers it ends up
being) of the same functionality. We might need to do an early spike to see
how things start to pan out. For the time being I'll leave the maven
coordinates using org.codehaus.groovy (so that's what snapshot versions
will have for now) and when it gets closer to a release of the version we
believe to have the envisaged significant breaking changes we can call for
a vote on a coordinate change. By that stage it will also hopefully be
clearer on what changes might need to be adopted wrt package names.
Cheers, Paul.
On Sat, Apr 1, 2017 at 1:24 AM, Jeff <pr...@gmail.com> wrote:
> 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.
>>>
>>>
>>> This is not much about direct dependencies, but about transitive
>> dependencies. Exclusions in Maven are horrible. You never want to exclude a
>> dependency. What you really want is to substitute it, so that it can belong
>> to the dependency resolution process.
>>
>
> I believe it is about transitive dependencies. By changing both the
> coordinates *and package names* accordingly, you now can have packages
> from older codehaus dependencies (both transitive or direct) that will not
> clash with packages from the newly named apache (direct or transitive)
> dependencies.
>
> I may be missing something but I believe it eliminates the specific
> transitive inclusion issue since old and new can coexist.
>
> On Fri, Mar 31, 2017 at 1:32 AM, Cédric Champeau <
> cedric.champeau@gmail.com> wrote:
>
>>
>>>
>>>
>>> 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.
>>>
>>>
>>> This is not much about direct dependencies, but about transitive
>> dependencies. Exclusions in Maven are horrible. You never want to exclude a
>> dependency. What you really want is to substitute it, so that it can belong
>> to the dependency resolution process.
>>
>
>
Re: Maven coordinates going forward
Posted by Jeff <pr...@gmail.com>.
>
> 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.
>>
>>
>> This is not much about direct dependencies, but about transitive
> dependencies. Exclusions in Maven are horrible. You never want to exclude a
> dependency. What you really want is to substitute it, so that it can belong
> to the dependency resolution process.
>
I believe it is about transitive dependencies. By changing both the
coordinates *and package names* accordingly, you now can have packages from
older codehaus dependencies (both transitive or direct) that will not clash
with packages from the newly named apache (direct or transitive)
dependencies.
I may be missing something but I believe it eliminates the specific
transitive inclusion issue since old and new can coexist.
On Fri, Mar 31, 2017 at 1:32 AM, Cédric Champeau <ce...@gmail.com>
wrote:
>
>>
>>
>> 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.
>>
>>
>> This is not much about direct dependencies, but about transitive
> dependencies. Exclusions in Maven are horrible. You never want to exclude a
> dependency. What you really want is to substitute it, so that it can belong
> to the dependency resolution process.
>
Re: Maven coordinates going forward
Posted by Cédric Champeau <ce...@gmail.com>.
>
>
>
>
> 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.
>
>
> This is not much about direct dependencies, but about transitive
dependencies. Exclusions in Maven are horrible. You never want to exclude a
dependency. What you really want is to substitute it, so that it can belong
to the dependency resolution process.
RE: Maven coordinates going forward
Posted by pr...@gmail.com.
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
To: users@groovy.apache.org
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 <ce...@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 <ke...@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 <bl...@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
Re: Maven coordinates going forward
Posted by Keegan Witt <ke...@gmail.com>.
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 <ce...@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 <ke...@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 <bl...@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
>>>
>>
>>
>
Re: Maven coordinates going forward
Posted by Scott Hickey <js...@gmail.com>.
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 <be...@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" <ce...@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 <ke...@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 <bl...@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
>>>
>>
>>
>
>
RE: Maven coordinates going forward
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
OK, in my mind that is perfectly fine. In this case the change of package name and Maven coordinates is required, but in this case it is a good thing. It’s a good thing because you are saying explicitly that both Groovy versions can co-exist, which is what separate packages and separate Maven coordinates allow you to do. As an example of how this was done very well I think of Jackson 1.x to 2.x where they can co-exist and use different packages/Maven coordinates. And also in my mind, it’s acceptable as an upgrade scenario because I can use legacy libraries not upgraded to Groovy 3 by treating them as I would any other JVM class, with just the decision of having extra overhead by having both Groovy 2 and Groovy 3 in my classpath.
I suppose there would need to be some compatibility layer though because of things like Closure being an abstract class, presumably Groovy 3 would have its own Closure type so there would need to be a converter/wrapper to pass a G3 closure into a G2 class taking groovy.lang.Closure, unless groovy.lang.Closure is not going to change for G3. It sounds like worst-case these problems are solvable via a special Groovy 2-compat library that maybe excludes groovy.lang.Closure so that it defers to the G3 implementation.
Jason
From: Cédric Champeau [mailto:cedric.champeau@gmail.com]
Sent: Thursday, March 30, 2017 9:18 AM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward
And again, _we have no choice_. If we want Groovy to run as a module, we HAVE to break binary compatibility. There's absolutely no other way around. It's a thing. If we don't want to break it, Groovy will never run as a module. And if JDK 9 modules become legion, then Groovy would die.
2017-03-30 15:16 GMT+02:00 Cédric Champeau <ce...@gmail.com>>:
To me the idea would be to be able to run Groovy 2 and Groovy NG concurrently.
2017-03-30 15:12 GMT+02:00 Winnebeck, Jason <Ja...@windstream.com>>:
Can you explain the story around a library like org.codehaus.groovy.modules.ht<http://org.codehaus.groovy.modules.ht>tp-builder:http-builder, which is no longer really maintained? What happens to such a library when Groovy 3 comes out and we are using that library? Let's say there is no maintainer to update the sources to Groovy 3 and re-release.
Jason
-----Original Message-----
From: Russel Winder [mailto:russel@winder.org.uk<ma...@winder.org.uk>]
Sent: Thursday, March 30, 2017 3:54 AM
To: users@groovy.apache.org<ma...@groovy.apache.org>
Subject: Re: Maven coordinates going forward
On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> We have to keep in mind that there's a larger story here, which is
> supporting Groovy as a module. And this *will* require package changes
> and binary breaking changes. So I don't think the status quo is
> acceptable in the long run.
So why not make Groovy 3 the place to do this?
Whatever has been said about the Python situation, the core problem was not the breaking change, the problem was the lack of active management of the change.
Python is a source deployment language where JRE-based langauges are not. Thus JRE-based application have the classic COBOL, FORTRAN, and Fortran problem of "we've lost the source" (banks and governments are the usual suspects for this). I would exclude this situation from our thinking. Organisations in such a state (as some UK banks and the UK government is) should take it as an opportunity to revolutionise (which the UK government is, cf. the job adverts for COBOL, FORTRAN and Fortran knowledgeable people who also know Python, Java, etc.
Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the mix made for a much, much easier time. So initially moving from Python
2 to Python 3 was a manual task (bad management by the Python 3 folk), then came the six generation of upgrade tooling (a start). By dropping
2.6 and 3.3, we get the far nicer future upgrade tooling (which works nicely to create 2.7 and 3.4+ compatible code). The moral here is choose the versions being upgraded from and to, and then make some nice automation.
So if we assume a base of Groovy 2.4 and ignore all previous Groovys and the breaking change of 3.0 can we write some Groovy (obviously :-) scripts that automate source changes?
If the Python 2 → Python 3 breaking change had been more actively managed with earlier arrival of six and future, the problems would have been much less. Most of the vocal Python 2 Remainers have now made their codes run on both Python 2 and Python 3, and there are very few complaints about providing Python 3 only. OK so there are still a few people who say "we must support Python 2.5" but those people are few and far between and are, in the main, totally ignored. Python 4 will undoubtedly have breaking changes, but they will be better managed in terms of supporting multi-version working and automated (well at least
semi-automated) upgrading and mixed-version working. The lessons of six and future have been well learned.
So Groovy will have breaking changes, this is right and proper. Put in place tools for upgrading, and support multi-version working where possible and practical. Do not be swayed by calls for "we must change nothing, backward compatibility". They have a version of Groovy that works for them so they should not upgrade – ever again. That must not stop the rest of us from progressing.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200<tel:+44%2020%207585%202200> voip: sip:russel.winder@ekiga.net<ma...@ekiga.net>
41 Buckmaster Road m: +44 7770 465 077<tel:%2B44%207770%20465%20077> xmpp: russel@winder.org.uk<ma...@winder.org.uk>
London SW11 1EN, UK w: www.russel.org.uk<http://www.russel.org.uk> skype: russel_winder
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.
Re: Maven coordinates going forward
Posted by Cédric Champeau <ce...@gmail.com>.
And again, _we have no choice_. If we want Groovy to run as a module, we
HAVE to break binary compatibility. There's absolutely no other way around.
It's a thing. If we don't want to break it, Groovy will never run as a
module. And if JDK 9 modules become legion, then Groovy would die.
2017-03-30 15:16 GMT+02:00 Cédric Champeau <ce...@gmail.com>:
> To me the idea would be to be able to run Groovy 2 and Groovy NG
> concurrently.
>
> 2017-03-30 15:12 GMT+02:00 Winnebeck, Jason <Jason.Winnebeck@windstream.
> com>:
>
>> Can you explain the story around a library like
>> org.codehaus.groovy.modules.http-builder:http-builder, which is no
>> longer really maintained? What happens to such a library when Groovy 3
>> comes out and we are using that library? Let's say there is no maintainer
>> to update the sources to Groovy 3 and re-release.
>>
>> Jason
>>
>> -----Original Message-----
>> From: Russel Winder [mailto:russel@winder.org.uk]
>> Sent: Thursday, March 30, 2017 3:54 AM
>> To: users@groovy.apache.org
>> Subject: Re: Maven coordinates going forward
>>
>> On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
>> > We have to keep in mind that there's a larger story here, which is
>> > supporting Groovy as a module. And this *will* require package changes
>> > and binary breaking changes. So I don't think the status quo is
>> > acceptable in the long run.
>>
>> So why not make Groovy 3 the place to do this?
>>
>> Whatever has been said about the Python situation, the core problem was
>> not the breaking change, the problem was the lack of active management of
>> the change.
>>
>> Python is a source deployment language where JRE-based langauges are not.
>> Thus JRE-based application have the classic COBOL, FORTRAN, and Fortran
>> problem of "we've lost the source" (banks and governments are the usual
>> suspects for this). I would exclude this situation from our thinking.
>> Organisations in such a state (as some UK banks and the UK government is)
>> should take it as an opportunity to revolutionise (which the UK government
>> is, cf. the job adverts for COBOL, FORTRAN and Fortran knowledgeable people
>> who also know Python, Java, etc.
>>
>> Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
>> 3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in
>> the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the mix
>> made for a much, much easier time. So initially moving from Python
>> 2 to Python 3 was a manual task (bad management by the Python 3 folk),
>> then came the six generation of upgrade tooling (a start). By dropping
>> 2.6 and 3.3, we get the far nicer future upgrade tooling (which works
>> nicely to create 2.7 and 3.4+ compatible code). The moral here is choose
>> the versions being upgraded from and to, and then make some nice automation.
>>
>> So if we assume a base of Groovy 2.4 and ignore all previous Groovys and
>> the breaking change of 3.0 can we write some Groovy (obviously :-) scripts
>> that automate source changes?
>>
>> If the Python 2 → Python 3 breaking change had been more actively managed
>> with earlier arrival of six and future, the problems would have been much
>> less. Most of the vocal Python 2 Remainers have now made their codes run on
>> both Python 2 and Python 3, and there are very few complaints about
>> providing Python 3 only. OK so there are still a few people who say "we
>> must support Python 2.5" but those people are few and far between and are,
>> in the main, totally ignored. Python 4 will undoubtedly have breaking
>> changes, but they will be better managed in terms of supporting
>> multi-version working and automated (well at least
>> semi-automated) upgrading and mixed-version working. The lessons of six
>> and future have been well learned.
>>
>> So Groovy will have breaking changes, this is right and proper. Put in
>> place tools for upgrading, and support multi-version working where possible
>> and practical. Do not be swayed by calls for "we must change nothing,
>> backward compatibility". They have a version of Groovy that works for them
>> so they should not upgrade – ever again. That must not stop the rest of us
>> from progressing.
>>
>> --
>> Russel.
>> ============================================================
>> =================
>> Dr Russel Winder t: +44 20 7585 2200 <+44%2020%207585%202200>
>> voip: sip:russel.winder@ekiga.net
>> 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
>> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>>
>> 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.
>>
>
>
Re: Maven coordinates going forward
Posted by Cédric Champeau <ce...@gmail.com>.
To me the idea would be to be able to run Groovy 2 and Groovy NG
concurrently.
2017-03-30 15:12 GMT+02:00 Winnebeck, Jason <Ja...@windstream.com>
:
> Can you explain the story around a library like
> org.codehaus.groovy.modules.http-builder:http-builder, which is no longer
> really maintained? What happens to such a library when Groovy 3 comes out
> and we are using that library? Let's say there is no maintainer to update
> the sources to Groovy 3 and re-release.
>
> Jason
>
> -----Original Message-----
> From: Russel Winder [mailto:russel@winder.org.uk]
> Sent: Thursday, March 30, 2017 3:54 AM
> To: users@groovy.apache.org
> Subject: Re: Maven coordinates going forward
>
> On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> > We have to keep in mind that there's a larger story here, which is
> > supporting Groovy as a module. And this *will* require package changes
> > and binary breaking changes. So I don't think the status quo is
> > acceptable in the long run.
>
> So why not make Groovy 3 the place to do this?
>
> Whatever has been said about the Python situation, the core problem was
> not the breaking change, the problem was the lack of active management of
> the change.
>
> Python is a source deployment language where JRE-based langauges are not.
> Thus JRE-based application have the classic COBOL, FORTRAN, and Fortran
> problem of "we've lost the source" (banks and governments are the usual
> suspects for this). I would exclude this situation from our thinking.
> Organisations in such a state (as some UK banks and the UK government is)
> should take it as an opportunity to revolutionise (which the UK government
> is, cf. the job adverts for COBOL, FORTRAN and Fortran knowledgeable people
> who also know Python, Java, etc.
>
> Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
> 3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in
> the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the mix
> made for a much, much easier time. So initially moving from Python
> 2 to Python 3 was a manual task (bad management by the Python 3 folk),
> then came the six generation of upgrade tooling (a start). By dropping
> 2.6 and 3.3, we get the far nicer future upgrade tooling (which works
> nicely to create 2.7 and 3.4+ compatible code). The moral here is choose
> the versions being upgraded from and to, and then make some nice automation.
>
> So if we assume a base of Groovy 2.4 and ignore all previous Groovys and
> the breaking change of 3.0 can we write some Groovy (obviously :-) scripts
> that automate source changes?
>
> If the Python 2 → Python 3 breaking change had been more actively managed
> with earlier arrival of six and future, the problems would have been much
> less. Most of the vocal Python 2 Remainers have now made their codes run on
> both Python 2 and Python 3, and there are very few complaints about
> providing Python 3 only. OK so there are still a few people who say "we
> must support Python 2.5" but those people are few and far between and are,
> in the main, totally ignored. Python 4 will undoubtedly have breaking
> changes, but they will be better managed in terms of supporting
> multi-version working and automated (well at least
> semi-automated) upgrading and mixed-version working. The lessons of six
> and future have been well learned.
>
> So Groovy will have breaking changes, this is right and proper. Put in
> place tools for upgrading, and support multi-version working where possible
> and practical. Do not be swayed by calls for "we must change nothing,
> backward compatibility". They have a version of Groovy that works for them
> so they should not upgrade – ever again. That must not stop the rest of us
> from progressing.
>
> --
> Russel.
> ============================================================
> =================
> Dr Russel Winder t: +44 20 7585 2200 voip:
> sip:russel.winder@ekiga.net
> 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>
> 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.
>
Re: Maven coordinates going forward
Posted by Jochen Theodorou <bl...@gmx.org>.
On 30.03.2017 20:58, Miro Bezjak wrote:
[...]
> So if we are talking about JDK9 modules them I'm with Jason and the rest
> of you. Sure, breaking backwards compatibility is a sensible thing to do
> in that case.
and I wish I would know how to solve all the problems. Right now it
seems like Groovy will run in classpath mode better than it will ever as
a module. And I wished we could just stay like that. But once a module
wants to depend on Groovy we are in trouble.
[...]
> If my memory serves me right didn't gradle also require groovy1 for
> plugin development a long time after release of groovy2 due to fear of
> backwards incompatibilities? I believe Jochen calmed their concerns.
I showed them ways to get around the incompatibilities. But yes, groovy1
was required for quite a long time.
> And yet again - if the reasons are right - break backwards compatibility.
>
> So now that we have changed the topic, may I ask: is JDK9 modules
> compatibility coming in groovy3?
For Groovy in classpath mode there is one more change to do by using
JDK9 specific code, which is to allow to call default methods on proxies.
For Groovy as named module... there are several things to do (writing
down in no order)
* we have to resolve the circular dependency between groovy-test and
groovy-core
* we have duplicated packages in some of our current modules
* we have to decide if we want to go with the same modules at all
* we may have to resort to a fat module that includes everything
* if we want groovy3 and groovy2 as separate modules, they cannot share
exact package names. That has a very big impact on the groovy.lang and
groovy.util package for example.
* if we do no compatibility module for groovy2 (only a jar), then it
means the Groovy 3 module cannot call code from the groovy 2 jar easily.
Not with pure Java at least.
* our joint compilation is untested for modules
* getting gradle to run under JDK9 is quite painful atm. I have yet to
check if using JAVA_OPTS like in
https://github.com/gradle/gradle/issues/719 at the very end will work (I
always tried GRADLE_OPTS and the jvmargs)
* we will have to get accessibility right, which means we have to rework
completely how we build a meta class (and how I planed to build one for
MOP2). This also means we will not be able to call private methods of
Java classes anymore, as the modules system is in the way for this. This
will affect testing and begs the question, if we should do it like we
did in the past for Groovy code still. We actually have this problem in
classpath mode as well. It can be solved by command line switches or by
transforming the modules on load... none of that is a good solution in
my opinion.
* we will have jdk9 specific code and we will require jdk9 for the
build. Thus we will very likely require a multi release jar
* @Grab's usage of the system class loader is no option in JDK9 anymore,
we will have to deprecate things here.
there is most likely a lot more
> Also, I like the C�deric's idea of corunnable groovy 2 & 3. Anybody else
> entertaining that idea? Is it doable considering the shared groovy.*
> packages?
well... depends... if Groovy 3 and 2-compat are in the same module, yes.
Otherwise Groovy 3 has to use a different package. Or we say Groovy 2 is
not available as module and has to be used in classpath mode. Then this
is also possible. to run Groovy 3 and Groovy 2 in classpath mode at the
same time, we still have the problem of overlapping class names in the
same package... GroovyObject for example is very likely to go away,
making most classes in groovy.lang different.
bye Jochen
RE: Maven coordinates going forward
Posted by Miro Bezjak <be...@gmail.com>.
I feel we have changed topics. OP's starting question was maven
coordinates. This naturally led to the question of package names. Now we
ended up on the topic of JDK9 modules. They are related to maven
coordinates and package names but my previous comment didn't intend to
address the modules.
So if we are talking about JDK9 modules them I'm with Jason and the rest of
you. Sure, breaking backwards compatibility is a sensible thing to do in
that case.
On the other hand, if we are only discussing whether maven coordinates or
package names should change for the sake of aesthetics, they I would ask
you to reconsider as I do not feel the pros outweigh the cons - trading
aesthetic beauty for new techical problems. I feel I'm in the same position
as Jason with maintaining and continuously adding new features to 10 year
old projects whose expected lifetime is at least that much more. I can also
tell you that things aren't so black and white as some are suggesting with
never upgrading. Those projects are not allowed _not_ to run on JDK8 or
JDK9 or JDK10 (when the time comes). If my memory serves me right didn't
gradle also require groovy1 for plugin development a long time after
release of groovy2 due to fear of backwards incompatibilities? I believe
Jochen calmed their concers. Somebody correct me if I'm wrong.
And yet again - if the reasons are right - break backwards compatibility.
So now that we have changed the topic, may I ask: is JDK9 modules
compatibility coming in groovy3?
Also, I like the Céderic's idea of corunnable groovy 2 & 3. Anybody else
entertaining that idea? Is it doable considering the shared groovy.*
packages?
On Mar 30, 2017 18:00, "Winnebeck, Jason" <Ja...@windstream.com>
wrote:
I think others have characterized it differently, but in my mind that is
the “Python” scenario. Groovy 3 comes out and immediately makes all
existing code incompatible. Without an incremental upgrade path, users,
especially enterprise users, are faced with a rewrite and have no choice
but to basically stay on Groovy 2 forever. With so many users staying on
2.x, it will fragment the community and the limited support that Groovy
receives. While http-builder-ng is a good example of an updated project,
even for that project’s documentation says it’s not backwards compatible so
it’s not a drop-in replacement either. At least with Java library usage
being very popular, there will be a lot of libraries we can still use in
G3. If it’s still possible for G2 to co-exist, then at least I can update
my own code to G3 while I wait (perhaps forever) for libraries to update to
G2, and I can deploy upgrades incrementally. An atomic rewrite all
functionality from scratch is never a valid scenario for 10+ year old
projects.
Jason
*From:* Guillaume Laforge [mailto:glaforge@gmail.com]
*Sent:* Thursday, March 30, 2017 10:21 AM
*To:* users@groovy.apache.org
*Subject:* Re: Maven coordinates going forward
And there's also groovy-wslite.
Also we can't wait for all possible abandonned project to update to a newer
version of Groovy.
Those projects depending on libraries using an old version of Groovy should
probably just not upgrade at all.
On Thu, Mar 30, 2017 at 4:09 PM, David Clark <pl...@gmail.com>
wrote:
The original http-builder is unmaintained. However http-builder-ng is
maintained:
https://http-builder-ng.github.io/http-builder-ng/
We already had to change the maven coordinates because of Maven/Sonatype
restrictions, so things should be fine provided people upgrade to the newer
library.
On Thu, Mar 30, 2017 at 8:12 AM, Winnebeck, Jason <
Jason.Winnebeck@windstream.com> wrote:
Can you explain the story around a library like
org.codehaus.groovy.modules.http-builder:http-builder, which is no longer
really maintained? What happens to such a library when Groovy 3 comes out
and we are using that library? Let's say there is no maintainer to update
the sources to Groovy 3 and re-release.
Jason
-----Original Message-----
From: Russel Winder [mailto:russel@winder.org.uk]
Sent: Thursday, March 30, 2017 3:54 AM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward
On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> We have to keep in mind that there's a larger story here, which is
> supporting Groovy as a module. And this *will* require package changes
> and binary breaking changes. So I don't think the status quo is
> acceptable in the long run.
So why not make Groovy 3 the place to do this?
Whatever has been said about the Python situation, the core problem was not
the breaking change, the problem was the lack of active management of the
change.
Python is a source deployment language where JRE-based langauges are not.
Thus JRE-based application have the classic COBOL, FORTRAN, and Fortran
problem of "we've lost the source" (banks and governments are the usual
suspects for this). I would exclude this situation from our thinking.
Organisations in such a state (as some UK banks and the UK government is)
should take it as an opportunity to revolutionise (which the UK government
is, cf. the job adverts for COBOL, FORTRAN and Fortran knowledgeable people
who also know Python, Java, etc.
Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in the
mix made for a very hard time. Allowing only 2.7 and 3.4+ in the mix made
for a much, much easier time. So initially moving from Python
2 to Python 3 was a manual task (bad management by the Python 3 folk), then
came the six generation of upgrade tooling (a start). By dropping
2.6 and 3.3, we get the far nicer future upgrade tooling (which works
nicely to create 2.7 and 3.4+ compatible code). The moral here is choose
the versions being upgraded from and to, and then make some nice automation.
So if we assume a base of Groovy 2.4 and ignore all previous Groovys and
the breaking change of 3.0 can we write some Groovy (obviously :-) scripts
that automate source changes?
If the Python 2 → Python 3 breaking change had been more actively managed
with earlier arrival of six and future, the problems would have been much
less. Most of the vocal Python 2 Remainers have now made their codes run on
both Python 2 and Python 3, and there are very few complaints about
providing Python 3 only. OK so there are still a few people who say "we
must support Python 2.5" but those people are few and far between and are,
in the main, totally ignored. Python 4 will undoubtedly have breaking
changes, but they will be better managed in terms of supporting
multi-version working and automated (well at least
semi-automated) upgrading and mixed-version working. The lessons of six and
future have been well learned.
So Groovy will have breaking changes, this is right and proper. Put in
place tools for upgrading, and support multi-version working where possible
and practical. Do not be swayed by calls for "we must change nothing,
backward compatibility". They have a version of Groovy that works for them
so they should not upgrade – ever again. That must not stop the rest of us
from progressing.
--
Russel.
============================================================
=================
Dr Russel Winder t: +44 20 7585 2200 <+44%2020%207585%202200> voip:
sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
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.
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
RE: Maven coordinates going forward
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
I think others have characterized it differently, but in my mind that is the “Python” scenario. Groovy 3 comes out and immediately makes all existing code incompatible. Without an incremental upgrade path, users, especially enterprise users, are faced with a rewrite and have no choice but to basically stay on Groovy 2 forever. With so many users staying on 2.x, it will fragment the community and the limited support that Groovy receives. While http-builder-ng is a good example of an updated project, even for that project’s documentation says it’s not backwards compatible so it’s not a drop-in replacement either. At least with Java library usage being very popular, there will be a lot of libraries we can still use in G3. If it’s still possible for G2 to co-exist, then at least I can update my own code to G3 while I wait (perhaps forever) for libraries to update to G2, and I can deploy upgrades incrementally. An atomic rewrite all functionality from scratch is never a valid scenario for 10+ year old projects.
Jason
From: Guillaume Laforge [mailto:glaforge@gmail.com]
Sent: Thursday, March 30, 2017 10:21 AM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward
And there's also groovy-wslite.
Also we can't wait for all possible abandonned project to update to a newer version of Groovy.
Those projects depending on libraries using an old version of Groovy should probably just not upgrade at all.
On Thu, Mar 30, 2017 at 4:09 PM, David Clark <pl...@gmail.com>> wrote:
The original http-builder is unmaintained. However http-builder-ng is maintained:
https://http-builder-ng.github.io/http-builder-ng/
We already had to change the maven coordinates because of Maven/Sonatype restrictions, so things should be fine provided people upgrade to the newer library.
On Thu, Mar 30, 2017 at 8:12 AM, Winnebeck, Jason <Ja...@windstream.com>> wrote:
Can you explain the story around a library like org.codehaus.groovy.modules.ht<http://org.codehaus.groovy.modules.ht>tp-builder:http-builder, which is no longer really maintained? What happens to such a library when Groovy 3 comes out and we are using that library? Let's say there is no maintainer to update the sources to Groovy 3 and re-release.
Jason
-----Original Message-----
From: Russel Winder [mailto:russel@winder.org.uk<ma...@winder.org.uk>]
Sent: Thursday, March 30, 2017 3:54 AM
To: users@groovy.apache.org<ma...@groovy.apache.org>
Subject: Re: Maven coordinates going forward
On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> We have to keep in mind that there's a larger story here, which is
> supporting Groovy as a module. And this *will* require package changes
> and binary breaking changes. So I don't think the status quo is
> acceptable in the long run.
So why not make Groovy 3 the place to do this?
Whatever has been said about the Python situation, the core problem was not the breaking change, the problem was the lack of active management of the change.
Python is a source deployment language where JRE-based langauges are not. Thus JRE-based application have the classic COBOL, FORTRAN, and Fortran problem of "we've lost the source" (banks and governments are the usual suspects for this). I would exclude this situation from our thinking. Organisations in such a state (as some UK banks and the UK government is) should take it as an opportunity to revolutionise (which the UK government is, cf. the job adverts for COBOL, FORTRAN and Fortran knowledgeable people who also know Python, Java, etc.
Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the mix made for a much, much easier time. So initially moving from Python
2 to Python 3 was a manual task (bad management by the Python 3 folk), then came the six generation of upgrade tooling (a start). By dropping
2.6 and 3.3, we get the far nicer future upgrade tooling (which works nicely to create 2.7 and 3.4+ compatible code). The moral here is choose the versions being upgraded from and to, and then make some nice automation.
So if we assume a base of Groovy 2.4 and ignore all previous Groovys and the breaking change of 3.0 can we write some Groovy (obviously :-) scripts that automate source changes?
If the Python 2 → Python 3 breaking change had been more actively managed with earlier arrival of six and future, the problems would have been much less. Most of the vocal Python 2 Remainers have now made their codes run on both Python 2 and Python 3, and there are very few complaints about providing Python 3 only. OK so there are still a few people who say "we must support Python 2.5" but those people are few and far between and are, in the main, totally ignored. Python 4 will undoubtedly have breaking changes, but they will be better managed in terms of supporting multi-version working and automated (well at least
semi-automated) upgrading and mixed-version working. The lessons of six and future have been well learned.
So Groovy will have breaking changes, this is right and proper. Put in place tools for upgrading, and support multi-version working where possible and practical. Do not be swayed by calls for "we must change nothing, backward compatibility". They have a version of Groovy that works for them so they should not upgrade – ever again. That must not stop the rest of us from progressing.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200<tel:+44%2020%207585%202200> voip: sip:russel.winder@ekiga.net<ma...@ekiga.net>
41 Buckmaster Road m: +44 7770 465 077<tel:%2B44%207770%20465%20077> xmpp: russel@winder.org.uk<ma...@winder.org.uk>
London SW11 1EN, UK w: www.russel.org.uk<http://www.russel.org.uk> skype: russel_winder
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.
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Maven coordinates going forward
Posted by Guillaume Laforge <gl...@gmail.com>.
And there's also groovy-wslite.
Also we can't wait for all possible abandonned project to update to a newer
version of Groovy.
Those projects depending on libraries using an old version of Groovy should
probably just not upgrade at all.
On Thu, Mar 30, 2017 at 4:09 PM, David Clark <pl...@gmail.com>
wrote:
> The original http-builder is unmaintained. However http-builder-ng is
> maintained:
>
> https://http-builder-ng.github.io/http-builder-ng/
>
> We already had to change the maven coordinates because of Maven/Sonatype
> restrictions, so things should be fine provided people upgrade to the newer
> library.
>
> On Thu, Mar 30, 2017 at 8:12 AM, Winnebeck, Jason <
> Jason.Winnebeck@windstream.com> wrote:
>
>> Can you explain the story around a library like
>> org.codehaus.groovy.modules.http-builder:http-builder, which is no
>> longer really maintained? What happens to such a library when Groovy 3
>> comes out and we are using that library? Let's say there is no maintainer
>> to update the sources to Groovy 3 and re-release.
>>
>> Jason
>>
>> -----Original Message-----
>> From: Russel Winder [mailto:russel@winder.org.uk]
>> Sent: Thursday, March 30, 2017 3:54 AM
>> To: users@groovy.apache.org
>> Subject: Re: Maven coordinates going forward
>>
>> On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
>> > We have to keep in mind that there's a larger story here, which is
>> > supporting Groovy as a module. And this *will* require package changes
>> > and binary breaking changes. So I don't think the status quo is
>> > acceptable in the long run.
>>
>> So why not make Groovy 3 the place to do this?
>>
>> Whatever has been said about the Python situation, the core problem was
>> not the breaking change, the problem was the lack of active management of
>> the change.
>>
>> Python is a source deployment language where JRE-based langauges are not.
>> Thus JRE-based application have the classic COBOL, FORTRAN, and Fortran
>> problem of "we've lost the source" (banks and governments are the usual
>> suspects for this). I would exclude this situation from our thinking.
>> Organisations in such a state (as some UK banks and the UK government is)
>> should take it as an opportunity to revolutionise (which the UK government
>> is, cf. the job adverts for COBOL, FORTRAN and Fortran knowledgeable people
>> who also know Python, Java, etc.
>>
>> Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
>> 3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in
>> the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the mix
>> made for a much, much easier time. So initially moving from Python
>> 2 to Python 3 was a manual task (bad management by the Python 3 folk),
>> then came the six generation of upgrade tooling (a start). By dropping
>> 2.6 and 3.3, we get the far nicer future upgrade tooling (which works
>> nicely to create 2.7 and 3.4+ compatible code). The moral here is choose
>> the versions being upgraded from and to, and then make some nice automation.
>>
>> So if we assume a base of Groovy 2.4 and ignore all previous Groovys and
>> the breaking change of 3.0 can we write some Groovy (obviously :-) scripts
>> that automate source changes?
>>
>> If the Python 2 → Python 3 breaking change had been more actively managed
>> with earlier arrival of six and future, the problems would have been much
>> less. Most of the vocal Python 2 Remainers have now made their codes run on
>> both Python 2 and Python 3, and there are very few complaints about
>> providing Python 3 only. OK so there are still a few people who say "we
>> must support Python 2.5" but those people are few and far between and are,
>> in the main, totally ignored. Python 4 will undoubtedly have breaking
>> changes, but they will be better managed in terms of supporting
>> multi-version working and automated (well at least
>> semi-automated) upgrading and mixed-version working. The lessons of six
>> and future have been well learned.
>>
>> So Groovy will have breaking changes, this is right and proper. Put in
>> place tools for upgrading, and support multi-version working where possible
>> and practical. Do not be swayed by calls for "we must change nothing,
>> backward compatibility". They have a version of Groovy that works for them
>> so they should not upgrade – ever again. That must not stop the rest of us
>> from progressing.
>>
>> --
>> Russel.
>> ============================================================
>> =================
>> Dr Russel Winder t: +44 20 7585 2200 <+44%2020%207585%202200>
>> voip: sip:russel.winder@ekiga.net
>> 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
>> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>>
>> 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.
>>
>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Maven coordinates going forward
Posted by David Clark <pl...@gmail.com>.
The original http-builder is unmaintained. However http-builder-ng is
maintained:
https://http-builder-ng.github.io/http-builder-ng/
We already had to change the maven coordinates because of Maven/Sonatype
restrictions, so things should be fine provided people upgrade to the newer
library.
On Thu, Mar 30, 2017 at 8:12 AM, Winnebeck, Jason <
Jason.Winnebeck@windstream.com> wrote:
> Can you explain the story around a library like
> org.codehaus.groovy.modules.http-builder:http-builder, which is no longer
> really maintained? What happens to such a library when Groovy 3 comes out
> and we are using that library? Let's say there is no maintainer to update
> the sources to Groovy 3 and re-release.
>
> Jason
>
> -----Original Message-----
> From: Russel Winder [mailto:russel@winder.org.uk]
> Sent: Thursday, March 30, 2017 3:54 AM
> To: users@groovy.apache.org
> Subject: Re: Maven coordinates going forward
>
> On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> > We have to keep in mind that there's a larger story here, which is
> > supporting Groovy as a module. And this *will* require package changes
> > and binary breaking changes. So I don't think the status quo is
> > acceptable in the long run.
>
> So why not make Groovy 3 the place to do this?
>
> Whatever has been said about the Python situation, the core problem was
> not the breaking change, the problem was the lack of active management of
> the change.
>
> Python is a source deployment language where JRE-based langauges are not.
> Thus JRE-based application have the classic COBOL, FORTRAN, and Fortran
> problem of "we've lost the source" (banks and governments are the usual
> suspects for this). I would exclude this situation from our thinking.
> Organisations in such a state (as some UK banks and the UK government is)
> should take it as an opportunity to revolutionise (which the UK government
> is, cf. the job adverts for COBOL, FORTRAN and Fortran knowledgeable people
> who also know Python, Java, etc.
>
> Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
> 3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in
> the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the mix
> made for a much, much easier time. So initially moving from Python
> 2 to Python 3 was a manual task (bad management by the Python 3 folk),
> then came the six generation of upgrade tooling (a start). By dropping
> 2.6 and 3.3, we get the far nicer future upgrade tooling (which works
> nicely to create 2.7 and 3.4+ compatible code). The moral here is choose
> the versions being upgraded from and to, and then make some nice automation.
>
> So if we assume a base of Groovy 2.4 and ignore all previous Groovys and
> the breaking change of 3.0 can we write some Groovy (obviously :-) scripts
> that automate source changes?
>
> If the Python 2 → Python 3 breaking change had been more actively managed
> with earlier arrival of six and future, the problems would have been much
> less. Most of the vocal Python 2 Remainers have now made their codes run on
> both Python 2 and Python 3, and there are very few complaints about
> providing Python 3 only. OK so there are still a few people who say "we
> must support Python 2.5" but those people are few and far between and are,
> in the main, totally ignored. Python 4 will undoubtedly have breaking
> changes, but they will be better managed in terms of supporting
> multi-version working and automated (well at least
> semi-automated) upgrading and mixed-version working. The lessons of six
> and future have been well learned.
>
> So Groovy will have breaking changes, this is right and proper. Put in
> place tools for upgrading, and support multi-version working where possible
> and practical. Do not be swayed by calls for "we must change nothing,
> backward compatibility". They have a version of Groovy that works for them
> so they should not upgrade – ever again. That must not stop the rest of us
> from progressing.
>
> --
> Russel.
> ============================================================
> =================
> Dr Russel Winder t: +44 20 7585 2200 voip:
> sip:russel.winder@ekiga.net
> 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>
> 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.
>
RE: Maven coordinates going forward
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
Can you explain the story around a library like org.codehaus.groovy.modules.http-builder:http-builder, which is no longer really maintained? What happens to such a library when Groovy 3 comes out and we are using that library? Let's say there is no maintainer to update the sources to Groovy 3 and re-release.
Jason
-----Original Message-----
From: Russel Winder [mailto:russel@winder.org.uk]
Sent: Thursday, March 30, 2017 3:54 AM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward
On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> We have to keep in mind that there's a larger story here, which is
> supporting Groovy as a module. And this *will* require package changes
> and binary breaking changes. So I don't think the status quo is
> acceptable in the long run.
So why not make Groovy 3 the place to do this?
Whatever has been said about the Python situation, the core problem was not the breaking change, the problem was the lack of active management of the change.
Python is a source deployment language where JRE-based langauges are not. Thus JRE-based application have the classic COBOL, FORTRAN, and Fortran problem of "we've lost the source" (banks and governments are the usual suspects for this). I would exclude this situation from our thinking. Organisations in such a state (as some UK banks and the UK government is) should take it as an opportunity to revolutionise (which the UK government is, cf. the job adverts for COBOL, FORTRAN and Fortran knowledgeable people who also know Python, Java, etc.
Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the mix made for a much, much easier time. So initially moving from Python
2 to Python 3 was a manual task (bad management by the Python 3 folk), then came the six generation of upgrade tooling (a start). By dropping
2.6 and 3.3, we get the far nicer future upgrade tooling (which works nicely to create 2.7 and 3.4+ compatible code). The moral here is choose the versions being upgraded from and to, and then make some nice automation.
So if we assume a base of Groovy 2.4 and ignore all previous Groovys and the breaking change of 3.0 can we write some Groovy (obviously :-) scripts that automate source changes?
If the Python 2 → Python 3 breaking change had been more actively managed with earlier arrival of six and future, the problems would have been much less. Most of the vocal Python 2 Remainers have now made their codes run on both Python 2 and Python 3, and there are very few complaints about providing Python 3 only. OK so there are still a few people who say "we must support Python 2.5" but those people are few and far between and are, in the main, totally ignored. Python 4 will undoubtedly have breaking changes, but they will be better managed in terms of supporting multi-version working and automated (well at least
semi-automated) upgrading and mixed-version working. The lessons of six and future have been well learned.
So Groovy will have breaking changes, this is right and proper. Put in place tools for upgrading, and support multi-version working where possible and practical. Do not be swayed by calls for "we must change nothing, backward compatibility". They have a version of Groovy that works for them so they should not upgrade – ever again. That must not stop the rest of us from progressing.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
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.
Re: Maven coordinates going forward
Posted by Russel Winder <ru...@winder.org.uk>.
On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> We have to keep in mind that there's a larger story here, which is
> supporting Groovy as a module. And this *will* require package
> changes and
> binary breaking changes. So I don't think the status quo is
> acceptable in
> the long run.
So why not make Groovy 3 the place to do this?
Whatever has been said about the Python situation, the core problem was
not the breaking change, the problem was the lack of active management
of the change.
Python is a source deployment language where JRE-based langauges are
not. Thus JRE-based application have the classic COBOL, FORTRAN, and
Fortran problem of "we've lost the source" (banks and governments are
the usual suspects for this). I would exclude this situation from our
thinking. Organisations in such a state (as some UK banks and the UK
government is) should take it as an opportunity to revolutionise (which
the UK government is, cf. the job adverts for COBOL, FORTRAN and
Fortran knowledgeable people who also know Python, Java, etc.
Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in
the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the
mix made for a much, much easier time. So initially moving from Python
2 to Python 3 was a manual task (bad management by the Python 3 folk),
then came the six generation of upgrade tooling (a start). By dropping
2.6 and 3.3, we get the far nicer future upgrade tooling (which works
nicely to create 2.7 and 3.4+ compatible code). The moral here is
choose the versions being upgraded from and to, and then make some nice
automation.
So if we assume a base of Groovy 2.4 and ignore all previous Groovys
and the breaking change of 3.0 can we write some Groovy (obviously :-)
scripts that automate source changes?
If the Python 2 → Python 3 breaking change had been more actively
managed with earlier arrival of six and future, the problems would have
been much less. Most of the vocal Python 2 Remainers have now made
their codes run on both Python 2 and Python 3, and there are very few
complaints about providing Python 3 only. OK so there are still a few
people who say "we must support Python 2.5" but those people are few
and far between and are, in the main, totally ignored. Python 4 will
undoubtedly have breaking changes, but they will be better managed in
terms of supporting multi-version working and automated (well at least
semi-automated) upgrading and mixed-version working. The lessons of six
and future have been well learned.
So Groovy will have breaking changes, this is right and proper. Put in
place tools for upgrading, and support multi-version working where
possible and practical. Do not be swayed by calls for "we must change
nothing, backward compatibility". They have a version of Groovy that
works for them so they should not upgrade – ever again. That must not
stop the rest of us from progressing.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Maven coordinates going forward
Posted by Cédric Champeau <ce...@gmail.com>.
We have to keep in mind that there's a larger story here, which is
supporting Groovy as a module. And this *will* require package changes and
binary breaking changes. So I don't think the status quo is acceptable in
the long run.
2017-03-30 9:22 GMT+02:00 Russel Winder <ru...@winder.org.uk>:
> On Wed, 2017-03-29 at 15:42 -0400, Keith Suderman wrote:
> > 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.
>
> If "if it ain't broke don't fix it" was a really good idea, we'd still
> be hunter gatherers with no cities, cars, computers, etc.
>
> Given the arguments so far, the best position as I see it is:
>
> 1. Change the Maven group to org.apache.groovy with Groovy 3, leave as
> is for Groovy 2
>
> 2. Leave the package structure as is for Groovy 2, but in Groovy 3 put
> all new classes in org.apache.groovy rather than org.codehaus.groovy.
> This will require more imports than desirable but as the code evolves
> IDEA will indicate when imports become redundant.
>
> 3. At leisure in Groovy 3 add a redirect layer to allow classes to
> transition from org.codehaus.groovy to org.apache.groovy.
>
> 4. In Groovy 4 have all the classes not in groovy or groovyx in
> org.apache.groovy with a bridging module for the org.codehaus.groovy
> namespace for legacy application code. If JRE9 is all it is cracked up
> to be, this should be doable.
>
> > Besides, think of using org.codehaus.groovy as paying homage to
> > Groovy's long and storied history. ;-)
>
> Whilst interesting for sentimental reasons, not a good rationale
> looking forward.
>
> --
> Russel.
> ============================================================
> =================
> Dr Russel Winder t: +44 20 7585 2200 voip:
> sip:russel.winder@ekiga.net
> 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>
Re: Maven coordinates going forward
Posted by Russel Winder <ru...@winder.org.uk>.
On Wed, 2017-03-29 at 15:42 -0400, Keith Suderman wrote:
> 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.
If "if it ain't broke don't fix it" was a really good idea, we'd still
be hunter gatherers with no cities, cars, computers, etc.
Given the arguments so far, the best position as I see it is:
1. Change the Maven group to org.apache.groovy with Groovy 3, leave as
is for Groovy 2
2. Leave the package structure as is for Groovy 2, but in Groovy 3 put
all new classes in org.apache.groovy rather than org.codehaus.groovy.
This will require more imports than desirable but as the code evolves
IDEA will indicate when imports become redundant.
3. At leisure in Groovy 3 add a redirect layer to allow classes to
transition from org.codehaus.groovy to org.apache.groovy.
4. In Groovy 4 have all the classes not in groovy or groovyx in
org.apache.groovy with a bridging module for the org.codehaus.groovy
namespace for legacy application code. If JRE9 is all it is cracked up
to be, this should be doable.
> Besides, think of using org.codehaus.groovy as paying homage to
> Groovy's long and storied history. ;-)
Whilst interesting for sentimental reasons, not a good rationale
looking forward.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Maven coordinates going forward
Posted by Keith Suderman <su...@anc.org>.
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 <be...@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 <ma...@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 <ma...@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 <ma...@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
Re: Maven coordinates going forward
Posted by Miro Bezjak <be...@gmail.com>.
-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" <ce...@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 <ke...@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 <bl...@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
>>
>
>
Re: Maven coordinates going forward
Posted by Cédric Champeau <ce...@gmail.com>.
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 <ke...@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 <bl...@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
>>
>
>
Re: Maven coordinates going forward
Posted by Keegan Witt <ke...@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 <bl...@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
>
Re: Maven coordinates going forward
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Re: Maven coordinates going forward
Posted by Wilson MacGyver <wm...@gmail.com>.
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.
On Mon, Mar 27, 2017 at 3:28 PM, Guillaume Laforge <gl...@gmail.com>
wrote:
> Just an added note on the topic of potential package name changes.
>
> In the past, we've had to move some AST transformations from groovy.lang
> to groovy.transforms, and we managed to make that transition without too
> much harm.
> Similarly to what we did on that occasion, we could offer a compatibility
> module that would just delegate classes from old packages to classes of the
> new packages. And once you've had the time to make the migration, you'd
> just remove the compatibility module.
> We could also have more complex solutions involving bytecode rewriting.
>
> But at some point, it'll really look ridiculous to still have org.codehaus
> here and there, although codehaus' already been long gone already.
>
> So package name changes are not all black'n white.
> There are possible shades of gray :-)
>
> Guillaume
>
>
> On Mon, Mar 27, 2017 at 9:03 PM, Winnebeck, Jason <
> Jason.Winnebeck@windstream.com> wrote:
>
>> 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 search.maven.org)
>> 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.
>>
>>
>>
>> Jason
>>
>>
>>
>> *From:* Keith Suderman [mailto:suderman@anc.org]
>> *Sent:* Monday, March 27, 2017 2:49 PM
>> *To:* users@groovy.apache.org
>> *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.
>>
>>
>>
>> Keith
>>
>>
>>
>>
>>
>> On Mar 27, 2017, at 2:20 PM, Jochen Theodorou <bl...@gmx.org> wrote:
>>
>>
>>
>> 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
>> version.
>>
>> 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
>>
>> suderman@cs.vassar.edu
>>
>>
>>
>>
>>
>>
>>
>>
>> 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.
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
--
Omnem crede diem tibi diluxisse supremum.
Re: Maven coordinates going forward
Posted by Guillaume Laforge <gl...@gmail.com>.
Just an added note on the topic of potential package name changes.
In the past, we've had to move some AST transformations from groovy.lang to
groovy.transforms, and we managed to make that transition without too much
harm.
Similarly to what we did on that occasion, we could offer a compatibility
module that would just delegate classes from old packages to classes of the
new packages. And once you've had the time to make the migration, you'd
just remove the compatibility module.
We could also have more complex solutions involving bytecode rewriting.
But at some point, it'll really look ridiculous to still have org.codehaus
here and there, although codehaus' already been long gone already.
So package name changes are not all black'n white.
There are possible shades of gray :-)
Guillaume
On Mon, Mar 27, 2017 at 9:03 PM, Winnebeck, Jason <
Jason.Winnebeck@windstream.com> wrote:
> 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 search.maven.org)
> 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.
>
>
>
> Jason
>
>
>
> *From:* Keith Suderman [mailto:suderman@anc.org]
> *Sent:* Monday, March 27, 2017 2:49 PM
> *To:* users@groovy.apache.org
> *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.
>
>
>
> Keith
>
>
>
>
>
> On Mar 27, 2017, at 2:20 PM, Jochen Theodorou <bl...@gmx.org> wrote:
>
>
>
> 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
> version.
>
> 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
>
> suderman@cs.vassar.edu
>
>
>
>
>
>
>
>
> 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.
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
RE: Maven coordinates going forward
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
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 search.maven.org) 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.
Jason
From: Keith Suderman [mailto:suderman@anc.org]
Sent: Monday, March 27, 2017 2:49 PM
To: users@groovy.apache.org
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.
Keith
On Mar 27, 2017, at 2:20 PM, Jochen Theodorou <bl...@gmx.org>> wrote:
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
version.
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
suderman@cs.vassar.edu<ma...@cs.vassar.edu>
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.
Re: Maven coordinates going forward
Posted by Keith Suderman <su...@anc.org>.
+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.
Keith
> On Mar 27, 2017, at 2:20 PM, Jochen Theodorou <bl...@gmx.org> wrote:
>
> 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
>> version.
>>
>> 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
suderman@cs.vassar.edu
Re: Maven coordinates going forward
Posted by Jochen Theodorou <bl...@gmx.org>.
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
> version.
>
> 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
RE: Maven coordinates going forward
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
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 version.
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.
Jason
-----Original Message-----
From: Russel Winder [mailto:russel@winder.org.uk]
Sent: Monday, March 27, 2017 1:29 PM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward
On Mon, 2017-03-27 at 12:47 -0400, Gerald Wiltse wrote:
>
[…]
> Specifically, reaching out to the Python maintainers for guidance. In
> hindsight, someone deeply involved usually has a very clear vision of
> "What we should have done instead was...". It would be a major missed
> opportunity if nobody pursues that avenue.
>
[…]
I cannot speak for the core developers, but I am sure I could ask them via the various Python mailing lists. The introduction of Python 3 was not handled well in my view from the social and management perspective and this led to a majority of the tribalism issues that were seen. The changes to the data model were large, and needed, and affected library writers more than end users. The biggest change that affected end users was the shift from ASCII to Unicode as the representation of strings.
This broke any code using strings for networking.
Not having packages such as future and six, and tools such as 2to3 properly in place before the mass push to Python 3 was a bit of a problem.
However the single biggest problem was that many influential people said "Python 3, no way" from the outset. Also a couple of high profile projects said "the issue of strings is too big, we will not change". A well-thought of Python distribution refused to accept the existence of Python 3, and out of that that distribution is now dead and Anaconda/Miniconda from Continuum Analytics is now the default distribution for people not use an OS with packaging – or actually sometimes anyway. Also a few Linux distributions based on mass use of Python are based on code that is at least a decade old (Scientific Linux, I am looking at you).
All of this led to a Python 2 vs Python 3 warfare that was almost totally nothing to do with technicalities. It was to do with vested interests and financial muscle. It became tribal almost like the Green/Purple Drazi in "Geometry of Shadows" an episode of Babylon 5 htt ps://www.youtube.com/watch?v=AcBTOU7RvbU .
It has taken a long time for Python 3 to become ascendant but ascendant it is. The old "stick with Python 2" project have quietly enabled Python 3 and tried to avoid any publicity about this.
So the change was a technical success and a management and social failure.
Thus changing the package names is a management problem not a technical problem. So the only real question is how to enable redirection at dynamic link time.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
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.
Re: Maven coordinates going forward
Posted by Russel Winder <ru...@winder.org.uk>.
On Mon, 2017-03-27 at 12:47 -0400, Gerald Wiltse wrote:
>
[…]
> Specifically, reaching out to the Python maintainers for
> guidance. In
> hindsight, someone deeply involved usually has a very clear vision of
> "What
> we should have done instead was...". It would be a major missed
> opportunity if nobody pursues that avenue.
>
[…]
I cannot speak for the core developers, but I am sure I could ask them
via the various Python mailing lists. The introduction of Python 3 was
not handled well in my view from the social and management perspective
and this led to a majority of the tribalism issues that were seen. The
changes to the data model were large, and needed, and affected library
writers more than end users. The biggest change that affected end users
was the shift from ASCII to Unicode as the representation of strings.
This broke any code using strings for networking.
Not having packages such as future and six, and tools such as 2to3
properly in place before the mass push to Python 3 was a bit of a
problem.
However the single biggest problem was that many influential people
said "Python 3, no way" from the outset. Also a couple of high profile
projects said "the issue of strings is too big, we will not change". A
well-thought of Python distribution refused to accept the existence of
Python 3, and out of that that distribution is now dead and
Anaconda/Miniconda from Continuum Analytics is now the default
distribution for people not use an OS with packaging – or actually
sometimes anyway. Also a few Linux distributions based on mass use of
Python are based on code that is at least a decade old (Scientific
Linux, I am looking at you).
All of this led to a Python 2 vs Python 3 warfare that was almost
totally nothing to do with technicalities. It was to do with vested
interests and financial muscle. It became tribal almost like the
Green/Purple Drazi in "Geometry of Shadows" an episode of Babylon 5 htt
ps://www.youtube.com/watch?v=AcBTOU7RvbU .
It has taken a long time for Python 3 to become ascendant but ascendant
it is. The old "stick with Python 2" project have quietly enabled
Python 3 and tried to avoid any publicity about this.
So the change was a technical success and a management and social
failure.
Thus changing the package names is a management problem not a technical
problem. So the only real question is how to enable redirection at
dynamic link time.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Maven coordinates going forward
Posted by Gerald Wiltse <je...@gmail.com>.
I am not sure if I agree or not yet ( I think I do.) But I think Jason's
point is that the situation with Python is perhaps as undesirable as one
could imagine for an ecosystem, so trying to learn as much from that
situation as possible might be wise.
Specifically, reaching out to the Python maintainers for guidance. In
hindsight, someone deeply involved usually has a very clear vision of "What
we should have done instead was...". It would be a major missed
opportunity if nobody pursues that avenue.
Gerald R. Wiltse
jerrywiltse@gmail.com
On Mon, Mar 27, 2017 at 12:16 PM, Daniel Sun <re...@hotmail.com>
wrote:
>
> > The two are independent. I suggest changing both at the same time would
> be the right thing to do.
>
> Agreed!
>
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/Maven-coordinates-going-forward-tp5739395p5739409.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>
Re: Maven coordinates going forward
Posted by Daniel Sun <re...@hotmail.com>.
> The two are independent. I suggest changing both at the same time would
be the right thing to do.
Agreed!
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/Maven-coordinates-going-forward-tp5739395p5739409.html
Sent from the Groovy Users mailing list archive at Nabble.com.
RE: Maven coordinates going forward
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
So that means we'll have a Python 3 situation where no code compiled with Groovy 2.x will ever be used again, unless the authors all release Groovy 3-specific versions?
Jason
-----Original Message-----
From: Russel Winder [mailto:russel@winder.org.uk]
Sent: Monday, March 27, 2017 11:40 AM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward
On Mon, 2017-03-27 at 09:58 -0500, David Clark wrote:
> Will this also change the package names to org.apache.groovy or will
> those remain org.codehaus.groovy?
>
The two are independent. I suggest changing both at the same time would
be the right thing to do.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
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.
Re: Maven coordinates going forward
Posted by Russel Winder <ru...@winder.org.uk>.
On Mon, 2017-03-27 at 09:58 -0500, David Clark wrote:
> Will this also change the package names to org.apache.groovy or will
> those
> remain org.codehaus.groovy?
>
The two are independent. I suggest changing both at the same time would
be the right thing to do.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Maven coordinates going forward
Posted by Schalk Cronjé <ys...@gmail.com>.
On 27/03/2017 16:58, David Clark wrote:
> Will this also change the package names to org.apache.groovy or will
> those remain org.codehaus.groovy?
>
I think that would be a good idea.
--
Schalk W. Cronj�
Twitter / Ello / Toeter : @ysb33r
Re: Maven coordinates going forward
Posted by David Clark <pl...@gmail.com>.
Will this also change the package names to org.apache.groovy or will those
remain org.codehaus.groovy?
On Mon, Mar 27, 2017 at 8:57 AM, Paul King <pa...@asert.com.au> wrote:
> Hi, it's still a little while away but we'll soon begin the work on
> what will be called Groovy 3 or Groovy 4 - the exact version number is
> potentially up for further debate depending on how other upcoming
> Parrot back port work pans out but we are not asking for feedback on
> that right now.
>
> This new version of Groovy will have the new Parrot parser merged.
> We're also planning to require JDK8 and it might have some other
> breaking changes depending on how things pan out. There has been
> discussion in the past that Apache Groovy might (should?) change the
> Maven coordinates to have group org.apache.groovy rather than
> org.codehaus.groovy. Previously we have spoken about not doing that
> before some major release point. The Groovy team is now interested in
> your feedback as to whether this new version might be the right time
> to make that change.
>
> Obviously, we'll need to publicise the change to make sure people can
> find the new versions but we are particularly interested in feedback
> on whether anyone would be adversely affected by such a change.
>
> Comments welcome,
>
> Cheers, Paul.
>
Re: Maven coordinates going forward, PS
Posted by Russel Winder <ru...@winder.org.uk>.
On Mon, 2017-03-27 at 15:59 +0100, Russel Winder wrote:
> On Mon, 2017-03-27 at 23:57 +1000, Paul King wrote:
> > […]
> > discussion in the past that Apache Groovy might (should?) change
> > the
> > Maven coordinates to have group org.apache.groovy rather than
> > org.codehaus.groovy. Previously we have spoken about not doing that
> > before some major release point. The Groovy team is now interested
> > in
> > your feedback as to whether this new version might be the right
> > time
> > to make that change.
Apologies, I pressed send before adding:
I think moving to org.apache.groovy for Groovy 3 would be an excellent
idea.
Clearly it would also be a good idea to move all the packages from
org.codehaus.groovy to org.apache.groovy, but that could be argued as
change for the sake of it. However I would say no, Groovy should move
forward not look back, and org.apache.groovy is the future.
Groovy 3 would strike me as the time to do this.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Maven coordinates going forward
Posted by Russel Winder <ru...@winder.org.uk>.
On Mon, 2017-03-27 at 23:57 +1000, Paul King wrote:
> Hi, it's still a little while away but we'll soon begin the work on
> what will be called Groovy 3 or Groovy 4 - the exact version number
> is
> potentially up for further debate depending on how other upcoming
> Parrot back port work pans out but we are not asking for feedback on
> that right now.
Some of us are already using Groovy 3.0.0. ;-)
> This new version of Groovy will have the new Parrot parser merged.
> We're also planning to require JDK8 and it might have some other
> breaking changes depending on how things pan out. There has been
> discussion in the past that Apache Groovy might (should?) change the
> Maven coordinates to have group org.apache.groovy rather than
> org.codehaus.groovy. Previously we have spoken about not doing that
> before some major release point. The Groovy team is now interested in
> your feedback as to whether this new version might be the right time
> to make that change.
I am all for requiring JDK8 for Groovy 3 *AND* getting rid of the build
of two lots of artefacts. Either we go with indy or we don't, I sugegst
that Groovy 3 is the right place to go with only indy and drop the
previous stuff. If the indy codes are slower then we fix it.
> Obviously, we'll need to publicise the change to make sure people can
> find the new versions but we are particularly interested in feedback
> on whether anyone would be adversely affected by such a change.
>
> Comments welcome,
>
I am always willing to make comments. Actions less likely. ;-) Well
unless it is GPars and Gant anyway.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder