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

[Nick <oi...@letterboxes.org>]

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

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

[Paul King <pa...@asert.com.au>]

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 <oi...@letterboxes.org> wrote:

> Hello,
>
> I asked a question on stack overflow, I wonder if anyone here knows the
> answer?
>
> https://stackoverflow.com/questions/49452422/why-does-groovy
> s-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
>
>