Maven coordinates going forward

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Maven coordinates going forward

paulk_asert
Hi, it's still a little while away but we'll soon begin the work on
what will be called Groovy 3 or Groovy 4 - the exact version number is
potentially up for further debate depending on how other upcoming
Parrot back port work pans out but we are not asking for feedback on
that right now.

This new version of Groovy will have the new Parrot parser merged.
We're also planning to require JDK8 and it might have some other
breaking changes depending on how things pan out. There has been
discussion in the past that Apache Groovy might (should?) change the
Maven coordinates to have group org.apache.groovy rather than
org.codehaus.groovy. Previously we have spoken about not doing that
before some major release point. The Groovy team is now interested in
your feedback as to whether this new version might be the right time
to make that change.

Obviously, we'll need to publicise the change to make sure people can
find the new versions but we are particularly interested in feedback
on whether anyone would be adversely affected by such a change.

Comments welcome,

Cheers, Paul.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven coordinates going forward

David Clark-2
Will this also change the package names to org.apache.groovy or will those remain org.codehaus.groovy?

On Mon, Mar 27, 2017 at 8:57 AM, Paul King <[hidden email]> wrote:
Hi, it's still a little while away but we'll soon begin the work on
what will be called Groovy 3 or Groovy 4 - the exact version number is
potentially up for further debate depending on how other upcoming
Parrot back port work pans out but we are not asking for feedback on
that right now.

This new version of Groovy will have the new Parrot parser merged.
We're also planning to require JDK8 and it might have some other
breaking changes depending on how things pan out. There has been
discussion in the past that Apache Groovy might (should?) change the
Maven coordinates to have group org.apache.groovy rather than
org.codehaus.groovy. Previously we have spoken about not doing that
before some major release point. The Groovy team is now interested in
your feedback as to whether this new version might be the right time
to make that change.

Obviously, we'll need to publicise the change to make sure people can
find the new versions but we are particularly interested in feedback
on whether anyone would be adversely affected by such a change.

Comments welcome,

Cheers, Paul.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven coordinates going forward

Russel Winder-3
On Mon, 2017-03-27 at 09:58 -0500, David Clark wrote:
> Will this also change the package names to org.apache.groovy or will
> those
> remain org.codehaus.groovy?
>

The two are independent. I suggest changing both at the same time would
be the right thing to do.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Maven coordinates going forward

Winnebeck, Jason
So that means we'll have a Python 3 situation where no code compiled with Groovy 2.x will ever be used again, unless the authors all release Groovy 3-specific versions?

Jason

-----Original Message-----
From: Russel Winder [mailto:[hidden email]]
Sent: Monday, March 27, 2017 11:40 AM
To: [hidden email]
Subject: Re: Maven coordinates going forward

On Mon, 2017-03-27 at 09:58 -0500, David Clark wrote:
> Will this also change the package names to org.apache.groovy or will
> those remain org.codehaus.groovy?
>

The two are independent. I suggest changing both at the same time would
be the right thing to do.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven coordinates going forward

ysb33r
In reply to this post by David Clark-2
On 27/03/2017 16:58, David Clark wrote:
Will this also change the package names to org.apache.groovy or will those remain org.codehaus.groovy?

I think that would be a good idea.


-- 
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven coordinates going forward

Daniel Sun
In reply to this post by Russel Winder-3

> The two are independent. I suggest changing both at the same time would
be the right thing to do.

Agreed!


Cheers,
Daniel.Sun
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven coordinates going forward

Gerald Wiltse
I am not sure if I agree or not yet ( I think I do.)  But I think Jason's point is that the situation with Python is perhaps as undesirable as one could imagine for an ecosystem, so trying to learn as much from that situation as possible might be wise. 

Specifically, reaching out to the Python maintainers for guidance.  In hindsight, someone deeply involved usually has a very clear vision of "What we should have done instead was...".  It would be a major missed opportunity if nobody pursues that avenue. 

Gerald R. Wiltse
[hidden email]


On Mon, Mar 27, 2017 at 12:16 PM, Daniel Sun <[hidden email]> wrote:

> The two are independent. I suggest changing both at the same time would
be the right thing to do.

Agreed!


Cheers,
Daniel.Sun



--
View this message in context: http://groovy.329449.n5.nabble.com/Maven-coordinates-going-forward-tp5739395p5739409.html
Sent from the Groovy Users mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven coordinates going forward

