Maven Shade Plugin
  1. Maven Shade Plugin
  2. MSHADE-103

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

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.3, 1.4
    • Fix Version/s: 2.0
    • Labels:
      None
    • Environment:
      Maven 3.0.3 (works with 2.2.1)
    • Number of attachments :
      2

      Description

      maven-shade-plugin doesn't consult repositories defined in
      settings.xml when trying to resolve parents of given pom. It contacts
      only central repo:

      [ERROR] Failed to execute goal
      org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on
      project richfaces-components-api: Error creating shaded jar: 1 problem
      was encountered while building the effective model for
      org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT
      [ERROR] [FATAL] Non-resolvable parent POM for
      org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact
      org.richfaces:richfaces-parent:pom:10 in central
      (http://repo1.maven.org/maven2) and 'parent.relativePath' points at
      wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT,
      /home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10
      [ERROR] for project
      org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
      /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
      for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at
      /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
      [ERROR] -> [Help 1]

      There is affected project (it references version 1.3.3, but the behavior is same with 1.4) if you would like to try at own:

      https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml

        Activity

        Hide
        Lukas Fryc added a comment -
        Show
        Lukas Fryc added a comment - Original issue: https://issues.jboss.org/browse/RF-11052
        Hide
        Dustin Parker added a comment -

        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...

        Show
        Dustin Parker added a comment - 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...
        Hide
        Henri Gomez added a comment - - edited

        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

        Show
        Henri Gomez added a comment - - edited 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
        Hide
        Vincent Massol added a comment - - edited

        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

        Show
        Vincent Massol added a comment - - edited 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
        Hide
        Benson Margulies added a comment -

        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.

        Show
        Benson Margulies added a comment - 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.
        Hide
        Joseph Walton added a comment - - edited

        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.

        Show
        Joseph Walton added a comment - - edited 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.
        Hide
        Joseph Walton added a comment - - edited

        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.

        Show
        Joseph Walton added a comment - - edited 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.
        Joseph Walton made changes -
        Field Original Value New Value
        Attachment MSHADE-103.tar.gz [ 60121 ]
        Hide
        Joseph Walton added a comment - - edited

        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.

        Show
        Joseph Walton added a comment - - edited 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.
        Hide
        Joseph Walton added a comment -

        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.

        Show
        Joseph Walton added a comment - 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.
        Joseph Walton made changes -
        Hide
        Benson Margulies added a comment -

        I guess we'll need a branch.

        Show
        Benson Margulies added a comment - I guess we'll need a branch.
        Benson Margulies made changes -
        Assignee Benson Margulies [ bmargulies ]
        Hide
        Benson Margulies added a comment -

        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.

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

        Show
        Benson Margulies added a comment - 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. ------------------------------------------------------------------------
        Benson Margulies made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Fix Version/s 2.0 [ 18623 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Benson Margulies
            Reporter:
            Lukas Fryc
          • Votes:
            19 Vote for this issue
            Watchers:
            18 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: