I think ordinary bundles will not work well regarding the mechanisms to
e.g. find protoccols.
Currently these assume all modules to be in the same classpath. So if
you put them into individual bundles they probably will not work out of
the box.
Maybe we can solve this using the Aries spi-fly as it seems the
Resourelocator mechanism is used. Not sure though.
So an ueber jar would fix that problem. On the other hand I am not sure
if we really would want to put all modules into it.
So I would rather like to first check how far we can get with a real
modularization.
Christian
On 17.11.2015 12:02, Raul Kripalani wrote:
Thanks for your input Guillaume. I had understood that you didn't generally
consider OSGi fragments fit for any purpose.
If the goal is to make Artemis a nice OSGi citizen, I agree with you that
proper modularisation with whiteboard pattern and OSGi services should be
the correct path.
If the goal was to make Artemis simply "work" in OSGi, I don't think an
uber jar is the optimal solution. Why? Even though I haven't dug into the
source, I'm pretty sure that not *all* modules present a split-package
situation. Therefore, building an uber-jar is killing flies with a bazooka
in my opinion, since you'll be forcing the user to drag in ALL optional
third party dependencies, whether they'll be using them or not.
That's why I think fragments are the right approach. You'd apply a
mix'n'match policy, where modules that present a split-package situation
would become fragments, whereas the rest would become normal bundles.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
