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
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
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
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
that runs them in the activator.
Maybe also there is some "JUnit in OSGi" magic, I didn't google for it
Reaching this holy grail can be done without any changes in the project
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...
It was Antoni Mylka who said at the right time 26.01.2009 17:09 the
2009/1/26 Leo Sauermann <email@example.com>:
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
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!
Antoni - should we change
http://aperture.wiki.sourceforge.net/ApertureInOSGi to reflect what I said
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
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:
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
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: firstname.lastname@example.org
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