You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Remko Popma <re...@gmail.com> on 2019/05/30 12:50:50 UTC
requesting your advice on picocli modules
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 <https://github.com/moditect/moditect/issues/67> 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
Re: requesting your advice on picocli modules
Posted by Remko Popma <re...@gmail.com>.
I've started to make this change.
Note that there is some impact when upgrading:
Script authors need to use
`@Grab('info.picocli:*picocli-groovy*:4.x')` from version 4.0, since
`@Grab('info.picocli:picocli:4.x')` will not work.
On Sat, Jun 1, 2019 at 1:28 AM MG <mg...@arscreat.com> wrote:
> Hi Remko,
>
> I agree option 1) is the cleanest, as well as it being the direction all
> of Groovy seems to be moving.
>
> Cheers,
> mg
>
>
> On 30/05/2019 14:50, Remko Popma wrote:
>
> 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 <https://github.com/moditect/moditect/issues/67> 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
>
>
>
Re: requesting your advice on picocli modules
Posted by Remko Popma <re...@gmail.com>.
I've started to make this change.
Note that there is some impact when upgrading:
Script authors need to use
`@Grab('info.picocli:*picocli-groovy*:4.x')` from version 4.0, since
`@Grab('info.picocli:picocli:4.x')` will not work.
On Sat, Jun 1, 2019 at 1:28 AM MG <mg...@arscreat.com> wrote:
> Hi Remko,
>
> I agree option 1) is the cleanest, as well as it being the direction all
> of Groovy seems to be moving.
>
> Cheers,
> mg
>
>
> On 30/05/2019 14:50, Remko Popma wrote:
>
> 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 <https://github.com/moditect/moditect/issues/67> 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
>
>
>
Re: requesting your advice on picocli modules
Posted by MG <mg...@arscreat.com>.
Hi Remko,
I agree option 1) is the cleanest, as well as it being the direction all
of Groovy seems to be moving.
Cheers,
mg
On 30/05/2019 14:50, Remko Popma wrote:
> 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 <https://github.com/moditect/moditect/issues/67> 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
>
Re: requesting your advice on picocli modules
Posted by Remko Popma <re...@gmail.com>.
On Fri, May 31, 2019 at 6:11 AM Milles, Eric (TR Tech, Content & Ops) <
eric.milles@thomsonreuters.com> 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 <ma...@gmail.com>
> *Sent:* Thursday, May 30, 2019 3:05 PM
> *To:* users@groovy.apache.org
> *Cc:* dev@groovy.apache.org
> *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 (<re...@gmail.com>)
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_moditect_moditect_issues_67&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=cocTYR8h3W8Rgqstyq52P9cQq-9lpVTUcc3nlMo8bI4&s=rZMbQ03MlXNGQEPuzueT5_EYYUeSQF8iF1JOgKJpqSw&e=>
> 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
>
>
Re: requesting your advice on picocli modules
Posted by Remko Popma <re...@gmail.com>.
On Fri, May 31, 2019 at 6:11 AM Milles, Eric (TR Tech, Content & Ops) <
eric.milles@thomsonreuters.com> 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 <ma...@gmail.com>
> *Sent:* Thursday, May 30, 2019 3:05 PM
> *To:* users@groovy.apache.org
> *Cc:* dev@groovy.apache.org
> *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 (<re...@gmail.com>)
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_moditect_moditect_issues_67&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=cocTYR8h3W8Rgqstyq52P9cQq-9lpVTUcc3nlMo8bI4&s=rZMbQ03MlXNGQEPuzueT5_EYYUeSQF8iF1JOgKJpqSw&e=>
> 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
>
>
Re: requesting your advice on picocli modules
Posted by "Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>.
Could your "picocli.groovy" package move to the groovy-cli-picocli subproject?
________________________________
From: Mario Garcia <ma...@gmail.com>
Sent: Thursday, May 30, 2019 3:05 PM
To: users@groovy.apache.org
Cc: dev@groovy.apache.org
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 (<re...@gmail.com>>) 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_moditect_moditect_issues_67&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=cocTYR8h3W8Rgqstyq52P9cQq-9lpVTUcc3nlMo8bI4&s=rZMbQ03MlXNGQEPuzueT5_EYYUeSQF8iF1JOgKJpqSw&e=> 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
Re: requesting your advice on picocli modules
Posted by Mario Garcia <ma...@gmail.com>.
+ 1 picoli-groovy.jar
Great project BTW!
El jue., 30 may. 2019 a las 14:51, Remko Popma (<re...@gmail.com>)
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 <https://github.com/moditect/moditect/issues/67> 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
>
>
Re: requesting your advice on picocli modules
Posted by MG <mg...@arscreat.com>.
Hi Remko,
I agree option 1) is the cleanest, as well as it being the direction all
of Groovy seems to be moving.
Cheers,
mg
On 30/05/2019 14:50, Remko Popma wrote:
> 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 <https://github.com/moditect/moditect/issues/67> 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
>
Re: requesting your advice on picocli modules
Posted by Mario Garcia <ma...@gmail.com>.
+ 1 picoli-groovy.jar
Great project BTW!
El jue., 30 may. 2019 a las 14:51, Remko Popma (<re...@gmail.com>)
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 <https://github.com/moditect/moditect/issues/67> 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
>
>