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.
