[forge-dev] forge on osgi
paul.bakker.nl at gmail.com
Sat Jun 18 15:29:21 EDT 2011
That's interesting, I hadn't heard about the service container yet. Yes, if
we combine both we have basically the same thing as why I think OSGI would
be good, possibly even better and created within JBoss (so we have access
to the right people). I do think we really need a service layer, just
modules will only solve part of the problem so we should definitly look at
So yes, it makes a lot of sense. I will spent some time on a prototype
anyway just because I want to try and then we have something to compare with
On Sat, Jun 18, 2011 at 9:02 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
> Your points about OSGi are well made and definitely worth exploring.
> I did leave out an important piece of information that may help bridge the
> design gap.
> One of the main motivators for creating JBoss Modules was to isolate the
> concern of modular classloading from services, which are unnecessarily
> coupled in OSGi. Of course, there is still an need for the services. That's
> why the JBoss Modular Services Container  was created, to solve the other
> half of the equation independently. JBM doesn't have a services layer
> because MSC provides that :)
> Together, JBoss Modules and the JBoss Modular Services Container match the
> functionality that OSGi provides (you can look at it like a Venn Diagram,
> with the overlap being the OSGi equivalent). JBoss even provides an OSGi
> container, which as you can probably guess, is layered on top of this
> I would personally prefer OSGI because it offers a bit more (services) than
>> JBM which I believe is very useful for Forge, but JBM being a JBoss project
>> is a good argument to prefer this solution.
> In essence, I don't think we should limit ourselves to JBM either. On the
> other hand, I don't know that we have to go all the way to OSGi. And I would
> say that this choice has little to do with the fact that JBM and MSC are
> JBoss projects. After all, if we used OSGi, we can use JBoss OSGi, or any
> other compliant container. The ownership doesn't really concern me.
> The reason I'm suggesting that we use JBM and MSC is because they are the
> simplest possible tool that can solve the problem (the best tool for the
> job). If they aren't, for some reason, then we can shift upwards to OSGi.
> Make sense?
>  https://github.com/jbossas/jboss-msc
>  https://github.com/jbosgi
> On Sat, Jun 18, 2011 at 08:53, Paul Bakker <paul.bakker.nl at gmail.com>wrote:
>> The osgi service model makes it possible to publish services to the
>> runtime. A service is just a Java interface, because services are running in
>> the same VM/runtime. Services are dynamic, meaning they can come and go any
>> time. From code you can ask the runtime for all services implementing a
>> specific interface (other "query" metadata is possible too). With weld-osgi
>> it's possble to do this completely using cdi annotations. Forge is already
>> higly modular at build time because Plugins are decoupled from other
>> plugins. If Plugins become services they are decoupled at runtime too. Forge
>> and osgi services seems to be a perfect fit to each other.
>> I've watched the JBoss world presentation (thanks for the links Dan!) and
>> JBM looks great too. JBM doesn't have a services layer though (which is an
>> explicit choice). We can live without though, since we already do now. The
>> largest problem that must be solved in Forge is the classloading itself, and
>> JBM does that perfectly. I would personally prefer OSGI because it offers a
>> bit more (services) than JBM which I believe is very useful for Forge, but
>> JBM being a JBoss project is a good argument to prefer this solution.
>> Either solution would keep the plugin development process exactly the same
>> as is. Plugin writers and users will not have to notice whatever we use.
>> I'll try to work on a prototype using OSGI, even if we go for JBM it will be
>> a fun experiment anyway ;-)
>> On Fri, Jun 17, 2011 at 6:39 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
>>> On Fri, Jun 17, 2011 at 11:59, Lincoln Baxter, III <
>>> lincolnbaxter at gmail.com> wrote:
>>>> The reason I want to go toward JBoss Modules is because I think that we
>>>> can get things working with absolutely 0 code changes required for plugin
>>>> developers, and yes, also because it's a jboss project.
>>> I have complete confidence that JBoss Modules  is the right way to go.
>>> It may be young, but it has been very carefully designed by someone who has
>>> crystal clear understanding of the problem. I'm not just saying that because
>>> David's my respected colleague, it's backed up with proof in the form of AS
>>> 7, his blogs about modularity   and the JBoss Modules presentation.
>>> I've heard the JavaDoc are very good as well. 
>>> If you haven't yet, I strongly recommend all of you to watch the
>>> presentation on JBoss Modules from JUDCon , which was given by David by
>>> his proxy, Jason Greene. It gives an overview of JBoss Modules, but more
>>> importantly it explains how it relates to OSGi and Maven.
>>> JBoss Modules truly is a good fit. Plus, Forge could really help get the
>>> word out about the benefit of modularity in general.
>>>  https://github.com/jbossas/jboss-modules
>>>  http://in.relation.to/Bloggers/ModularizedJavaWithJBossModules
>>>  http://vimeo.com/24776447
>>> Dan Allen
>>> Principal Software Engineer, Red Hat | Author of Seam in Action
>>> Registered Linux User #231597
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
> forge-dev mailing list
> forge-dev at lists.jboss.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the forge-dev