Issue Details (XML | Word | Printable)

Key: MNG-2796
Type: Bug Bug
Status: Closed Closed
Resolution: Duplicate
Priority: Major Major
Assignee: Unassigned
Reporter: David Jencks
Votes: 15
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Maven 2 & 3

Yet another snapshot/timestamp version resolution problem

Created: 26/Jan/07 05:50 PM   Updated: 17/Dec/08 10:06 PM   Resolved: 16/Jun/07 04:00 AM
Component/s: Artifacts and Repositories, Inheritance and Interpolation
Affects Version/s: 2.0.4
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Duplicate
 
Related
 

Complexity: Intermediate


 Description  « Hide

In the geronimo openejb3 integration we've encountered yet another problem with broken version resolution. It would be great if the maven team could fix these problems soon: I think that the geronimo and openejb developers have now spent several weeks trying to understand bizarre version resolution errors and trying to find workarounds for them.

Here's what we think the relevant project details are. Reproducing this problem requires deploying snapshots at different revision numbers so I don't really see how to provide a test project.

openejb project structure:

base openejb pom

openejb container pom, parent is openejb pom. Snapshot deployed with a timestamped version 3.0-incubating-20070126.103431-21

openejb server pom, parent is openejb pom. Snapshot deployed with a timestamped version 3.0-incubating-20070126.103431-20
server pom has a dependency on container pom, using this:

<dependencies>
<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>container</artifactId>
<version>${pom.version}</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
</dependencies>


Subproject server/openejb-ejbd, parent pom is server.pom. Snapshot deployed at 3.0-incubating-20070126.103431-20

Both container and server are pom-packaged projects, i.e. they have no code of their own.

Openejb builds and deploys fine by itself, and the timestamped versions are as indicated above.

geronimo-openejb module has a dependency

<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>openejb-ejbd</artifactId>
</dependency>

whose version is supplied in an ancestor dependencyManagement section:

<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>openejb-ejbd</artifactId>
<version>${openejbVersion}</version>
</dependency>

where

<openejbVersion>3.0-incubating-SNAPSHOT</openejbVersion>


When we build the geronimo-openejb module in geronimo the build breaks because the incorrect version of openejb container is resolved:

This appears to be the relevant section of the -X trace, note that after the incorrect non-resolution at -20 container is correctly resolved at -21 a few lines later:

[DEBUG] openejb-client: resolved to version 3.0-incubating-20070126.103431-20 from repository apache.snapshots
[DEBUG] Retrieving parent-POM: org.apache.openejb:server::3.0-incubating-SNAPSHOT for project: null:openejb-client:jar:3.0-incubating-20070126.103431-20 from the repository.
[DEBUG] server: resolved to version 3.0-incubating-20070126.103431-20 from repository apache.snapshots
[DEBUG] Retrieving parent-POM: org.apache.openejb:openejb::3.0-incubating-SNAPSHOT for project: null:server:pom:null from the repository.
[DEBUG] openejb: resolved to version 3.0-incubating-20070126.103431-22 from repository apache.snapshots
[DEBUG] Retrieving parent-POM: org.apache:apache::3 for project: org.apache.openejb:openejb:pom:3.0-incubating-SNAPSHOT from the repository.
[DEBUG] org.apache.openejb:openejb-client:jar:3.0-incubating-SNAPSHOT:compile (selected for compile)
[DEBUG] Retrieving parent-POM: org.apache.geronimo.specs:specs::1.2 for project: null:geronimo-ejb_3.0_spec:jar:1.0-M1 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.geronimo.genesis.config:project-config::1.1 for project: org.apache.geronimo.specs:specs:pom:1.2 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.geronimo.genesis.config:config::1.1 for project: null:project-config:pom:null from the repository.
[DEBUG] Retrieving parent-POM: org.apache.geronimo.genesis:genesis::1.1 for project: org.apache.geronimo.genesis.config:config:pom:null from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::3 for project: org.apache.geronimo.genesis:genesis:pom:1.1 from the repository.
[DEBUG] org.apache.geronimo.specs:geronimo-ejb_3.0_spec:jar:1.0-M1:compile (removed - nearer found: 1.0)
[DEBUG] Artifact not found - using stub model: System is offline.

