Re: [smila-dev] aperture bundles for smila integration

["Antoni Mylka" <antoni.mylka@xxxxxxxxx>]

2008/12/5  <Daniel.Stucky@xxxxxxxxxxx>:
> Hi aperture team,
>
> I just took a look at the osgi distribution of release 1.2.0. There are
> several issues that need to be addressed to allow integration of
> aperture in smila.
>
> - non EPL compatible licenses
> There are some 3rd party components which licenses are not compatible
> with EPL (e.g. jaudiotagger-1.0.8.jar is LGPL). These libs simply cannot
> be contributed to smila. These libs and the dependencies on them have to
> be made optional in aperture, perhaps by fine grained bundles (see
> below).

Does this apply only to LGPL? What about Sun libs (JAI, Javamail etc.)
Please have a look at
http://aperture.wiki.sourceforge.net/Dependencies and write exactly
which dependencies are inacceptable because of their license.

> - eclipse legal process
> we have to create a Contribution Questionnaire (CQ) for each bundle and
> for each lib used in the bundles. That means a CQ for every (nested) jar
> is needed. Of course we can skip CQs for non EPL compatible libs, as
> they will be rejected anyway. At first we should focus on functionality
> we want to make use of in smila (this would be MimeTypeIdentifier an
> Extractors only). For some jars used in aperture this was already done
> and we can simply reuse those CQs (e.g. commons-*.jar).
> Eclipse also usually allows only usage of "released" 3rd party software,
> not any nightly builds or beta releases.

Does this include test dependencies, i.e. jars only used for tests,
the final bundle does not depend on them
(infSail/unionSail/nrlvalidator).

Apart from that there are 5 problems:
demork-2.1.jar - Gunnar, can you make an official release?
DFKIUtils2.jar - this one is LGPL, i'd rather rewrite DeliciousCrawler
to remove the need for it
jpim - this project appears to be dead, we may have to fork it, i'll
try to get in touch with the author
sesame - will have to integrate bnd in the build process of Aduna
pdfbox - tricky, there has been no release in years, thousands of
people use trunk, i'm sure that ESF does it too

> - fine grained bundles
> In order to be able to integrate selected functionality (either because
> we don't need it or we can't use it because of license issues) a finer
> grained bundleing is needed. In addition, some of the 3rd party jars
> used in aperture are already used in smila. We provide each 3rd party
> jar as a separate bundle (and contribute them to Orbit). This allows for
> easier update of 3rd party dependencies. Perhaps this is a practical
> approach for aperture, too.

Right now the impl bundle contains the following jars that need to be
turned into bundles if you want to enforce this policy:

 activation-1.0.2-upd2.jar
 ant-compression-utils-1.7.1.jar
 applewrapper-0.2.jar
 bcmail-jdk14-132.jar
 bcprov-jdk14-132.jar
 commons-codec-1.3.jar
 commons-httpclient-3.1.jar
 commons-lang-2.3.jar
 DFKIUtils2.jar
 flickrapi-1.0.jar
 fontbox-0.2.0-dev.jar
 htmlparser-1.6.jar
 ical4j-1.0-beta4.jar
 jacob-1.10.jar
 jacob.dll
 jai_codec-1.1.3.jar
 jai_core-1.1.3.jar
 jaudiotagger-1.0.8.jar
 JempBox-0.2.0.jar
 jpim-0.1-aperture-1.jar
 jutf7-0.9.0.jar
 mail-1.4.jar
 metadata-extractor-2.4.0-beta-1.jar
 mstor-0.9.11.jar
 pdfbox-0.7.4-dev-20071030.jar
 poi-3.0.2-FINAL-20080204.jar
 poi-scratchpad-3.0.2-FINAL-20080204.jar

We have included them inside precisely not to turn them into proper
bundles ourselves. This is something we might use some help for. All
of them need to be equipped with proper osgi manifests and contributed
to orbit am I right?

> Please let us discuss the listed issues and how both projects can help
> each other. Of course we are willing to contribute to aperture to
> achieve smila integration!

Great, since doing all this will require quite a lot of work.

> For further communication please send copies to smila-dev@xxxxxxxxxxx.
>

OK


-- 
Antoni Myłka
antoni.mylka@xxxxxxxxx