[forge-dev] forge on osgi

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
this.
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
:-)

Paul

On Sat, Jun 18, 2011 at 9:02 PM, Dan Allen <dan.j.allen at gmail.com> wrote:

> Paul,
>
> 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 [1] 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
> foundation.
>
> 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?
>
> -Dan
>
>
> [1] https://github.com/jbossas/jboss-msc
> [2] 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 ;-)
>>
>> Paul
>>
>> 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 [1] 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 [2] [3] and the JBoss Modules presentation.
>>> I've heard the JavaDoc are very good as well. [4]
>>>
>>> If you haven't yet, I strongly recommend all of you to watch the
>>> presentation on JBoss Modules from JUDCon [5], 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.
>>>
>>> -Dan
>>>
>>> [1] https://github.com/jbossas/jboss-modules
>>> [2] http://in.relation.to/Bloggers/ModularizedJavaWithJBossModules
>>> [3]
>>> http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsReviewPart1
>>> [4]
>>> https://github.com/jbossas/jboss-modules/blob/master/src/main/java/org/jboss/modules/ConcurrentClassLoader.java
>>> [5] http://vimeo.com/24776447
>>>
>>> --
>>> Dan Allen
>>> Principal Software Engineer, Red Hat | Author of Seam in Action
>>> Registered Linux User #231597
>>>
>>> http://www.google.com/profiles/dan.j.allen#about
>>> http://mojavelinux.com
>>> http://mojavelinux.com/seaminaction
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://www.google.com/profiles/dan.j.allen#about
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20110618/1f74d15e/attachment-0001.html 