Could your "picocli.groovy" package move to the groovy-cli-picocli subproject?

________________________________
From: Mario Garcia <mario.g...@gmail.com>
Sent: Thursday, May 30, 2019 3:05 PM
To: us...@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 
(<remko.po...@gmail.com<mailto:remko.po...@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

Reply via email to