[forge-dev] forge on osgi

Lincoln Baxter, III lincolnbaxter at gmail.com
Fri Jun 17 11:25:20 EDT 2011


Hey Paul,

This is definitely the direction we should take, but I don't think we should
be using OSGI. I'd still like to use JBoss Modules since it is far simpler
and lighter, and also allows us to define our own module structure for
plugins, meaning we can re-use the existing maven repository for plugin
distribution, and also future proof us for the Java module system whenever
that comes around. It'll mean a little overhead work to get the plugin
loading done right, but I think it will be worth it to let people use Maven
natively and not worry about any kind of special packaging whatsoever.

I've started toying with JBoss Modules here:
https://github.com/forge/core/tree/master/plugin-loader
https://issues.jboss.org/browse/SEAMFORGE-136

Thoughts?
~Lincoln

On Fri, Jun 17, 2011 at 8:28 AM, Paul Bakker <paul.bakker.nl at gmail.com>wrote:

> Hi guys,
>
> Since I started to work with OSGI a lot recently I start to feel more and
> more that Forge should run on OSGI. We have discussed this before but I now
> have a more clear view of how to do that.
>
> How I would like to structure it:
> -The shell becomes the most important bundle. In the bundle activator we
> bootstrap Forge
> -Every plugin (including all internal ones) become OSGI services in
> separate bundles (this will hardly require any code changes)
> -We deploy all bundles in an OSGI runtime (e.g. Felix) and start up from
> there
>
> When the shell needs to execute a plugin, or need to create a list of
> plugins it uses the BundleContext to retrieve all services that publish the
> Plugin interface (which is currently already a marker interface). We iterate
> over the list of services and check the @Alias annotation to know which
> plugins are there.
> After the plugin has been found we can iterate over all methods to find all
> commands.
>
> The service lookup mechanism can probably even be done in a nicer way by
> using https://github.com/mathieuancelin/weld-osgi which looks excellent.
>
> For plugins, everything will stay the same, we can still inject the Shell
> etc, the only thing is that we actually inject services under the hood. It
> will require a significant rewrite at the core, but I think it's do-able and
> will avoid a lot of difficult problems later on. The largest problem at the
> moment that I still worry about is that plugins are not really isolated from
> the core at the moment, which makes it impossible for plugins to use
> additional libraries for example. The maven build and project structure
> won't have to change.
>
> If we do this, it will give us a nice way to solve the plugin repository
> problem too. We can use the existing bundle repository spec. for this which
> includes transitive dependencies etc.
>
> Just to demonstrate my idea I uploaded a very, very, simple prototype. This
> uses bndtools which should be replaced by weld-osgi, but the code is pretty
> similar: https://github.com/paulbakker/forge-osgi
>
> Paul
>
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>


-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20110617/fdef0ee5/attachment-0001.html 


More information about the forge-dev mailing list