Maven release and versions maven plugin

Question

What is the numbering/versioning strategy for dependencies when doing snapshots/releases?

A team of 15 developers,20 Maven parent projects = total 70+ POMs including child module POMs. Currently there are a lot of dependencies where most of these 70 depend on one or the other.

Past:

All POMS have 1.0.0-SNAPSHOT as their version and also under dependencies tags.It gets uploaded to Nexus repo with mvn deploy.

Present:

We started doing mvn release recently. So all 20 parent POMs are now 1.0.1-SNAPSHOT and release ver 1.0.0 for all of them lies in Nexus.All <dependencies> tags now point to 1.0.0

Problem:

Developers don't want to point to release versions. They need bleeding edge development version 1.0.X-SNAPSHOT from their peers whether its unstable or not.

SCM wants to point to RELEASE versions only as he has to do a mvn release once a week which will fail as it points to snapshot versions.

Question:

Now I know the version plugin , but the question is, what do I put in the POM so that both parties are satisfied by running their own version of mvn versions: command. Preferably, the POMs should point to SNAPSHOTS so 15 people are happy, and when SCM does the release, he can run a mvn versions:something and everything gets converted to RELEASE versions in place of SNAPSHOTS. Then back to SNAPSHOTS for developers.

is this a single big-bang release, or are all the separate modules released independently? IOW how many projects does the SCM run `mvn release:prepare release:perform` on in order to cut the release — Stephen Connolly, Feb 01 '13 at 10:33
20 projects released one by one . each would have 2-15 modules like projA-parent, projA-jar,projA-war,projA-Ear.. so total POMs modified by the release plugin would be 100+, but I am ok to do 20 iterations of a solution if there is one.. — Pulak Agrawal, Feb 01 '13 at 11:47

score 3 · Answer 1 · answered Feb 01 '13 at 15:17

I am putting this as an answer, even though at present this is not quite working answer.

When I added the completionGoals configuration option in the Maven Release Plugin, my aim was to enable the work-flow where development used version ranges, but that releases would be pinned to concrete versions only.

One of the enabling goals that was added to the Versions Maven Plugin was the versions:resolve-ranges goal. What is missing is a way to unresolve those ranges again afterwards.

We don't really have anywhere safe to stash the originating ranges that the release plugin will not object to or clean up before we need it again.

The closest solution I have thought of is to inject XML PI's beside the version containing the version range... in such a situation, the pom.xml would get transformed from, e.g.

<project>
  ...
  <dependencies>
    ...
    <dependency>
      <groupId>com.foo.bar</groupId>
      <artifactId>manchu</artifactId>
      <version>[1.2.3,2.0)</version>
    </dependency?
    ...
  </dependencies>
  ...
</project>

to

<project>
  ...
  <dependencies>
    ...
    <dependency>
      <groupId>com.foo.bar</groupId>
      <artifactId>manchu</artifactId>
      <version>1.5.7</version>
      <?versions-maven-plugin allowed-version-range="[1.2.3,2.0)"?>
    </dependency?
    ...
  </dependencies>
  ...
</project>

by ensuring that the preparationGoals included the versions:resolve-ranges goal... (Note: the versions plugin might have to fork a third Maven to work around the lack of pom.xml reloading in order to have the clean verify be meaningful, though resolve-ranges is supposed to resolve in the exact version that the build is working with, so it shouldn't be an issue).

Then in completionGoals you have the (as yet unimplemented) versions-maven-plugin goal that removes the XML PI's and puts the ranges back in place.

There are a number of issues preventing this at present:

Unsure if the Maven Release Plugin's pom rewriting will remove the XML PI's (needs testing to confirm)
The XML parsing library in versions-maven-plugin is hacky at best, and a better solution is needed to enable the XML PI injection
My son demands attention, leaving very little time for me to attend to these issues.

However, you might be able to codge something together.

Set completionGoals to something like versions:use-next-snapshots versions:commit
Run your releases like so mvn versions:use-releases versions:commit scm:commit release:prepare release:perform install

So what should happen:

We switch the -SNAPSHOTs to releases
We commit the change to SCM
We start the release preparation
When the pom.xml is transformed to the next development version, we also advance the dependencies (using the fact that all our dependencies had the exact same command (with the install at the end) so their next -SNAPSHOT is already in the local repository, so they will get advanced for us automatically (in theory)) and we rely on release:prepare to commit the changes for us.
The release is performed as normally
We install the next development -SNAPSHOT into the local repo so that all the down-stream projects will get their version of this updated when they run versions:use-next-snapshots

The above is slightly error prone... I'd far prefer if I could offer you the version range based solution, but, well right now this is the best solution I can see.

interesting .. let me give it some thought, though I am sort of surprised that there is no existing approach for this. I presumed this would be a common enough quandry for "Maven people" — Pulak Agrawal, Feb 03 '13 at 14:28
Keep in mind, that most people dislike [developing on top of sand](http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html) so the issue you have is your developers like building on top of sand and therefore keep snapshot dependencies in trunk as a matter of course. — Stephen Connolly, Feb 03 '13 at 15:27
I know that its a best practice to not do this. But its only that - a best practice. Now if my RELEASE is happening once in 3 weeks, and in between the developer needs the latest "base-utility-project" which is "base" for everything, they cannot afford surprises 3 weeks later !! I'd like to call it analogous to "code merge" where the sooner you have the other guys' code, the better it is as a thumb rule. Here it is sort of a merge for my library JAR, that's all. And I got to manage it somehow. — Pulak Agrawal, Feb 04 '13 at 07:47
Well, your question seems to imply that living on sand is a permanent part of the development process. The best practice in such cases is either: to cut regular milestones of the upstream dependency; or to refactor the upstream dependency into an API and IMPL. The API should be stable between sprints, and newer versions of the IMPL should only fix bugs or introduce new features, hence you don't need the latest. Use a CI system (e.g. Jenkins) to run builds on both the current code as in SCM, and integration builds with the latest bleeding edge shifting sand dependencies. — Stephen Connolly, Feb 04 '13 at 09:10
You could have Jenkins cut milestone releases of all your stuff every night, and advance versions automatically. Alternatively, if they are *that* tightly coupled, perhaps they should be in the same multi-module build and then the `-SNAPSHOT` dependency will be updated by the Maven release plugin automatically when releasing the multi-module project as one. — Stephen Connolly, Feb 04 '13 at 09:12
thanks alot for your inputs.. but this is what I am testing now 1. Use `dependencyManagement` in 20 Parent POMs 2. Use `dependencies` in the rest 50 or so module POMs 3. Use a pre-build step in Jenkins `mvn versions:use-releases -DallowSnapshots=true` 4. `mvn release` as the main build step 5. Use a post-build step in Jenkins `mvn versions:use-latest-snapshots -DallowSnapshots=true` 6. Repeat steps 3-5 for 20 projects in Jenkins. Maybe automate that too with script/CLI. In short, convert all snapshot dependencies to Release before the actual release, then after the release convert back to SS — Pulak Agrawal, Feb 05 '13 at 12:32
this solution which I was testing works.. with some modifications. I'll post a proper answer on how to do it with Jenkins — Pulak Agrawal, Feb 19 '13 at 07:48

Maven release and versions maven plugin

Past:

Present:

Problem:

Question:

1 Answers1