I'm pretty new to the Grails Framework and I'm experiencing some strange behavior. If I use the grails commandline tool this way
grails "-DghprbPullTitle=Title with spaces" clean
grails fails with this error message
| Script 'With' not found, did you mean:
1) IntegrateWith
2) Init
3) CreateUnitTest
Starting grails this way will work
grails "-DghprbPullTitle=Title_without_spaces" clean
Ok one can now say "Then just avoid spaces" The problem is, that this occurs while I'm using Jenkins + Grails Plugin + Pull Request Builder Plugin. The Pull Request Builder Plugin generates some of these parameter with whitespaces.
Any thoughts how I can use grails with such whitespace-containing parameter. Or how I can tell the Pull Request Builder Plugin no to generate such parameter.
Maven on the other hand is able to handle such parameter.
Thanks in advance,
Marco
I ended up using shell builder with grailsw call instead of the Grails plugin.
Ok so it was a bug in the grails commandline tool. It will be fixed in grails 2.4-RC1.
See Grails Issue Tracker
The problem is that Grails Plugin + Pull Request Builder Plugin makes it pass build parameters from PR Builder plugin to grails commands. Those arguments with spaces are not required for build to happen, it's some kind of default in Grails Plugin to pass those parameters along to grails commands.
If Grails Wrapper on Grails Plugin didn't work for you, using Shell commands instead of Grails Plugin worked for me: it avoids parameters with space and makes GitHub notifications to work. It's worse for grails installations maintenance, but at least it's an alternative.
I submitted a PR https://github.com/jenkinsci/grails-plugin/pull/12 to work around this by suppressing the -D build environment variables.
I am using the Github pull request builder plugin https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin to run test-app and was running into the same issues as others. I am not using any of the variables that the ghprb plugin passes in so I added an option to suppress -D build environment variables. When this option is checked none of the -D variables are passed to grails allowing the build with grails plugin to run the targets as expected.
If you want to test it out to see if it works for you, you can download it from here http://jmoses.co/data/grails.hpi and install it manually How to install a plugin in Jenkins manually?
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
When I type generate-all, generate-controller or generate-vies, Grails current version (2.3.2) does not recognizes them. However, these commands remains on the Grails documentation. Does anyone knows if these commands were removed (and the docs are not up-to-date)?
Try grails compile first.
These commands are now part of the scaffolding plugin, and you might need to get grails to fetch the plugin
I have a Grails 2.2.3 application and I'm using TeamCity 7.1.3 as my build server. So far, everything was working like a charm until one fine day I decided to update a plugin in my BuildConfig.groovy file.
Locally, I was of course able to update the plugin - but I was asked to confirm the plugin update, which is not a problem if it's locally and I'm the master of the cli, but it is a HUGE PROBLEM if this confirmation dialog pops up at the buildserver where I have no access to the command line during the build step.
Is there a commandline option like -y where I can tell the system to force the y parameter if asked for confirmation? Something like grails refresh-dependencies -y?
You have to specify --non-interactive while issuing commands.
For example: grails compile --non-interactive
To bypass the manual interaction, mainly useful in build servers as in your case.
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?
I have read the documentation for Grails and Webtest in this site:
http://www.grails.org/plugin/webtest
And it's very unupdated. Most of the scripts listed there doesn't work.
I am looking a way to run a working alternative of -nostart listed there.
This is because it's very slow to rerun tests. Or maybe a way to run webtests from outside of Grails
Can you give me any pointer?
Thanks in advance
The webtest plugin changed from version 1.3 to use the new hooks provided by the grails test-app script. Unfortunately one piece of functionality not provided by test-app is the -nostart option.
You could try using
grails interactive
then
test-app -functional
hitting enter should re-run the functional tests without doing a complete restart of grails.
I've also removed the -nostart option from the documentation. All the other documentation should be up to date. What other scripts did not work?
You can raise issues here: http://jira.codehaus.org/browse/GRAILSPLUGINS/component/12994