Maven 2 & 3

[regression] Resolution of parent POMs for dependency using version range does not consider all configured repositories

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 3.0.2
  • Fix Version/s: 3.0.3
  • Component/s: None
  • Labels:
    None
  • Environment:
    WinXP SP3, Java 6u20
  • Complexity:
    Intermediate
  • Number of attachments :
    5

Description

I have a bit of a strange issue. When running under Maven 3.0.2 I am getting build errors when I try to build one of our projects when one of their dependencies have a range version. But when setting it to a specific version it seems to work. The same project works without a hitch in Maven 2.2.1.

As can be seen from the first included verbose trace (mvn-verify-range-version.log). Maven attempts to get the pom from our snapshot repository. That will, obviously, not work for a released artefact.

Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems to skip that step completely. Even though it resolves to the same version in the end. As seen in the other verbose trace (mvn-verify-fixed-version.log)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Kristoffer Peterhansel added a comment -

I forgot to mention one thing - since it is not obvious. But in this case it seems to be the parent of the dependency with the version range (coreapis in this case) that is being checked. Not the parent of the project we are running maven against.

Show
Kristoffer Peterhansel added a comment - I forgot to mention one thing - since it is not obvious. But in this case it seems to be the parent of the dependency with the version range (coreapis in this case) that is being checked. Not the parent of the project we are running maven against.
Hide
Permalink
Kristoffer Peterhansel added a comment -

Just tried to do the same with the -o option. And interestingly enough it appears to still try to validate the masterproject pom against the snapshot repository. And it still fails with the 'excuse' that is cannot resolve it. Hard to accept since it finds it just fine as the parent of the project of the pom maven is running against - or it would fail much sooner.

Show
Kristoffer Peterhansel added a comment - Just tried to do the same with the -o option. And interestingly enough it appears to still try to validate the masterproject pom against the snapshot repository. And it still fails with the 'excuse' that is cannot resolve it. Hard to accept since it finds it just fine as the parent of the project of the pom maven is running against - or it would fail much sooner.
Hide
Permalink
Kristoffer Peterhansel added a comment -

I just realized that this works just fine on our Hudson server. So it seems like it could be some sort of environment thing. But they use the same identical settings.xml . The only differences I can think of is that it is running JDK 6u17 and Windows 2003 R2

Show
Kristoffer Peterhansel added a comment - I just realized that this works just fine on our Hudson server. So it seems like it could be some sort of environment thing. But they use the same identical settings.xml . The only differences I can think of is that it is running JDK 6u17 and Windows 2003 R2
Hide
Permalink
Sei Syvalta added a comment -

Adding my post to the user list here too:

I'm running into this too. I tried to create a test project but unfortunately the problem didn't reproduce there.

Some background:

  • dependency to artifact with version range [1.0.1, 2.0), matching versions [1.0.1, 1.0.2, 1.0.3-SNAPSHOT].
  • problems occurs when 1.0.3-SNAPSHOT tries to load it's released parent pom.
  • if parent of 1.0.3-SNAPSHOT is changed to a snapshot the build succeeds.

Some observations:

  • when SNAPSHOT is resolved from local repository it's list of repositories is empty. Also when it's parent is resolved it's list of repositories is empty.
  • org.apache.maven.model.building.DefaultModelBuilder.readParentExternally fails because of that (no repositories)
  • parent is not found from local repository because the key in repo tracking properties is "test-parent-pom-1.0.1.pom>releases" but is searched with key "test-parent-pom-1.0.1.pom>".

Stack trace from one point of execution:
org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(org.sonatype.aether.RepositorySystemSession, java.util.Collection<? extends org.sonatype.aether.resolution.ArtifactRequest>) line: 237
org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactRequest) line: 214
org.apache.maven.repository.internal.DefaultModelResolver.resolveModel(java.lang.String, java.lang.String, java.lang.String) line: 115
org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(org.apache.maven.model.Model, org.apache.maven.model.building.ModelBuildingRequest, org.apache.maven.model.building.DefaultModelProblemCollector) line: 819
org.apache.maven.model.building.DefaultModelBuilder.readParent(org.apache.maven.model.Model, org.apache.maven.model.building.ModelBuildingRequest, org.apache.maven.model.building.DefaultModelProblemCollector) line: 670
org.apache.maven.model.building.DefaultModelBuilder.build(org.apache.maven.model.building.ModelBuildingRequest, java.util.Collection<java.lang.String>) line: 308
org.apache.maven.model.building.DefaultModelBuilder.build(org.apache.maven.model.building.ModelBuildingRequest) line: 232
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactDescriptorRequest, org.sonatype.aether.resolution.ArtifactDescriptorResult) line: 308
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactDescriptorRequest) line: 173
org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.collection.CollectResult, java.util.LinkedList<org.sonatype.aether.impl.internal.GraphEdge>, java.util.List<org.sonatype.aether.graph.Dependency>, java.util.List<org.sonatype.aether.repository.RemoteRepository>, org.sonatype.aether.collection.DependencySelector, org.sonatype.aether.collection.DependencyManager, org.sonatype.aether.collection.DependencyTraverser, org.sonatype.aether.impl.internal.DataPool) line: 419
org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.collection.CollectRequest) line: 233

