Re: requesting your advice on picocli modules
On Fri, May 31, 2019 at 6:11 AM Milles, Eric (TR Tech, Content & Ops) <
eric.mil...@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
> *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 ()
> 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
>
>
Re: requesting your advice on picocli modules
Could your "picocli.groovy" package move to the groovy-cli-picocli subproject?
From: Mario Garcia
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
(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
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
+ 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
>
>
[GitHub] [groovy-website] paulk-asert edited a comment on issue #10: SSL Certificate not signed by a standard certificate authority
paulk-asert edited a comment on issue #10: SSL Certificate not signed by a standard certificate authority URL: https://github.com/apache/groovy-website/issues/10#issuecomment-497450454 Groovy's repos are here: https://gitbox.apache.org/repos/asf and most mirrored on github. Currently the :site-dev:generateSite task in the groovy-website repo is used to build the dev site. I manually copy the generated content into the groovy-dev-site (asf-site branch) and then commit. We have tasks in the groovy-release gradle build files that do such git operations. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy-website] paulk-asert commented on issue #10: SSL Certificate not signed by a standard certificate authority
paulk-asert commented on issue #10: SSL Certificate not signed by a standard certificate authority URL: https://github.com/apache/groovy-website/issues/10#issuecomment-497450454 Groovy's repos are here: https://gitbox.apache.org/repos/asf Currently the :site-dev:generateSite task in the groovy-website repo is used to build the dev site. I manually copy the generated content into the groovy-dev-site (asf-site branch) and then commit. We have tasks in the groovy-release gradle build files that do such git operations. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy-website] paulk-asert edited a comment on issue #8: Clarification: any purpose for master branch?
paulk-asert edited a comment on issue #8: Clarification: any purpose for master branch? URL: https://github.com/apache/groovy-website/issues/8#issuecomment-497447395 We may still delete the branch but I am travelling at the moment and not game to try that since I probably won't get time to fix right now if anything goes wrong. I'll leave issue open for the time being. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy-website] paulk-asert commented on issue #8: Clarification: any purpose for master branch?
paulk-asert commented on issue #8: Clarification: any purpose for master branch? URL: https://github.com/apache/groovy-website/issues/8#issuecomment-497447395 We may still delete the branch but I am travelling at the moment and not game to try that since I probably won't get time to fix right now if anything goes wrong. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy-website] paulk-asert commented on issue #10: SSL Certificate not signed by a standard certificate authority
paulk-asert commented on issue #10: SSL Certificate not signed by a standard certificate authority URL: https://github.com/apache/groovy-website/issues/10#issuecomment-497446851 Fixing the user site is a couple of steps away. I may not get to look at it for some weeks. Next step is getting dev site properly automatic. In the groovy-website repo there is a gradle build which produces the site zip. We need to add another task to check that into the groovy-dev-site repo as a fresh check in. We can probably reuse some task defns from the groovy-release repo. It will need someone with Apache credentials to test. Fixing the user site will then be a replication of this but with a bit more work first and won't build a total replacement but additions for each release as well as some content which is replaced whenever we rebuild the site. Plus we need to liaise with Apache infra to get the new site in place... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy-website] paulk-asert commented on issue #9: Set execute bits on ./gradlew script
paulk-asert commented on issue #9: Set execute bits on ./gradlew script URL: https://github.com/apache/groovy-website/pull/9#issuecomment-497445847 merged, thanks This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy-website] asfgit closed pull request #9: Set execute bits on ./gradlew script
asfgit closed pull request #9: Set execute bits on ./gradlew script URL: https://github.com/apache/groovy-website/pull/9 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy-website] visch opened a new issue #10: SSL Certificate not signed by a standard certificate authority
visch opened a new issue #10: SSL Certificate not signed by a standard certificate authority URL: https://github.com/apache/groovy-website/issues/10 Replicate, go to https://groovy-lang.org/api.html in the latest version of chrome and look at the HTTPS status. I'll dive into this tonight and see if I can't help move the needle on this. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy-website] leoger commented on issue #9: Set execute bits on ./gradlew script
leoger commented on issue #9: Set execute bits on ./gradlew script URL: https://github.com/apache/groovy-website/pull/9#issuecomment-497413050 It's just the file permissions. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy-website] leoger opened a new pull request #9: Set execute bits on ./gradlew script
leoger opened a new pull request #9: Set execute bits on ./gradlew script URL: https://github.com/apache/groovy-website/pull/9 Without this change, someone who tries to follow the instructions in README.adoc under either "Generating the [...] site" section will simply get a "Permission denied" error from their shell if they are on a Unix-like system. We ought to make that initial experience better, so I changed the mode on the build wrapper from 644 to 755. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy-website] leoger commented on issue #8: Clarification: any purpose for master branch?
leoger commented on issue #8: Clarification: any purpose for master branch? URL: https://github.com/apache/groovy-website/issues/8#issuecomment-497410403 Thanks! That's pretty obvious now, what with there being nothing there except for the README and gitignore. It does seem to clutter the `git log --graph` output and similar views. Something to consider, but it's your judgment call, of course. Since there's potentially additional action, I am not closing this issue, but you should go ahead and close it when you decide. Thanks again. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
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 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
