Gents, ladies...
Here is the issue : I am integrating a grails application within a complex and heterogeneous system that uses maven to build and fetch dependencies. Fair enough, there are a few different ways to add a plugin, but I would like to have all the dependencies managed by maven, as the conflicts and scopes in the dependency trees would then be solved by maven.
This will install the hibernate plugin at validation time, and resolve its dependencies
<execution>
<id>Hibernate plugin</id>
<phase>validate</phase>
<goals>
<goal>install-plugin</goal>
</goals>
<configuration>
<pluginName>hibernate</pluginName>
<pluginVersion>${grails.version}</pluginVersion>
</configuration>
</execution>
Apparently, there is no way to specify exclusions directly in the execution configuration to prevent it from resolving its dependencies (in the dependencies.groovy script) independently.
I tried
<dependency>
<groupId>javassist</groupId>
<artifactId>javassist</artifactId>
<version>3.11.0.GA</version>
<scope>provided</scope>
</dependency>
The dependency will not appear in the lib dir of the WEB-INF folder in the target build dir. However it is still packaged in the war archive. Remember the aim is to use maven for all things relating to dependencies. But anyway since it seems there is no hope of excluding it using the pom, I try using the BuildConfig with :
case Environment.PRODUCTION :
build( "org.grails.plugins:hibernate:1.3.7" ) {
excludes "javassist"
}
break
This was a last resort, and it works. Specifying the build here, will effectively override the dependencies that come from the groovy script.
So my question is, is there anyway to override these dependencies using maven ?
Obviously I verified that the dependency I was trying to scope in provided isn't included anywhere else (it is excluded from grails-gorm).
Is there an easy way to solve this ?
UPDATE :
To prevent the war from resolving jar dependencies, there is a --nojars flag, but the war goal of the grails war mojo doesn't allow the passing of args. The exec mojo does, however there is only one execution spec possible for an instance of this plugin, and no lifecycle phase can be specified for the exec mojo.