groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <>
Subject Re: requesting your advice on picocli modules
Date Fri, 31 May 2019 03:41:22 GMT
On Fri, May 31, 2019 at 6:11 AM Milles, Eric (TR Tech, Content & Ops) <> wrote:

> Could your "picocli.groovy" package move to the groovy-cli-picocli
> subproject?
They do different things: groovy-cli has its own annotations
(@Option, @OptionField, @UnparsedField, etc), to be used with CliBuilder.
The groovy-cli-picocli subproject provides a CliBuilder implementation that
supports these annotations and other Groovy 2.5 CliBuilder features, using
picocli as the underlying parser.

The picocli.groovy package in picocli allows the use of _picocli_
annotations (not groovy-cli annotations) in Groovy scripts. It is not
related to CliBuilder and works with older versions of Groovy.

So, it's probably better to keep them separate to avoid confusion.

> ------------------------------
> *From:* Mario Garcia <>
> *Sent:* Thursday, May 30, 2019 3:05 PM
> *To:*
> *Cc:*
> *Subject:* Re: requesting your advice on picocli modules
> + 1 picoli-groovy.jar
> Great project BTW!
> El jue., 30 may. 2019 a las 14:51, Remko Popma (<>)
> escribió:
> Hi,
> I maintain the picocli library for creating command line applications in
> Groovy, Java, and other JVM languages.
> I have a question for the Groovy community (both users and developers):
> Currently, the picocli main jar contains both the core `picocli` package
> and a `picocli.groovy` package with classes that make it easy for Groovy
> scripts to use picocli annotations. I'm considering splitting up this jar.
> In an upcoming major release of the library I plan to provide a Java 9
> JPMS modular jar containing just the core `picocli` package and
> additionally a `module-info.class` to make this jar a full-fledged Java
> module.
> The question is what to do with the picocli.groovy package. I see two
> options:
> 1) have a `picocli-groovy` jar containing _only_ the picocli.groovy
> package - this jar would require (have a dependency on) the core picocli
> jar (the JPMS modular jar). Ideally this `picocli-groovy` jar would also be
> a JPMS module, but not sure if that's possible.
> 2) have a `picocli-legacy?` (name TBD) jar containing both the core
> picocli package and the picocli.groovy package - similar to the current
> picocli-3.9.x jar
> I believe the first option may be cleanest. Scripts would need to change
> their grape module from @Grab('info.picocli:picocli:$version') to
> @Grab('info.picocli:picocli-groovy:4.0.0') and that would bring in the
> transitive dependency on 'info.picocli:picocli:4.0.0', if my understanding
> is correct.
> Can anyone see any drawbacks with this approach?
> Would there be any point in additionally providing a `picocli-legacy`
> (name TBD) jar containing both the core picocli package and the
> picocli.groovy package, similar to the current picocli-3.9.x jar?
> On a side-note, has anyone had any issues with putting the
> `module-info.class` in the root of the modular jar versus putting it in
> META-INF/versions/9/ in the jar?
> Some people
> <>
> use META-INF/versions/9/ as a way to (hopefully) avoid issues with older
> tools unable to cope with the `module-info.class`. Does anyone have any
> experience with this?
> Remko

View raw message