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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"