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 <pa...@asert.com.au> 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. > >
