It depends on the application,
and bundling each mimetype detector is much too granular. putting
single classes in bundles is out of question.
you may want to view it from the aperture user's side, not from the
aperture developers side
for the aperture user, he is only interested in getting aperture and
make it run, so the understanding of the details inside the impl is not
The activators: they usually contain only a few lines of code and
should be simple to understand.
Stacking them or combining them adds just another framework of a
We will go for the simple way first, if we find problems we worry then.
as we all don't know much about OSGI, I would keep it as simple as
Es begab sich aber da Christiaan Fluit zur rechten Zeit 10.11.2006
12:16 folgendes schrieb:
What I see here is a proposal for organizing stuff in bundles but what
is lacking IMHO is a rationale for why you draw the lines there. If I
understand you correctly, all Aperture APIs and related stuff would go
into a single bundle, right? But what does a MimeTypeIdentifier API have
to do with a Crawler API, except that they are both part of the Aperture
project? Why not put them into their own bundles?
To be honest, I don't feel like I have very strong ammunition to shoot
at your proposal with ;) or solid, undeniable arguments for my own
proposal. I actually start to feel that the chosen granularity might
depend a lot on your application, how much you use of Aperture, to which
extent you want to be able to tweak your installed application, etc. As
long as the code and build scripts are neatly organized, I expect people
can always create a different setup of bundles for their own use if they
Just one more argument for fine-grained bundles ;) : each bundle can
have its own private classpath. This makes it possible to e.g. create an
extractor for a specific MIME type that contains all its third party
dependencies, without necessarily exposing those dependencies to the
rest of the application. This may prevent certain class loading
conflicts. For example the bibtex2rdf stuff we've seen last week bundles
its own XML parser, I believe including classes that implement core Java
factory interfaces (SAX factories, etc.). Imagine that for some reason
you want to use this jar as is, adding such a jar file to a regular Java
application may cause a lot of hard to debug problems when for example
the bundled XML parser is buggy and gets transparently used in other
parts of the application as well. Seeing how Aperture's third party
dependencies are expanding and that itself is still meant to be part of
a bigger application, this may become an issue in the future.
However, more important IMO are the BundleActivators, as they require
some programming as well as intimate knowledge of Aperture's internals
and therefore you want to create them once and for all. Am I right in
that the construction of the BundleActivators does not depend on the
bundle granularity that you choose? Or can a bundle only have a single
BundleActivator? In that case, perhaps BundleActivators can be chained,
so that for example you have a single ExtractorsBundleActivator that on
its turn invokes a HtmlBundleActivator, a PdfBundleActivator, etc.? This
would then support both the "1 extractor impl bundle" strategy and the
"1 bundle per extractor impl" strategy.
Again, my knowledge of OSGi is limited so feel free to say that this is
all nonsense or has all been solved before.
Antoni Mylka wrote:
I've gone through some tutorials and I see it as follows.
We would need one core aperture bundle. It would contain all interfaces
and vocabulary classes. I would exclude following packages from this
all extractor subpackages except extractor.impl
Security, util and vocabulary could stay. This core bundle would
register following services:
The implementations of these interfaces could all be placed in one big
bundle, or in separate bundles, even if each bundle would contain a
single class. The activators of these implementation bundles would
register all implementations with appropriate registries.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Aperture-devel mailing list
DI Leo Sauermann http://www.dfki.de/~sauermann
P.O. Box 2080 Fon: +49 631 205-3503
67608 Kaiserslautern Fax: +49 631 205-3472
Germany Mail: email@example.com