Re: Maven coordinates going forward

It is also indeed a problem, which will lead us to move some classes around, from a package to another. On Mon, Mar 27, 2017 at 10:14 PM, Wilson MacGyver wrote: > as I recall, there are also rules about jigsaw not allowing same package > path from multiple modules. It's not

Re: Maven coordinates going forward

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. On Mon, Mar 27, 2017 at 3:28 PM, Guillaume Laforge wrote: > Just an added note on the topic of potential package name changes.

Re: Maven coordinates going forward

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

Re: Maven coordinates going forward

Just an added note on the topic of potential package name changes. In the past, we've had to move some AST transformations from groovy.lang to groovy.transforms, and we managed to make that transition without too much harm. Similarly to what we did on that occasion, we could offer a compatibility

Re: Maven coordinates going forward

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

RE: Maven coordinates going forward

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

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

Re: Maven coordinates going forward

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

Re: Maven coordinates going forward

> 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

Re: Maven coordinates going forward

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

RE: Maven coordinates going forward

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:rus...@winder.org.uk] Sent: Monday, March 27, 2017 11:40 AM To:

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.

Re: Maven coordinates going forward

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

Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser online!]

On 27.03.2017 16:13, Cédric Champeau wrote: I would only make indy the default if we have performance tests showing that it's as fast as, or better than the legacy call site caching, with JDK 8+. There's a "performance" submodule that we could use for that purpose too. As far as I remember,

Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser online!]

On 27.03.2017 17:01, Russel Winder wrote: On Mon, 2017-03-27 at 16:26 +0200, Andres Almiray wrote: Measure, don't guess! ;-) Perhaps setting up a set of JMH benchmarks would help? I know there's a Gradle plugin for it (wink wink, nudge nudge). I certainly agree with measure don't guess.

Maven coordinates going forward

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

Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser online!]

Measure, don't guess! ;-) Perhaps setting up a set of JMH benchmarks would help? I know there's a Gradle plugin for it (wink wink, nudge nudge). --- Java Champion; Groovy Enthusiast http://andresalmiray.com http://www.linkedin.com/in/aalmiray -- What goes

Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser online!]

Russel, seems we were thinking about the same things. I responded to the earlier thread. Does that answer your question? In summary, we could start trying to move to indy only on master. I think stability wise we are in good shape. There are some question marks still however about indy performance

Re: Groovy and JVM version [was Testing the Java 8 / Parrot parser online!]

On Sat, 2017-03-25 at 09:26 +0100, Jochen Theodorou wrote: > […] > > I cannot suggest to users to use indy with a normal JDK7, so the > minimum  > requirement for it is JDK8. And we are not there yet. I have to admit I am still of the opinion that you define a version that will be the last

Re: Testing the Java 8 / Parrot parser online!

Well, master is currently destined for Groovy 3 (or perhaps 4 - depending on how things pan out and how we finalise numbering) and it is ear-marked for JDK8+, so we could start making those changes soon. I was going to wait until I split off the GROOVY_2_6_X branch which I'll do after working out