I feel we have changed topics. OP's starting question was maven coordinates. This naturally led to the question of package names. Now we ended up on the topic of JDK9 modules. They are related to maven coordinates and package names but my previous comment didn't intend to address the modules.
So if we are talking about JDK9 modules them I'm with Jason and the rest of you. Sure, breaking backwards compatibility is a sensible thing to do in that case. On the other hand, if we are only discussing whether maven coordinates or package names should change for the sake of aesthetics, they I would ask you to reconsider as I do not feel the pros outweigh the cons - trading aesthetic beauty for new techical problems. I feel I'm in the same position as Jason with maintaining and continuously adding new features to 10 year old projects whose expected lifetime is at least that much more. I can also tell you that things aren't so black and white as some are suggesting with never upgrading. Those projects are not allowed _not_ to run on JDK8 or JDK9 or JDK10 (when the time comes). If my memory serves me right didn't gradle also require groovy1 for plugin development a long time after release of groovy2 due to fear of backwards incompatibilities? I believe Jochen calmed their concers. Somebody correct me if I'm wrong. And yet again - if the reasons are right - break backwards compatibility. So now that we have changed the topic, may I ask: is JDK9 modules compatibility coming in groovy3? Also, I like the Céderic's idea of corunnable groovy 2 & 3. Anybody else entertaining that idea? Is it doable considering the shared groovy.* packages? On Mar 30, 2017 18:00, "Winnebeck, Jason" <jason.winneb...@windstream.com> wrote: I think others have characterized it differently, but in my mind that is the “Python” scenario. Groovy 3 comes out and immediately makes all existing code incompatible. Without an incremental upgrade path, users, especially enterprise users, are faced with a rewrite and have no choice but to basically stay on Groovy 2 forever. With so many users staying on 2.x, it will fragment the community and the limited support that Groovy receives. While http-builder-ng is a good example of an updated project, even for that project’s documentation says it’s not backwards compatible so it’s not a drop-in replacement either. At least with Java library usage being very popular, there will be a lot of libraries we can still use in G3. If it’s still possible for G2 to co-exist, then at least I can update my own code to G3 while I wait (perhaps forever) for libraries to update to G2, and I can deploy upgrades incrementally. An atomic rewrite all functionality from scratch is never a valid scenario for 10+ year old projects. Jason *From:* Guillaume Laforge [mailto:glafo...@gmail.com] *Sent:* Thursday, March 30, 2017 10:21 AM *To:* users@groovy.apache.org *Subject:* Re: Maven coordinates going forward And there's also groovy-wslite. Also we can't wait for all possible abandonned project to update to a newer version of Groovy. Those projects depending on libraries using an old version of Groovy should probably just not upgrade at all. On Thu, Mar 30, 2017 at 4:09 PM, David Clark <plotinussm...@gmail.com> wrote: The original http-builder is unmaintained. However http-builder-ng is maintained: https://http-builder-ng.github.io/http-builder-ng/ We already had to change the maven coordinates because of Maven/Sonatype restrictions, so things should be fine provided people upgrade to the newer library. On Thu, Mar 30, 2017 at 8:12 AM, Winnebeck, Jason < jason.winneb...@windstream.com> wrote: Can you explain the story around a library like org.codehaus.groovy.modules.http-builder:http-builder, which is no longer really maintained? What happens to such a library when Groovy 3 comes out and we are using that library? Let's say there is no maintainer to update the sources to Groovy 3 and re-release. Jason -----Original Message----- From: Russel Winder [mailto:rus...@winder.org.uk] Sent: Thursday, March 30, 2017 3:54 AM To: users@groovy.apache.org Subject: Re: Maven coordinates going forward On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote: > We have to keep in mind that there's a larger story here, which is > supporting Groovy as a module. And this *will* require package changes > and binary breaking changes. So I don't think the status quo is > acceptable in the long run. So why not make Groovy 3 the place to do this? Whatever has been said about the Python situation, the core problem was not the breaking change, the problem was the lack of active management of the change. Python is a source deployment language where JRE-based langauges are not. Thus JRE-based application have the classic COBOL, FORTRAN, and Fortran problem of "we've lost the source" (banks and governments are the usual suspects for this). I would exclude this situation from our thinking. Organisations in such a state (as some UK banks and the UK government is) should take it as an opportunity to revolutionise (which the UK government is, cf. the job adverts for COBOL, FORTRAN and Fortran knowledgeable people who also know Python, Java, etc. Python also had the problem of Python 2.6 and 2.7 along with 3.3 and 3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the mix made for a much, much easier time. So initially moving from Python 2 to Python 3 was a manual task (bad management by the Python 3 folk), then came the six generation of upgrade tooling (a start). By dropping 2.6 and 3.3, we get the far nicer future upgrade tooling (which works nicely to create 2.7 and 3.4+ compatible code). The moral here is choose the versions being upgraded from and to, and then make some nice automation. So if we assume a base of Groovy 2.4 and ignore all previous Groovys and the breaking change of 3.0 can we write some Groovy (obviously :-) scripts that automate source changes? If the Python 2 → Python 3 breaking change had been more actively managed with earlier arrival of six and future, the problems would have been much less. Most of the vocal Python 2 Remainers have now made their codes run on both Python 2 and Python 3, and there are very few complaints about providing Python 3 only. OK so there are still a few people who say "we must support Python 2.5" but those people are few and far between and are, in the main, totally ignored. Python 4 will undoubtedly have breaking changes, but they will be better managed in terms of supporting multi-version working and automated (well at least semi-automated) upgrading and mixed-version working. The lessons of six and future have been well learned. So Groovy will have breaking changes, this is right and proper. Put in place tools for upgrading, and support multi-version working where possible and practical. Do not be swayed by calls for "we must change nothing, backward compatibility". They have a version of Groovy that works for them so they should not upgrade – ever again. That must not stop the rest of us from progressing. -- Russel. ============================================================ ================= Dr Russel Winder t: +44 20 7585 2200 <+44%2020%207585%202200> voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder 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>
