And again, _we have no choice_. If we want Groovy to run as a module, we HAVE to break binary compatibility. There's absolutely no other way around. It's a thing. If we don't want to break it, Groovy will never run as a module. And if JDK 9 modules become legion, then Groovy would die.
2017-03-30 15:16 GMT+02:00 Cédric Champeau <cedric.champ...@gmail.com>: > To me the idea would be to be able to run Groovy 2 and Groovy NG > concurrently. > > 2017-03-30 15:12 GMT+02:00 Winnebeck, Jason <Jason.Winnebeck@windstream. > com>: > >> 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. >> > >