Show
Sei Syvalta added a comment - Adding my post to the user list here too: I'm running into this too. I tried to create a test project but unfortunately the problem didn't reproduce there. Some background: dependency to artifact with version range [1.0.1, 2.0), matching versions [1.0.1, 1.0.2, 1.0.3-SNAPSHOT] . problems occurs when 1.0.3-SNAPSHOT tries to load it's released parent pom. if parent of 1.0.3-SNAPSHOT is changed to a snapshot the build succeeds. Some observations: when SNAPSHOT is resolved from local repository it's list of repositories is empty. Also when it's parent is resolved it's list of repositories is empty. org.apache.maven.model.building.DefaultModelBuilder.readParentExternally fails because of that (no repositories) parent is not found from local repository because the key in repo tracking properties is "test-parent-pom-1.0.1.pom>releases" but is searched with key "test-parent-pom-1.0.1.pom>". Stack trace from one point of execution: org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(org.sonatype.aether.RepositorySystemSession, java.util.Collection<? extends org.sonatype.aether.resolution.ArtifactRequest>) line: 237 org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactRequest) line: 214 org.apache.maven.repository.internal.DefaultModelResolver.resolveModel(java.lang.String, java.lang.String, java.lang.String) line: 115 org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(org.apache.maven.model.Model, org.apache.maven.model.building.ModelBuildingRequest, org.apache.maven.model.building.DefaultModelProblemCollector) line: 819 org.apache.maven.model.building.DefaultModelBuilder.readParent(org.apache.maven.model.Model, org.apache.maven.model.building.ModelBuildingRequest, org.apache.maven.model.building.DefaultModelProblemCollector) line: 670 org.apache.maven.model.building.DefaultModelBuilder.build(org.apache.maven.model.building.ModelBuildingRequest, java.util.Collection<java.lang.String>) line: 308 org.apache.maven.model.building.DefaultModelBuilder.build(org.apache.maven.model.building.ModelBuildingRequest) line: 232 org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactDescriptorRequest, org.sonatype.aether.resolution.ArtifactDescriptorResult) line: 308 org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactDescriptorRequest) line: 173 org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.collection.CollectResult, java.util.LinkedList<org.sonatype.aether.impl.internal.GraphEdge>, java.util.List<org.sonatype.aether.graph.Dependency>, java.util.List<org.sonatype.aether.repository.RemoteRepository>, org.sonatype.aether.collection.DependencySelector, org.sonatype.aether.collection.DependencyManager, org.sonatype.aether.collection.DependencyTraverser, org.sonatype.aether.impl.internal.DataPool) line: 419 org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.collection.CollectRequest) line: 233
Hide
Permalink
Sei Syvalta added a comment - - edited
  • org.apache.maven.model.building.DefaultModelBuilder.readParentExternally fails because of that (no repositories)
  • parent is not found from local repository because the key in repo tracking properties is "test-parent-pom-1.0.1.pom>releases" but is searched with key "test-parent-pom-1.0.1.pom>".

The difference to the working direct SNAPSHOT reference (i.e. non-range) is the list of repositories. The local repo lookup fails also in that case, but parent will be found from remote repo.

Show
Sei Syvalta added a comment - - edited org.apache.maven.model.building.DefaultModelBuilder.readParentExternally fails because of that (no repositories) parent is not found from local repository because the key in repo tracking properties is "test-parent-pom-1.0.1.pom>releases" but is searched with key "test-parent-pom-1.0.1.pom>". The difference to the working direct SNAPSHOT reference (i.e. non-range) is the list of repositories. The local repo lookup fails also in that case, but parent will be found from remote repo.
Hide
Permalink
Sei Syvalta added a comment - - edited

Very simple test to reproduce the error. Build module a first and then b. Building b should fail. If not try cleaning local repo and try again.

Show
Sei Syvalta added a comment - - edited Very simple test to reproduce the error. Build module a first and then b. Building b should fail. If not try cleaning local repo and try again.
Hide
Permalink
Sei Syvalta added a comment -

Previous version didn't work with a clean repo. Needed to change the range from [1.0,2.0) to [1.0-SNAPSHOT,2.0).

Show
Sei Syvalta added a comment - Previous version didn't work with a clean repo. Needed to change the range from [1.0,2.0) to [1.0-SNAPSHOT,2.0).
Hide
Permalink
Kristoffer Peterhansel added a comment -

Nice work. Didn't think it would be so easy to reproduce =)

Instead of cleaning the repo you can just use another one. Running Maven on these projects with an option like "-Dmaven.repo.local=..\repo" will do it for me.

Show
Kristoffer Peterhansel added a comment - Nice work. Didn't think it would be so easy to reproduce =) Instead of cleaning the repo you can just use another one. Running Maven on these projects with an option like "-Dmaven.repo.local=..\repo" will do it for me.
Hide
Permalink
Benjamin Bentmann added a comment -

Fixed in r1074131, thanks for the example project.

Show
Benjamin Bentmann added a comment - Fixed in r1074131 , thanks for the example project.

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    Kristoffer Peterhansel
Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: