Re: Optional modules and Groovy 4

[Paul King]

There has been a common request to have a way to get a "reasonably
full-featured" version of Groovy with all of the common functionality. This
is what the current "all" pom provides. So, I think simply removing the
all pom wouldn't be well received. There is certainly scope to have
different packaging choices rather than just the most common and certainly
scope for having a different (clearer?) name. I think though that we
wouldn't want to get too fancy or it will just be confusing.

On Fri, May 29, 2020 at 12:32 AM Milles, Eric (TR Tech, Content & Ops) <
eric.mil...@thomsonreuters.com> wrote:

> Maybe instead of removing items from the "all" pom, a separate artifact
> gets created that includes commonly-used components.  Or has the time come
> to stop producing the "all" artifact?
>
>
>
> *From:* Paul King 
> *Sent:* Tuesday, May 26, 2020 6:35 AM
> *To:* Groovy_Developers 
> *Subject:* Re: Optional modules and Groovy 4
>
>
>
>
>
>
>
> On Tue, May 26, 2020 at 9:17 PM Remko Popma  wrote:
>
> Isn't  groovy-dateutil in use because of the convenience of utility
> methods for converting from String to Date and back?
>
>
>
> Yes, converting String <-> java.util.Date is still widely used even though
> we include String <-> JSR-310 Date/Time classes by default which could
> cover most similar use cases.
>
>
>
> Apart from that, when we are talking about groovy-all, we are talking
> about a maven thing, not a jar, right?
>
>
>
> Correct, just what is included in the groovy-all pom.
>
>
>
> Cheers, Paul.
>
>
>
> On Tue, May 26, 2020 at 5:56 PM Guillaume Laforge 
> wrote:
>
> Sounds like a good idea to review the (optional) modules for 4.0.
>
>
>
> On Tue, May 26, 2020 at 6:39 AM Daniel.Sun  wrote:
>
> +1
>
> Cheers,
> Daniel Sun
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.sunlan.me%2F=02%7C01%7Ceric.milles%40thomsonreuters.com%7C6837042754ce49e05fb008d80168e651%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637260897333820367=fOHeOkBLBm9vT8AkDlBM96n1m2%2FJ23Cy2aNI0xO94W4%3D=0>
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroovy.329449.n5.nabble.com%2FGroovy-Dev-f372993.html=02%7C01%7Ceric.milles%40thomsonreuters.com%7C6837042754ce49e05fb008d80168e651%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637260897333830361=%2FOd3QjL1iQh%2BcHk4n3ZRqzSu%2BtAM3PU%2FQFJkzkKeoLQ%3D=0>
>
>
>
>
> --
>
> Guillaume Laforge
> Apache Groovy committer
>
> Developer Advocate @ Google Cloud Platform
>
>
>
> Blog: http://glaforge.appspot.com/
> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fglaforge.appspot.com%2F=02%7C01%7Ceric.milles%40thomsonreuters.com%7C6837042754ce49e05fb008d80168e651%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637260897333830361=naJWuflnEV2zn%2BqAnH0fmPw3Hl0hknao3T49W4pKjww%3D=0>
>
> Twitter: @glaforge
> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fglaforge=02%7C01%7Ceric.milles%40thomsonreuters.com%7C6837042754ce49e05fb008d80168e651%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637260897333830361=mCK%2FkS1j%2BtdhlEKSxL%2FsQ3cxOxfZC0OWWrQR4CMvCD0%3D=0>
>
>

RE: Optional modules and Groovy 4

[Milles, Eric (TR Tech, Content & Ops)]

Maybe instead of removing items from the "all" pom, a separate artifact gets 
created that includes commonly-used components.  Or has the time come to stop 
producing the "all" artifact?

From: Paul King 
Sent: Tuesday, May 26, 2020 6:35 AM
To: Groovy_Developers 
Subject: Re: Optional modules and Groovy 4



On Tue, May 26, 2020 at 9:17 PM Remko Popma 
mailto:remko.po...@gmail.com>> wrote:
Isn't  groovy-dateutil in use because of the convenience of utility methods for 
converting from String to Date and back?

Yes, converting String <-> java.util.Date is still widely used even though we 
include String <-> JSR-310 Date/Time classes by default which could cover most 
similar use cases.

