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 <glafo...@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.winneb...@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:suder...@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 <blackd...@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
>>
>> suder...@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.

Reply via email to