groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Péter Gergely Horváth <peter.gergely.horv...@gmail.com>
Subject Re: Maven coordinates going forward
Date Tue, 28 Mar 2017 11:29:49 GMT
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 <glaforge@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 <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