You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Cédric Champeau <ce...@gmail.com> on 2017/12/03 09:31:27 UTC
[VOTE] Automatic module names
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,
Re: [VOTE] Automatic module names
Posted by Søren Berg Glasius <so...@glasius.dk>.
+1
On Sun, 3 Dec 2017 at 18:38 Leonard Brünings <gr...@bruenings-it.net>
wrote:
> +1 with the amendment from Rémi
>
> Am 03.12.2017 um 11:39 schrieb Remi Forax:
>
> Cedric,
> you can not have a dash in the name if you want the module name be
> referenced in a module-info.java.
>
> so it should be org.apache.groovy.json
>
> cheers,
> Rémi
>
>
> On December 3, 2017 10:31:27 AM GMT+01:00, "Cédric Champeau"
> <ce...@gmail.com> <ce...@gmail.com> wrote:
>>
>> 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,
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
> --
Best regards / Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.
Re: [VOTE] Automatic module names
Posted by Cédric Champeau <ce...@gmail.com>.
Right, the exact name of the module can be discussed. I have nothing
against org.apache.groovy.json.
2017-12-03 18:38 GMT+01:00 Leonard Brünings <gr...@bruenings-it.net>:
> +1 with the amendment from Rémi
>
> Am 03.12.2017 um 11:39 schrieb Remi Forax:
>
> Cedric,
> you can not have a dash in the name if you want the module name be
> referenced in a module-info.java.
>
> so it should be org.apache.groovy.json
>
> cheers,
> Rémi
>
>
> On December 3, 2017 10:31:27 AM GMT+01:00, "Cédric Champeau"
> <ce...@gmail.com> <ce...@gmail.com> wrote:
>>
>> 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,
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
>
Re: [VOTE] Automatic module names
Posted by Leonard Brünings <gr...@bruenings-it.net>.
+1 with the amendment from Rémi
Am 03.12.2017 um 11:39 schrieb Remi Forax:
> Cedric,
> you can not have a dash in the name if you want the module name be
> referenced in a module-info.java <http://module-info.java>.
>
> so it should be org.apache.groovy.json
>
> cheers,
> Rémi
>
>
> On December 3, 2017 10:31:27 AM GMT+01:00, "Cédric Champeau"
> <ce...@gmail.com> wrote:
>
> 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,
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [VOTE] Automatic module names
Posted by Jochen Theodorou <bl...@gmx.org>.
right, it has to be a valid java identifier.
Am 03.12.2017 um 11:39 schrieb Remi Forax:
> Cedric,
> you can not have a dash in the name if you want the module name be
> referenced in a module-info.java <http://module-info.java>.
>
> so it should be org.apache.groovy.json
>
> cheers,
> Rémi
>
>
> On December 3, 2017 10:31:27 AM GMT+01:00, "Cédric Champeau"
> <ce...@gmail.com> wrote:
>
> 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,
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [VOTE] Automatic module names
Posted by Remi Forax <fo...@univ-mlv.fr>.
Cedric,
you can not have a dash in the name if you want the module name be referenced in a module-info.java.
so it should be org.apache.groovy.json
cheers,
Rémi
On December 3, 2017 10:31:27 AM GMT+01:00, "Cédric Champeau" <ce...@gmail.com> wrote:
>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,
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [VOTE] Automatic module names
Posted by Daniel Sun <re...@hotmail.com>.
+1
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Automatic module names
Posted by Guillaume Laforge <gl...@gmail.com>.
+1
On Sun, Dec 3, 2017 at 10:49 AM, Jochen Theodorou <bl...@gmx.org> wrote:
> +1
>
>
> On 03.12.2017 10:31, Cédric Champeau wrote:
>
>> 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,
>>
>>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: [VOTE] Automatic module names
Posted by Jochen Theodorou <bl...@gmx.org>.
+1
On 03.12.2017 10:31, Cédric Champeau wrote:
> 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,
>
Re: [VOTE] Automatic module names
Posted by Paul King <pa...@asert.com.au>.
+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 <ce...@gmail.com>
wrote:
> 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,
>
>