Maven 2 & 3

version expression constant

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1
  • Fix Version/s: Issues to be reviewed for 3.x
  • Component/s: Dependencies, POM
  • Labels:
    None
  • Environment:
    eclipse linux xp
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

early versions, we define modules versions with expressions, and set them to the parent pom,
simply;

<properties>
<ibb-core-cache.version>1.0.1</ibb-core-cache.version>
<ibb-core-util.version>1.0.1</ibb-core-util.version>
</properties>

and then, we give this property to modules pom as expression ,

<name>ik-plug</name>
<packaging>jar</packaging>
<version>$

{ibb-core-util.versionn}

</version>

but know , it gives an error you know like this,
"[WARNING] Some problems were encountered while building the effective model for ibb-parent:ibb-modules-parent:pom:1.0.0
[WARNING] 'version' contains an expression but should be a constant. @ ibb-parent:ibb-modules-parent:$

{ibb-core-jars.version}

, C:\dev\ibb\workspace\core\ibb-modules-parent\pom.xml
"

but I think that, this enhancement is causes wrong result,

think that , if we have i project already developing about 3 years, this project has a lot of modules, and this modules have sub modules , and this sub modules already bound to some other modules not define in your pom, but your updates must be affect them, at this situation, developer want to write the existing version numbers with properties to parent pom, and want to manage them like this. at the attach file below , the close projects are belongs to open projects, but they are the different team developing this. I cant force the other developers to cache their versions, I must use this versions as initial step

Issue Links

is related to

Improvement - An improvement or enhancement to an existing feature or task. MNG-4297 Disallow use of properties in the project coordinates

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Chris Price added a comment -

I think there are valid use cases where expressions should be able to be used as version numbers. At least until mix-ins become available, using expressions for version numbers allows us to keep our poms DRY in ways that would be impossible otherwise.

For example, we have the following:

  • A super POM that EVERYTHING inherits from
  • A "jar" pom that contains settings that we use on our "standard" jars
  • A "swc" pom that contains settings we use on swcs.

We have two projects that we release, let's call them "Project A" and "Project B". Both are multimodule projects and contain both jars and swcs.

Right now, we keep version number constants in the super POM, like:

<properties>
<version.project-a>3.1-SNAPSHOT</version.project-b>
<version.project-b>7.3-SNAPSHOT</version.project-b>
</properties>

Using this pattern, poms from A and B can inherit from the jar/swc parent poms accordingly, and just specify $

{version.project-a}

for their version number. And there is NOTHING that we have to maintain in more than one place.

If we have to have a single "project-a" parent pom that explicitly specifies a version number, then we are going to have to have the jar/swc parent poms inherit from that one, and then have the real modules inside of project a inherit from those. And we'll have to maintain another copy of those jar/swc poms for project b. With mix-ins we should be able to eliminate that redundancy, but until then, we are faced with the choice of using expressions for the version numbers or duplicating all of the content of our jar/swc poms, and the expressions path seems MUCH more manageable.

Show
Chris Price added a comment - I think there are valid use cases where expressions should be able to be used as version numbers. At least until mix-ins become available, using expressions for version numbers allows us to keep our poms DRY in ways that would be impossible otherwise. For example, we have the following: A super POM that EVERYTHING inherits from A "jar" pom that contains settings that we use on our "standard" jars A "swc" pom that contains settings we use on swcs. We have two projects that we release, let's call them "Project A" and "Project B". Both are multimodule projects and contain both jars and swcs. Right now, we keep version number constants in the super POM, like: <properties> <version.project-a>3.1-SNAPSHOT</version.project-b> <version.project-b>7.3-SNAPSHOT</version.project-b> </properties> Using this pattern, poms from A and B can inherit from the jar/swc parent poms accordingly, and just specify $ {version.project-a} for their version number. And there is NOTHING that we have to maintain in more than one place. If we have to have a single "project-a" parent pom that explicitly specifies a version number, then we are going to have to have the jar/swc parent poms inherit from that one, and then have the real modules inside of project a inherit from those. And we'll have to maintain another copy of those jar/swc poms for project b. With mix-ins we should be able to eliminate that redundancy, but until then, we are faced with the choice of using expressions for the version numbers or duplicating all of the content of our jar/swc poms, and the expressions path seems MUCH more manageable.
Hide
Permalink
Axel Fontaine added a comment -

