Latest revision as of 10:19, 27 April 2012

File path1 differs from path2

Reason

While merging two repositories, MT4E encountered two artifacts with the same name and version. Since the name and the version are the same, the content of the JAR files should be the same.

There are two main reasons for this warning:

1. The classes are the same but the cryptographic signatures in the file META-INF/MANIFEST.MF are different.
2. An Eclipse project violated the versioning rules. Orbit is a common candidate here.

The first case happens when a project signs too many bundles. Some projects need bundles from org.eclipse.osgi, for example. Instead of consuming them from a public p2 repository, the developers added the bundle to their map files, so the build downloads and compiles them together with all the project's own code.

When all bundles are signed, these are signed as well. The timestamp is part of the cryptographic key, so the signature of the bundle changes even though the code inside doesn't change.

Now the bundles are packaged and put on an update site. Depending on where you got your bundles, you might end up with two files which are different but which contain the exact same code.

The second case happens when Orbit republishes an existing OSS project. Take org.apache.batik.pdf. The official project's version number is "1.6.0". Orbit imported the code. Then an error was found. Now Orbit was in trouble. The rules say "if something changes, you must increment the service segment"

That would mean Orbit would publish Batik 1.6.0 as 1.6.1. This would be confusing but the only option since OSGi bundles can't have four-digit versions.

Now imagine what would happen when Batik released 1.6.1. Orbit would have to publish this as 1.6.2. Now another problem is found. The original 1.6.1 would become 1.6.3... You get the idea.

Possible solutions

If the signatures in the file META-INF/MANIFEST.MF are the only difference between the two JARs, delete one of them.

If this is an Orbit bundle, check whether you really need both versions.

If you need both versions (for example, because you already published the broken version in a Maven repository), you need to add a "map qualifier" patch. Add this code to your patches:

mapQualifier( "pattern", "version" )

A "pattern" is the coordinate of the artifact before the qualifiers are stripped and before any Orbit renames have happened. "version" is the desired version for matching artifacts.

In order to fix the Batik problem above, this would look like so:

mapQualifier( "org.apache.batik:*:1.6.0.v201011041432", "1.6.0.1" )

This will give all bundles in the group org.apache.batik with the OSGi version 1.6.0.v201011041432 (this includes the qualifier!) the version 1.6.0.1.

Note that as far as Maven is concerned, 1.6.0.1 is greater than 1.6.0