Jonathan Livni
Jonathan Livni

Reputation: 107102

Workaround to maven's "Failed to resolve artifact" in non-trivial dependencies

When building an old project, sometimes I encounter the dreaded Failed to resolve artifact error.

What I do then is search for the jar and pom of that specific artifact and use the mvn install:install-file goal to manually install it locally.

This solves the trivial case, but sometimes the project's dependency on the artifact is not trivial and includes in the project's pom fields such as:

      <scope>runtime</scope>

or worse:

      <exclusion>
        <groupId>cglib</groupId>
        <artifactId>cglib-nodep</artifactId>
      </exclusion>

How would you handle these cases? Is there a way to add these fields to the command as well?

Upvotes: 0

Views: 2757

Answers (1)

bmargulies
bmargulies

Reputation: 100051

A runtime dependency is one that Maven will add to the test classpath, and include in an assembly or war, but will not include in the compile classpath. If you need to run tests or package, you just have to do exactly the same install:install-file thing (or, better yet, run a repo manager and deploy it). Runtime is a scope.

If, on the other hand, you ran into:

<dependency>
   <groupId>abelian</groupId>
   <artifactId>grape</groupId>
   <type>transitive</type>
</dependency>

Then you'd need to use -Dpackaging=transitive for install:install-file, and similarly for 'classifier' (-Dclassifier).

If you need to add something to your dependency tree that had an exclusion in its pom, then you're going to need to find or construct a POM with that exclusion, and pass it to the install-file goal, which has a -D for the POM. There's nothing you can tell install:install-file to tell it to add exclusions when constructing a POM from thin air.

Upvotes: 1

Related Questions