I have a grails app and the groovy under /src/groovy has import statements for Java POI HSSF
for example
import org.apache.poi.hssf.usermodel.HSSFWorkbook
import org.apache.poi.hssf.usermodel.HSSFCellStyle
What is the best way to add POI to my grails app so its deployed with the war. I tried adding the jars to /lib and then adding them as runtime dependencies in BuilConfig.groovy.
dependencies {
runtime 'mysql:mysql-connector-java:5.1.22'
runtime 'poi-3.9-20121203'
runtime 'poi-ooxml-3.9'
runtime 'poi-ooxml-schemas-3.9'
runtime 'xml-apis-ext-1.3.04'
runtime 'xmlbeans-2.3.0'
runtime 'xmlpull-1.1.3.1'
runtime 'xstream-1.4.7'
}
I also tried adding it as a compile plugin this way
plugins {
runtime ":hibernate:3.6.10.13"
compile ":excel-import:1.0.0"
}
Both generate this error on grails war
java.lang.NoClassDefFoundError: _GrailsClasspath_groovy$_run_closure1
EDIT: my repositories has maven but still complains about missing class def Read jars from lib folder in grails
While adding any dependency or plugin in Grails, maven artifact semantics has to be followed instead if the plain jar name. For example,
runtime 'xmlbeans-2.3.0'
should be
runtime 'org.apache.xmlbeans:xmlbeans:2.3.0'
which corresponds to
runtime '<groupId>:<artifactId>:<version>'
Same is applicable for all the other dependencies and plugins. Rewrite those one by one and remove all jars from lib directory. Clean and compile the app subsequently.
Related
I'm trying to find documentation and code samples on how to add a local / non-maven jar file to my Grails 3.x project?
I found the separate thread How to add a non-maven jar to grails - but that's only to grails 2.3, and the file structure and configuration has undergone a big overhaul in 3.x.
Any help and (especially) code samples would be wonderful! The .jar is in the local project directory, and I intend to package with the .war for deployment.
Additionally, once i add the dependency, should i just be able to call it's methods from the controller & service files? or do i need to include them in those as well?
thx!
Grails 3 uses Gradle, so there's nothing Grails specific about including a local jar. It's as easy as adding a file dependency to the dependencies block of your build.gradle file.
Per the Gradle documentation on File Dependencies:
To add some files as a dependency for a configuration, you simply pass a file collection as a dependency:
dependencies {
...
compile files('libs/a.jar', 'libs/b.jar')
// or
compile fileTree(dir: 'libs', include: '*.jar')
}
The above example shows two ways to include jars that exist in a local libs/ directory; you can do either/or. The jar(s) can be anywhere on the filesystem, just make sure you point to the correct path.
To use the classes from the dependency in your application, you'll include them in your services, controllers and all other classes like you normally would. Say libs/a.jar has a class org.example.Something, you'd add an import to the top of your Grails class like so:
import org.example.Something
Grails is able to configure dependencies when you specify them in the BuildConfig.groovy file. Usually when you add it there and call grails compile --refresh-dependencies it will resolve the dependency, and download to .grails/ivy-cache/..... (in my case). However, one time, after downloading the jar files, it failed to automatically add the jar to the classpath. Does anybody have any idea on how this will happen? It has worked for me before on many other Maven repository dependencies. The specific dependency I failed to add to my Grails project classpath is http://mvnrepository.com/artifact/javax.mail/mail/1.4.7
I can just manually add the lib to the classpath, but I'd rather have dependencies resolved automatically with the BuildConfig.groovy file. I also can't manually add jars into the "Grails Dependencies" library in the classpath; they can only be outside that library.
I was trying to add some Java Libraries (AWS SDK for Java, Apache Commons Math, etc.) to my Grails project since some of my Java source code (placed in src/java) had dependencies. By following this answer, I was able to resolve compile errors by adding the jar files to the /lib folder and add it to the build path, as answered here: Add Java Libraries to a Netbeans Grails Project
However, when I call my Java source code from my controller during runtime, it is unable to find the Java libraries that I added, showing a NoClassDefFoundError. Should I be adding something to the BuildConfig.groovy file? I'm not sure what the name convention for the jar files to be added to the dependencies.
The question you refer to is 5 years old. You should use newer resources :)
The preferred approach now is to use dependencies in BuildConfig.groovy, and let Grails (via Ivy or Maven) download the jars for you once and reuse them for various projects.
It's not always obvious what the syntax is, and I find that http://mvnrepository.com/ is a great resource. For example if you search for "commons math" and click through to http://mvnrepository.com/artifact/org.apache.commons/commons-math you'll see a few versions. Click on version 2.2 and you'll see the Maven dependency XML but you can click on the Gradle tab and it's going to be similar to what you need for Grails. So I'd add
dependencies {
compile 'org.apache.commons:commons-math:2.2'
}
and if necessary change compile to runtime, build, etc. depending on what you need the jar in the build process.
In the rare case that you do have a jar that isn't available in a Maven repo (e.g. a shared library at your company) then you can put the jar file in the lib directory. As you've seen, Grails doesn't auto-detect it (this is as of version 2.0). But you can run grails compile --refresh-dependencies to get your jar added to the classpath.
My issue turns out to be the fact that AWS Java SDK had dependencies (Apache HTTP Client) that were not installed yet and that I was unaware of.
This is what I had to configure this for my BuildConfig.groovy file
dependencies {
runtime 'org.apache.httpcomponents:httpclient:4.2.5'
runtime 'com.amazonaws:aws-java-sdk:1.4.7'
}
All the dependencies for AWS Java SDK 1.4.7 can be found here: http://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk/1.4.7. All the dependencies outside of HTTP client were already installed for me, but may not be for your Grails setup.
How do I reference a dependency by convention within my project build path? Allow me to elaborate...
I'm using the Groovy/Grails Tool Suite (GGTS 3.0). I'm referencing the dependency as such in my BuildConfig.groovy:
dependencies {
compile 'tgt:jaxb-utils:1.0'
}
The referenced jar file is successfully pulled down from the Artifactory repo - I can find the jar file on my local file system in the Ivy cache. When I run any grails targets (grails compile, grails run-app, grails run-tests), it works fine - meaning my code that imports the classes from the jar has no problems. When I run grails war, the referenced jar file is packed into the constructed war.
However, and here is the crux of this post - the project build path does not reference this jar file by default or convention, so my java or groovy code that imports the classes from the jar file reports a unable to resolve class ... error.
One solution is to simply add the jar file to the lib folder and update the build path accordingly, or modify the build path to reference the jar file in the Ivy cache folder. However, I'd have to do this for any/all dependencies pulled down in this way. Any jars in the lib folder will get saved to the team source code repository, and that seems like wasted space since the grails commands work fine with just the dependency reference in BuildConfig.groovy.
Am I just being too idealistic (ie - difficult) here, or is there a better way to clean up the unable to resolve class ... errors in my IDE without having to manually add the dependent jar files to my lib folder and update my build path? Ideas?
Eclipse / STS / GGTS : If you have Grails plugin installed, you can do the following :
Right click on your project -> Grails Tools -> Refresh dependencies (or shortcut "Alt+G, R")
What's the difference between build, runtime, and compile, in BuildConfig.groovy (1.3.7)
grails.project.dependency.resolution = {
plugins {
build "acme:acme-cache:latest.integration"
}
dependencies {
build "com.foo.bar:foobar:1.0.5"
runtime "org.apache.httpcomponents:httpclient:4.0.3"
compile("com.thoughtworks.xstream:xstream:1.3.1")
}
}
build - dependency that is only needed by the build process
runtime - dependency that is needed to run the application, but not compile it e.g. JDBC implementation for specific database vendor. This would not typically be needed at compile-time because code depends only the JDBC API, rather than a specific implementation thereof
compile - dependency that is needed at both compile-time and runtime. This is the most common case
There are a couple of other dependency scopes:
test - dependency that is only needed by the tests, e.g. a mocking/testing library
provided - dependency that is needed at compile-time but should not be packaged with the app (usually because it is provided by the container). An example is the Servlet API
It seems the 2 previous answers conflict on the distinction between compile and build. I believe that build is the scope that includes grails compile and grails run-app, while compile is just the former.
Starting from Grails 3, dependencies are managed by Gradle. The grails-app/conf/BuildConfig.groovy file has been replaced by the build.gradle file in the project's root.
The Grails user guide explain how to set grails depencies with gradle. See also the related Gradle documentation for further details on managing dependencies using it.
A couple grails commands help illustrate the difference. Consider grails run-app and grails compile. grails compile is the compile step and will include compile-time dependencies. grails run-app is the run step and will include runtime dependencies. Build dependencies are anything that you might need to run any of these commands, for example, a custom script that hooks into some build events.
So you would pick the one that best fits when you need to be certain the dependency is included.