Apart from that, when we are talking about groovy-all, we are talking about a 
maven thing, not a jar, right?

Correct, just what is included in the groovy-all pom.

Cheers, Paul.

On Tue, May 26, 2020 at 5:56 PM Guillaume Laforge 
mailto:glafo...@gmail.com>> wrote:
Sounds like a good idea to review the (optional) modules for 4.0.

On Tue, May 26, 2020 at 6:39 AM Daniel.Sun 
mailto:sun...@apache.org>> wrote:
+1

Cheers,
Daniel Sun



-
Apache Groovy committer & PMC member
Blog: 
http://blog.sunlan.me<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.sunlan.me%2F=02%7C01%7Ceric.milles%40thomsonreuters.com%7C6837042754ce49e05fb008d80168e651%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637260897333820367=fOHeOkBLBm9vT8AkDlBM96n1m2%2FJ23Cy2aNI0xO94W4%3D=0>
Twitter: @daniel_sun

--
Sent from: 
http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroovy.329449.n5.nabble.com%2FGroovy-Dev-f372993.html=02%7C01%7Ceric.milles%40thomsonreuters.com%7C6837042754ce49e05fb008d80168e651%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637260897333830361=%2FOd3QjL1iQh%2BcHk4n3ZRqzSu%2BtAM3PU%2FQFJkzkKeoLQ%3D=0>


--
Guillaume Laforge
Apache Groovy committer
Developer Advocate @ Google Cloud Platform

Blog: 
http://glaforge.appspot.com/<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fglaforge.appspot.com%2F=02%7C01%7Ceric.milles%40thomsonreuters.com%7C6837042754ce49e05fb008d80168e651%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637260897333830361=naJWuflnEV2zn%2BqAnH0fmPw3Hl0hknao3T49W4pKjww%3D=0>
Twitter: 
@glaforge<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fglaforge=02%7C01%7Ceric.milles%40thomsonreuters.com%7C6837042754ce49e05fb008d80168e651%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637260897333830361=mCK%2FkS1j%2BtdhlEKSxL%2FsQ3cxOxfZC0OWWrQR4CMvCD0%3D=0>

Re: Optional modules and Groovy 4

[Paul King]

On Tue, May 26, 2020 at 9:17 PM Remko Popma  wrote:

> Isn't  groovy-dateutil in use because of the convenience of utility
> methods for converting from String to Date and back?
>

Yes, converting String <-> java.util.Date is still widely used even though
we include String <-> JSR-310 Date/Time classes by default which could
cover most similar use cases.

Apart from that, when we are talking about groovy-all, we are talking about
> a maven thing, not a jar, right?
>

Correct, just what is included in the groovy-all pom.

Cheers, Paul.

On Tue, May 26, 2020 at 5:56 PM Guillaume Laforge 
> wrote:
>
>> Sounds like a good idea to review the (optional) modules for 4.0.
>>
>> On Tue, May 26, 2020 at 6:39 AM Daniel.Sun  wrote:
>>
>>> +1
>>>
>>> Cheers,
>>> Daniel Sun
>>>
>>>
>>>
>>> -
>>> Apache Groovy committer & PMC member
>>> Blog: http://blog.sunlan.me
>>> Twitter: @daniel_sun
>>>
>>> --
>>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Twitter: @glaforge 
>>
>

Re: Optional modules and Groovy 4

[Remko Popma]

Isn't  groovy-dateutil in use because of the convenience of utility methods
for converting from String to Date and back?

Apart from that, when we are talking about groovy-all, we are talking about
a maven thing, not a jar, right?


On Tue, May 26, 2020 at 5:56 PM Guillaume Laforge 
wrote:

> Sounds like a good idea to review the (optional) modules for 4.0.
>
> On Tue, May 26, 2020 at 6:39 AM Daniel.Sun  wrote:
>
>> +1
>>
>> Cheers,
>> Daniel Sun
>>
>>
>>
>> -
>> Apache Groovy committer & PMC member
>> Blog: http://blog.sunlan.me
>> Twitter: @daniel_sun
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge 
>

Re: Optional modules and Groovy 4

[Guillaume Laforge]

Sounds like a good idea to review the (optional) modules for 4.0.

On Tue, May 26, 2020 at 6:39 AM Daniel.Sun  wrote:

> +1
>
> Cheers,
> Daniel Sun
>
>
>
> -
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>


-- 
Guillaume Laforge
Apache Groovy committer
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Twitter: @glaforge 

Re: Optional modules and Groovy 4

[Daniel.Sun]

+1

Cheers,
Daniel Sun



-
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Optional modules and Groovy 4

[Paul King]

I should have mentioned. I plan to get feedback from users via email and
possibly twitter/slack but wanted thoughts here first.

Cheers, Paul.


On Tue, May 26, 2020 at 12:57 PM Paul King  wrote:

>
> Hi Everyone,
>
> I just did a quick check of stats of downloads of the optional modules in
> Groovy 3 with a view to considering possible changes for Groovy 4. I just
> looked at downloads over the last week and only for Groovy 3.
>
> Results as percentage of overall downloads:
> groovy-dateutil 74.9%
> groovy-yaml 15.1%
> groovy-cli-commons 5.5%
> groovy-jaxb 2.4%
> groovy-bsf 2.2%
>
> I think we can make the observation that groovy-dateutil is still in
> widespread use. Despite the newer JSR-310 date/time classes, the legacy
> ones are still important. We could consider adding them back into
> groovy-all.
> PROs: simpler inclusion, won't affect projects already explicitly
> mentioning the module
> CONs: slightly noisier classpath for projects not wanting those classes
> but they can exclude, it might look like we can't make up our mind, there
> might be slightly less incentive for users to upgrade to the newer classes
> which have many advantages
>
> It seems that there is enough interest in YAML that it should also be
> included in groovy-all.
> PROs: simpler inclusion, won't affect projects already explicitly
> mentioning the module
> CONs: slightly noisier classpath for projects not wanting YAML but they
> can exclude
>
> I haven't checked download numbers (and perhaps moot since it isn't
> optional) but I was leaning towards adding groovy-testng to optional
> modules for Groovy 4. There seems less interest in that technology since
> JUnit 5.
>
> In my view, groovy-servlet, groovy-jmx and groovy-docgenerator would be
> other candidates to add to the optional list.
>
> Note: we have split out the legacy AstBuilder classes (well more
> accurately the global transform associated with them) into a
> groovy-astbuilder module in Groovy 3. We have already ear-marked that as
> optional for Groovy 4. We encourage people to use the groovy-macro classes
> instead.
>
> I would be interested in others' thoughts.
>
> Cheers, Paul.
>
>

Optional modules and Groovy 4

[Paul King]

Hi Everyone,

I just did a quick check of stats of downloads of the optional modules in
Groovy 3 with a view to considering possible changes for Groovy 4. I just
looked at downloads over the last week and only for Groovy 3.

Results as percentage of overall downloads:
groovy-dateutil 74.9%
groovy-yaml 15.1%
groovy-cli-commons 5.5%
groovy-jaxb 2.4%
groovy-bsf 2.2%

I think we can make the observation that groovy-dateutil is still in
widespread use. Despite the newer JSR-310 date/time classes, the legacy
ones are still important. We could consider adding them back into
groovy-all.
PROs: simpler inclusion, won't affect projects already explicitly
mentioning the module
CONs: slightly noisier classpath for projects not wanting those classes but
they can exclude, it might look like we can't make up our mind, there might
be slightly less incentive for users to upgrade to the newer classes which
have many advantages

It seems that there is enough interest in YAML that it should also be
included in groovy-all.
PROs: simpler inclusion, won't affect projects already explicitly
mentioning the module
CONs: slightly noisier classpath for projects not wanting YAML but they can
exclude

I haven't checked download numbers (and perhaps moot since it isn't
optional) but I was leaning towards adding groovy-testng to optional
modules for Groovy 4. There seems less interest in that technology since
JUnit 5.

In my view, groovy-servlet, groovy-jmx and groovy-docgenerator would be
other candidates to add to the optional list.

Note: we have split out the legacy AstBuilder classes (well more accurately
the global transform associated with them) into a groovy-astbuilder module
in Groovy 3. We have already ear-marked that as optional for Groovy 4. We
encourage people to use the groovy-macro classes instead.

I would be interested in others' thoughts.

Cheers, Paul.