search

thrau / jarchivelib

A simple archiving and compression library for Java
https://github.com/thrau/jarchivelib
Apache License 2.0
198 stars 36 forks source link

org.rauschig:jarchivelib maven jar contains commons-compress classes #32

Closed nvamelichev closed 9 years ago

nvamelichev commented 9 years ago

org.rauschig:jarchivelib:jar:0.6.1 maven artifact simultaneously depends on and contains org.apache.commons:commons-compress:jar:1.8 (you can see this here, in the "Packages" section).

If maven-enforcer-plugin is configured with BanDuplicateClasses rule, plain Java (non-OSGI) projects depending on jarchivelib will fail to build:

[WARNING] Rule 2: org.apache.maven.plugins.enforcer.BanDuplicateClasses failed with message:
Duplicate classes found:

  Found in:
    org.rauschig:jarchivelib:jar:0.6.0:compile
    org.apache.commons:commons-compress:jar:1.8:compile

Looks like this had been done to package jarchivelib as an OSGI bundle. Using Import-Package: org.apache.commons.compress.*;version=1.8 instead of Embed-Dependency will probably solve this problem and will ensure that the users can add dependency on externally-packaged commons-compress bundle, e.g. from Eclipse Orbit. See this stackoverflow question for a similar solution.

thrau commented 9 years ago

Yes, the bundle-plugin is configured in a way to embed commons-compress into the resulting jarchivelib bundle. This is not a clean solution and was done for convenience reasons, because commons-compress is not OSGi compatible, there is no wrapper bundle of the current version of commons-compress, (that I know of 1,2), and neither is the dependency org.tukaani.xz.

A clean solution would be to build (or find) wrapper bundles for both of these and provide an OSGi features file s.t. jarchivelib can be conveniently installed to an OSGi container without knowing transitive dependencies. Then the Embed-Dependency declaration can be removed. A menial task I have been avoiding :-)

I can't think of a workaround until then at the top of my head.

thrau commented 9 years ago

Turns out I'm totally wrong. commons-compress actually IS OSGi compatible. I'll release the fix with 0.6.2

nvamelichev commented 9 years ago

commons-compress seems to have some OSGI support, but org.tukaani.xz does not (see COMPRESS-199). It looks like the "super-clean" solution would require adding OSGI support to xz library.

thrau commented 9 years ago

thanks for pointing it out. 0.6.2 should be on central in a few hours.

nvamelichev commented 9 years ago

Thank you! :-)