org.apache.openejb:container:pom:3.0-incubating-20070126.103431-20


[DEBUG] Using defaults for missing POM org.apache.openejb:container:pom:3.0-incubating-SNAPSHOT:compile
[DEBUG] org.apache.openejb:container:pom:3.0-incubating-20070126.103431-20:compile (selected for compile)
[DEBUG] org.apache.geronimo.specs:geronimo-ejb_3.0_spec:jar:1.0-M1:compile (removed - nearer found: 1.0)
[DEBUG] org.apache.openejb:container:pom:3.0-incubating-20070126.103431-20:compile (selected for compile)
[DEBUG] Skipping disabled repository tomcat-m2-repo
[DEBUG] Skipping disabled repository apache-incubator
[DEBUG] Skipping disabled repository codehaus
[DEBUG] Skipping disabled repository central
[DEBUG] openejb-core: resolved to version 3.0-incubating-20070126.103431-20 from repository apache.snapshots
[DEBUG] Retrieving parent-POM: org.apache.openejb:container::3.0-incubating-SNAPSHOT for project: null:openejb-core:jar:3.0-incubating-20070126.103431-20 from the repository.
[DEBUG] Skipping disabled repository tomcat-m2-repo
[DEBUG] Skipping disabled repository apache-incubator
[DEBUG] Skipping disabled repository codehaus
[DEBUG] Skipping disabled repository central
[DEBUG] container: resolved to version 3.0-incubating-20070126.103431-21 from repository apache.snapshots
[

The error at the end of the build is:

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

Missing:
----------
1) org.apache.openejb:container:pom:3.0-incubating-SNAPSHOT
Path to dependency:
1) org.apache.geronimo.modules:geronimo-openejb:jar:2.0-M2-SNAPSHOT
2) org.apache.openejb:openejb-ejbd:jar:3.0-incubating-SNAPSHOT
3) org.apache.openejb:container:pom:3.0-incubating-20070126.103431-20

----------
1 required artifact is missing.

for artifact:
org.apache.geronimo.modules:geronimo-openejb:jar:2.0-M2-SNAPSHOT
...
...

Changing the ${pom.version} to 3.0-incubating-SNAPSHOT fixes the issue as apparently does defining a property

<version>3.0-incubating-SNAPSHOT</version> and replacing ${pom.version} with ${version}

---------------------------------------
There are a lot of possibly related issues:
MNG-2339
MNG-2486
MNG-2647
MNG-2651
MNG-2653
MNG-2756
MNG-2782



Jason Dillon added a comment - 06/Feb/07 08:54 PM

IMO, maven should never change the value of ${pom.version} ... if a pom says:

<project>
    ...
    <version>1.2-SNAPSHOT</version>
    ...
</project>


Then ${pom.version} should always resolve to 1.2-SNAPSHOT. If you need to know what the timestamp-build version is then I suggest adding ${pom.effectiveVersion} which can change dynamically.


Jason Dillon added a comment - 06/Feb/07 09:09 PM

Also, I can hear this coming... "why don't you use <dependencyManagement>...". This feature of Maven is great for managing external dependencies, but for internal module management it becomes unmanageable quickly.

For Geronimo, we have ~200+ modules and to enumerate each one of those in a <dependencyManagement> is unruly, and tends to become unmaintained quickly. Its much easier to use <version>${pom.version}</version> in poms when defining dependencies sibling modules.

But, as noted by David, this won't work when dealing with snapshots as when deploying a snapshot, the module being deployed will have its ${pom.version} changed magically to the timestamp-build version which is going to produce invalid dependencies, since the dependencies using <version>${pom.version}</version> now have invalid versions (using the deployed modules timestamp-build version not the timestamp-build version of the dependency.

I really think the best way to handle this is to never change the value of ${pom.version} and introduce a ${pom.effectiveVersion} which will dynamically change.