[VOTE] Automatic module names

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[VOTE] Automatic module names

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,

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Automatic module names

Jochen Theodorou
+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,
>

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Automatic module names

Guillaume Laforge
Administrator
+1

On Sun, Dec 3, 2017 at 10:49 AM, Jochen Theodorou <[hidden email]> wrote:
+1


On <a href="tel:03.12.2017%2010" value="+33312201710" target="_blank">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

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Automatic module names

Remi Forax
In reply to this post by Cédric Champeau
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" <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Automatic module names

Leonard Brünings

+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" [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Automatic module names

sbglasius
+1


On Sun, 3 Dec 2017 at 18:38 Leonard Brünings <[hidden email]> 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" [hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Automatic module names

Cédric Champeau
In reply to this post by Leonard Brünings
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 <[hidden email]>:

+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" [hidden email] 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.


Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Automatic module names

Daniel Sun
In reply to this post by Cédric Champeau
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Automatic module names

Jochen Theodorou
In reply to this post by Remi Forax
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"
> <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Automatic module names

paulk_asert
In reply to this post by Cédric Champeau
+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 <[hidden email]> 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,