RE: Maven coordinates going forward

2017-03-30 Thread predatorvi
I’m a bit OCD and it makes little sense to continue developing against coordinates and packages with a naming scheme that represents a defunct brand/organization. So I vote for a coordinate change. If the coordinate changes, then the package naming should change too in my opinion. This solves

Re: Maven coordinates going forward

2017-03-30 Thread Keegan Witt
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

RE: Maven coordinates going forward

2017-03-30 Thread Miro Bezjak
I feel we have changed topics. OP's starting question was maven coordinates. This naturally led to the question of package names. Now we ended up on the topic of JDK9 modules. They are related to maven coordinates and package names but my previous comment didn't intend to address the modules. So i

RE: Maven coordinates going forward

2017-03-30 Thread Winnebeck, Jason
I think others have characterized it differently, but in my mind that is the “Python” scenario. Groovy 3 comes out and immediately makes all existing code incompatible. Without an incremental upgrade path, users, especially enterprise users, are faced with a rewrite and have no choice but to bas

Dynamic class loader and dependency management

2017-03-30 Thread Rodolphe
Hi all, I have a web server application inside which I can launch groovy scripts that can be modified/relaunched at any time, without needing to restart the server. The groovy files have got some dependencies between them. As I haven't found a way to perform the compilation of the script to be lau

Re: Maven coordinates going forward

2017-03-30 Thread Guillaume Laforge
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 wrote: > The

Re: Maven coordinates going forward

2017-03-30 Thread David Clark
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 Th

RE: Maven coordinates going forward

2017-03-30 Thread Winnebeck, Jason
OK, in my mind that is perfectly fine. In this case the change of package name and Maven coordinates is required, but in this case it is a good thing. It’s a good thing because you are saying explicitly that both Groovy versions can co-exist, which is what separate packages and separate Maven co

Re: Maven coordinates going forward

2017-03-30 Thread Cédric Champeau
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

Re: Maven coordinates going forward

2017-03-30 Thread Cédric Champeau
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 : > 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 l

RE: Maven coordinates going forward

2017-03-30 Thread Winnebeck, Jason
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 a

Re: Groovy compiler configuration BytecodeProcessor

2017-03-30 Thread Cherif Gouiaa
OK. Thanks for the (fast) response. Actually, I just need to confirm that there is no way to limit the amount of memory which a sandboxed groovy script will use. (By the way, the sandbox is based on your blog post )... 2017-03-30 13:18 GMT+01:0

Re: Groovy compiler configuration BytecodeProcessor

2017-03-30 Thread Cédric Champeau
It can be used for various purposes: dumping the generated bytecode, post-processing it (to avoid runtime instrumentation), storing generated bytecode on disk, ... As for memory size a groovy script will allocate, this statement is too blury: the only thing you can measure is the size of the genera

Groovy compiler configuration BytecodeProcessor

2017-03-30 Thread Cherif Gouiaa
What is the exact role of a BytecodeProcessor when used in a org.codehaus.groovy.control.CompilerConfiguration. Can I rely on it to measure the memory size which a groovy script will allocate. (i.e. original.length) ? -- *Cherif Gouiaa* Ingenieur de developpement [image: logo] --

Re: Maven coordinates going forward

2017-03-30 Thread Russel Winder
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.

Re: Maven coordinates going forward

2017-03-30 Thread Cédric Champeau
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

Re: Maven coordinates going forward

2017-03-30 Thread Russel Winder
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