From: Gunnar A. G. <gun...@df...> - 2008-12-09 10:01:28
|
Hi Aperturers, One thing to all this - even if smile requires the micro-bundle approach, let us not forget the lesson learned from sesame where at least everyone I know still uses the one-jar. So lets make sure than while this is being refactored, we still have some way of building it the old way (or the "usable" way :) - Gunnar Leo Sauermann wrote: > Hi Smila, Aperture, > > In the past.... we intentionally did NOT turn each dependency of > Aperture into a separate OSGi bundle because we learned that "special" > versions of the dependencies work better than others, so it was easier > to just put all compatible ones into the bundle directly as libs. But > now.... plan B, that was long prepared by us anyway. > > If "you"(=smila) do the work of putting the *needed* libs into ORBIT > repo, then we can do the packaging of aperture into microbundles. > That means: > * we all concentrate on the Mimetype Identifier and Exctractors now! > ** what libs are needed for the extractors and mimetype identifiers? > (ignore the subcrawlers and crawlers!) > > Aperture People (=Antoni, could you make a ticket for this), do: > * separate core OSGi bundle (= we have this already, just verify that we > have a core Aperture bundle that doesn't depend on weird libs) > * why is applewrapper-0.2.jar in the core bundle? > * why is aduna-commons-xml-2.0 in the core (this is ok I think > because its needed in the SAX util package of us)? > * otherwise, this is clean as a baby face: Require-Bundle: > org.semweb4j.rdf2go.api,org.semweb4j.rdf2go.impl.base > * separate all extractors into "individual bundles" (= we planned that > this step will happen sometime, now it does, so we have to extend the > build.xml a bit. this should be mangeable given our year-long preparations) > * we put all crawlers & subcrawlers into an extra package "the rest" > > > the "individual extractor bundles" have to have proper OSGi dependencies > - on released OSGi Jars of 3rd party libs > > * for funny stuff like demork, we ignore it and put it into "the rest" > * For central stuff like PDFBox, we have to have a release - why not > join PDFBox and make one? (or we pay them again something to do it, we > already outsorced some work to them) > * crawlers and subcrawlers go into "the rest" > > ==> we have a release of three chunks pretty soon, one core, many good > extractors, all the bad ones in "the rest" > > It will be a LOT OF WORK for making the individual Manifests of the > individual extractors right, > this is a mixture of the selectors.xml and the finegrained activators, > can be a bit tricky. > will take time. > I guess it will take more than a month, given the Christmas break in > between. > > overall, this procedure has the following advantages: > * we follow the guidelines and path we did the last years, no changes in > plans > * we have a good release for SMILA/Eclipse/OSGI with core features SOON > * we can clean up later "the rest" but do not make ugly decisions today > that will make this harder > > best > Leo > > > Coming to the 5 problems and my views on them: >> Apart from that there are 5 problems: >> demork-2.1.jar - Gunnar, can you make an official release? >> > if not, we move it to "the rest" > we should move demork into a separate sourceforge project where we ALL > join as admins, so that someone can pick up the mess if needed and can > make decisions. > >> DFKIUtils2.jar - this one is LGPL, i'd rather rewrite DeliciousCrawler >> to remove the need for it >> > I asked Andreas Lauer, the author, about a license change or a rewrite. > He would also have to do a publshing of the libs. > answer pending. > >> jpim - this project appears to be dead, we may have to fork it, i'll >> try to get in touch with the author >> > Fork is ok, or they should add us as admins. > Otherwise - we move it to "the rest" >> sesame - will have to integrate bnd in the build process of Aduna >> > bnd? >> pdfbox - tricky, there has been no release in years, thousands of >> people use trunk, i'm sure that ESF does it too >> > we can bug them further to release, pay them a little, or get ourselves > into the admin team. > Do they have sensible Ant scripts to do releases? > > best > Leo > > > > > It was Antoni Mylka who said at the right time 05.12.2008 11:25 the > following words: >> 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 >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> smila-dev mailing list >> smi...@ec... >> https://dev.eclipse.org/mailman/listinfo/smila-dev >> > > > -- > ____________________________________________________ > DI Leo Sauermann http://www.dfki.de/~sauermann > > Deutsches Forschungszentrum fuer > Kuenstliche Intelligenz DFKI GmbH > Trippstadter Strasse 122 > P.O. Box 2080 Fon: +49 631 20575-116 > D-67663 Kaiserslautern Fax: +49 631 20575-102 > Germany Mail: leo...@df... > > Geschaeftsfuehrung: > Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > Amtsgericht Kaiserslautern, HRB 2313 > ____________________________________________________ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel -- Gunnar Aastrand Grimnes gunnar.grimnes [AT] dfki.de DFKI GmbH Knowledge Management Trippstadter Strasse 122 D-67663 Kaiserslautern Germany Office: +49 631 205 75-117 Mobile: +49 177 277 4397 |