I have used the script from Arthur to create a list of duplicate packages.
I removed the obvious false positives (mainly from examples) and created
a wiki page:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61329082
So first thing is that there a quite a lot of such packages. So if we
want to clean them up it will be a lot of work. It is also probably not
possible to avoid breaking the API then moving packages or classes.
Still I think it makes sense to start with this task while keeping
things stable (just to improve the modularity of artemis over time).
When we consider breaking the API then I think we should rather do it in
the server
module as I guess that less people depend on the server than on the client.
Unfortunately I think we can not fix this in the short term so we will
need an alternative solution.
If you look at the packages closely you will find that most duplications
are between artemis-core-client and artemis-server. So it might be a
good idea to build a bundle out of these two.
Eventually this might also be a case for a fragment if we want to allow
the installation of just artemis-core-client too. So maybe
artemis-server could be a fragment to artemis-core-client. Not sure
though as I rarely use fragments.
There are 4 packages were artemis-commons is also involved. So as this
is a rather low number we can try to fix these. In case it fails it
could be added to the bigger bundle.
I would be happy about any feedback or alternative solutions.
Christian
On 13.11.2015 15:21, Guillaume Nodet wrote:
I was looking at supporting OSGi deployment for Artemis.
The first big problem I hit is the existence of split packages. Split
packages are java packages shared across multiple jars (which become
bundles in OSGi).
Examples of those are org.apache.activemq.artemis.uri (shared between
artemis-jms-client and artemis-core-client) or
org.apache.activemq.artemis.api.config (shared between artemis-core-client
and artemis-commons).
The reason they are problematic is that in OSGi, each bundle has its own
class loader, importing classes from other packages based on packages. The
same package can not be imported from 2 different bundles.
So the question is: would it be possible to get rid of those split packages
? It can be done either by moving the classes from a jar to another one,
keeping the same package name, or by renaming one of the split package so
that there's no duplicate package names across jars.
Thoughts ?
Guillaume Nodet
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