Russel Winder-3
On Mon, 2017-03-27 at 12:47 -0400, Gerald Wiltse wrote:
>
[…]
> Specifically, reaching out to the Python maintainers for
> guidance.  In
> hindsight, someone deeply involved usually has a very clear vision of
> "What
> we should have done instead was...".  It would be a major missed
> opportunity if nobody pursues that avenue.
>
[…]

I cannot speak for the core developers, but I am sure I could ask them
via the various Python mailing lists. The introduction of Python 3 was
not handled well in my view from the social and management perspective
and this led to a majority of the tribalism issues that were seen. The
changes to the data model were large, and needed, and affected library
writers more than end users. The biggest change that affected end users
was the shift from ASCII to Unicode as the representation of strings.
This broke any code using strings for networking.

Not having packages such as future and six, and tools such as 2to3
properly in place before the mass push to Python 3 was a bit of a
problem.

However the single biggest problem was that many influential people
said "Python 3, no way" from the outset. Also a couple of high profile
projects said "the issue of strings is too big, we will not change". A
well-thought of Python distribution refused to accept the existence of
Python 3, and out of that that distribution is now dead and
Anaconda/Miniconda from Continuum Analytics is now the default
distribution for people not use an OS with packaging – or actually
sometimes anyway. Also a few Linux distributions based on mass use of
Python are based on code that is at least a decade old (Scientific
Linux, I am looking at you).

All of this led to a Python 2 vs Python 3 warfare that was almost
totally nothing to do with technicalities. It was to do with vested
interests and financial muscle. It became tribal almost like the
Green/Purple Drazi in "Geometry of Shadows" an episode of Babylon 5 htt
ps://www.youtube.com/watch?v=AcBTOU7RvbU .

It has taken a long time for Python 3 to become ascendant but ascendant
it is. The old "stick with Python 2" project have quietly enabled
Python 3 and tried to avoid any publicity about this.

So the change was a technical success and a management and social
failure.

Thus changing the package names is a management problem not a technical
problem. So the only real question is how to enable redirection at
dynamic link time.
 
--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Maven coordinates going forward

Winnebeck, Jason
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.

Jason

-----Original Message-----
From: Russel Winder [mailto:[hidden email]]
Sent: Monday, March 27, 2017 1:29 PM
To: [hidden email]
Subject: Re: Maven coordinates going forward

On Mon, 2017-03-27 at 12:47 -0400, Gerald Wiltse wrote:
>
[…]
> Specifically, reaching out to the Python maintainers for guidance.  In
> hindsight, someone deeply involved usually has a very clear vision of
> "What we should have done instead was...".  It would be a major missed
> opportunity if nobody pursues that avenue.
>
[…]

I cannot speak for the core developers, but I am sure I could ask them via the various Python mailing lists. The introduction of Python 3 was not handled well in my view from the social and management perspective and this led to a majority of the tribalism issues that were seen. The changes to the data model were large, and needed, and affected library writers more than end users. The biggest change that affected end users was the shift from ASCII to Unicode as the representation of strings.
This broke any code using strings for networking.

Not having packages such as future and six, and tools such as 2to3 properly in place before the mass push to Python 3 was a bit of a problem.

However the single biggest problem was that many influential people said "Python 3, no way" from the outset. Also a couple of high profile projects said "the issue of strings is too big, we will not change". A well-thought of Python distribution refused to accept the existence of Python 3, and out of that that distribution is now dead and Anaconda/Miniconda from Continuum Analytics is now the default distribution for people not use an OS with packaging – or actually sometimes anyway. Also a few Linux distributions based on mass use of Python are based on code that is at least a decade old (Scientific Linux, I am looking at you).

All of this led to a Python 2 vs Python 3 warfare that was almost totally nothing to do with technicalities. It was to do with vested interests and financial muscle. It became tribal almost like the Green/Purple Drazi in "Geometry of Shadows" an episode of Babylon 5 htt ps://www.youtube.com/watch?v=AcBTOU7RvbU .

It has taken a long time for Python 3 to become ascendant but ascendant it is. The old "stick with Python 2" project have quietly enabled Python 3 and tried to avoid any publicity about this.

So the change was a technical success and a management and social failure.

Thus changing the package names is a management problem not a technical problem. So the only real question is how to enable redirection at dynamic link time.
 
--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven coordinates going forward

Jochen Theodorou
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
1234
Loading...