insted of using
grails> set-version
command, is there any possible ways to generate application version when deployed itself.
You can set it by changing app.version in application.properties (at the project base directory).
I'm not completely clear what you mean by "when deployed", but you could change the version programmatically during your build (by editing the file), if that's what you're asking.
Once the application is packaged up into a war and deployed, changing the version would be tougher. You can rename the war (to not include the version), if that's what you're concerned about.
The app version is static; the set-version script simply updates the version number in application.properties. The version is a build-time property, it's not something that you would change at deployment time.
I'm not sure why you would want to change a version number during deployment. From a configuration management perspective build numbers are usually part of the build itself and don't ever change until there is another build.
I was able to achieve this (grails 3.3.0) by setting the version parameter in build.gradle file of the application
version "0.2"
Related
I'm trying to upgrade a Grails app from 3.3 to 4 (specifically 4.0.3 for now) and the Views-Json 2.0.2 plugin. Profile is angular.
When I run the app in development mode everything works. However when I attempt to build using gradlew :server-api:assemble the build fails at the Task :server-api:compileGsonViews (yeah, renamed 'server' to 'server-api' for clarity).
It looks like it's not finding my Java classes (there are a few under src/main/java).
I've see refs to setting the classpath for the compileGsonViews, but I was undable to make it work.
Anyone with suggestions?
Running on Windows 10 with latest OpenJDK 1.8.x
Somehow I seem to have stumbled on the solution. In my build.gradle I had enabled the grails pathingJar, commenting that out allowed my war to build. However with the property commented out, I was unable to use the gradlew bootRun command as it failed due to the path being too long.
The solution (for me) was to add a build property, the build file then looks like:
def usePathing = Boolean.valueOf( System.getProperty('pathingJar', 'false') )
if (usePathing) {
grails {
pathingJar = true
}
}
If I was better with gradle I think I could (maybe) determine the goal that is being targeted and use that, but the above works. The commend to assemble the war is the same; but to run the app directly I need to make it gradlew server-api:bootRun -DpathingJar=true
I'm going to build a maven project for the first time. I downloaded maven- 3.1.1 and I want to know if I can use jdk 1.7.0._05. If there is any other version that I need to use, please do specify.
Thanks :)
As far as I know there isn't any version that you are forced to use to build Maven project. You can simply run:
mvn -version
to see what version is used currently by Maven. This version should match the JDK you have set as JAVA_HOME, so in case if you want to change it, simply change your JAVA_HOME to different directory.
Have a look at System Requirements noted at the download page:
JDK: 1.5 or above (this is to execute Maven - it still allows you to build against 1.3 and prior JDK's)
After upgrading my jenkins install on ubuntu using ubuntu packages, I'm getting an error with the cloudbees licence plugin.
java.lang.NullPointerException
at com.cloudbees.jenkins.plugins.license.BootHook.innerOnLoaded(BootHook.java:59)
at com.cloudbees.jenkins.plugins.license.BootHook.onLoaded(BootHook.java:49)
at jenkins.model.Jenkins.<init>(Jenkins.java:845)
at hudson.model.Hudson.<init>(Hudson.java:81)
at hudson.model.Hudson.<init>(Hudson.java:77)
at hudson.WebAppMain$2.run(WebAppMain.java:214)
My jenkins version is 1.492
If I disable the plugin, that works, but I cannot see some project that are in folders.
How can I do ?
A change in core affected the plugin.
Briefly, there is a conflict between versions of Bouncy Castle in core and the plugin. As the plugin has to support a wide range of Jenkins versions, it includes a version of Bouncy Castle, and requests that this be loaded in an isolated classloader... Under certain circumstances core will resolve the classloaders differently when looking for extensions, and the extension can end up resolving a different version of Bouncy Castle... which results in the extension (free-license-plugin) not being found, and the corresponding NPE.
We fixed this issue a couple of days after 1.490 was released. The fix is in cloudbees-license 3.5 and free-license 3.2 (also in nectar-license 3.3 - but that is only of relevance if you are running any of the Jenkins Enterprise plugins)
To get a borked system back to working here is the set of steps to follow:
Stop Jenkins (if you haven't already)
Remove the following directories $JENKINS_HOME/plugins/cloudbees-license, $JENKINS_HOME/plugins/free-license and if present $JENKINS_HOME/plugins/nectar-license
Remove the following files $JENKINS_HOME/plugins/cloudbees-license.hpi, $JENKINS_HOME/plugins/cloudbees-license.jpi, $JENKINS_HOME/plugins/free-license.hpi, $JENKINS_HOME/plugins/cloudbees-license.jpi, and if present $JENKINS_HOME/plugins/nectar-license.hpi or $JENKINS_HOME/plugins/nectar-license.jpi (Note: normally there will only be either the .hpi or the .jpi file present. Which is present depends on what version of Jenkins was installed when you downloaded the plugin originally. It doesn't matter which.
Download the latest versions of the plugins that you removed: (Note: only download the nectar-license plugin if you removed it in steps 2 and 3)
cloudbees-license
free-license
nectar-license (only if needed)
It is up to you whether you rename the .hpi to .jpi. Jenkins will pick it up either way, but for longer-term compatibility I would recommend renaming them to the .jpi extension.
Start Jenkins
Do the funky-chicken dance
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 would like to printout the grails war file version on my main page template, so when I deploy a WAR file, it become easy to recognize which version of the app is running on which server and so on.
Where to set it and how to print it out in a gsp tag?
There's a tag you can use as a short cut
<g:meta name="app.version"/>
You can set it using
grails set-version someVersionHere
I figured out how to display it but still don't know how to set it except by changing it in the application.properties
ApplicationName Version: ${grailsApplication.metadata['app.version']} Built by grailsApplication.metadata['app.grails.version']
I guess its the only way!!
To answer your question of SETTING the VERSION:
For example building with Jenkins or Hudson will automatically set the build number and CVS revision number to your war.
Using that sort of build tool + the Build Info plugin is a good way to achieve visibility to which version of your site you are running.
Of course setting up Jenkins takes some effort, but the it is a one-time cost and then you will just have button "Build Now" that will take care of it and you can optionally also configure deployment tasks to upload it automatically as well... but now I've drifted slightly off-topic.