CODEWITHSUNDEEP
mavenportability
gturri
gturri

Reputation: 14599

Is maven-download-plugin not portable, or am I crazy?

TL;DR: I stumbled upon a situation where my pom.xml works fine on Windows, but fails on Linux. Since I'm rather new to maven, I'm not sure whether it's a common situation, or if I messed up somewhere.

More details:

I use the maven-download-plugin like this:

  <plugin>
    <groupId>com.googlecode.maven-download-plugin</groupId>
    <artifactId>maven-download-plugin</artifactId>
    <version>1.1.0</version>
    <executions>
      <execution>
        <id>get-stuff</id>
        <phase>generate-sources</phase>
        <goals>
          <goal>wget</goal>
        </goals>
        <configuration>
          <url>http://myUrl/my.tar.gz</url>
          <unpack>true</unpack>
          <outputDirectory>${project.build.directory}</outputDirectory>
        </configuration>
      </execution>
    </executions>
  </plugin>
 <plugin>

On Windows it works like a charm (ie: it downloads and unpack). On Linux, it fails with the following error:

[ERROR] Failed to execute goal com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget (get-moab) 
  on project my-project: Execution get-stuff of goal com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget failed:
  An API incompatibility was encountered while executing com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget: java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.Commandline.createArg()Lorg/codehaus/plexus/util/cli/Arg;

I found a workaround (<unpack>false</unpack>, and then "manually" unpack with antrun), but my pom.xml looked better without those additional 15 lines...

To put it in a nutshell:

More technical details:

Upvotes: 1

Views: 552

Answers (2)

Harald Wellmann
Harald Wellmann

Reputation: 12865

Did you check the Maven versions (mvn -version)? org.codehaus.plexus.util is a dependency of Maven Core, so if maven-download-plugin is running under a different version of Maven it was compiled for, this would explain the error.

Upvotes: 1

user944849
user944849

Reputation: 14951

My first troubleshooting step when a build works on one machine and not another is to clean out the local Maven repository on the failing machine, and let Maven re-download all of the artifacts. That's often enough to fix the problem.

If the build fails with the same error, then I clean out the local repository on the working machine and build. Usually then I see that I've missed a dependency in the POM that just happened to exist in my local repository already. Fixing the POM often makes the build work on both systems.

Upvotes: 1

Related Questions