[forge-dev] forge on osgi

[Paul Bakker]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20110618/0404521a/attachment-0001.html