Uploaded image for project: 'Maven Dependency Plugin'
  1. Maven Dependency Plugin
  2. MDEP-82

go-offline / resolve-plugins does not resolve all plugin dependencies

    Details

    • Type: Bug
    • Status: Reopened
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0-alpha-4
    • Fix Version/s: None
    • Component/s: go-offline, resolve-plugins
    • Labels:
      None
    • Environment:
      Maven 2.0.6

      Description

      The attached pom.xml is a very simple JAR project, without any direct dependencies or plugin dependencies.

      Start with an empty local repository, and run mvn dependency:go-offline on it. Some files get downloaded, but not everything that is needed for the build. If you run "mvn -o package" afterwards, you end up with the following error:

      [ERROR] BUILD ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found

      Afterwards, even "mvn package" without the "-o" parameter does not work any longer.

      1. maven-dependency-plugin-2.3.patch
        5 kB
        Paul Warren
      2. pom.xml
        0.4 kB
        Arne Degenring

        Issue Links

          Activity

          Hide
          brianf@infinity.nu Brian E. Fox (imported) added a comment -

          The problem is that the project isn't injected with the plugins from the standard lifecycle. I may have to hard code the standard ones (site,clean,default) until I can figure out how to get at the list directly.

          Show
          brianf@infinity.nu Brian E. Fox (imported) added a comment - The problem is that the project isn't injected with the plugins from the standard lifecycle. I may have to hard code the standard ones (site,clean,default) until I can figure out how to get at the list directly.
          Hide
          shinsato Harold Shinsato added a comment -

          Being able to go offline so all needed dependencies (including plugin dependencies) will work is something we have a requirement to do for our builds or it will be hard for us to get to use maven. Is there a workaround for this issue that would not require writing custom code?

          Show
          shinsato Harold Shinsato added a comment - Being able to go offline so all needed dependencies (including plugin dependencies) will work is something we have a requirement to do for our builds or it will be hard for us to get to use maven. Is there a workaround for this issue that would not require writing custom code?
          Hide
          lewisd Derek Lewis added a comment -

          This issue has been open with no comment for a long time. Is there really no fix or workaround with the problem? I'm required to package a zip of the ~/.m2/repository directory with our software, including all dependencies needed to build from behind a strict corporate firewall. This bug is causing a great deal of grief for me. Is this fixed in maven 3?

          Show
          lewisd Derek Lewis added a comment - This issue has been open with no comment for a long time. Is there really no fix or workaround with the problem? I'm required to package a zip of the ~/.m2/repository directory with our software, including all dependencies needed to build from behind a strict corporate firewall. This bug is causing a great deal of grief for me. Is this fixed in maven 3?
          Hide
          devman07 Devin Reid added a comment -

          A workaround I have found for this issue is to run a build with the property 'maven.repo.local' set to a directory in the project base directory and run a build to the install phase. One can then archive the resulting project and move it to environments that have no network access and be able to build successfully with the '-o' option.

          I've tested this successfully with Maven 2.2.1 and Maven 3.0.3.

          First run:
          mvn -Dmaven.repo.local=lib clean install

          Now the following command will work just fine.
          mvn -Dmaven.repo.local=lib -o clean install

          Show
          devman07 Devin Reid added a comment - A workaround I have found for this issue is to run a build with the property 'maven.repo.local' set to a directory in the project base directory and run a build to the install phase. One can then archive the resulting project and move it to environments that have no network access and be able to build successfully with the '-o' option. I've tested this successfully with Maven 2.2.1 and Maven 3.0.3. First run: mvn -Dmaven.repo.local=lib clean install Now the following command will work just fine. mvn -Dmaven.repo.local=lib -o clean install
          Hide
          lewisd Derek Lewis added a comment -

          Devin, I've used a similar situation to work around the problem. However, it means having to build everything, which is time consuming, and also means that commands you haven't run (like mvn deploy) won't work, because the deploy plugin wasn't downloaded.

          Show
          lewisd Derek Lewis added a comment - Devin, I've used a similar situation to work around the problem. However, it means having to build everything, which is time consuming, and also means that commands you haven't run (like mvn deploy) won't work, because the deploy plugin wasn't downloaded.
          Hide
          paulcwarren Paul Warren added a comment -

          Hi Folks,

          Ability (or inability) to go-offline is a showstopper for us. We have very large customers who state they have to have offline development.

          So naturally this was the goal I looked at first. One problem I have with it is the fact that it resolves top level dependencies only. It doesnt recursively descend through all subsequent transtive dependencies. I am new to maven but as that stands I don't see how it is adequate to actually solve the problem. But maybe I missed some fundamental concept. Anyway, I had a fiddle with the code and made is descend and resolve all transaitive dependencies and this was sufficient for my use case. I was then able to go-offline. I am going to attach the patch in case it helps others or you would like to fold it into the source.

          Show
          paulcwarren Paul Warren added a comment - Hi Folks, Ability (or inability) to go-offline is a showstopper for us. We have very large customers who state they have to have offline development. So naturally this was the goal I looked at first. One problem I have with it is the fact that it resolves top level dependencies only. It doesnt recursively descend through all subsequent transtive dependencies. I am new to maven but as that stands I don't see how it is adequate to actually solve the problem. But maybe I missed some fundamental concept. Anyway, I had a fiddle with the code and made is descend and resolve all transaitive dependencies and this was sufficient for my use case. I was then able to go-offline. I am going to attach the patch in case it helps others or you would like to fold it into the source.
          Hide
          paulcwarren Paul Warren added a comment -

          The recursive descent patch as promised.

          Show
          paulcwarren Paul Warren added a comment - The recursive descent patch as promised.
          Hide
          cinquero Mark added a comment -

          This issue is even more annoying for proper two-phase deployments where packages are built on bare build systems without network access and where testing is done after the build on the target platform: it absolutely makes no sense to execute the tests just to prepare the package sources, but the tests won't have all dependencies later on when I don't execute the tests...

          Try:

          git clone https://github.com/cometd/cometd.git
          cd cometd
          git checkout 2.4.0
          mvn -Dmaven.repo.local=/tmp/maven-repo dependency:go-offline
          mvn -Dmaven.repo.local=/tmp/maven-repo -o install

          Show
          cinquero Mark added a comment - This issue is even more annoying for proper two-phase deployments where packages are built on bare build systems without network access and where testing is done after the build on the target platform: it absolutely makes no sense to execute the tests just to prepare the package sources, but the tests won't have all dependencies later on when I don't execute the tests... Try: git clone https://github.com/cometd/cometd.git cd cometd git checkout 2.4.0 mvn -Dmaven.repo.local=/tmp/maven-repo dependency:go-offline mvn -Dmaven.repo.local=/tmp/maven-repo -o install
          Hide
          michael-o Michael Osipov added a comment -

          This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still persists, retest your problem with the most recent version of Maven and the affected component, reopen and post your results.

          Show
          michael-o Michael Osipov added a comment - This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still persists, retest your problem with the most recent version of Maven and the affected component, reopen and post your results.
          Hide
          danielcompton Daniel Compton added a comment -

          This is still an issue. Running mvn dependency:resolve-plugins as a second step works, but shouldn't be needed.

          Show
          danielcompton Daniel Compton added a comment - This is still an issue. Running mvn dependency:resolve-plugins as a second step works, but shouldn't be needed.
          Hide
          hboutemy Hervé Boutemy added a comment -

          it looks like the first coment from Brian was not understood: "The problem is that the project isn't injected with the plugins from the standard lifecycle. I may have to hard code the standard ones (site,clean,default) until I can figure out how to get at the list directly."
          I'll try to explain more in details.

          But the plugin does not have the logic to detect these defaults (that are dependant on Maven version used)
          I don't know if adding these defaults is feasible, or will give expected reault

          one workaround, that is in fact a best-practice: please define plugins versions in your pom (or parent), even for default plugins that get "magically" injected by core if you did not tell anything
          Your build will be more repeatable (you won't be hit if Maven core changes versions), and go-offline will do the expected job

          Show
          hboutemy Hervé Boutemy added a comment - it looks like the first coment from Brian was not understood: "The problem is that the project isn't injected with the plugins from the standard lifecycle. I may have to hard code the standard ones (site,clean,default) until I can figure out how to get at the list directly." I'll try to explain more in details. go-offline downloads everything that is declared in dependencies or plugins: if you did not declare anything, there is nothing to download but if you didn't declare anything, what is run when you launch a build? default plugins from standard lifecycle: http://maven.apache.org/ref/current/maven-core/default-bindings.html But the plugin does not have the logic to detect these defaults (that are dependant on Maven version used) I don't know if adding these defaults is feasible, or will give expected reault one workaround, that is in fact a best-practice: please define plugins versions in your pom (or parent), even for default plugins that get "magically" injected by core if you did not tell anything Your build will be more repeatable (you won't be hit if Maven core changes versions), and go-offline will do the expected job
          Hide
          hboutemy Hervé Boutemy added a comment -

          I just tested the pom.xml proposed as test case:

          • with Maven 3.0.5+ and maven-depdendency-plugin 2.8, plugins from standard lifecycle are downloaded
          • with Maven 2.2.1, plugins from standard lifecycle are not downloaded

          IIUC, Maven 3.x fixes the issue, by better detecting effective plugins (ie declared plugins + plugins from standard lifecycle)
          Of course, if go-offline is called with one Maven version and the build is done later with another Maven version that has other plugins versions in standard lifecycle, there will be an issue: that's where defining explicitely plugins version in your pom.xml (or parent) is a best practice to avoid relying on Maven defaults then being dependant on precise Maven version used

          If nobody objects, I'll close this issue as fixed in 3 days

          Show
          hboutemy Hervé Boutemy added a comment - I just tested the pom.xml proposed as test case: with Maven 3.0.5+ and maven-depdendency-plugin 2.8, plugins from standard lifecycle are downloaded with Maven 2.2.1, plugins from standard lifecycle are not downloaded IIUC, Maven 3.x fixes the issue, by better detecting effective plugins (ie declared plugins + plugins from standard lifecycle) Of course, if go-offline is called with one Maven version and the build is done later with another Maven version that has other plugins versions in standard lifecycle, there will be an issue: that's where defining explicitely plugins version in your pom.xml (or parent) is a best practice to avoid relying on Maven defaults then being dependant on precise Maven version used If nobody objects, I'll close this issue as fixed in 3 days

            People

            • Assignee:
              Unassigned
              Reporter:
              arned Arne Degenring
            • Votes:
              12 Vote for this issue
              Watchers:
              21 Start watching this issue

              Dates

              • Created:
                Updated:

                Development