6

I have a company-wide parent pom with a <dependencyManagement> section which defines the versions of my projects that should be used throughout my application, some of which are SNAPSHOTs, a bit like this:

<dependencyManagement>
  <dependencies>
    ...
    <dependency>
      <groupId>my.group</groupId>
      <artifactId>myArtifact</artifactId>
      <version>1.0-SNAPSHOT</version>
    </dependency>
    ...
  <dependencies>
</dependencyManagement>

When I run release:prepare on the parent pom, these SNAPSHOTs are not removed. The result is that the projects which inherit from the parent cannot use its versions when being released themselves. How do I ensure that the <dependencyManagement> section of the parent pom is updated when I release?

I saw this question: why does maven release plugin allow for SNAPSHOT version in dependency managment?, but the tickets mentioned claim to be fixed in earlier versions of the plugin.

Maven Release Plugin 2.3.1
Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+0000)
Java version: 1.6.0_31, vendor: Sun Microsystems Inc.
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Community
  • 1
  • 1
Conan
  • 2,288
  • 1
  • 28
  • 42
  • Is the given dependency part of your reactor? – khmarbaise Jun 07 '12 at 18:17
  • No, in this case it is not. The parent pom does not have any modules declared in it, as it is used across a number of different projects. The idea is to centralise stuff that's common to all our projects, such as repositories, metadata, etc. Does that make a difference? – Conan Jun 08 '12 at 08:04
  • So, what is you real problem ? - You can't release your own project ? - You'd like the plugin strip snapshot as it is mentionned in JIRA's ? – Jean-Rémy Revy Jun 08 '12 at 11:20
  • I can release the parent fine, it just has SNAPSHOTs in its `` section. The problem is that when I come to release a project that is inheriting from it, it will inherit these SNAPSHOT versions - and the release plugin doesn't pick up on that fact, leading to an unreliable release. – Conan Jun 08 '12 at 16:52

2 Answers2

1

So you are trying to release artifacts that are not part of the build you are preparing? If you make a relase:perform, which artifacts should the plugin upload to the repository if they doesn't exist? (if they do, why do you put the snapshot version?).
I think as @khmarbaise said, the plugin will not remove SNAPSHOTS that are not part of your reactor (the plugin may think they are third party dependencys).

This is a comment, I've put it as answer because I dont' have reputation to post comments yet... and Sorry for my English!

Pablo Lascano
  • 662
  • 6
  • 14
  • Yes, in this scenario I'm releasing just a parent artifact, with `pom` packaging. The only artifact I expect to be uploaded at this time is the parent pom. When it comes to actually releasing a particular code-containing project, it'll be inheriting from the released parent and hence using the versions defined in its `` section; if they contain SNAPSHOTs, then my release is in a dubious state where I can't rely on it being re-usable in future. – Conan Jun 08 '12 at 16:49
  • As a workaround, if the purpose of the release is just replace SNAPSHOT on dependencyManagement and commit to SCM you should try doing only that process manually (or better make a batch process), do not manually change the versions on each project, come on don give up!. Try something like this (in a .bat file): sed -i 's/-SNAPSHOT//g' pom.xml; cvs commit pom.xml. You can use GnuWin for sed functionality, or better, start using linux! – Pablo Lascano Jun 08 '12 at 18:48
1

The maven-release-plugin is only concerned with checking whether you have SNAPSHOT-s in your <dependencies/> section. The <dependencies/> will be inherited by all modules which extend this parent. They will always try to resolve these dependencies before building.

The difference between the <dependencies/> and <dependencyManagement/> sections is that the latter only defines versions which will be used. This said, the release plugin is not at all concerned if you have defined SNAPSHOT-s there, unless this parent project is an aggregator or part of an aggregator and this parent is being released as a whole with the aggregator.

Similarly, the maven-release-plugin does not take care of <pluginManagement/>. Also, I believe it only addresses Maven properties containing artifact versions only when these are relating to <dependencies/>.

The worse part is -- as far as I recall -- you will not even get warned if a dependency/plugin has a SNAPSHOT version, if it's in a <*Management/> section.

For this reason, the approach I have resorted to is to have a parent POM with <properties/> containing the versions of the artifacts. Before releasing it, I scan it for SNAPSHOT-s using grep:

grep SNAPSHOT pom.xml
carlspring
  • 31,231
  • 29
  • 115
  • 197
  • I do actually have the versions defined in `` in the parent pom, which are then referenced in the `` section. I was hoping to define all the versions of our internal projects in a single pom as SNAPSHOTs, and keep all versions out of our various project poms. That relies on the parent pom specifying release versions in the dependencyManagement however, so I guess this won't work. I guess I'll have to move the version info into each different project, which is a shame. I want to avoid having to manually change versions as part of the release process. – Conan Jun 08 '12 at 16:44
  • 1
    What surprises me about this is that when I release a particular project which is inheriting versions from the `` section of the parent, that it doesn't complain about the SNAPSHOTs. It seems that if the versions aren't mentioned in the poms being released, then the release plugin just lets them go rather than prompting to remove the SNAPSHOTs. – Conan Jun 08 '12 at 16:46
  • 1
    I'm sad that `` behaves this way, but it seems to be by design, so I'm accepting this answer. Thanks for your feedback! – Conan Jun 12 '12 at 11:45
  • Unfortunately, at times, even code following conventions has it's limitations and unforseen (at the time of it's writing) usages. You could always file either a change request or bug report in the JIRA: http://jira.codehaus.org/browse/MRELEASE . – carlspring Jun 12 '12 at 12:26