Maven 2 & 3

DefaultArtifactResolver has problems when used with multiple repos

Details

  • Complexity:
    Intermediate
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

DefaultArtifactResolver attaches the repositories to artifacts (AFAIK) to optimize the repo look ups.

Here I have a case

1) An artifact dependens on org.eclipse.equniox:app:1.2.0
2) org.eclipse.equinox:app depends on org.eclipse.equinox:registry:[3.4.0,4.0.0)
3) Both central repo and custom corporate repo has org.eclipse.equinox:registry
4) central repo has outdated versions
3.2.1-R32x_v20060814
3.3.0-v20070522
5) DefaultArtifactResolver for optimization attaches central repo (last one wins)
6) Central repo neither satisfies the version range nor - even if it did - has the latest version
7) dependency is not satisfied
8) Build halts

Attached patch is a dirty hack to disable signle repo downloand and checks all the repositories.

Issue Links

This issue relates to:
MNG-3560 unable to use plugins that exist in multiple repositories Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Nicolas Dumoulin added a comment -

I can confirm this annoying bug. For instance, our fix is to use our proxy as a mirro of the central repo.

Show
Nicolas Dumoulin added a comment - I can confirm this annoying bug. For instance, our fix is to use our proxy as a mirro of the central repo.
Hide
Permalink
Hasan Ceylan added a comment - - edited

it's a bloker...
patch is provided

it's over 3 months and even not assigned yet....

Should we not bother to contribute to maven?

Show
Hasan Ceylan added a comment - - edited it's a bloker... patch is provided it's over 3 months and even not assigned yet.... Should we not bother to contribute to maven?
Hide
Permalink
Brett Porter added a comment -

we can take a look for 2.2.x, but a patch that is classified as a "dirty hack" with no tests in critical functionality is not something we can just apply. If you put together an integration test and more information about the changes required it can be adopted much faster. Thanks!

We don't assign things as they come in, they get reviewed as people with time look over them, and our priorities tend to be on regressions and bugs with large numbers of votes.

Show
Brett Porter added a comment - we can take a look for 2.2.x, but a patch that is classified as a "dirty hack" with no tests in critical functionality is not something we can just apply. If you put together an integration test and more information about the changes required it can be adopted much faster. Thanks! We don't assign things as they come in, they get reviewed as people with time look over them, and our priorities tend to be on regressions and bugs with large numbers of votes.
Hide
Permalink
Hasan Ceylan added a comment -

Hello Brett,

Two things:
1) Responding with a feed back
2) Closing the issue...

These two things obviously totally different.

If I had got this feedback three months ago, - while I still remember all the insights - I would have solved it totally by then.

So, not that the fact that it's not been solved, but no feedback has been provided for so long, that is I'm not happy with.

Regards,
Hasan Ceylan

Show
Hasan Ceylan added a comment - Hello Brett, Two things: 1) Responding with a feed back 2) Closing the issue... These two things obviously totally different. If I had got this feedback three months ago, - while I still remember all the insights - I would have solved it totally by then. So, not that the fact that it's not been solved, but no feedback has been provided for so long, that is I'm not happy with. Regards, Hasan Ceylan
Hide
Permalink
Jean-Noel Rouvignac added a comment -

This problem look very similar to MNG-3560 .

Show
Jean-Noel Rouvignac added a comment - This problem look very similar to MNG-3560 .
Hide
Permalink
Dennis Homann added a comment -

I just stumbled upon a problem which sounds related:

  • an artifact was resolved from a remote mirror and placed in the local repository, along with a file _maven.repositories which points to the ID of mirror where the artifact was resolved from
  • when I disconnect from the network, Maven will try to resolve the artifact from remote repositories although it is present locally, and the build will fail
  • when I disconnect from the network AND run with -o, Maven will fail with "The repository system is offline but the artifact ... is not available in the local repository."
  • when I delete the _maven.repositories file for the artifact in question, it will get resolved locally and the build will fail for the next dependency as described above
Show
Dennis Homann added a comment - I just stumbled upon a problem which sounds related:
  • an artifact was resolved from a remote mirror and placed in the local repository, along with a file _maven.repositories which points to the ID of mirror where the artifact was resolved from
  • when I disconnect from the network, Maven will try to resolve the artifact from remote repositories although it is present locally, and the build will fail
  • when I disconnect from the network AND run with -o, Maven will fail with "The repository system is offline but the artifact ... is not available in the local repository."
  • when I delete the _maven.repositories file for the artifact in question, it will get resolved locally and the build will fail for the next dependency as described above

People

Vote (6)
Watch (5)

Dates

  • Created:
    Updated:
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.