From: <Dan...@em...> - 2009-01-27 07:22:05
|
Hi all, perhaps we can offer some help for running JUnit tests for OSGi bundles within eclipse and with ant. Ralf Rausch set up our build process and I'm sure he can share his experiences with JUnit and OSGi. @Ralf: could you please join this discussion ? Do we have any useful documentation about this topic on the wiki that is not too Smila specific ? Bye, Daniel Von: Leo Sauermann [mailto:leo...@df...] Gesendet: Montag, 26. Januar 2009 23:06 An: Antoni Mylka Cc: Aperture Devel Betreff: Re: [Aperture-devel] [smila-dev] Re: Aperture bundlization for SMILA Hi Antoni, uh, our writing times did overlap :-) I will try answer to this more detailled tomorrow, first answer is: I think that by splitting aperture up into X (~45) OSGi bundles will not gain us much. we still would have to edit all manifest files by hand (ok, but helped with the manifest editor), and we would still have to write a lot of new ant scripts to automate the build process using Eclipse's OSGi build system. The onejar problem would not be solved automatically, as in the current solution we would need to tweak around with ant to do it. My previous experiences with NEPOMUK with the osgi build process make me a bit negative about thinking that "this does rock my world", but I am probably only conservative. I mean, in NEPOMUK our whole build process was as ugly as it can get, triggering many many things by hand, depending on a gazillion of configuration variables that are out of control (such as, the default Java compiler configured in a user's workspace, which we never managed to really outlock and therefore have to cope with these "unsupported version number..." You experienced the "fun" yourself...) The holy grail goal of testing inside osgi is not achieved by using eclipse, we still have no automated way to run tests from within eclipse. My experience is that pressing the "Run JUnit test" button from PDE uses a different classloader and not exactly the manifests as will be used in a real OSGi environment, I think only way to reach holy grail-dom and ascension to semi-god-dom would be to start an OSGi container from command line and somehow trigger the JUnit tests from within, probably by starting a special bundle that runs them in the activator. Maybe also there is some "JUnit in OSGi" magic, I didn't google for it yet. Reaching this holy grail can be done without any changes in the project structure, already today we could start an OSGi container and run the tests, the only way to test is it to test it with the built osgi jars, and not from within PDE. so switching to the proposed PDE development & ETP model would not get us closer to eternity. What would help though is to have all 3rd party libs as bundles. anyway, open for more suggestions... best Leo It was Antoni Mylka who said at the right time 26.01.2009 17:09 the following words: 2009/1/26 Leo Sauermann <leo...@df...> <mailto:leo...@df...> : <snip> I made this masterplan back last year, where I said: * one aperture core OSGi bundle * one OSGi bundle for each Extractor (only for extractors that depend on "Eclipse-Friendly" 3rd party libs) * all remaining crawlers & subcrawlers & extractors into an extra OSGi package "the rest" Antoni, we already prepared all the fine-grained-activators for this, so the task at hand is just to check the weird dependencies in the core OSGi bundle (lib/applewrapper, lib/aduna-commons-xml-2.0.jar) and move - one by one - the most useful extractors into individual OSGi bundles. OK, very well, see below for the way I think it could be done, Once we got some core Extractors out there, we can do a release and done. Can we get these running quick? * Excel, Jpg, Office, OpenDocument, Pdf, Plaintext, Powerpoint, RTF ... + all others that depend on POI (PDF will be a beast because we have no official release of PDFBox) So we are halfway there - we still miss the individual bundles for each extractor. A proper packaging must somehow be "one bundle per extractor" because of the 3rd party libs hassle. At the moment we have "all safe extractors into one bundle" which we call "contrib", which is a bit weird, because it is NOT what we have in the aperture-contrib project, but anyway, it works (tm) As nobody objected back then, I assume this is still the masterplan! Daniel? Antoni - should we change http://aperture.wiki.sourceforge.net/ApertureInOSGi to reflect what I said above? OK, all is well, but I really don't like selectors.xml. Doing bundle-per-extractor with selectors.xml would entail - separate build targets in build.xml for each bundle, - separate set of 6 ant properties for each bundle - separate manifest to be maintained by hand I would rearange the sources the way I did in http://www.dfki.uni-kl.de/~mylka/aperture-smila-test.tar.gz and switch to developing aperture in an OSGI-way, as a separate PDE projects, compiled against a common target platform. And then to write an ant script that would automate it, and create a onejar version for "normal" users. Each module would get its own ant script that would define module-specific properties and include (via an XML ENTITY) a core common for all modules to ensure that all build in the same way. This can be done gradually - start with core and impl and then pluck components one-by-one into individual bundles, resolving all issues in the process. We could keep all tests in a single module that would depend on everyhing else to avoid the need to maintain separate dependencies between modules and between tests, and such a test bundle would be a great way to test if everything works INSIDE AN OSGI CONTAINER - which has been my private holy grail for a long time: http://tinyurl.com/sf1989887 So my proposal 1. rearange the code just like in the above mentioned tar.gz 2. start with core,impl,example and test (all unit tests go into test) 3. create manifests for the 4 above, the target platform, write the ant scripts etc. 4. open those four projects in an eclipse workspace, see if everything works, compiles, and tests pass (this will weed out 99% of all problems with manifests, imports/exports,classpaths etc) we've been having. 5. then start extracting the mime identifier, and extractors one-by-one into separate projects, all the time checking if everything is OK. (all bundles are resolved and start, tests pass). What do you think? -- ____________________________________________________ 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 ____________________________________________________ |