Why does Groovy's CliBuilder depend on apache commons-cli, which isn't included in groovy-all?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Why does Groovy's CliBuilder depend on apache commons-cli, which isn't included in groovy-all?

Nick
Hello,

I asked a question on stack overflow, I wonder if anyone here knows the
answer?

https://stackoverflow.com/questions/49452422/why-does-groovys-clibuilder-depend-on-apache-commons-cli-which-isnt-included

To quote it:

 > I've been attempting to use the Groovy CliBuilder, as described here:
 >
 > http://docs.groovy-lang.org/2.4.7/html/gapi/groovy/util/CliBuilder.html
 >
 > However, it depends on classes missing from groovy-all-2.4.7,
specifically those in Apache's commons-cli library.
 >
 > Ok, so I could add that dependency. But I find there is what looks
like a version of the Apache CliBuilder class bundled in groovy-all in
the groovyjarjarcommonscli package!
 >
 > Firstly, why bundle that at all?
 >
 > Secondly, why not use it to back Groovy's CliBuilder implementation?
 >
 > Thirdly, can I rely groovyjarjarcommonscli being there for use in the
future?


Thanks!

Nick

Reply | Threaded
Open this post in threaded view
|

Re: Why does Groovy's CliBuilder depend on apache commons-cli, which isn't included in groovy-all?

paulk_asert
The groovy-all jar doesn't bundle Groovy's optional dependencies such as: ant, junit, bsf, commons-logging, log4j, jline, testng, xstream, commons-cli, jansi, ivy, etc. It includes all of Groovy's modules and embeds a small set of required dependencies for its own internal purposes like asm and antlr and commons-cli.

This lets you write scripts or classes which also use those dependencies directly or indirectly, e.g. hibernate uses antlr, spring uses asm and importantly they might be different versions and that's okay.

The embedded commons-cli is used for the command-line tools (groovy, groovyc, groovysh, groovyConsole etc.). There are other technical reasons like classloader issues related to the approach we have taken but mostly it's a separation of concerns issue. We might change what cli handling package we use internally and we might supply different modules which offer different CliBuilder implementations which might have different dependencies. We don't want to tie all these things together. Technically, you can use the groovyjarjarcommonscli package if you want direct access to the commons-cli library though it's not recommended and it's not possible via CliBuilder - it is specifically designed not to use the internal one. In the future with JDK9/10+ we will likely not make such embedded packages visible at all.

Long story short, add the commons-cli dependency to your project and/or classpath. That's the correct approach.

Cheers, Paul.


On Fri, Mar 30, 2018 at 1:02 AM, Nick <[hidden email]> wrote:
Hello,

I asked a question on stack overflow, I wonder if anyone here knows the answer?

https://stackoverflow.com/questions/49452422/why-does-groovys-clibuilder-depend-on-apache-commons-cli-which-isnt-included

To quote it:

> I've been attempting to use the Groovy CliBuilder, as described here:
>
> http://docs.groovy-lang.org/2.4.7/html/gapi/groovy/util/CliBuilder.html
>
> However, it depends on classes missing from groovy-all-2.4.7, specifically those in Apache's commons-cli library.
>
> Ok, so I could add that dependency. But I find there is what looks like a version of the Apache CliBuilder class bundled in groovy-all in the groovyjarjarcommonscli package!
>
> Firstly, why bundle that at all?
>
> Secondly, why not use it to back Groovy's CliBuilder implementation?
>
> Thirdly, can I rely groovyjarjarcommonscli being there for use in the future?


Thanks!

Nick