groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: requesting your advice on picocli modules
Date Fri, 31 May 2019 16:28:55 GMT
Hi Remko,

I agree option 1) is the cleanest, as well as it being the direction all 
of Groovy seems to be moving.


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