I'm using Eclipse 4.5 with the Groovy-Eclipse 2.9.2/4.5 plugin which I thought was supposed to have the Groovy 2.5 compiler. However, it didn't have any picocli support so I added the groovy-cli-picocli-2.5.2-indy.jar to my classpath and was able to compile. However #2, when trying to run the script via Eclipse I get:
java.lang.ClassNotFoundException: picocli.CommandLine$ParameterException
It looks like groovy-cli-picocli-2.5.2-indy.jar does not have CommandLine class at all.
I would just throw jars at this from the fullblown picocli distribution but I'm under the impression they all have to somehow wrap nicely into Eclipse Groovy library via groovy.cli.picocli.CliBuilder.
Is my Groovy 2.5.2 missing this or am I somehow missing the boat on how it's supposed to work because picocli is not working for me in this configuration. Thanks!
You are correct: groovy-cli-picocli-2.5.2.jar (and groovy-cli-picocli-2.5.2-indy.jar) do not contain the picocli classes.
You need to add the picocli jar to the classpath.
If you use Maven, the groovy-all POM should include all dependencies.
(My original answer mentioned picocli classes that are shaded into the groovy-2.5.x.jar under the groovyjarjarpicocli package but these are intended for use internally by Groovy and not meant to be used by applications.)
Related
All groovyconsole binary distros I have found don't support Java 14. The console complains if you try to specify a Jar file that has been compiled with Java 14, for example.
The obvious solution, I thought, was to build Groovy with Java 14. That seems non-trivial.
gradle.wrapper.properties files contain
distributionUrl=http://services.gradle.org/distributions/gradle-2.3-bin.zip
which is a broken URL. Change that to https and then it works, partially.
You then get
FAILURE: Build failed with an exception.
What went wrong:
Could not determine java version from '14.0.2'.
Reading the docs for gradle makes it clear that most (all?) versions of gradle do not support Java 14. Definitely version 2.3 does not. Why - I have no idea.
So... back to my original question. How can I get a groovy installation to support Java 14?
Thanks!
If the Jar cannot be loaded, it is most likely the asm lib, which is unable to read it. To read Java14 you need at least ASM 7.2 I think. ASM in Groovy is not provided as standalone library, because of possible conflicts with other jar dependencies it is shadowed (bytecode is transformed by renaming the packages and directly added to the Groovy jar). I see here 2 options:
compile Groovy yourself and change the dependencies to have at least ASM 7.2. It does not matter if you build Groovy with a lower version of the JDK, the JDK still allows to read "old" jars.
use at least Groovy 2.5.9, 3.0.0 or 2.4.19, as they include asm 7.2 or higher
Of course this does not mean it will change the Groovy Gradle is using easily. For that I would use Groovy 2.5 and read Bumping Groovy version in Gradle?
If this does not solve the problem or answer the question I would need more details.
I'm pretty new to Groovy (coming from Java), so this may be a stupid question :-)
Nonetheless: I'd like to structure a couple of Groovy scripts using packages. And I'd like to import some general Groovy classes from some other package.
How can I make sure that my Groovy scripts finds the other classes in the other packages? The only classpath related files I can remember are JARs.
If you from java:
Groovy loads classes as java and also includes non-compiled with extension .groovy.
So, you have to place your classes relative to classpath according to their package name.
The command line should be something like this:
groovy -cp "path_to_classes_root" "path_and_name_of_main_groovy_script.groovy"
I believe this problem not to be related to module exclusions in JDK 9 (as with java.se.ee), but rather with the fact that JDK 9 includes a newer version of org.w3c.dom.ls in the java.xml module that does not have the DocumentLS class.
The important bit of the stack trace is this:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [spring-test/test-container.xml]; nested exception is java.lang.NoClassDefFoundError: org/w3c/dom/ls/DocumentLS
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:414)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:304)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:181)
Even if I include a runtime dependency with this class, like xerces:xerces 2.4.0, the JDK java.xml module is preferred (I guess).
I am using Gradle 4.1. Is there any way to restrict the scope of a
JDK provided module?
As you have correctly analyzed, the package org.w3c.dom.ls is present in the platform module java.xml. Any class on the class path that is in the same package will be ignored. That's called a split package and several fixes exist - the following two might help you.
Patch java.xml
You can add the classes of the Xerxes JAR to the java.xml module with --patch-module:
java --patch-module java.xml=xerxes-4.0.0.jar ...
I've never tried that with a JAR that contains some of the same classes. As I understand it, the JDK classes will then be replaced with the Xerxes classes, which means they better be a fully binary compatible replacement.
Upgrade java.xml
Another hope is to replace java.xml with the upgrade module path:
The upgrade module path (--upgrade-module-path) contains compiled definitions of modules intended to be used in place of upgradeable modules built-in to the environment (compile time and run time).
You face two problems:
the upgrade module path is supposed to be used only for upgradable modules (which java.xml is not), but I think I've read somewhere that that's not enforced (yet?) - didn't try it
the artifact you replace java.xml with needs to be fully binary compatible update - would that be the case for Xerxes?
From what I can tell, DocumentLS is from a 2002 draft of the W3C API, it doesn't appear to have made it into a released version. It looks like xerces-2.4.0 (from 2006?) includes it but newer versions don't. So upgrading to a more recent Xerces may be needed here. If Spring really depends on DocumentLS then it will need to be updated too.
I upgraded to groovy 2 release and now my build is broken.
It fails when importing classes: groovy.json.JsonSlurper and XmlSlurper.
I have checked http://groovy.codehaus.org/gapi/ and cannot find these classes anymore. Do they still exist in groovy 2? Or have they moved somewhere?
The groovy.jar distributed with groovy 2 has been split out to contain just the bare minimum, with all the additional modules (XML, SQL, JSON, etc.) in separate jars. However, in the embeddable directory, you'll find a jar file groovy-all-2.0.0.jar which contains groovy and all the modules together, like previous versions. The easiest way to migrate is to use this jar file.
If you're using Maven Central, you can use an artifactId of groovy-all to get everything, or groovy (plus modules) to have finer grained control over your dependencies. Here's a list of the modules available on Maven Central: http://search.maven.org/#search|ga|1|g%3A%22org.codehaus.groovy%22
Never mind. Need to include groovy-xml and groovy-json jars.
These were split from groovy's jar. See: http://www.infoq.com/articles/new-groovy-20
When I import, groovy-json-2.4.3 and groovy-xml-2.4.3 , JsonSlurper is recognized.
Also refer for new code refactor after 1.8.0 version: Parsing array of JSON arrays in Groovy
I faced a similar issue in Gradle build of a Java project (Gradle uses Groovy).
Gradle stopped including the local Groovy libs in classpath automatically. So, I had to include the following lines (marked with +) in my build.gradle file:
buildscript {
ext {
springbootVersion = '2.x.x'
awsVersion = '1.x.x'
...
}
+ dependencies {
+ classpath localGroovy()
+ }
repositories ...
}
Instead of using "groovy.json.jsonSlurper", use "net.sf.json.groovy.JsonSlurper".
Your script must be running.
I'm on Windows 7 64-bit, using JDK 1.6.0_29, groovy 1.8.1, and JasperReports/iReport 4.1.3.
I have the following jars from the JasperReports distribution in my CLASSPATH:
commons-beanutils-1.8.0.jar, commons-collections-2.1.1.jar, commons-digester-1.7.jar, commons-logging-1.0.4.jar, jasperreports-4.1.3.jar, poi-3.7-20101029.jar
I have also tried adding all the jars in the ${JASPER_HOME}/lib distribution in case I was missing some important jar.
The jasper report is to be generated by a groovy script. I have created a very simple report with iReport that contains only some static text in the title. I am able to compile and view the report from within iReport.
When I try and compile the report from the script:
def jasperReport = JasperCompileManager.compileReport("filename")
I get the following error:
Caught: java.lang.AbstractMethodError
java.lang.AbstractMethodError
at net.sf.jasperreports.compilers.JRGroovyCompiler.compileUnits(JRGroovyCompiler.java:96)
at net.sf.jasperreports.engine.design.JRAbstractCompiler.compileReport(JRAbstractCompiler.java:188)
at net.sf.jasperreports.engine.JasperCompileManager.compileReport(JasperCompileManager.java:212)
at net.sf.jasperreports.engine.JasperCompileManager.compileReport(JasperCompileManager.java:145)
at net.sf.jasperreports.engine.JasperCompileManager$compileReport.call(Unknown Source)
at wis_validate_environment.run(wis_validate_environment.groovy:58)
Is there possibly some conflict between the groovy that JasperReports is using (JRGroovyCompiler? from the stacktrace) and the groovy that I am using to compile the report?
There were a couple of things I had to change in order to resolve this issue.
Creating a report using the Report Wizard and the default settings creates the language="groovy" parameter in the jasperReport tag. When I remove language parameter, I no longer get the AbstractMethodError mentioned above.
I also needed to add the jdt-compiler-3.1.1.jar in my classpath.
I found the problem was explained here:
http://www.mail-archive.com/user#ofbiz.apache.org/msg23404.html
There seems to be a problem with the versions of one of the dependent libraries that our project uses that conflicts with groovy's.
In short use groovy-all.jar or make sure are your dependancies match those of the version of groovy you are using.