My grails app should work with two plugins: shiro and quartz2.
I'm add both of plugins to BuildConfig.groovy:
compile ":shiro:1.1.4"
compile ":quartz2:2.1.6.2"
(after that ide downloaded them)
The problem in dependencies: shiro depends from shiro-quartz:1.2.0 and shiro-quartz from org.opensymphony.quartz 1.6.1
I wonder why but quartz2 looking for methods implementation to quartz-1.6.1.jar.
Quartz2 cannot find implementations and that's why project cannot be build.
I think quartz2 should search methods implementations in "normal" quartz lib, like quartz:1.0-RC7, but he do not.
So, how can i solve shiro and quartz2 plugins conflict?
I heard about dependency excluding, but i not sure about this sugesstion.
P.S. with quartz(not quartz2) the same problem occurred
You can run dependency-report to check what dependencies the plugins are trying to add to your project. The problem seems to be that shiro-quartz depends on quartz 1.x and quartz plugin uses quartz 2.x.
Normally you could do:
compile (":shiro:1.1.4") {
excludes('org.opensymphony.quartz:quartz')
}
But there's a bug, and this transitive dependency isn't excluded. There's an open ticket to adjust this.
The good thing is that there's a workaround:
compile (":shiro:1.1.4") {
excludes([name: 'quartz', group: 'org.opensymphony.quartz'])
}
With this, Grails will use Quartz 2.x only.
Related
In grails 2.x, we were allowed to add an in place plugin by adding following in BuildConfig.groovy
grails.plugin.location."my-plugin" = "../my-plugin"
My question is, can we add our local plugins similarly in-place in grails3.0 as well or there is some other way to do this in grails.
Actual purpose is to test the plugin whether it's working properly or not before pushing it to bintray.
Yes, there is. Grails 3 is based on Gradle so multi-project gradle builds solve your issue.
Basically you add dependency as:
compile project(':../my-custom-plugin')
and has to modify settings.gradle to include plugin:
include '../my-custom-plugin'
Check Grails documentation on Plugins and Multi-Project Builds in http://grails.github.io/grails-doc/latest/guide/plugins.html
Other way is to install plugin in local maven repository using gradle publishToMavenLocal command and resolve if from there, before publishing to Bintray or other dependency repository.
Additionally since Grails 3.1.1, reloading is now supported for 'inline' plugins. Check https://github.com/grails/grails-core/releases/tag/v3.1.1 and http://grails.io/post/138665751278/grails-3-gradle-multi-project-builds
It is done using grails { plugins { syntax. Copied from docs:
grails {
plugins {
compile ":hibernate"
compile project(':myplugin')
}
}
This multi-project thing is a bit too big to answer in a short post. I just recently started with it, but, thankfully, I now have the hang of it. There's a tutorial on my site with a plugin handling the domain classes and services and all other sub-projects (just one, a web application in this example) using the plugin. The code is also downloadable. Here's the link: http://www.databaseapplications.com.au/grails-multi-app.jsp Make no mistake, there are a few things to watch out for.
I am using grails 2.2.1, in windows.
I want to develop a plugin which depends on spring-security-core plugin, so I add dependency into BuildConfig.groovy of my plugin:
plugins {
compile ':spring-security-core:1.2.7.3'
}
Then in my grail application project, I specify the dependency in BuildConfig.groovy in:
grails.plugin.location."xxxxx" = "../grails-plugins/xxxx"
After that, when I try to refresh dependency of my grail application project, it always prompt
unable to resolve class org.springframework.security.authentication.UsernamePasswordAuthenticationToken
this class is a class depends on by spring-security-core plugin and my plugin use this class too.
Is it a grails bug? or I miss something? Please help, thanks in advance!
I tested here. In Grails 2.2.1 you need to set legacyResolve to true since
Grails 2.2 no longer uses the BuildConfig of the plugin for dependency
resolution and only uses data provided by POMs
When you set this and refresh dependencies the install messages of Spring Security Core will appear.
I've just switched to grails 2.2 and have got a major plugin problem. I've got an application - my-app and a plugin - my-plugin. I want to install spring-security-core plugin into my-plugin, and then install my-plugin into my-app. When I've done this and did s2-quickstart, so that LoginController got created. I can start my-plugin with no problems now, but when I try to start my-app it complains that it cannot find any springsecurity classes. Errors looks like this:
12: unable to resolve class org.springframework.security.web.WebAttributes # line 12, column 1.
7: unable to resolve class org.springframework.security.authentication.AccountExpiredException # line 7, column 1.
11: unable to resolve class org.springframework.security.core.context.SecurityContextHolder # line 11, column 1.
It looks to me, like only my-plugin can see spring security plugin dependencies, and my-app cannot, so they didn't cascade even thought according to manual they should have.
I've also tryed to install spring-security-core plugin by adding in BuildConfig.conf this:
compile ":spring-security-core:1.2.7.3"
but it didn't work either.
Any ideas?
If you use install-plugin in a plugin, it's only installed locally by adding a line in application.properties. It doesn't get exported as a dependency of your plugin. This could be used for plugins like code-coverage where you want to use it during development and testing but not force users to also install it.
In older versions of Grails the dependsOn map in the plugin descriptor was used to express plugin dependencies. This is now deprecated in favor of dependencies registered in the plugins secton of BuildConfig.groovy. This is both for consistency and to take advantage of the more fine-grained features supported by the dependency DSL including specifying scopes and exclusions. This is also true for applications - don't use install-plugin for either apps or plugins, always use BuildConfig.groovy.
Take a look at the spring-security-ldap plugin's BuildConfig.groovy. It has a compile-scope dependency on the core plugin, plus one for the hibernate plugin that's not exported (since it's just for testing) and a build-scope dependency on the release plugin (also not exported since it's just used to release the plugins).
You should probably using a similar dependency on the core plugin in your BuildConfig.groovy. Delete any plugin references in your application.properties and convert to BuildConfig.groovy syntax and run grails clean followed by grails compile.
Thank you Burt for your advice. I've used it and here's what I came to:
I created a plugin-app and installed spring-security-core plugin in it (using DataSource.groovy, and not install plugin). Then I created a main-app and installed my plugin-app (again using DataSource.groovy). When I did this in grails 2.1.1 everything worked just fine - I could use spring-security in my main-app, so the dependency got pulled just right. When I did everything the same, but in grails 2.2 I couldn't use spring-security in my main-app, so dependencies didn't get pulled. That's why I think this might be some kind of a bug in new grails version.
I am using Grails 1.3.7 and cannot figure out how to get version 4.0 of httpclient off of my classpath (in favour of 4.1). I need to do this because of a no-args constructer used in 4.1 that the plugin relies on.
Running a grails 'dependency-report', it appears that 4.1 should be the one being used at runtime. And it IS, if I package things up into a .war. HOWEVER version 4.0 is still ending up on the classpath when using run-app for some reason. Note it is (correctly) being used at compile time for some grails internals, and somehow it is still ending up on my classpath.
-> Can I figure out where exactly that 4.0 .jar is coming from and ending up on my classpath and stop it from happening (where are all the .jars put when running via run-app?)
-> Can I tell grails to compile with 4.1 instead of 4.0 for its internals (in this case the http-builder by org.codehaus.groovy.modules.http-builder module?) Arguable not the best solution but I'll take it, as packaging everything into a .war every time I want to test it is not pleasant.
Help would be greatly appreciated.
I just went through the same thing, add the following to your BuildConfig.groovy
dependencies {
build 'org.apache.httpcomponents:httpcore:4.1.2'
build 'org.apache.httpcomponents:httpclient:4.1.2'
runtime 'org.apache.httpcomponents:httpcore:4.1.2'
runtime 'org.apache.httpcomponents:httpclient:4.1.2'
}
cheers
Lee
You can get httpclient 4.0 off of the classpath by adding an excludes line in BuildConfig.groovy. Figure out which plugin is declaring it as a dependency by using the grails dependency-report command.
Once you find which one included it, you can exclude it in the plugins section of BuildConfig.groovy. Example:
plugins {
compile ':other-plugin:1.0.0' // other-plugin depends on httpclient 4.1
compile(':aws:1.2.12.2') { // aws plugin depends on httpclient:3.1
excludes 'httpclient'
}
}
The plugin that relies on the no-arg constructor in httpclient 4.1 should declare it as a dependency. If it does not you should open an issue with the author of the plugin. To workaround this, you can list httpclient 4.1 in the dependencies section as leebutts describes above.
I'm working with IntelliJ IDEA 10.0.1 and Grails 1.3.7. I have a mavenized Grails project which depends on many logging libraries.
Here's the problem:
I have to use JCL as logging framework, but grails per default is working with SLF4J and has some default dependencies like jcl-over-slf4j, which are inherited by every grails project. First of all I have excluded every jcl-over-slf4j transitive dependency in my project pom file and verified with mvn dependency:tree that my pom is clean of any SLF4J bridging libraries.
But nevertheless jcl-over-slf4j is still beeing downloaded to my local maven repo when I try to start my grails app. This leads obviously to a StackOverflowError at runtime, since both jcl-over-slf4j and slf4j-jcl are in the classpath.
So because of which declaration the jcl-over-slf4j dependency is still beeing downloaded?
Since my pom is clean the obvious conclusion would be that Grails itself depends on those libraries. As mentioned before Grails has some default dependencies, on which every Grails project depends.
I know that I can exclude inherited depencencies in the BuildConfig.groovy file and if I run grails dependency-report I can also see that these dependencies are not listed anymore.
grails.project.dependency.resolution = {
inherits("global") {
excludes "jcl-over-slf4j", "jul-to-slf4j", "slf4j-log4j12"
}
}
But even then the jcl-over-slf4j dependency is still beeing downloaded to my repo when I start my grails app! Am I missing something? Is there a different way to exclude inherited grails dependencies when you're using a mavenized grails project?
Any help would be appreciated
Thanks!
Slash
Ok I think I got the answer now..
The problem is that the defined maven-grails-plugin (which is mandatory when you use maven + grails) within my pom file depends on jcl-over-slf4j and therefore gets downloaded when I start my application through maven. With my current maven version (2.2.1) it's not possible to exclude a dependency from a plugin. There is also a jjira issue regarding this problem. Can not exclude a dependency from a plugin
As soon as I remove the maven-grails-plugin the dependency is not downloaded anymore, but as drawback I'm not able to start the application through maven anymore..
Lessons learned: Don't use Maven + Grails + JCL in conjunction.
Note that with mvn dependency:tree just project dependencies are listed, but plugin dependencies are NOT listed.
Hope this is of any help!
Regards Slash