weird compile error for groovy script

[webczat]

Hello, I have a script with many classes in a project, the script itself uses things like groovy's cli builder.
When trying to compile the project, i get such error:
Description Resource Path Location Type
The project was not built since its build path is incomplete. Cannot find the class file for org.apache.commons.cli.CommandLineParser. Fix the build path then try building this project letsencrypt-client Unknown Java Problem
Description Resource Path Location Type
The type org.apache.commons.cli.CommandLineParser cannot be resolved. It is indirectly referenced from required .class files Engine.groovy /letsencrypt-client line 1 Java Problem
Of course I know I use it indirectly, but what's wrong? it is bundled in groovy-all, or it is not?

[eric-milles]

Commons CLI is packed with groovy-all, but in a translated form. It is intended for internal use. If you are trying to reference "org.apache.commons.cli" in any of your sources, you will need to pull in commons-cli.

[webczat]

well, does it also affect referencing it indirectly using a CliBuilder? I am not directly referencing commons cli. is that the intention that I should download it myself?
It is not the case for a normal version of groovy.
Also, if so, shouldn't eclipse plugin add it automatically like it does with ivy?

[eric-milles]

So I'm getting that you are not using any Commons CLI classes directly in your sources. You are only referencing the CliBuilder. Can you provide a short example script that demonstrates the problem?

[webczat]

I have reported this same bug to groovy as it does not seem to be greclipse related, but they answerred like you did, that commons-cli is repacked for internal use. Still, groovy apis themselves allow you to for example parse command line, their answer is that it is an intended behavior that I should add commons-cli to classpath. You already bundle bsf and servlet api and ivy for ... actually identical reason.
To cause the problem, run this... single line of code
c = new CliBuilder()
when running from eclipse it should not work, and definitely won't after running it by
java -cp /path/to/groovy-all.jar groovy.ui.GroovyMain scriptname.groovy
but will work with commons-cli on classpath or when running groovy normally

[eric-milles]

If the intended use, even for core Groovy is:

@Grab('commons-cli:commons-cli:1.3.1')
def cb = new CliBuilder()
...

Then this is a non-issue. Adding commons-cli to the Groovy Libraries container would not help you in building a standalone command-line utility.

[webczat]

no. groovy bundles normal commons-cli, and if you actually use groovy from command line like by using a groovy command from shell, then this commons-cli is loaded and used properly. so @grab for commons-cli is not what they intent.

[webczat]

also you already bundle bsf and ivy and servlet api. it is as optional as commons-cli, so commons-cli should be there for same reason they are.

[eric-milles]

Those were added before my time. I'm of the opinion they should be removed rather than adding new ones. @grab should replace the need for any bundling of fixed versions of libraries.

[webczat]

are you avare that grabbing will break? you know, normal groovy tar.gz contains commons-cli and stuff. And, actually, that means grabbing commons-cli in presence of another one on the classpath is an error, and I have experienced that directly, when I directly tried to use my own version of commons-cli. So I would not use grab for something like that.

[eric-milles]

You can add a jar file to your .groovy/lib directory a lot faster than I could ever add a library to the Groovy Support classpath container. You can choose any version of a dependency you wish and not get locked into a choice made by someone else. I'm not sure I understand the wisdom of compelling me to make a change to the classpath container.

[webczat]

the reason is compatibility with groovy itself, because only when you start an embedded one with manually specifying a classpath, you have such a problem. normally it just works. I find that behavior a little counterintuitive, because I have to add something to .groovy/lib to make it work under eclipse, while i don't in any other case.