2

All our projects are built using maven. we have centralized some of our main configuration within a super pom.

In order to always have an update version of this super pom (without having to modify the version), we have used the following syntax :

<parent>
    <groupId>my.organization</groupId>
    <artifactId>superPom</artifactId>
    <version>RELEASE</version>
</parent>

The problem is that Maven Eclipse plugin (m2e) doesn't understand this syntax (the RELEASE constant is not resolved). So, our Eclipse users can't use built-in compilation.

What do you suggest to overcome this problem ?

By the way, we have tried several options from a maven point of view (especially those described here), but the version.RELEASE is the easiest for everybody (except those who are using Eclipse).

EDIT: Our projects sources are split within multiple SVN repositories. This super pom is an independent project. It is retrieved through our Nexus server.

Community
  • 1
  • 1
Arno
  • 737
  • 4
  • 17

2 Answers2

3

You are trying to go into the wrong direction. A release in maven is a particular version like 1.0.0 and it indicates that you have a defined state of that artifact. In your case you super pom has a particular state. If you are trying to define the version to "RELEASE" you are saying my release is always the same but in reallity it's not true.

Usually such a super pom will change over the time lets say today you have defined some particular dependency versions in it (dependencyManagemet). And tomorrow you change those definition. Now the 1.000.000$ questions which state of the super pom is used in a build which has been done today? Ok in that simple scenario you can answer the question but if you have changed the super pom sometime yesterday you can't answer the question accurately.

Furthermore if you try to recreate an artifact of let's say last week you can't say which exact state of super pom has been used at that particular time cause you have no indicator which gives you the chance to see it.

And that's the reason why you need real versions like 1.0.0 or 1.1.0 etc.

I can strongly recomment to use real versions like 1.0.0 etc. but NOT things like "RELEASE" that will creep in the Maven system with its corrdinate group, artifact and version.

khmarbaise
  • 81,692
  • 23
  • 160
  • 199
  • I totally agree with your point on how to use versions. I actually have to deal with this situation. – Arno Sep 11 '12 at 16:36
  • I think, my explanation wasn't accurate enough: the super pom constraint comes from the release management team. The content is exclusively related to RM (repositories, ...). I don't care if this configuration changes. But i don't wan't the developers to spend time in updating the version of this super pom. We tried the snapshot solution (as mentionned by Yanflea), but the RM guys broke our build several times while testing their new configuration. – Arno Sep 11 '12 at 16:44
  • @Arno, you said the parent pom is an independent project and comes from the release management team, I can't imagine how this would work. The parent pom may simple but it is a part of the multi-module project (which becomes a specific artifact `groupId:artifact:version` when doing build, with type pom, no difference with a jar or war artifact), it is not a configuration file that should be managed by elease management team. – yorkw Sep 11 '12 at 21:32
2

Version ranges and expansion indeed do not work for parent artifacts.

Someone advised to invoke the version plugin instead :

mvn versions:update-parent

which does not cover exactly your need, but I am afraid there is no better workaround. Other ideas : using a SNAPSHOT parent pom (not very satisfactory I admit). See also Maven2 cannot find parent from relative path.

Community
  • 1
  • 1
Yanflea
  • 3,716
  • 1
  • 12
  • 14