groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Laforge <glafo...@gmail.com>
Subject Re: Maven coordinates going forward
Date Thu, 30 Mar 2017 14:20:32 GMT
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 <plotinussmith@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.Winnebeck@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:russel@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.winder@ekiga.net
>> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@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>

Mime
View raw message