Hey Paul,<br><br>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.<br>
<br>I've started toying with JBoss Modules here:<br><a href="https://github.com/forge/core/tree/master/plugin-loader">https://github.com/forge/core/tree/master/plugin-loader</a><br><a href="https://issues.jboss.org/browse/SEAMFORGE-136">https://issues.jboss.org/browse/SEAMFORGE-136</a><br>
<br>Thoughts?<br>~Lincoln<br><br><div class="gmail_quote">On Fri, Jun 17, 2011 at 8:28 AM, Paul Bakker <span dir="ltr"><<a href="http://paul.bakker.nl">paul.bakker.nl</a>@<a href="http://gmail.com">gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi guys,<div><br></div><div>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.</div>
<div><br></div><div>How I would like to structure it:</div><div>-The shell becomes the most important bundle. In the bundle activator we bootstrap Forge</div><div>-Every plugin (including all internal ones) become OSGI services in separate bundles (this will hardly require any code changes)</div>
<div>-We deploy all bundles in an OSGI runtime (e.g. Felix) and start up from there</div><div><br></div><div>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. </div>
<div>After the plugin has been found we can iterate over all methods to find all commands.</div><div><br></div><div>The service lookup mechanism can probably even be done in a nicer way by using <a href="https://github.com/mathieuancelin/weld-osgi" target="_blank">https://github.com/mathieuancelin/weld-osgi</a> which looks excellent. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br>
</div><div>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: <a href="https://github.com/paulbakker/forge-osgi" target="_blank">https://github.com/paulbakker/forge-osgi</a></div>
<div><br></div><font color="#888888"><div>Paul</div><div><br></div><div><br></div><div><br></div>
</font><br>_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com">http://ocpsoft.com</a><br><a href="http://scrumshark.com">http://scrumshark.com</a><br>"Keep it Simple"<br>