Maven 2 & 3

Modules of Maven projects are deployed with Timestamp during reactor build when uniqueVersion is set to false in parent profile

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.8
  • Fix Version/s: 2.0.11, 2.1.0-M1, 3.0-alpha-3
  • Component/s: Deployment
  • Labels:
    None
  • Environment:
    Red Hat Linux, Maven 2.0.8, Java 1.6, Cruisecontrol
  • Complexity:
    Intermediate
  • Number of attachments :
    4

Description

When deploying artifacts into local repository with cruisecontrol by using the following command:

mvn -U -P mvn-profile ... -DuniqueVersion=false deploy

The parent is always beeing deployed correctly, without timestamp as <MODULE_VERSION>-SNAPSHOT. But all Modules are beeing deployed with Timestamp.

Issue Links

This issue is duplicated by:
MDEPLOY-57 <uniqueVersion>false</uniqueVersion> not honored inside <profile> Critical Closed
This issue supercedes:
MNG-2470 uniqueVersion not inherited in child projects Major Closed
This issue depends upon:
MNG-4009 [regression] Effects of active profiles from parent are not inherited by children. Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Matthias Wegerhoff added a comment -

I recognized that this only happens when deploying snapshots with a profile defined in settings.xml. When defining Repositories in a profile in settings xml and deploying the artifact by using this profile with

mvn -U -P mvn-profile ... -DuniqueVersion=false deploy

all modules are beeing deployed with timestamps.

Show
Matthias Wegerhoff added a comment - I recognized that this only happens when deploying snapshots with a profile defined in settings.xml. When defining Repositories in a profile in settings xml and deploying the artifact by using this profile with mvn -U -P mvn-profile ... -DuniqueVersion=false deploy all modules are beeing deployed with timestamps.
Hide
Permalink
Brett Porter added a comment -

are you defining uniqueVersion in your POM somehow? It is not an option to Maven or the deploy plugin, so it would need to be substituted into the distributionManagement element of your POM.

Could you provide a small number of POMs that illustrates the problem?

Show
Brett Porter added a comment - are you defining uniqueVersion in your POM somehow? It is not an option to Maven or the deploy plugin, so it would need to be substituted into the distributionManagement element of your POM. Could you provide a small number of POMs that illustrates the problem?
Hide
Permalink
Matthias Wegerhoff added a comment -

Thanks for your response, i attached a minimized pom.xml as well as a minimized settings.xml that is used by out build-server.

Show
Matthias Wegerhoff added a comment - Thanks for your response, i attached a minimized pom.xml as well as a minimized settings.xml that is used by out build-server.
Hide
Permalink
Brett Porter added a comment -

given these settings, I expect -DuniqueVersion=true|false to have no effect.

So since the POM defines it with <uniqueVersion>false</uniqueVersion> that should be honoured. Is that what is happening?

Show
Brett Porter added a comment - given these settings, I expect -DuniqueVersion=true|false to have no effect. So since the POM defines it with <uniqueVersion>false</uniqueVersion> that should be honoured. Is that what is happening?
Hide
Permalink
Matthias Wegerhoff added a comment -

Defining <uniqueVersion>false</uniqueVersion> in the projects pom.xml takes only effect on the parent but not on child-modules. No matter if i´m calling the deploy-goal with or without the parameter -DuniqueVerison=false

Show
Matthias Wegerhoff added a comment - Defining <uniqueVersion>false</uniqueVersion> in the projects pom.xml takes only effect on the parent but not on child-modules. No matter if i´m calling the deploy-goal with or without the parameter -DuniqueVerison=false
Hide
Permalink
Brett Porter added a comment -

do your child modules declare a repository as well?

Show
Brett Porter added a comment - do your child modules declare a repository as well?
Hide
Permalink
Matthias Wegerhoff added a comment -

No, they lust define their parent:

<parent>
<artifactId>example</artifactId>
<groupId>de.myCompany</groupId>
<version>trunk-SNAPSHOT</version>
<relativePath>../pom.xml</relativePath>
</parent>

Do I have to add an seperate profile/distributionManagement section in every child-pom?

Show
Matthias Wegerhoff added a comment - No, they lust define their parent: <parent> <artifactId>example</artifactId> <groupId>de.myCompany</groupId> <version>trunk-SNAPSHOT</version> <relativePath>../pom.xml</relativePath> </parent> Do I have to add an seperate profile/distributionManagement section in every child-pom?
Hide
Permalink
Brett Porter added a comment -

I can't reproduce the problem. See attached test case

Show
Brett Porter added a comment - I can't reproduce the problem. See attached test case
Hide
Permalink
Benjamin Bentmann added a comment -

Fixed in r737402. Already works in Maven 2.1.x as of r689163.

Show
Benjamin Bentmann added a comment - Fixed in r737402. Already works in Maven 2.1.x as of r689163.
Hide
Permalink
Bob Fields added a comment -

We are seeing this issue in maven 2.2.1. A parent pom.xml with many submodules, was changed from uniqueVersion=true to uniqueVersion=false. No other repository configuration exists in any submodules. Child maven-metadata.xml files already existed with <versioning> info. The parent maven-metadata.xml file does not have a <versioning> section, but the child maven-metadata.xml files still have the old <versioning> info, causing a mismatch in dependencies.

Parent maven-metadata: http://oss.sonatype.org/content/groups/public/org/andromda/andromda/3.4-SNAPSHOT/maven-metadata.xml

Child maven-metadata: http://oss.sonatype.org/content/groups/public/org/andromda/andromda-core/3.4-SNAPSHOT/maven-metadata.xml

Show
Bob Fields added a comment - We are seeing this issue in maven 2.2.1. A parent pom.xml with many submodules, was changed from uniqueVersion=true to uniqueVersion=false. No other repository configuration exists in any submodules. Child maven-metadata.xml files already existed with <versioning> info. The parent maven-metadata.xml file does not have a <versioning> section, but the child maven-metadata.xml files still have the old <versioning> info, causing a mismatch in dependencies. Parent maven-metadata: http://oss.sonatype.org/content/groups/public/org/andromda/andromda/3.4-SNAPSHOT/maven-metadata.xml Child maven-metadata: http://oss.sonatype.org/content/groups/public/org/andromda/andromda-core/3.4-SNAPSHOT/maven-metadata.xml
Hide
Permalink
Bob Fields added a comment -

Sorry, we had to delete and re-create the referenced artifacts because everybody was broken, so they are correct currently. Deleting the old maven-metadata.xml files caused new ones to be created correctly, without the versioning info, however the deploy plugin really should update the metadata correctly without having to delete.

Show
Bob Fields added a comment - Sorry, we had to delete and re-create the referenced artifacts because everybody was broken, so they are correct currently. Deleting the old maven-metadata.xml files caused new ones to be created correctly, without the versioning info, however the deploy plugin really should update the metadata correctly without having to delete.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.