I am using SVN + maven + hudson/jenkins.
I am having 8 modules under one build. After a perfect build i am able tag it and publish it for a clean release. Its a happy day scenario
Here, My requirement is to tag only 3 newly built modules and publish it for a release. How can I tag only the modules which are successful via hudson/maven.
The Maven Release plugin does this for you.
Related
I have Maven2 project. This project have 1 internal dependency which stored in internal (for our company) Sonatype Nexus. I setup the dependency version in pom.xml as parameter which I provide via Jenkins.
Sometimes I do not have proper dependency version in Nexus so my build can fail on donwload dependency step. I want to add ability to trigger special task (script) if dependency is not found to upload this dependency into Nexus and continue the build.
Can I do so?
I think about fake build for version exists always in Nexus which will check if given version is in Nexus, upload it and launch real build. But such way looks terrible.
Thanks In Advance!
You do NOT need to upload anything. You just need to access Nexus via the public group and the download from the Central repository, that is part of that group will happen automatically.
I'd like to find the best way to manage releases using Maven 2, Bamboo 3.1 and JIRA 4.3. I've tried many things but I keep hitting dead ends due to bugs or missing functionality.
My end goal is to have versions come from JIRA, have Bamboo take those versions and build artefacts from them using Maven then deploy those artefacts to a repository (Nexus in our case).
Here are the approaches I have tried:
1) Use a place holder in all poms for project versions:
Parent pom
<project ...>
<groupId>group</groupId>
<artifactId>parent</artifactId>
<version>${ci.version}</version>
...
<modules>...</modules>
</project>
Child pom
<project ...>
<parent>
<groupId>group</groupId>
<artifactId>parent</artifactId>
<version>${ci.version}</version>
</parent>
<artifactId>child</artifactId>
...
</project>
This builds if you start the build from the project root pom and specify -Dci.version=<my-version> on the command line. Combine this with the Bamboo Release Management Plugin and I can build and deploy versions of my modules and release as needed.
The problem with this approach is that Maven does not replace place holder variables in poms when deploying or installing which means the poms in the repository have the ${ci.version} marker when I'd really like them to have the concrete version. Because of the place holder it means nobody can use the modules I deploy. See MNG-2971.
2) Use concrete SNAPSHOT versions in the pom and configure bamboo to execute the Maven Release Plugin using the Bamboo Release Management Plugin.
Unfortunately the Maven Release Plugin needs the version to increment to, the bamboo plugin allow you to get the name of the current version to build but not the next one. Without this information using the Maven Release Plugin would increment the version to something that is not managed by JIRA. To make this option work I'd either need the next version available to me or be able to run a plan after the Bamboo Release Management Plugin has done it's thing (this second fix would also add extra mess to the commit logs as you'd get one commit for the auto increment and one for the proper increment).
2.b) Same as 2) but you have to specify the next version in Bamboo before any release build through the plan configuration interface, setting the value manually to the next JIRA version the plan should be working on. This fixes the problem with 2) but adds extra manual steps.
3) Do things manually, probably using the Maven Release Plugin. Completely ignore all release functionality in Bamboo and manually manage released on the command line by calling the Maven Release Plugin goal to change the version as and when needed. JIRA versions will also need to be released manually when this happens. We also need to configure a bamboo build to run and test the tag that the release plugin creates for the non-SNAPSHOT version.
This option has so much process involved something is bound to go wrong.
I can't be the only person trying to get automated releases using these technologies, can anyone help.
Thanks
matt,
You have to specify in your goal -Dci.version={bamboo.custom.brmp.name}
I stumbled upon your question when I was looking for exact the same information, but then for JIRA 4.4 and Bamboo 3.3, where the release management plugin has been replaced / upgraded with the JIRA Bamboo plugin ...
Hope this helps,
Francis
I'm very new to Maven, and have a question about building multiple Maven projects.
We have two Maven projects, Project A and Project B.
Project A depends on an artefact generated by Project B.
When changes to project A or B are checked into SVN, our local Hudson server builds the modified project (and any dependent projects) and uploads the artefacts into our local Nexus repository.
Now, consider two developers.
Developer 1 hacks away at project A only, and when Developer 1 builds project A locally, Maven goes and gets the latest project B snapshot artefact from our Nexus server.
Developer 2 hacks on both project A and project B simultaneously. When Developer 2 builds project A locally, we want maven to build project B with any local changes and use the resulting artefact to build project A. How do we set up Maven to build using the local version of project B instead of getting the artefact from Nexus? Is this a standard usage pattern for Maven?
How do we set up Maven to build using the local version of project B instead of getting the artefact from Nexus?
You can setup an updatePolicy for the snapshots artifacts per repository. Actually, Maven checks for SNAPSHOT updates only once a day by default. So if you build a version of B locally, you should be able to use it to build A for some time, even if a new SNAPSHOT is deployed to your Nexus. If this doesn't suit your needs, you can change this policy. You could also build offline (using the -o option).
PS: AFAIK, automatic updates will be disabled by default in Maven 3.x, you will have to explicitly ask for updates (with the -U option).
I am developing code actively, with my developing team. When we release to our customers, I would like to provide jars without the -SNAPSHOT so they only need to update when a new dot version is created.
This there a maven plugin that provides this functionality. I know there is because everyone else must do it some how. I doubt it is manually.
I would appreciate answers to be explicit as possible.
Please and thank you.
Some plugins can help here, as already mentioned in this answer and in the comments of this one: the Maven Release Plugin if you want to fully automate the release and/or the Maven Versions Plugin.
With the Maven Release Plugin
Releasing a project with the Maven Release Plugin is done in two steps: prepare and perform and here is what the documentation writes about the release:prepare goal:
Preparing a release goes through the
following release phases:
Check that there are no uncommitted changes in the sources
Check that there are no SNAPSHOT dependencies
Change the version in the POMs from x-SNAPSHOT to a new version (you
will be prompted for the versions to
use)
Transform the SCM information in the POM to include the final
destination of the tag
Run the project tests against the modified POMs to confirm everything is
in working order
Commit the modified POMs
Tag the code in the SCM with a version name (this will be prompted
for)
Bump the version in the POMs to a new value y-SNAPSHOT (these values
will also be prompted for)
Commit the modified POMs
In other words, the Maven Release Plugin is exactly doing what you're asking for.
With the Maven Versions Plugin
If you don't use the Maven Release Plugin, the Maven Versions Plugin can be helpful. In particular, the following goals:
versions:update-parent updates the parent section of a
project so that it references the
newest available version. For example,
if you use a corporate root POM, this
goal can be helpful if you need to
ensure you are using the latest
version of the corporate root POM.
versions:update-child-modules
updates the parent section of the child modules of a project so the
version matches the version of the
current project. For example, if you
have an aggregator pom that is also
the parent for the projects that it
aggregates and the children and parent
versions get out of sync, this mojo
can help fix the versions of the child
modules. (Note you may need to invoke
Maven with the -N option in order to
run this goal if your project is
broken so badly that it cannot build
because of the version mis-match).
versions:set can be used to set the project version from the
command line.
versions:commit removes the pom.xml.versionsBackup files. Forms
one half of the built-in "Poor Man's
SCM".
versions:revert restores the pom.xml files from the
pom.xml.versionsBackup files. Forms
one half of the built-in "Poor Man's
SCM".
I mentioned several goals but the "most" interesting is probably versions:update-child-modules here. It would allow to change the version in the top parent pom and then to automate the update of the child. See Fixing a multi-module build for an example.
Can't help more, you need to experiment yourself now. Good luck!
References
The Maven Release Plugin
The Maven Versions Plugin
I have a couple of projects that I'm working on in Eclipse (or any IDE, so I don't want to depend on specific eclipse dependency maven capabilities). Some projects depend on other projects. Typically in Eclipse I would add the projects as references to other projects, but I'm not sure how to handle this when using Maven. In the deployment environment, there will be jars created and the maven build can pull the latest jars from the repository. Is there a way to reference another project's source code using maven while in the dev environment? For example...
I have this scenario:
Project A depends on B
I need to make a change to B and that will require an update to A. I don't want to make the change to B and check it in without checking in A since that will break A. And I would like to manage these dependencies through Maven -- any help would be appreciated.
thanks,
Jeff
The maven 2 eclipse plugin has 'workspace dependency resolution', where the dependencies are first looked up in the workspace, and then in the repository.
What I do is use SNAPSHOT version when doing my development. Project A depends on the latest SHAPSHOT version of Project B, so when I change Project B, I have Team City recompile and push out a new SHAPSHOT artifact to artifactory. Then I clean and compile project A to get the new Project B.