Sunday, October 21, 2012

maven references failure - workaround

Overview

This maven use case presents three alternatives to solve its dependencies when the usual method fails - maven update.

It was created from direct experience during a CXF web service project using eclipse and rampart library.

The alternatives shown are:

1. Upgrades to a newer version that probably has already been fixed, but solving some last issue manually.

2. Comments about the maven's exclusion element alternative, useful in cases of fewer occurrences.

3. Shows a solution when there are too many occurrences and the prior alternative comes to be time consuming.



In a CXF web service project requiring rampar 1.4 library, it was added the following dependencies:

<dependency>
  <groupId>org.apache.rampart</groupId>
  <artifactId>rampart-policy</artifactId>
  <version>1.4</version>
</dependency>

<dependency>
  <groupId>org.apache.rampart</groupId>
  <artifactId>rampart-core</artifactId>
  <version>1.4</version>
</dependency>

The first approach is to add the dependencies as usual.
After adding them and performing the respective update, it was generated a huge list of messages about missing dependencies - exactly 73 lines.

Here is a small sample of the error messages generated:

Description  Resource  Path  Location  Type
ArtifactDescriptorException: Failed to read artifact descriptor for bouncycastle:bcprov-jdk13:jar:132: ArtifactResolutionException: Failure to transfer bouncycastle:bcprov-jdk13:pom:132 from http://ws.zones.apache.org/repository2 was cached in the local repository, resolution will not be reattempted until the update interval of apache-ws-snapshots2 has elapsed or updates are forced. Original error: Could not transfer artifact bouncycastle:bcprov-jdk13:pom:132 from/to apache-ws-snapshots2 (http://ws.zones.apache.org/repository2): Connect times out  pom.xml  /SecureClient  line 1  Maven Dependency Problem
Missing artifact antlr:antlr:jar:2.7.7  pom.xml  /SecureClient  line 1  Maven Dependency Problem
Missing artifact aopalliance:aopalliance:jar:1.0  pom.xml  /SecureClient  line 1  Maven Dependency Problem
Missing artifact asm:asm:jar:3.3.1  pom.xml  /SecureClient  line 1  Maven Dependency Problem
...
...




If maven references fail downloading the respective jars (broken references) a workaround is to try another version, preferably a newer one.

Solution

I began switching the rampart version to a newer one:

<dependency>
    <groupId>org.apache.rampart</groupId>
    <artifactId>rampart-core</artifactId>
    <version>1.6.2</version>
</dependency>


but still failed due to one dependency : xalan 2.7.1 .
The message returned was "an invalid file".

The workaround was to complete the task manually.

The xalan dependency was downloaded from
http://mvnrepository.com/artifact/xalan/xalan/2.7.1
and the the new jar file was copied overwriting the older one.


How do we overwrite the older jar?

Copy the new jar to the local repository.



Where is the local repository?

To find out where is the local repository, edit:
 /home/$USER/.m2/settings.xml

and check the element:
<localRepository>${user.home}/work/dev/java/repository/mvn_repo</localRepository>


Alternatively, if using eclipse, check the preferences:
menu > windows > preferences > maven > user settings > local repository


How do we get the reference for a new version?

Go to maven repository.
There you get the snippet for the pom dependency and if necessary, you may download the jar file also.
Check it on the link above.


Suppose that switching to newer versions is not possible due to compatibility issues.
 

How to fix?

Checking the pom file on the local repository, I've noticed a huge list of dependencies created automatically by maven during the update at the first attempt.

A possible solution is to use exclusions.
For instance:

<dependency>
  ...
  <exclusions>
    <exclusion>
      <groupId>javax.jms</groupId>
      <artifactId>jms</artifactId>
    </exclusion>
  ...
  </exclusions>
</dependency>

Considering that I had a pom file containing more than 300 lines, dozens of dependencies, that procedure would be time consuming.
Not advisable, at all!

So I had to work on an alternative solution.
Instead of excluding explicitly, why not doing implicitly, and let the maven procedure and the compiler warn if something wrong goes on?

To do so, I downloaded the two jar files from  maven central repository :

rampart-core-1.4.jar
rampart-policy-1.4.jar


After it was added the rampart dependencies:

<dependency>
  <groupId>org.apache.rampart</groupId>
  <artifactId>rampart-policy</artifactId>
  <version>1.4</version>
</dependency>

<dependency>
  <groupId>org.apache.rampart</groupId>
  <artifactId>rampart-core</artifactId>
  <version>1.4</version>
</dependency>


Then, it was performed the manual installations using the following commands:

mvn install:install-file -Dfile=rampart-core-1.4.jar -DgroupId=org.apache.rampart  -DartifactId=rampart-policy -Dversion=1.4 -Dpackaging=jar
mvn install:install-file -Dfile=rampart-core-1.4.jar -DgroupId=org.apache.rampart  -DartifactId=rampart-core -Dversion=1.4 -Dpackaging=jar




In the code below, it's possible to notice the "rampart-policy-1.4.pom" file generated by the manual installation omitting the dependencies:

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.apache.rampart</groupId>
  <artifactId>rampart-policy</artifactId>
  <version>1.4</version>
  <description>POM was created from install:install-file</description>
</project>


Finally, the project was updated using maven > update dependencies, without no errors.

The final result with rampart dependency correctly assigned:



The successful build:


No comments:

Post a Comment

eclipse: java: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" or Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder

  >PROBLEM Using Eclipse, you try to run a simple logging test using "org.slf4j.Logger" like the sample below: package Test; im...