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 <wmacgy...@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 <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. > -- 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>
