Thanks everyone for the feedback. I was mostly interested in feedback on
the maven coordinates rather than package names, but it was good to get
views on both. We have already started creating new classes using the
org.apache package prefix rather than org.codehaus and I presume that we
can continu
>
> Is this not the whole point of releasing versioned binaries? It just
>> means a couple of extra steps when I upgrade. First, change the
>> coordinates (group + version instead of just the version) and a quick
>> refactor of my imports. Every modern IDE makes this easy.
>>
>>
>> This is not m
On 30.03.2017 20:58, Miro Bezjak wrote:
[...]
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.
and I wish I would know how to solve all the problems. Right now it
seems like Groovy wi
>
>
>
>
> Is this not the whole point of releasing versioned binaries? It just
> means a couple of extra steps when I upgrade. First, change the
> coordinates (group + version instead of just the version) and a quick
> refactor of my imports. Every modern IDE makes this easy.
>
>
> This is not m
from Mail for Windows 10
From: Keegan Witt
Sent: Thursday, March 30, 2017 8:24 PM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward
That's a good point. It could cause some issues for Groovy as a transitive
dependency, but doing a global exclude in Maven is fairly ea
That's a good point. It could cause some issues for Groovy as a transitive
dependency, but doing a global exclude in Maven is fairly easy to do.
On Tue, Mar 28, 2017 at 1:42 PM, Cédric Champeau
wrote:
> One thing one has to consider when changing Maven coordinates, is...
> Maven. Despite being
ewrite 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
rg.uk<mailto:rus...@winder.org.uk>]
Sent: Thursday, March 30, 2017 3:54 AM
To: users@groovy.apache.org<mailto: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
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 t
o: 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 ch
excludes
groovy.lang.Closure so that it defers to the G3 implementation.
Jason
From: Cédric Champeau [mailto:cedric.champ...@gmail.com]
Sent: Thursday, March 30, 2017 9:18 AM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward
And again, _we have no choice_. If we want
>
>> -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 Cham
ay, 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
ovy 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
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.
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.
2017-03-30 9:22 GMT+02:00 Russel Winder :
> On Wed, 2017-03-29 at 1
On Wed, 2017-03-29 at 15:42 -0400, Keith Suderman wrote:
> Given Cédric's email and recent comments I think I have been
> convinced to change my vote to a -1 for changing Maven coordinates or
> package names.
>
> Is there a compelling technical argument for either change? Going by
> the old adage
Given Cédric's email and recent comments I think I have been convinced to
change my vote to a -1 for changing Maven coordinates or package names.
Is there a compelling technical argument for either change? Going by the old
adage, "if it ain't broke don't fix it", what exactly is being "fixed"?
The transitive dependency problem is also challenge for non-open source,
internally developed enterprise applications as well. I'm having a hard
time seeing how this "should be fairly low impact."
I agree with: "I would do this for the "breaking" version of Groovy,
whatever it is, but not before."
-1 for both maven coordinates and package change. Please don't break
backwards compatibility. Maybe I'm missing something but I see no good
reason for either change.
As others have mentioned, there is a lot of unmaintained code that would
stop working as a result of a package change. So in my opin
One thing one has to consider when changing Maven coordinates, is... Maven.
Despite being a build tool, it does a fairly poor job when coordinates
change. In particular, think of conflict resolution. What should it decide
if A depends on org.codehaus.groovy:2.4.10 and B depends on
org.apache.groovy
I'm +1 on Maven coordinate change. That should be fairly low impact.
I agree package renames should be taken on a case-by-case basis. Offhand,
the two biggest things that come to mind are custom ASTs, and the
compilation bits. For the former, I'd think it shouldn't be any worse than
the groovy.
On 27.03.2017 22:14, Wilson MacGyver 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.
That is right, yes... it is only a problem for Groovy as named or
automatic module though. As long a
ing 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 i
>> 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
vy
>> 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
>>
On 27 March 2017 at 19:49, Keith Suderman wrote:
> +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 Groo
> 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
: 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
+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 th
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
winder.org.uk]
Sent: Monday, March 27, 2017 1:29 PM
To: users@groovy.apache.org
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 invo
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
PM, Daniel Sun
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/Mav
> 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 l
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
AM
To: users@groovy.apache.org
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 bo
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.
=
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 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
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
40 matches
Mail list logo