I also believe expressions should be allowed.

This enables you to decouple updating your version number from checking in to version control, which is one of the big problems with the traditional Maven release process.

This way, the only change actually commited for a new release is the code. No need to additionally modify the POM.

I've described this in detail here: http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios.html

Show
Axel Fontaine added a comment - I also believe expressions should be allowed. This enables you to decouple updating your version number from checking in to version control, which is one of the big problems with the traditional Maven release process. This way, the only change actually commited for a new release is the code. No need to additionally modify the POM. I've described this in detail here: http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios.html
Hide
Permalink
Don Brown added a comment -

Agreed. I've started converting projects to not have the version hard-coded in the poms and it has done wonders to development speed and flexibility, especially in a continuous deployment environment.

Show
Don Brown added a comment - Agreed. I've started converting projects to not have the version hard-coded in the poms and it has done wonders to development speed and flexibility, especially in a continuous deployment environment.
Hide
Permalink
Nicolas Grobisa added a comment -

I agree with Axel Fontaine and Don Brown. I have been investigating this problem for some time now.
I believe Maven is taking a wrong turn here. I understand why they want to do it: Basically, if you allow version expressions, you may endanger reproducibility, but this cannot be a restriction. In any case, it should be a configurable warning/error. This restriction is a major barrier for people wanting to do continuous delivery.
The essence of the problem comes from Maven wanting to do everything. In some ways, it is analog to storing the SCM URL inside the POM. For many reasons and in different scenarios, some of the POM information should be kept outside the POM, or at least provide the flexibility for users to do it one way or the other.

Show
Nicolas Grobisa added a comment - I agree with Axel Fontaine and Don Brown. I have been investigating this problem for some time now. I believe Maven is taking a wrong turn here. I understand why they want to do it: Basically, if you allow version expressions, you may endanger reproducibility, but this cannot be a restriction. In any case, it should be a configurable warning/error. This restriction is a major barrier for people wanting to do continuous delivery. The essence of the problem comes from Maven wanting to do everything. In some ways, it is analog to storing the SCM URL inside the POM. For many reasons and in different scenarios, some of the POM information should be kept outside the POM, or at least provide the flexibility for users to do it one way or the other.
Hide
Permalink
Cameron Rochester added a comment -

We are also using a centralised list of version properties for managing our multi-module build. At last count we have about 50 modules each with independent versions. There doesn't seem to be anyway to manage versions in a centralised manner beyond this approach. I also think Maven needs to reconsider where they are going with this approach.

Show
Cameron Rochester added a comment - We are also using a centralised list of version properties for managing our multi-module build. At last count we have about 50 modules each with independent versions. There doesn't seem to be anyway to manage versions in a centralised manner beyond this approach. I also think Maven needs to reconsider where they are going with this approach.
Hide
Permalink
Nathaniel Mishkin added a comment -

FWIW, my use case for using properties in specifying the <version> for a project's component is this: I've created a project whose sole purpose in life is to create a variant (in this case, signed) of an existing artifact that's not mine (not produced by any of my projects). In the variant project I've created I want to do something like this:

<project>
<properties>
<x.version>4.32</x.version>
</properties>

<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>x</artifactId>
<version>$

{x.version}</version>
</dependency>
</dependencies>

<groupId>...</groupId>
<artifactId>x.variant</artifactId>
<version>${x.version}

</version>
...
</project>

(In real life the property definition is specified an ancestor POM.)

Show
Nathaniel Mishkin added a comment - FWIW, my use case for using properties in specifying the <version> for a project's component is this: I've created a project whose sole purpose in life is to create a variant (in this case, signed) of an existing artifact that's not mine (not produced by any of my projects). In the variant project I've created I want to do something like this: <project> <properties> <x.version>4.32</x.version> </properties> <dependencies> <dependency> <groupId>...</groupId> <artifactId>x</artifactId> <version>$ {x.version}</version> </dependency> </dependencies> <groupId>...</groupId> <artifactId>x.variant</artifactId> <version>${x.version} </version> ... </project> (In real life the property definition is specified an ancestor POM.)

People

  • Assignee:
    Unassigned
    Reporter:
    Faruk
Vote (43)
Watch (41)

Dates

  • Created:
    Updated: