I recently upgraded a project to Grails 1.3.5. This deleted everything in the /lib dir, though the project continues to work, so I guess the way dependencies are specified (and the location they're stored) has changed. I want to remove some libs that I'm no longer using, but can't do this until I find where the dependencies are specified.
Thanks,
Don
I'm surprised that anything was deleted from your lib directory - that shouldn't happen.
Dependencies are registered in BuildConfig.groovy in your app and in the plugins that work with Grails 1.2 and above. Older plugins will continue to have jars in their lib directories which will be added to the classpath, and you can still do the same. Obviously it's best to use the dependency management if possible so you have just the one copy of the jar in your Ivy cache instead of one for every project on your machine.
You can run grails dependency-report to generate Ivy reports to see what's managed by Ivy in each environment. These will end up in target/dependency-report and there's no index file, so just open any of the .html files and you can navigate to the others from there, e.g. target/dependency-report/org.grails.internal-{appname}-runtime.html.
Related
I'm not sure how to ask this question, but I'll try anyway. I found different people having some kind of similar problem. But none with the exact same issue.
I have a grails 2.3.x application, it uses a customized version of a plugin. I'm use to old versions of Grails (pre-Maven dependency resolution), when we were able to include the customized version of the plugin into the /lib folder. I'm doing the same thing, but I am not able to solve anything. :(
Is there a way to tell grails, that lib directory (or some other, into the project folder) have the plugin zip file on it as we were use to?
UPDATE
Just to clarify. I want the packaged plugin into the project directory, not the source code.
UPDATE 2
Try to add the packaged plugin into plugins folder inside project root without any luck. While BuildConfig.groovy have the dependency declared or not.
Not sure if I have understood your question correctly. It seems you want to use a customized version of a plugin in your grails-app. You can do so by creating a "custom-plugins" folder in the root of the application and placing the custom version of the plugin inside this folder. Then in the BuildConfig we can specify the plugin location at the beginning of the file like this:
Assuming I have
myGrailsApp/custom-plugins/custom-plugin-1
grails.plugin.location."custom-plugin-1"="custom-plugins/custom-plugin-1"
That is it.
If you package the plugin as a .zip file and put it in a plugins directory in the root of your application, it will be loaded from there. You might also need to remove the plugin dependency declaration from BuildConfig.groovy before this will work.
I use Grails 2.2.3. I have put jar file in lib directory, IDEA immediately resolved the dependency. But when I start app I get NullPointerException on class from this library. If I try it second time or more I get java.lang.NoClassDefFoundError. I found a lot of advice how to resolve this issue but none were useful in my case.
Library (mylib-1.jar) compiled in maven and added to lib dir. In BuildConfig.groovy, dependency is mentioned as:
dependencies {
compile 'com.mylib:mylib:1'
}
I tried
grails clean
grails compile --refresh-dependencies
grails refresh-dependencies
but nothing helps. In result war file I can see this library in WEB-INF/lib, but even if deploy this war I get the same error.
How can this be resolved?
You're confusing NoClassDefFoundError with ClassNotFoundException. ClassNotFoundException happens when a class you want isn't there, but you get a NoClassDefFoundError when the class is there, but a class it depends on isn't. So you're missing another jar file that this jar file depends on.
This is one of the many reasons why it's best to use dependency management instead of manually copying jar files to the lib directory. If you use a Maven repo where the jars have proper POM files, their dependencies are specified, and the resolver can download the entire tree of dependencies for you, rather than you having to find all of the jars yourself.
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.
I used yesterday itext-2.0.8 and today i changed to itext-2.1.7. even it is picking 2.0.8 into war file also two versions of itext jars are coming in war file. Now, there is no reference in pom or BuildConfig regarding 2.0.8, even it adding in war file.
Why it picking old referred jars and what bases it selecting which jars need to go for war file.
What should i do to eliminate them.
i deleted target folder and i run grails clean, even same output.
i think, i have to manually delete the all itext-2.0.8 in maven repo(.m2) and grails repo(.grails).
please give me your valuable suggestions please
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")