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 needed there.

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 framework.

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 possible.


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 
want to.

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 
core bundle:
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 
P.O. Box 2080          Fon:   +49 631 205-3503
67608 Kaiserslautern   Fax:   +49 631 205-3472
Germany                Mail: