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.
>
>
