I need to set a different classpath for one single grails xxx command.
The point is that my application uses latest version of commons-httpclient. I have no problems with this. But after building my application I need to use grails maven-deploy to store my war file in a webdav repository, and the command conflicts with the latest version of commons-httpclient. This command works great if I add commons-httpclient-2.0.2.jar in the classpath (lib folder for example), but the app will fail on trying to use the regular features that depends on commons-httpclient.
I need to add this other jar in the classpath just for running the maven-deploy command, any ideas?
I'm using jenkins (huson) to build the app, so, any tips on making the solution achievable with grails jenkins plugins will be appreciated.
Thanks a lot,
Does the grails maven-deploy command conflicts due to another dependency on httpclient?
Which one is it? May be you could exclude the dependency it?
Related
I'm working on a Grails plugin whose main contribution is a taglib. In Grails 3.1.11 it worked ok. I also have a simple Grails app just for testing the plugin. Enter Grails 3.2.2.
After migrating plugin and app to 3.2.2 the plugin shows no signs of life. The plugin doWithApplicationContext closure is no longer executed at app startup. The taglib is not found by gsp:s. I did the migration by creating a new plugin and app with Grails 3.2.2 and then fill in the sources.
Sorry for this vague question, but what strings should I pull to find out what's wrong?
Edit 1: Yes, I did the sanity check to have the app depend on a non-existing version of the plugin and got the expected conflict. So it's not that the plugin is totally decoupled from the app.
Edit 2: After setting DEBUG logging on packages grails.plugins and org.grails.plugins a warning message appeared. It came from org.grails.plugins.CorePluginFinder. It couldn't find the plugin descriptor (...Plugin.groovy). I examined the plugin jar, found the plugin descriptor class in a file hierarchy rooted in BOOT-INF. Clearly the plugin loader didn't look into that hierarchy. I thought I was seeing a Grails bug because I didn't know about Boot repackaging. I added a post here to that effect, but after getting Graeme's answer I deleted the post because it detracted attention.
What you are seeing is that if you run gradle assemble on a plugin then the bootRepackage task is run which re-packages the plugin JAR as a runnable JAR which is not what you want when you plan to use the plugin from an application.
If you simply run gradle publish or gradle publishToMavenLocal or gradle jar then you get the JAR file that has not been re-packaged by Boot. As far as I am aware this is not a change from Grails 3.1.
You can also disable Boot repackaging all together in the plugin build.gradle if you never plan to use the plugin as an actual application or runnable JAR file:
bootRepackage.enabled = false
I wrote a Grails plugin, lets say PluginA which has dependency on another plugin, lets say PluginB, which I wrote myself too, these both plugins are being used by a main project. I am trying to build a continious integration system for this project using jenkins, so far I managed to setup everything in Jenkins. But while building the project, I get this error
Zip C:\Users\me\project\PluginA\grails-PluginA-0.1.zip is not a valid plugin
So, how do I generate that zip file, I noticed that all my other plugins have that zip file but I don't remember building them. I also tried to do a grails compile-plugin but I got an error saying that few classes were not found as they were in PluginB. So, how can I specify that PluginA has dependency on PluginB while running a grails command?
It's not entirely clear, but I believe the problem you are having occurs when trying to build the main project and not the plugins, so I will address that situation.
Since the error message mentions a zip file, I will also assume you are using Grails 2.x. If you are using Grails 3.x, then stop reading now and add info on how you are specifying your dependencies.
Key info: In my experience plugins don't come with their dependencies; I've had to re-declare them in my top-level projects. I have no idea if that is the intent of the grails plugin design, but I have found it works to do so.
Step 1: Build PluginB and install it to your local maven repo using
grails maven-install
Step 2: Specify PluginB as a dependency for PluginA in its app/conf/BuildConfig.groovy
Step 3: Build PluginA and install it to your local maven repo using the same command as for PluginB.
Step 4: In your main project, specify dependencies on BOTH PluginA and PluginB in app/conf/BuildConfig.groovy
Step 4 is the key.
If I've misinterpreted your problem, sorry about that! Please provide some more detail on exactly which part is failing and I'll let you know if I have any info on it.
My problem is the following:
I would like to use the propertyregex task in ant. The project I am working on is built on various different servers and I don't want to configure (install the ant-nodeps.jar) every server. The source needs to include everything, that is not installed on the system by default.
So now I would need to add the ant-nodeps.jar to the ant classpath from within the build file. Does somebody know how to do that?
Cheers,
Robert
The propertyregex task is part of ant-contrib and can be installed as part of your build using Apache ivy
Checkout the following example, which demonstrates how to download and use the "for" task (also from the ant-contrib project):
Problems getting my ANT builds to work after OS upgrade
The one downside is that ivy does not come pre-packaged with ANT, so the following answer has a tip on how to bootstrap your ANT builds. Once ivy is started it can be used to pull down everything else your build needs.
Ivy fails to resolve a dependency, unable to find cause
Update
While I understand you requirement to have no change on the target platforms, it's a very difficult problem to solve if you must also match several old versions of the build software. I have found incompatibilities between the latest ANT and 5 year old versions like 1.7 (ANT 1.6.5 is now 8 years old....)
What I do is install a very limited number of ANT versions on my Jenkins slave nodes. Build jobs can then only choose from these and then use ivy to download all other 3rd party software dependencies (This setup emulates how you'd manage a set of Maven projects).
I suspect you're using ANT to run your deployments? If that is the case I would suggest switching to something like Groovy, which can be deployed as a single jar file and can pull down dependencies on the fly, using Grape.
In Grails, there is a variant how to include local plugin from sources. According to docs, one may type in BuildConfig.groovy:
// Useful to test plugins you are developing.
grails.plugin.location.shiro =
"/home/dilbert/dev/plugins/grails-shiro"
// Useful for modular applications where all plugins and
// applications are in the same directory.
grails.plugin.location.'grails-ui' = "../grails-grails-ui"
The problem is that it doesn't work in Grails 2.0.RC1. I've tried to do grails clean, to install plugin with grails install-plugin and to place it to BuildConfig.groovy. Still unable to resolve.
This works for me
grails.plugin.location.shiro = "/home/dilbert/dev/plugins/grails-shiro"
Where shiro is the name of the plugin (not the name of the directory it's in). Make sure the path to the plugin is either an absolute path or the relative path to the plugin from the application.
I've found that this sometimes doesn't work if the plugin is listed in application.properties or BuildConfig.groovy, so if it is, remove it, then execute grails clean and restart the app.
You can also install the plugin into your local maven cache.
The documentation speaks about this:
3.7.10 Deploying to a Maven Repository
maven-install
The maven-install command will install the Grails project or plugin artifact into your local Maven cache:
grails maven-install
This has the advantage of allowing you to include the plugin in your parent application using the more common ":plugin-name:version" syntax
Which allows your application to determine the best place to retrieve the plugin when in production. From an internal maven-repo or equivalent.
With Grails 3.x there is another way to do this. Suppose you've a grails app and plugin (source code) inside the same project directory:
/my-project
---/my-app
---/grails-shiro
To run your local plugin, you must create a settings.gradle file in the my-projectdirectory specifying the location of your application and plugin:
include 'my-app', 'grails-shiro'
Then add the dependency in your application's build.gradle:
compile project(':grails-shiro')
You've done.
Look at the plugins documentation for more information.
Surround the plugin name with quotes in case it contains dashes:
grails.plugin.location.'plugin-name-with-dashes' = "<path>"
You can add the .zip file for the plugin in your /lib and it will be installed.
Example:
compile ":myPlugin:1.0"
File:
/lib/myPlugin-1.0.zip
Note: You have to zip the content of the plugin folder.
Source: http://grails.1312388.n4.nabble.com/Insert-own-local-plugin-into-build-config-td4646704.html
I'm using STS latest version (2.7) and latest grails as well. After I created a freshly grails project in STS it freezes in the updating grails dependencies for a long time and it comes out as a timeout error. And it follows by some GroovyObject error, but the project still runs fine in command-line. So I ditched STS for refreshing dependencies, and I included the dependency in BuildConfig.groovy and use grails compile but I still got ClassNotFound error when compiling, it's like grails didn't pick up the Ivy CLASSPATH. So, I'm thinking of changing it to Maven to resolve any dependencies.
My question would be which one is better and integrated seamlessly in STS or Eclipse?, but I still want to use grails commands, not maven.
If your project is just a grails project - use grails dependencies.
I've experience with mavenized grails project, and plain grails project. First is good when you have multimodule project, and only one of them is grails module. At this case you'll lost all grails commands, you need to use commands like mvn grails:run-app and it's complicated thing to pass arguments into commands :(