Maven 2.x and 3.x Site Plugin

Maven searches only central repository for imported dependencies

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 3.0
  • Fix Version/s: None
  • Component/s: Maven 3
  • Labels:
    None
  • Environment:
    Windows 7
  • Number of attachments :
    1

Description

We are using dependencyManagement with "import" scope like described here:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies

Problem occurs only at site generation, not at build time, where it works perfectly.

The site plugin tries to find the imported artifacts, but searches only the central repository and ignores the repositories in settings.xml configuration. Mirror settings work, if "central" is mirrored, but dependencies need to be resolved from two repositories, so one mirror does not help here.

I try to attach the relevant parts of the stacktrace.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Richard Eggert added a comment -

This problem also manifests itself for parent poms that don't exist in the build tree (i.e., not accessible via the relativePath) or in central (deployed to a repository other than central), as well as for build extensions that do not reside in central. It seems as if the maven-site-plugin ignores all repositories except central when resolving these.

Show
Richard Eggert added a comment - This problem also manifests itself for parent poms that don't exist in the build tree (i.e., not accessible via the relativePath) or in central (deployed to a repository other than central), as well as for build extensions that do not reside in central. It seems as if the maven-site-plugin ignores all repositories except central when resolving these.
Hide
Permalink
Richard Eggert added a comment -

I'll try to put together an example that I can attach here when I find some time, but here's how to reproduce the problem for the parent POM use case:

In your active profile in settings.xml, configure a remote repository that points to a location in your local file system. Make sure that the central repository is independently reachable (either directly or via a configured mirror).

Create a new Maven project with packaging type "pom". Configure the distributionManagement section such that "mvn deploy" will target the "remote" repository on your file system that you configured in settings.xml. Run "mvn deploy" on this project, then delete your local repository (but not the "remote" one that you deployed to).

Create a second Maven project with packaging type "pom". Use the first project configured above as the "parent" POM, but set the relativePath element to be empty (forcing it to be resolved via repository). In the "modules" section of the POM, specify a sub-module.

Within the second Maven project, create the sub-module project that you specified in the POM, using the containing project's POM as the parent (set relativePath to "..").

From within the second Maven project (the container of the sub-module), run "mvn package". This should work perfectly. Then run "mvn site". This will fail, being unable to resolve the dependency to the parent POM (the first project that you deployed) against the central repository (apparently ignoring the "remote" repository on the local filesystem, as well as the fact that the parent POM was already downloaded into the local repository during "mvn package").

Something similar will happen if you specify a build extension in the sub-module POM.

Show
Richard Eggert added a comment - I'll try to put together an example that I can attach here when I find some time, but here's how to reproduce the problem for the parent POM use case: In your active profile in settings.xml, configure a remote repository that points to a location in your local file system. Make sure that the central repository is independently reachable (either directly or via a configured mirror). Create a new Maven project with packaging type "pom". Configure the distributionManagement section such that "mvn deploy" will target the "remote" repository on your file system that you configured in settings.xml. Run "mvn deploy" on this project, then delete your local repository (but not the "remote" one that you deployed to). Create a second Maven project with packaging type "pom". Use the first project configured above as the "parent" POM, but set the relativePath element to be empty (forcing it to be resolved via repository). In the "modules" section of the POM, specify a sub-module. Within the second Maven project, create the sub-module project that you specified in the POM, using the containing project's POM as the parent (set relativePath to ".."). From within the second Maven project (the container of the sub-module), run "mvn package". This should work perfectly. Then run "mvn site". This will fail, being unable to resolve the dependency to the parent POM (the first project that you deployed) against the central repository (apparently ignoring the "remote" repository on the local filesystem, as well as the fact that the parent POM was already downloaded into the local repository during "mvn package"). Something similar will happen if you specify a build extension in the sub-module POM.
Hide
Permalink
Edward Winston added a comment -

We recently ran into this problem as well. It was confusing because it was working on my local machine and not on the server. As a work around, it appears that if the parent pom in question is installed in your local repository instead of retrieved from a remote repository things will work. This means that in you $

{HOME}

/.m2/repository directory find the artifact in question. Then change the file _maven.repositories to not have the location from where the pom was downloaded. In our case the file went from this :

parent-pom-1.pom>central=

to this :

parent-pom-1.pom>=

After this change it all worked.

Show
Edward Winston added a comment - We recently ran into this problem as well. It was confusing because it was working on my local machine and not on the server. As a work around, it appears that if the parent pom in question is installed in your local repository instead of retrieved from a remote repository things will work. This means that in you $ {HOME} /.m2/repository directory find the artifact in question. Then change the file _maven.repositories to not have the location from where the pom was downloaded. In our case the file went from this : parent-pom-1.pom>central= to this : parent-pom-1.pom>= After this change it all worked.
Hide
Permalink
Shawn Brown added a comment -

It sounds like the following issue is related: http://jira.codehaus.org/browse/MSITE-663

I spent some time stepping through the site plugin code while troubleshooting that issue, and the root cause seemed to be that the site plugin wasn't giving Maven the full list of repositories to search.

Show
Shawn Brown added a comment - It sounds like the following issue is related: http://jira.codehaus.org/browse/MSITE-663 I spent some time stepping through the site plugin code while troubleshooting that issue, and the root cause seemed to be that the site plugin wasn't giving Maven the full list of repositories to search.

People

  • Assignee:
    Unassigned
    Reporter:
    Markus Tippmann
Vote (7)
Watch (10)

Dates

  • Created:
    Updated: