Doing proper osgi modularization involves way more than moving packages to resolve split package issues. It requires dynamic dependency injection support which I doubt the current Artemis project supports. If the goal is to to just add osgi support, The uber jar approach is the simplest most correct way to do it without requiring a major re-architecture of th current Artemis di systems.
On Friday, November 13, 2015, Guillaume Nodet <gno...@apache.org> wrote: > An uber-jar is obviously a simpler solution, but it's really not the best > one. I'd rather spend time on a clean solution. > After the split package problem, the next steps would be enhance the > service discovery mechanism to ensure it can work in OSGi, provide a > ConfigAdmin support, a karaf feature, etc... > I'm willing to contribute to solve that and I'll propose some PR, I just > need some indication on how you want to proceed, especially with the split > packages. > > The ActiveMQDefaultConfiguration is used by both client and servers, so I > suppose artemis-commons would be a good place for it. We just need a > specific package for it. What about > org.apache.activemq.artemis.api.config.common ? > > The jms related classes in org.apache.activemq.artemis.uri could be moved > to org.apache.activemq.artemis.uri.jms. > > Thoughts ? > > Guillaume > > > > 2015-11-13 16:33 GMT+01:00 Clebert Suconic <clebert.suco...@gmail.com > <javascript:;>>: > > > ahhh... same package on different JARs... ok.. I missed that. > > > > Yeah.. that needs to be fixed. > > > > On Fri, Nov 13, 2015 at 10:29 AM, Daniel Kulp <dk...@apache.org > <javascript:;>> wrote: > > > > > > I’d much much rather see the split packages resolved than have an uber > > jar. > > > > > > Can the packages be moved into a “common” jar or something that can be > > referenced by both? > > > > > > > > > Dan > > > > > > > > > > > >> On Nov 13, 2015, at 10:27 AM, Clebert Suconic < > > clebert.suco...@gmail.com <javascript:;>> wrote: > > >> > > >> https://issues.apache.org/jira/browse/ARTEMIS-93 > > >> > > >> OSGI still an open task. Fancy contributing? (as the British would > say) > > >> > > >> The first thing thing I know we will need is an uber JAR. I think we > > >> talked about this during the last Apache Con with some folks.. and I > > >> also remember talking to some other folks.. that the first thing we > > >> will need is an Uber Jar... > > >> > > >> > > >> ActiveMQ has it being done here: > > >> > > >> https://github.com/apache/activemq/tree/master/activemq-osgi > > >> > > >> > > >> Maybe that's an easy transfer? > > >> > > >> > > >> And that would take care of your issue of multiple split jars.. (We > > >> need the split jars as the clients don't want to have server > > >> objects... and other things that are best to be kept separate... you > > >> don't need the resource adapter on the client for instance). > > >> > > >> > > >> > > >> On Fri, Nov 13, 2015 at 9:21 AM, Guillaume Nodet <gno...@apache.org > <javascript:;>> > > 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 > > >> > > >> > > >> > > >> -- > > >> Clebert Suconic > > > > > > -- > > > Daniel Kulp > > > dk...@apache.org <javascript:;> - http://dankulp.com/blog > > > Talend Community Coder - http://coders.talend.com > > > > > > > > > > > -- > > Clebert Suconic > > > -- Hiram Chirino Engineering | Red Hat, Inc. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
