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.<br>
<br>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.<br><br>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.)<br>
<br>~Lincoln<br><br><div class="gmail_quote">On Fri, Jun 17, 2011 at 11:40 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;"><div>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. </div>
<div>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. </div><div>
<br></div><div>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: <a href="http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html" target="_blank">http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html</a>. Packaging will stay exactly the same (just plain JAR files).</div>
<div>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. </div>
<div><br></div>I'll take a good look at your code this weekend :-)<div><br></div><div><font color="#888888">Paul</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Fri, Jun 17, 2011 at 5:25 PM, Lincoln Baxter, III <span dir="ltr"><<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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" target="_blank">https://github.com/forge/core/tree/master/plugin-loader</a><br><a href="https://issues.jboss.org/browse/SEAMFORGE-136" target="_blank">https://issues.jboss.org/browse/SEAMFORGE-136</a><br>
<br>Thoughts?<br>~Lincoln<br><br><div class="gmail_quote"><div><div></div><div>On Fri, Jun 17, 2011 at 8:28 AM, Paul Bakker <span dir="ltr"><<a href="http://paul.bakker.nl" target="_blank">paul.bakker.nl</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>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></div></div>_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">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><font color="#888888"><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br><a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
"Keep it Simple"<br>
</font><br>_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">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></div></div></div>
<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>