Thanks for your input Guillaume. I had understood that you didn't generally consider OSGi fragments fit for any purpose.
If the goal is to make Artemis a nice OSGi citizen, I agree with you that proper modularisation with whiteboard pattern and OSGi services should be the correct path. If the goal was to make Artemis simply "work" in OSGi, I don't think an uber jar is the optimal solution. Why? Even though I haven't dug into the source, I'm pretty sure that not *all* modules present a split-package situation. Therefore, building an uber-jar is killing flies with a bazooka in my opinion, since you'll be forcing the user to drag in ALL optional third party dependencies, whether they'll be using them or not. That's why I think fragments are the right approach. You'd apply a mix'n'match policy, where modules that present a split-package situation would become fragments, whereas the rest would become normal bundles. I appreciate this discussion with you, master! Regards, *Raúl Kripalani* PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and Messaging Engineer http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk On Tue, Nov 17, 2015 at 9:09 AM, Guillaume Nodet <[email protected]> wrote: > 2015-11-17 1:52 GMT+01:00 Raul Kripalani <[email protected]>: > > > Hi Guillaume, > > > > Out of curiosity, why do you think OSGi fragments are not a good solution > > in general? > > > > The original primary use case for fragments is to extend a given bundle. > Using it as a workaround for proper modularisation is too much imho. > A cleaner way to extend a given bundle's functionality is to use OSGi > services which allow for more dynamism in OSGi. > Installing a fragment will cause bundles to be refreshed > > > > > > As for everything, they have their use case, right? Or is there a reason > to > > avoid them altogether, beyond one's liking or disliking of the technique? > > > > There are valid use cases for using fragments, but again, I don't think > using those as a workaround for proper modularisation is one of them (even > though it works and certainly has been used this way, especially when you > don't have real control over the code you want to deploy in OSGi). > > In the Artemis use case, the best way is definitely to refactor the code as > needed so that it becomes a nice OSGi citizen. As a short term solution > (especially if there are some incompatibilities that need to be pushed to a > major version for example), the simplest way imho is to use an > uber-bundle. The benefits is that all the OSGi stuff is concentrated into > a single maven module, and the amount of work is much less. The only small > disadvantage compared to fragments would be that a bunch of import package > need to be optional, whereas with fragments, those could be mandatory for a > given fragment. But at the end, both are similar as you can't really force > an unresolvable fragment to cause a failure, so that in both case, if > something is missing, there will be a runtime exception such as > ClassNotFoundException. > > > > > > Thanks, > > Raúl. > > On 16 Nov 2015 15:18, "Guillaume Nodet" <[email protected]> wrote: > > > > > I really don't see the point of using fragments. Fragments are not a > > good > > > OSGi solution in general. > > > The easiest way forward (even instead of using fragments) would be to > use > > > an uber-jar imho. > > > At least, it has the benefit of limiting the code changes and locating > > all > > > the OSGi stuff in a single module. > > > > > > 2015-11-16 11:48 GMT+01:00 Raul Kripalani <[email protected]>: > > > > > > > Once again, I do suggest you explore the OSGi Fragment route. > > > > > > > > I haven't digged into the Artemis source, but if your modularity > scheme > > > > consists of modules that provide classes and resources to a central > > one, > > > it > > > > could fit well. > > > > > > > > This is the strategy I'm using with certain modules to OSGify Apache > > > > Ignite. > > > > > > > > It also resolves the split package situation quite elegantly without > > > being > > > > a workaround (depending on the rationale of the split packages to > begin > > > > with). > > > > On 16 Nov 2015 03:15, "artnaseef" <[email protected]> wrote: > > > > > > > > > How much work are we talking to get Artemis properly OSGi-ready? > An > > > > > uber-jar > > > > > is a work-around. If nothing better can be accomplished, then we > may > > > > have > > > > > to live with it in the near-term, but it is important to understand > > > what > > > > > challenges are driving us toward a work-around. > > > > > > > > > > Also, we have an individual showing interest to make this happen, > so > > > > let's > > > > > encourage that effort! Thank you Guillaume. > > > > > > > > > > I may be a bit tainted as these days I'm spending large amounts of > > time > > > > > refactoring code and eliminating the impacts of work-arounds and > > > > shortcuts. > > > > > > > > > > > > > > > > > > > > -- > > > > > View this message in context: > > > > > > > > > > > > > > > http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703972.html > > > > > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. > > > > > > > > > > > > > > >
