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

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.

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.

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?

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.

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.

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?

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.

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)

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

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.

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.