From: Antoni M. <ant...@gm...> - 2008-12-05 10:25:46
|
2008/12/5 <Dan...@em...>: > 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 smi...@ec.... > OK -- Antoni Myłka ant...@gm... |