I looked into the split packages in detail now. There are definitely
some cases that we can not solve without breaking the api.
The most prominent being the package
org.apache.activemq.artemis.api.core which is present in commons and
core-client.
So we can not solve the split package problem and must use some form of
combined jar. I am currently experimenting
with putting commons, core-client and server together. This solves
almost all of the split packages without packing all of artemis into one
jar.
I also took a closer look into spi-fly and I am not so fond of it
anymore. There are two big problems:
1. It needs to weave all bundles using ServiceLoader to tweak their
classloader.
2. It can not handle bundles going down or being restarted.
So I am looking into an alternative solution now. For example we could
create each impl as a service using an extender pattern based on the
META-INF/services informations.
The point where the instances are looked up must be enhanced then to
also look into OSGi services when in OSGi.
Christian
On 17.11.2015 14:33, Christian Schneider wrote:
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
