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 -

        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: