I propose the following approach:
1. remove the split packages
2. make each jar a bundle
3. use spi-fly to wire up the optional protocols and eventually other
modules
If any of these steps proves to be to much work or is otherwise not
acceptable by the ActiveMQ community we fall back to the ueber jar approach.
Do you have a concrete target date when you need the OSGi support? If
yes then we could also set us a time limit for the above steps.
From my side the effort on Artemis is not yet product relevant so I do
not have a concrete release date.
WDYT?
Christian
On 17.11.2015 13:06, Guillaume Nodet wrote:
As I said, my proposal of the uber-jar is just meant to be a short term
solution.
The locator pattern is not really ideal in OSGi either, the best way is
definitely to use OSGi services,
but it mainly depends how far we would want to go with modularisation.
We could decide to make protocols available in the OSGi registry and even
support them being changed on the fly why not impacting other protocols,
but this may be problematic with how the core is written (not sure that can
easily be supported, and that would also affect the configuration of those
transports).
If we don't go that way, using a locator pattern is good enough and we
should be able to easily tweak the code to support OSGi.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
