groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject Re: [VOTE] Automatic module names
Date Mon, 04 Dec 2017 10:09:58 GMT
+1 with the following comments:

* No minus in module names as previously noted.
* WRT no fat jar, I think you could argue Groovy is both a library and an
application, so I think there is still a case for wanting to provide
special support for non-Gradle and non-Maven users of Groovy. Having said
that, I think our zip (and other) distributions go a long way to supporting
such users and we can explore further support such as some kind of fat jar
later and in ways that don't compromise more typical usage.
* Just as a side note, we should also explore options like what I believe
Kotlin provides of providing package translation during compilation. This
won't stop the need for some breaking package names but might mean just a
recompile will be enough in some cases to migrate to a new version of
Groovy. We could have a compiler switch which turned on the translations
and added in some extra automatic imports.

Cheers, Paul.

On Sun, Dec 3, 2017 at 7:31 PM, C├ędric Champeau <>

> Hi fellow Groovy devs,
> We had 2 different conversations in the past weeks regarding automatic
> module names for Groovy. We also starting receiving notifications that some
> 3rd party projects are blocked by Groovy when upgrading to modules (which
> is no surprise). Logback for one.
> We need to move forward, and take small steps forward. So, here's the plan:
> 1a. Replace the groovy-all jar with a groovy-all POM with just
> dependencies, so that those depending on groovy-all.jar would now get
> groovy.jar, groovy-json.jar and friends, instead of the all jar.
> 1b. Add automatic module names for all jars we have. Since we know
> breaking changes are coming, I'd suggest using "org.codehaus.groovy",
> "org.codehaus.groovy-json", ...
> 2. Fix split packages
> 3. When this is fixed, change module names to "org.apache.groovy",
> "org.apache.groovy-json", ...
> I would do 1a and 1b as soon as possible (2.5).
> I would do 2 and 3 for 3.0, since those are binary breaking changes. This
> is also why I would leverage that to move to org.apache module names.
> I am against providing another -all jar, which would be confusing. Also we
> have to get rid, as a larger community (java), of the bad habit of using
> fat jars as dependencies. Those should only be used in final applications,
> not libraries, so should be transparent to consumers.
> Please vote, so that we can move forward.
> [ ] +1 The plan sounds good
> [ ] 0 I don't understand enough of the context to have an opinion
> [ ] -1 because...
> Thanks a lot,

View raw message