ActiveMQDefaultConfiguration is part of the APi. That would break people's integrations. I would like to avoid moving it.
We could move stuff without changing package names easily into artemis-commons. We could create a new one there and deprecate the old one.. or play with extensions... I would prefer to keep the API unchanged. On Fri, Nov 13, 2015 at 2:19 PM, Guillaume Nodet <[email protected]> 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 <[email protected]>: > >> 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> >> 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 >> > [email protected] - http://dankulp.com/blog >> > Talend Community Coder - http://coders.talend.com >> > >> >> >> >> -- >> Clebert Suconic >> -- Clebert Suconic
