maven-shade-plugin does not resolve from user-defined repositories

Original issue: https://issues.jboss.org/browse/RF-11052

In one of our company's projects, shade tries to resolve using the repositories defined in the module's parent:

<repositories>
    <repository>
        <id>download.osgeo.org</id>
        <url>http://download.osgeo.org/webdav/geotools</url>
    </repository>
    <repository>
        <id>JBOSS</id>
        <name>JBoss Repository</name>
        <url>http://repository.jboss.org/nexus/content/groups/public/</url>
    </repository>
</repositories>

(Yep, the JBoss one is out of date.) It doesn't consult settings.xml, though. Also, the parent POM it's trying to find is already in ~/.m2/repository. Our workaround is to put our company repository in that section, which makes sense anyway. Running it once with the workaround caused the parent POM to be downloaded AGAIN. Subsequent times, the POM was NOT redownloaded. Also, if you have a repository manager like Nexus configured on your machine as a mirror for *, this avoids the problem. Oddly enough, the problem didn't happen on Jenkins even though neither of these workarounds was present.

Actually, now that I think about it, is this by design? This is producing an artifact, the dependency-reduced POM, and its contents should be predictable, not dependent on what a particular developer has in her settings.xml...

I've got the same behaviour but in another context.

A project with parent pom (in SNAPSHOT) deployed in artifactory.
Project build works fine from Maven (3.0.3) command line or via Jenkins (1.451) in a FreeStyle job but it fail with same error when building project in Jenkins as a Maven job.

If I put back artifactory repos location in pom.xml (which is weird), everything goes fine.

Tried with shade 1.3.2 and 1.5.0

Anyone encountered the problem ?

PS: JIRA opened in Jenkins : https://issues.jenkins-ci.org/browse/JENKINS-12843

I also got bitten again by this issue this morning and it took us a long time to find the reason...

To reproduce: https://github.com/xwiki/xwiki-rendering/tree/master/xwiki-rendering-standalone

It is very unlikely that this is specific to shade. It does not have repository-sensitive code, it just calls the core of Maven to do its work.

This doesn't seem to occur with Maven 3.0.4. Could it be due to MNG-5149 or MNG-5224?

Sorry, I'm still seeing this with 3.0.4.

I have a case where the "remote" repository is a local directory and the local repository is configured to keep the build isolated.

In MSHADE-103.tar.gz, with settings.xml configured with local paths:

mvn3 --settings settings.xml clean package

fails to find the parent pom even though it's already in the configured local repository.

The dependency is an arbitrary choice of jar. If it's removed then the shading succeeds. Shading also succeeds when createDependencyReducedPom is set to false.

If, after a failed build, I remove the _maven.repositories file from the local repository then the build succeeds. The call to mavenProjectBuilder.build only knows about the local repository but the artifact is specifically tagged as coming from the alternate remote repo.

Looks like MNG-5185 would make this clearer.

Maven 3's ProjectBuilder API makes it possible to pass in the remote repositories: the attached patch works with Maven 3. Of course, this breaks compatibility with Maven 2. The difficulty, and value, of maintaining a dual Maven 2/Maven 3 plugin is a topic for discussion.

I guess we'll need a branch.

Thank you for the patch.

------------------------------------------------------------------------
r1354665 | bimargulies | 2012-06-27 14:51:17 -0400 (Wed, 27 Jun 2012) | 3 lines

MSHADE-103: maven-shade-plugin does not resolve from user-defined repositories
o note: trunk now requires Maven 3.0.

------------------------------------------------------------------------