[forge-dev] forge on osgi

[Lincoln Baxter, III]

I think doing a side-by side prototype would be an excellent test. Let's try
to do that and come together and see what we can make. I'll be focusing on
this significantly after I get back from JAXConf next week.

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.

David, does JBM have the concept of a service model? I don't believe it
does, just checking. Paul, why do you think we'd need this? (Not familiar
with OSGi, so I just want to understand.)

~Lincoln

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

> 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
> manifests:
> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html.
> 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 :-)
>
> Paul
>
>
> 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:
>> 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"
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>
> _______________________________________________
> 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/a73ffc14/attachment.html