I want to automate version and changelog creation from Git commits. So it's basically the same thing as npm standard-version but it's for Maven. So how can I achieve the versioning automatically?
additional information: I want to increase the version at POM file using the Git Commit-lint messages. In npm if you commit features it increases MINOR, and if you commit fix it increases PATCH version automatically at Semantic Versioning and creates a changelog for these changes. I was wondering if there is a similar way for Maven?
I couldn't find a direct way for Maven. However, you can still use standard-version to create the changelog and bump up the version. You have to write a script to make package.json and Maven versions same. I used the Versions Maven Plugin to accomplish it.
mvn versions:set -DnewVersion=%npm_package_version% && mvn versions:commit
Related
I've a maven project and I'm using the maven-release-plugin to prepare the release.
When I run the mvn --batch-mode release:prepare command, it creates two commits as follows
(HEAD -> develop) [maven-release-plugin] prepare for next development
iteration
(tag: myapp-1.0.0) [maven-release-plugin] prepare release
myapp-1.0.0
This correctly updates all the pom files.
but I've some text files in my project where there is a version token. I'm looking for a way to replace these version tokens appropriately as per the commits.
For example, the prepare release commit should replace the token to 1.0.0 and prepare for next development should replace the token to 1.0.1-SNAPSHOT
I've checked the documentation but didn't find any way to do this. If somebody has any ideas on how to achieve this through maven-release-plugin or with the help of any other plugin, please suggest.
EDIT:
This issue is not solved even if I place the files inside resources directory. The thing I've observed is that the release plugin only selectively adds the pom.xml files in the commit, not other files even if they are modified gets added into to the commits pushed by release plugin.
Let me clarify I am not looking for replacing version in the source file and have it replaced in the generated artifact. We can argue about why there is version field in non source file, but there are genuine scenarios anyone can think of.
As a developer I want that the release commit made by the maven release should be accurate i.e. It should contain all the changes associated with that specific release version.
As khmarbaise said: Use ${project.version} in the respective files, put them into a resources directory and use filtering.
I have a project being built with maven using TFS for source control and Octopus for deployment.
At the moment, I can perform a TFS CI build, create an octopus deploy package as a zip file from the output, and use octopus to deploy to my deployment target, extract the package and install the app.
What I would like to do is increment the version of the application projects when a new build is performed (perhaps nightly).
Is the correct way to do this, to get my build server to set the new version on the project, using mvn versions:set -DnewVersion=x.y.z then to run mvn deploy to push the updated packages to the networked repository. Then to finally create my maven package from this?
I'm a bit unsure the best way to allow my build server to up issue the versions and then use those updated versions of the packages in the build.
It seems like I may have the wrong end of the stick here. Any pointers greatly appreciated.
If you had already at Maven 3.2 or better Maven 3.3+ you could have done that in a more convenient way, but if you are at Maven 3.1. you need to go
via build-helper-maven-plugin and versions-maven-plugin you can do simply via:
mvn build-helper:parse-version versions:set \
-DnewVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}\${parsedVersion.nextIncrementalVersion} \
versions:commit
But as far as I know the versions:commit will probably not work based on support of TFS for Maven SCM....(I never tested it with TFS). But the commit step be done by something different.
I'm trying to create a deploy job in Jenkins. Up until now I was building my artifact via the maven install goal and then deploying it on the application server with a shell script. However, I'd now like to skip the install part and just get the artifact from my nexus repository.
I know there is the maven dependency:get which I can use to retrieve the artifact from the repository but is there any way I can make sure I'll get the latest version without passing it as a build parameter?
You have different options:
1) Use the Repository Connector Plugin. With this plugin, you get an additional "Artifact Resolver" build step, where you can download an artifact from a centrally configured (Manage Jenkins) repository to the workspace of your deploy job (with different options like renaming etc).
If you use the version LATEST, you always get the latest version. Likewise, you can use RELEASE for the latest release version or ranges like [1.0,1.1).
There are two caveats however:
In the newest version of the plugin, LATEST is broken (see https://issues.jenkins-ci.org/browse/JENKINS-20263), so you need to use version 0.8.2 for now).
You should manually fingerprint the downloaded artifact, since this is not automatically done right now.
2) Use dependency:get as suggested, but use LATEST or RELEASE as above. However, I do not think this is a really elegant solution. (if you simply use SNAPSHOTs with the same base version, follow khmarbaise's advice and simply add -U to the commandline)
3) Use the Maven Deployment Linker Plugin plugin, which is a rather elegant alternative, since you can copy artifacts from other jobs like Copy-Artifact, but they are still retrieved from your Artifact repository (thus you do not waste diskspace and time). The largest problem with that plugin is that it currently does not support authentification.
I'm trying to migrate our legacy build system to maven. I've successfully managed to get maven doing some tagging in CVS, by using the release:prepare and release:perform tasks.
I'm new to maven, and my understanding of tags in CVS is a bit hazy, so please bear with me.
Our code consists of a series of modules, and each module is versioned in CVS using tags.
So for example the module ER_api_test has a version 0.18.0, 0.19.0, etc, each corresponding to tags in CVS (eg ER_api_test_0-18).
Now I want to do some branching. So I need to take an old version of the module, and branch it. If I use version 0.8.0, then when I commit and promote (create the CVS tag using our build system), that will give me 0-8-1.
Now when I check out the code for 0-8-0, the pom.xml has a version 0.8.0. I believe that in order to branch this module, I will need to modify this to 0.8.1-SNAPSHOT. Indeed, when I make the modification manually, I can then use my maven release:perform command to create 0.8.1.
I'd like to run a command which will make this modification of version automatically. There is a maven command called "release:update-versions" which I'm trying to use to do this, but it complains because my version is not a snapshot:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.3.2:update-versions (default-cli) on project ER_api_test: You don't have a SNAPSHOT project in the reactor projects list.
How do I modify the version automatically? I would like to use a maven command if possible, as opposed to awk or sed, since the build system runs in java.
Edit:
one option would be to try to use maven to do the branching. Here are the commands which CVS runs in order to check out the branch:
cvs -z3 -d :pserver:user#cvshost:2401/opt/cvs/us -q tag -c -b ER_api_test_0-4_patches
cvs -z3 -d :pserver:user#cvshost:2401/opt/cvs/us -q tag -c ER_api_test_0-4-0
If I can get maven to run an equivalent command, and simultaneously update the version to a snapshot, that will also work.
We use Maven with Subversion internally. We also use Maven's Release plugin. We noticed the issue described below when running through the following (correct, I presume) steps.
1. We run release:prepare:
Maven updates the trunk version to 1.0.0.
Maven runs svn copy trunk/myproject tags/myproject-1.0.0, thus creating tag myproject-1.0.0.
Maven updates the trunk version to 1.0.1-SNAPSHOT.
2. We run release:rollback:
Maven resets the trunk version to 1.0.0-SNAPSHOT.
Maven does not remove the tag, because Maven doesn't do this kind of stuff.
3. We commit more changes to trunk, obviously against version 1.0.0-SNAPSHOT.
4. We run release:prepare again:
Maven updates the trunk version to 1.0.0.
Maven runs svn copy trunk/myproject tags/myproject-1.0.0, thinking it created tag myproject-1.0.0 out of the latest trunk. But, alas, Subversion (1.6 and 1.7 alike) will instead create tags/myproject-1.0.0/myproject on Maven's behalf.
5. We run release:perform:
Maven checks out the contents of tag myproject-1.0.0.
Maven builds the contents and deploys the result to Nexus.
The problem is obvious: the change in step 3 did not make it into the tag. We are now releasing 1.0.0 without the change in it.
The questions are: How can we fix this? Is Maven's release rollback feature inherently broken?
In fairness, rollback should reset the project and SCM to a state that allows a second prepare to occur. This includes removing the tag. The answer is now apparent (Googling "maven release rollback remove tag"):
http://maven.apache.org/maven-release/maven-release-plugin/examples/rollback-release.html:
The created branch/tag in SCM for the release is removed. Note: This
is not yet implemented so you will need to manually remove the
branch/tag from your SCM. For more info see MRELEASE-229.
The resolution would then be to force release:rollback to include a command to delete the SCM tag using something like org.codehaus.mojo:exec-maven-plugin. Short of this, wrap rollback inside a script that does that externally.
As you've discovered, release:rollback doesn't have a whole lot of utility when it doesn't clean up SCM. What our shop has done is setup our Jenkins automation to run "mvn release:prepare release:perform" in combination with the Jenkins M2 Release Plugin.
If it fails we need to delete the tag in Subversion but, then again, we would have to do this anyway with rollback.