groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Laforge <glafo...@gmail.com>
Subject Re: Maven coordinates going forward
Date Tue, 28 Mar 2017 04:48:34 GMT
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 <wmacgyver@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 <glaforge@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 <blackdrag@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>

Mime
View raw message