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.
Related
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
We're building feature branches into a version 'feature_'. Each feature build will produce the same version. Since these are no releases, I want to deploy the artefacts into the Snapshots repo, but Nexus does not allow versions without 'SNAPSHOT' into the Snapshot repo.
How to configure Nexus to allow any version in a repo?
Solved it by appending '-SNAPSHOT' to the branch version.
It's quite tricky to get Maven in Jenkins to use the right version. The way I solved it now is like this. In the build job configure Git to build the branches origin/feature/*. Then:
In the 'build' section, first thing to do is execute a shell command to construct a file 'env.properties' containing the feature branch version to be used by the Maven build command.
echo BRANCH_VERSION="feature_${GIT_BRANCH##*/}-SNAPSHOT" > env.properties
This uses the GIT_BRANCH environment property of Jenkins. The '##*/' is a Bash Shell Parameter Expansion which strips everything from the parameter value except the part after the last '/' character.
Then use the Environment Injector Plugin to 'inject environment variables' to the build job using the 'env.properties' created in the previous step.
Put 'env.properties' in the 'Properties File Path' field.
Use Maven to build a versioned pom with the correct version using 'Invoke top-level Maven targets':
help:effective-pom -Dbuild.number=${BRANCH_VERSION} -Doutput=versioned-pom.xml. This step is necessary because otherwise the pom in the jar artefact does not contain the correct version causing other problems.
Use another 'Invoke top-level Maven targets' step to do the actual build and deploy using the pom version created in the previous step: -f versioned-pom.xml clean source:jar deploy
That's all folks. If anyone knows a simpler solution, let me know.
This is actually a Maven restriction. You can still use version like feature_x-1.2.3-SNAPSHOT though.
What are you actually trying to achieve though?
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 looking to release a stand-alone patch without committing it. when i prepare a release for a version i get the following error:[ERROR] fatal: Not a git repository (or any of the parent directories): .git
can i release without committing?
for now, what i'm doing is generate a jar locally and upload it manually as an artifact.
I had the same issue with mercurial. You need to use the -DpushChanges=false argument.
See my anwser to a similar question: link
If you don't want to commit anything to the SCM, I think you should try do to a dry run :
Since the Release Plugin performs a number of operations that change the project, it may be wise to do a dry run before a big release or on a new project. To do this, commit all of your files as if you were about to run a full release and run:
mvn release:prepare -DdryRun=true
This is a parameter of the release:prepare Mojo : dryRun.
We currently use Maven (v2.2.1) to manage our Java projects, including using release:prepare and release:perform to version our releases.
While this is all pretty simple, I find myself needing to produce the build artifacts from a previous release - is it possible to have maven checkout a given (svn) tag, and build the artifacts from that version?
ie. I have the following tags for a project in SVN:
project-1.0.0
project-1.0.1
project-1.1.0
I would like to build 'project-1.0.1' (or in fact any tag from that project).
Edit:
In order to clarify what I'm trying to do, consider the release:prepare and release:perform goals.
During :prepare and :perform Maven asks what SCM tag should be used for this release, and afterwards creates the tag, checks out the source for this tag into a separate directory in order to produce a sort of cleanroom build of your project.
What I would like to do is actually perform this last part, whereby I supply the SCM tag (on the command line, rather than hard coding it in the pom, as that would not be particularly flexible), and Maven happily goes off to checkout the code and perform a cleanroom build, resulting in the final build artifact, in exactly the same way as release:perform.
You may want to look at bootstrapping a project using maven scm plugin.
By defining a pom, which contains your scm configuration with the specified tag, as well as the desired maven goal, you can checkout a tag of your choice and build the same.
The link contains an example configuration.