jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2.x Release Plugin
  • MRELEASE-161

If there is more than one artifact with the same artifactId in dependencyManagement only the first one is updated

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0-beta-4
  • Fix Version/s: None
  • Component/s: prepare
  • Labels:
    None
  • Environment:
    Maven 2.0.4 under windows
  • Testcase included:
    yes
  • Patch Submitted:
    Yes

Description

I have a multi module project. When I do release:prepare, the release plugin update the version tag of all my submodules in the dependencyManagement section.
For the same module I have declared two artifacts like this :

<dependency>
  <groupId>com.bla</groupId>
  <artifactId>blabla</artifactId>
  <version>1.0-SNAPSHOT</version>
  <type>test-jar</type>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>com.bla</groupId>
  <artifactId>blabla</artifactId>
  <version>1.0-SNAPSHOT</version>
</dependency>

In this case, the release plugin only update the first dependency.

This is due to element search in the "updateDomVersion" method of the AbstractRewritePomsPhase class. I've attached a patch to solve the problem. I don't know if this is the right way to do. I change all the artifacts in the same pass. I don't take car of different type/classifier

  • Options
    • Sort By Name
    • Sort By Date
    • Ascending
    • Descending
    • Download All

Attachments

  1. Text File
    MRELEASE-161.patch
    01/Feb/11 3:17 AM
    0.8 kB
    Reimo Daum
  2. Text File
    multipleArtifacts.patch
    13/Sep/06 8:43 AM
    3 kB
    Sébastien Cesbron
  3. Hide
    Zip Archive
    release-test.zip
    09/May/07 11:06 AM
    14 kB
    Chris Wewerka
    1. XML File
      release-test/pom.xml 2 kB
    2. File
      release-test/.../.classpath 0.4 kB
    3. File
      release-test/.../.project 0.7 kB
    4. File
      release-test/.../.component 0.2 kB
    5. File
      release-test/.../org.eclipse.jdt.core.prefs 0.2 kB
    6. XML File
      release-test/.../org.eclipse.wst.common.project.facet.core.xml 0.2 kB
    7. XML File
      release-test/.../pom.xml 1 kB
    8. Java Source File
      release-test/.../AppModuleOne.java 0.2 kB
    9. Java Source File
      release-test/.../AppTestModuleOne.java 0.7 kB
    10. File
      release-test/.../.classpath 0.5 kB
    11. File
      release-test/.../.project 0.7 kB
    12. File
      release-test/.../.component 0.2 kB
    13. File
      release-test/.../org.eclipse.jdt.core.prefs 0.2 kB
    14. XML File
      release-test/.../org.eclipse.wst.common.project.facet.core.xml 0.2 kB
    15. XML File
      release-test/.../pom.xml 1 kB
    16. Java Source File
      release-test/.../AppModuleTwo.java 0.2 kB
    17. Java Source File
      release-test/.../AppTestModuleTwo.java 0.8 kB
    Download Zip
    Show
    Zip Archive
    release-test.zip
    09/May/07 11:06 AM
    14 kB
    Chris Wewerka

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MRELEASE-634 Versions of snapshot dependencies to the same artifact with different classifiers are not updated correctly during release:prepare

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MRELEASE-659 snapshot dependency check on preparation of release: check artifacts WITH versions

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-2871 Subartifact (ejb-client, test-jar etc.) are not reselved as active project artifacts in build phases prior to package

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Chris Wewerka added a comment - 09/May/07 11:01 AM

With 2.0-beta-5 and maven 2.0.6 a related issue (two dependencies to a project, one to the normal artifact, one to the test-jar) results in an error:

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

Missing:
----------
1) com.o2.release-test:release-test-module-one:test-jar:tests:5.0.2

I've attached a testcase to reproduce this bug.

Show
Chris Wewerka added a comment - 09/May/07 11:01 AM With 2.0-beta-5 and maven 2.0.6 a related issue (two dependencies to a project, one to the normal artifact, one to the test-jar) results in an error: [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Failed to resolve artifact. Missing: ---------- 1) com.o2.release-test:release-test-module-one:test-jar:tests:5.0.2 I've attached a testcase to reproduce this bug.
Hide
Permalink
Chris Wewerka added a comment - 09/May/07 11:06 AM

Testcase for the above comment

Show
Chris Wewerka added a comment - 09/May/07 11:06 AM Testcase for the above comment
Hide
Permalink
Vincent Dupain added a comment - 28/Sep/07 4:26 AM

There a workflow to this bug: generate one jar that merge main jar and test jar:
<build>
<resources>
<resource>
<directory>src/main/java</directory>
<targetPath>../../src/merge/java</targetPath>
</resource>
<resource>
<directory>src/test/java</directory>
<targetPath>../../src/merge/java</targetPath>
</resource>
</resources>
<sourceDirectory>src/merge/java</sourceDirectory>

<plugins>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<configuration>
<filesets>
<fileset>
<directory>src/merge/java</directory>
</fileset>
</filesets>
</configuration>
</plugin>
...
<build>

and in the pom that depends on the 2 jars, you only have to depend on the main jar
<dependencies>
<!-- Kamayo Dependencies -->
<!--
<dependency>
<groupId>com.kamayo</groupId>
<artifactId>core</artifactId>
<version>${version}</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>
-->
<dependency>
<groupId>com.kamayo</groupId>
<artifactId>core</artifactId>
<version>${version}</version>
<type>jar</type>
</dependency>
...
</dependencies>

Show
Vincent Dupain added a comment - 28/Sep/07 4:26 AM There a workflow to this bug: generate one jar that merge main jar and test jar: <build> <resources> <resource> <directory>src/main/java</directory> <targetPath>../../src/merge/java</targetPath> </resource> <resource> <directory>src/test/java</directory> <targetPath>../../src/merge/java</targetPath> </resource> </resources> <sourceDirectory>src/merge/java</sourceDirectory> <plugins> <plugin> <artifactId>maven-clean-plugin</artifactId> <configuration> <filesets> <fileset> <directory>src/merge/java</directory> </fileset> </filesets> </configuration> </plugin> ... <build> and in the pom that depends on the 2 jars, you only have to depend on the main jar <dependencies> <!-- Kamayo Dependencies --> <!-- <dependency> <groupId>com.kamayo</groupId> <artifactId>core</artifactId> <version>${version}</version> <type>test-jar</type> <scope>test</scope> </dependency> --> <dependency> <groupId>com.kamayo</groupId> <artifactId>core</artifactId> <version>${version}</version> <type>jar</type> </dependency> ... </dependencies>
Hide
Permalink
Reimo Daum added a comment - 01/Feb/11 3:17 AM

I attached possible solution for this bug - it does not break tests but i'm not sure if it's a correct way to solve this issue as this loop break has been there for ages.

My solutions is not to break the loop as there are also other dependendcies with same "groupId + artifactId" but different type.

Show
Reimo Daum added a comment - 01/Feb/11 3:17 AM I attached possible solution for this bug - it does not break tests but i'm not sure if it's a correct way to solve this issue as this loop break has been there for ages. My solutions is not to break the loop as there are also other dependendcies with same "groupId + artifactId" but different type.

People

  • Assignee:
    Unassigned
    Reporter:
    Sébastien Cesbron
Vote (10)
Watch (10)

Dates

  • Created:
    13/Sep/06 8:43 AM
    Updated:
    28/Feb/12 3:23 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.