Maven Remote Resources Plugin
  1. Maven Remote Resources Plugin
  2. MRRESOURCES-53

use of remote resources plugin breaks ability to use test-jar artifacts

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 1.5
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      1

      Description

      I have a dead simple project configuration that breaks if I inherit from org.apache:apache . If I disable the remote resources plugin portion, it works.

      The plugin is trying to resolve a test-jar artifact during the compile phase, but such an artifact does not exist until the test-compile phase.

      To reproduce: unpack the project provided. run 'mvn clean compile'. that will fail. test-compile will work. If you install, then compile will work because it will find the test-jar in the local repo. You must not have any related snapshot artifacts in the local repo related to this project to reproduce.

      If you break the inheritance to the apache parent, it will work. Or, you can override the usage of the remote resources plugin and disable it to get the project to function.

      It seems to work if I assign the plugin to operate in a late phase – such as prepare-package. Perhaps all that is required is that the plugin operate in as late a phase as it can by default?
      If it must operate in compile however, it cannot look for dependencies that are not generated until test-compile such as test-jar types.

        Activity

        Hide
        Scott Carey added a comment -

        Upon further reflection, pushing this to a later phase won't work. Since it is currently designed to create resources prior to the process-resources phase, it cannot attempt to resolve any artifacts generated in the current reactor.

        It could instead be re-designed to execute during prepare-package, but that would essentially be a completely different plugin.

        Fixing one of two things should do it:

        • Do not resolve items that will be built in this reactor, including test-jars.
        • Do not resolve any items in test scope.

        Any suggestions for a viable workaround to the problem are welcome as well.

        Show
        Scott Carey added a comment - Upon further reflection, pushing this to a later phase won't work. Since it is currently designed to create resources prior to the process-resources phase, it cannot attempt to resolve any artifacts generated in the current reactor. It could instead be re-designed to execute during prepare-package, but that would essentially be a completely different plugin. Fixing one of two things should do it: Do not resolve items that will be built in this reactor, including test-jars. Do not resolve any items in test scope. Any suggestions for a viable workaround to the problem are welcome as well.
        Hide
        Scott Carey added a comment -

        Other details:
        I tested with Maven 3.0.1.
        I can reproduce without the apache parent pom if I configure remote-resources in the example parent pom the same way that the apache parent does:

              <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-remote-resources-plugin</artifactId>
                <version>1.1</version>
                <executions>
                  <execution>
                    <goals>
                      <goal>process</goal>
                    </goals>
                    <configuration>
                      <resourceBundles>
                        <resourceBundle>org.apache:apache-jar-resource-bundle:1.4</resourceBundle>
                      </resourceBundles>
                    </configuration>
                  </execution>
                </executions>
              </plugin>
        
        Show
        Scott Carey added a comment - Other details: I tested with Maven 3.0.1. I can reproduce without the apache parent pom if I configure remote-resources in the example parent pom the same way that the apache parent does: <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-remote-resources-plugin </artifactId> <version> 1.1 </version> <executions> <execution> <goals> <goal> process </goal> </goals> <configuration> <resourceBundles> <resourceBundle> org.apache:apache-jar-resource-bundle:1.4 </resourceBundle> </resourceBundles> </configuration> </execution> </executions> </plugin>
        Hide
        Steven Bethard added a comment - - edited

        I wonder if the issue is that test-jar doesn't work right when things are added as <executions>? That seems to be the one common thing between this report, and http://jira.codehaus.org/browse/MEXEC-91.

        Show
        Steven Bethard added a comment - - edited I wonder if the issue is that test-jar doesn't work right when things are added as <executions> ? That seems to be the one common thing between this report, and http://jira.codehaus.org/browse/MEXEC-91 .
        Hide
        Scott Carey added a comment -

        I can confirm that changing the configuration to:

              <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-remote-resources-plugin</artifactId>
                <version>1.1</version>
                <goals>
                  <goal>process</goal>
                </goals>
                <configuration>
                  <resourceBundles>
                    <resourceBundle>org.apache:apache-jar-resource-bundle:1.4</resourceBundle>
                  </resourceBundles>
                </configuration>
              </plugin>
        

        avoids the problem.

        I can override the parent's execution and replace it like so, and this works:

              <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-remote-resources-plugin</artifactId>
                <version>1.1</version>
                <executions>
                  <execution>
                    <phase>none</phase>
                  </execution>
                </executions>
                <goals>
                  <goal>process</goal>
                </goals>
                <configuration>
                  <resourceBundles>
                    <resourceBundle>org.apache:apache-jar-resource-bundle:1.4</resourceBundle>
                  </resourceBundles>
                </configuration>
              </plugin>
        

        That is one tricky bug to work around. I'm lucky I only need one execution. Any idea if it is in the remote resources plugin or somewhere else?

        Show
        Scott Carey added a comment - I can confirm that changing the configuration to: <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-remote-resources-plugin </artifactId> <version> 1.1 </version> <goals> <goal> process </goal> </goals> <configuration> <resourceBundles> <resourceBundle> org.apache:apache-jar-resource-bundle:1.4 </resourceBundle> </resourceBundles> </configuration> </plugin> avoids the problem. I can override the parent's execution and replace it like so, and this works: <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-remote-resources-plugin </artifactId> <version> 1.1 </version> <executions> <execution> <phase> none </phase> </execution> </executions> <goals> <goal> process </goal> </goals> <configuration> <resourceBundles> <resourceBundle> org.apache:apache-jar-resource-bundle:1.4 </resourceBundle> </resourceBundles> </configuration> </plugin> That is one tricky bug to work around. I'm lucky I only need one execution. Any idea if it is in the remote resources plugin or somewhere else?
        Hide
        Steven Bethard added a comment - - edited

        I'm pretty confident it's in the maven-jar-plugin because I can provoke this issue without the remote resources plugin using the maven-exec-plugin or even just the maven-surefire-plugin: http://jira.codehaus.org/browse/MEXEC-91.

        Both of these issues should probably be merged and assigned to the maven-jar-plugin but I don't know how to do that. Hopefully a real maven committer will come by some time soon and do that.

        Show
        Steven Bethard added a comment - - edited I'm pretty confident it's in the maven-jar-plugin because I can provoke this issue without the remote resources plugin using the maven-exec-plugin or even just the maven-surefire-plugin : http://jira.codehaus.org/browse/MEXEC-91 . Both of these issues should probably be merged and assigned to the maven-jar-plugin but I don't know how to do that. Hopefully a real maven committer will come by some time soon and do that.
        Hide
        Benjamin Bentmann added a comment -

        The issue is not in the maven-jar-plugin. The maven-remote-resources-plugin explicitly resolves the test classpath of the project (ProcessRemoteResourcesMojo.java:697) which naturally fails when the test classes haven't even compiled.

        Show
        Benjamin Bentmann added a comment - The issue is not in the maven-jar-plugin . The maven-remote-resources-plugin explicitly resolves the test classpath of the project ( ProcessRemoteResourcesMojo.java:697 ) which naturally fails when the test classes haven't even compiled.
        Hide
        Robert Scholte added a comment -

        Is this still a problem with maven-reomote-resources-1.2.1?
        I tried the project with Maven 3 and had no problem to run mvn clean compile, so is this example-project still valid to reproduce the issue?

        Show
        Robert Scholte added a comment - Is this still a problem with maven-reomote-resources-1.2.1? I tried the project with Maven 3 and had no problem to run mvn clean compile , so is this example-project still valid to reproduce the issue?
        Hide
        Scott Carey added a comment -

        In the base pom.xml:

        <!-- if this override is set, the project builds, if it is
        commented out, it fails. -->
        <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-remote-resources-plugin</artifactId>
        <version>1.1</version>
        <executions>
        <execution>
        <phase>none</phase>
        <goals>
        <goal>process</goal>
        </goals>
        </execution>
        </executions>
        </plugin>

        It works 'out of the box' because that section is not commented out. I just tested it and it works in maven 3.0.1, 3.0.2, and 3.0.3.

        It does NOT work if you comment out that version override and inherit it all from the parent. It breaks with maven 3.0.1, 3.0.2, and 3.0.3.

        There is still a bug, though I have not tried updating all the version references to the latest.

        'mvn versions:display-plugin-updates' prints out:
        [INFO] The following plugin updates are available:
        [INFO] maven-jar-plugin ..................................... 2.3.1 -> 2.3.2
        [INFO] maven-remote-resources-plugin .......................... 1.1 -> 1.2.1
        [INFO] maven-resources-plugin ................................. 2.4.3 -> 2.5

        and the apache parent has been revved from version 8 to 10.

        Show
        Scott Carey added a comment - In the base pom.xml: <!-- if this override is set, the project builds, if it is commented out, it fails. --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-remote-resources-plugin</artifactId> <version>1.1</version> <executions> <execution> <phase>none</phase> <goals> <goal>process</goal> </goals> </execution> </executions> </plugin> It works 'out of the box' because that section is not commented out. I just tested it and it works in maven 3.0.1, 3.0.2, and 3.0.3. It does NOT work if you comment out that version override and inherit it all from the parent. It breaks with maven 3.0.1, 3.0.2, and 3.0.3. There is still a bug, though I have not tried updating all the version references to the latest. 'mvn versions:display-plugin-updates' prints out: [INFO] The following plugin updates are available: [INFO] maven-jar-plugin ..................................... 2.3.1 -> 2.3.2 [INFO] maven-remote-resources-plugin .......................... 1.1 -> 1.2.1 [INFO] maven-resources-plugin ................................. 2.4.3 -> 2.5 and the apache parent has been revved from version 8 to 10.
        Hide
        Scott Carey added a comment -

        I can confirm that it still fails if updated to use version 10 of the apache parent.

        It fails if maven-jar-plugin is updated to 2.3.2

        It fails if maven-resources-plugin is updated to 2.5

        It fails if the maven-remote-resources-plugin is version 1.1, with the execution override (to none) missing so that it executes.

        It fails if using maven-remote-resources-plugin 1.2.1

        It succeeds if the maven-remote-resources-plugin is explicitly disabled (execution -> none).
        I have not re-validated that moving the resource bundle configuration from inside the execution to plugin global scope fixes it (my comments from Jan 26 and 30 2011)

        Show
        Scott Carey added a comment - I can confirm that it still fails if updated to use version 10 of the apache parent. It fails if maven-jar-plugin is updated to 2.3.2 It fails if maven-resources-plugin is updated to 2.5 It fails if the maven-remote-resources-plugin is version 1.1, with the execution override (to none) missing so that it executes. It fails if using maven-remote-resources-plugin 1.2.1 It succeeds if the maven-remote-resources-plugin is explicitly disabled (execution -> none). I have not re-validated that moving the resource bundle configuration from inside the execution to plugin global scope fixes it (my comments from Jan 26 and 30 2011)
        Hide
        Robert Scholte added a comment -
        [INFO] --- maven-remote-resources-plugin:1.2.1:process (default) @ avro-ipc ---
        Downloading: http://repository.apache.org/snapshots/org/apache/avro/avro/1.5.0-SNAPSHOT/avro-1.5.0-SNAPSHOT-tests.jar
        

        Of cource this won't work.

        But what are you trying to do? My guess is you're using the maven-remote-resource-plugin for the wrong reason.

        Show
        Robert Scholte added a comment - [INFO] --- maven-remote-resources-plugin:1.2.1:process (default) @ avro-ipc --- Downloading: http://repository.apache.org/snapshots/org/apache/avro/avro/1.5.0-SNAPSHOT/avro-1.5.0-SNAPSHOT-tests.jar Of cource this won't work. But what are you trying to do? My guess is you're using the maven-remote-resource-plugin for the wrong reason.
        Hide
        Scott Carey added a comment -

        The maven-remote-resources-plugin is pulling test artifacts from 'mvn clean compile'. I don't know why.

        But what are you trying to do?

        The same thing you are trying to do.
        Use the Apache parent project at the top level parent. This adds license info to make an Apache compliant release jar.
        http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-remote-resources-plugin/1.2.1/maven-remote-resources-plugin-1.2.1.pom
        parent ->
        http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/19/maven-plugins-19.pom
        parent ->
        http://repo1.maven.org/maven2/org/apache/maven/maven-parent/19/maven-parent-19.pom
        parent ->
        http://repo1.maven.org/maven2/org/apache/apache/9/apache-9.pom

        apache's parent pom uses the maven-remote-resources-plugin. This breaks any build that uses test-jar artifacts.
        I don't know enough to point blame at the plugin or the parent pom.

        This is the common bit to Apache Avro, and Apache Maven via Apache's parent that breaks projects that use test-jar artifacts and try to 'mvn clean compile':

        <!-- We want to package up license resources in the JARs produced -->
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-remote-resources-plugin</artifactId>
          <executions>
            <execution>
              <goals>
                <goal>process</goal>
              </goals>
              <configuration>
                <resourceBundles>
                  <resourceBundle>org.apache:apache-jar-resource-bundle:1.4</resourceBundle>
                </resourceBundles>
              </configuration>
            </execution>
          </executions>
        </plugin>

        As noted before, if this is changed to set the configuration at the plugin level rather than inside executions, it works fine. That is what makes me feel like this is a bug in the plugin or how maven works in general. I am not sure what the expected difference in behavior is expected to be other than how it works with command-line usage.

        Show
        Scott Carey added a comment - The maven-remote-resources-plugin is pulling test artifacts from 'mvn clean compile'. I don't know why. But what are you trying to do? The same thing you are trying to do. Use the Apache parent project at the top level parent. This adds license info to make an Apache compliant release jar. http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-remote-resources-plugin/1.2.1/maven-remote-resources-plugin-1.2.1.pom parent -> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/19/maven-plugins-19.pom parent -> http://repo1.maven.org/maven2/org/apache/maven/maven-parent/19/maven-parent-19.pom parent -> http://repo1.maven.org/maven2/org/apache/apache/9/apache-9.pom apache's parent pom uses the maven-remote-resources-plugin. This breaks any build that uses test-jar artifacts. I don't know enough to point blame at the plugin or the parent pom. This is the common bit to Apache Avro, and Apache Maven via Apache's parent that breaks projects that use test-jar artifacts and try to 'mvn clean compile': <!-- We want to package up license resources in the JARs produced --> <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-remote-resources-plugin </artifactId> <executions> <execution> <goals> <goal> process </goal> </goals> <configuration> <resourceBundles> <resourceBundle> org.apache:apache-jar-resource-bundle:1.4 </resourceBundle> </resourceBundles> </configuration> </execution> </executions> </plugin> As noted before, if this is changed to set the configuration at the plugin level rather than inside executions, it works fine. That is what makes me feel like this is a bug in the plugin or how maven works in general. I am not sure what the expected difference in behavior is expected to be other than how it works with command-line usage.
        Hide
        Scott Carey added a comment -

        My question is why does the configuration above try and download the test-jar artifact? The configuration is to download org.apache:apache-jar-resource-bundle:1.4, not the project's test-jar artifact.

        Has the comment from last february by Benjamin Bentmann been addressed?

        The issue is not in the maven-jar-plugin. The maven-remote-resources-plugin explicitly resolves the test classpath of the project (ProcessRemoteResourcesMojo.java:697) which naturally fails when the test classes haven't even compiled.

        Show
        Scott Carey added a comment - My question is why does the configuration above try and download the test-jar artifact? The configuration is to download org.apache:apache-jar-resource-bundle:1.4, not the project's test-jar artifact. Has the comment from last february by Benjamin Bentmann been addressed? The issue is not in the maven-jar-plugin. The maven-remote-resources-plugin explicitly resolves the test classpath of the project (ProcessRemoteResourcesMojo.java:697) which naturally fails when the test classes haven't even compiled.
        Hide
        Daniel Kulp added a comment -


        Added a new configuration option to allow specifying the scopes used for resolving dependencies. Also, made the default "runtime" instead of "test" in most cases.

        Show
        Daniel Kulp added a comment - Added a new configuration option to allow specifying the scopes used for resolving dependencies. Also, made the default "runtime" instead of "test" in most cases.

          People

          • Assignee:
            Daniel Kulp
            Reporter:
            Scott Carey
          • Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: