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
[2]
https://github.com/jbosgi
On Sat, Jun 18, 2011 at 08:53, Paul Bakker
<paul.bakker.nl@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
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
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
_______________________________________________
forge-dev mailing list
forge-dev@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