[forge-dev] forge on osgi
paul.bakker.nl at gmail.com
Fri Jun 17 11:40:34 EDT 2011
I still don't know much about JBoss Modules, but it would make sense because
they're both JBoss projects. On the other hand, OSGI is well proven now,
while JBoss Modules is relatively new. I'm sure it works great, but I'm more
worried about knowledge / best practices at this point.
Does JBoss Modules have a service model? I think that's an important
requirement. If it doesn't have a service model we would have to create one
ourselves and that would be like re-inventing OSGI.
We, and plugin writers, can still use Maven as they do now. The only extra
thing needed is the maven-bundle-plugin which will take care of generating
Packaging will stay exactly the same (just plain JAR files).
Using weld-osgi most of the code will stay the same as is, only the
bootstrap process and plugin loading mechanism will change considerably.
Maybe we should create a prototype both for osgi and Jboss Modules, and see
which works best.
I'll take a good look at your code this weekend :-)
On Fri, Jun 17, 2011 at 5:25 PM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:
> 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:
> 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
>> 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
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
> Lincoln Baxter, III
> "Keep it Simple"
> forge-dev mailing list
> forge-dev at lists.jboss.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the forge-dev