My feelings about this question are likely consistent with what the JBoss AS team has to say about their OSGi story. The container can be OSGi compliant, we just don&#39;t want to build it on OSGi. In a diagram, that looks like:<br>

<br>OSGi plugin layer<br>------------------<br>    Forge Core<br>------------------<br>  JBoss Modules<br><br>The general argument here is that OSGi is a fine target for application-level programmers, but it has too much architectural coupling for building containers (such as JBoss AS and Forge).<br>

<br>Therefore, I think a reasonable approach is to have an OSGi-compliant plugin layer so that plugin writers can code against OSGi and be able to have their plugin loaded as a bundle. This layer would be in addition to the preferred plugin layer, which loads the plugin as a (JBoss) module.<br>

<br>As for how to create that OSGi-compliant plugin layer, I have no idea. That&#39;s not my dept.<br><br>Sound reasonable?<br><br>-Dan<br><br><div class="gmail_quote">On Mon, Sep 24, 2012 at 5:02 PM,  <span dir="ltr">&lt;<a href="mailto:ggastald@redhat.com" target="_blank">ggastald@redhat.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    I&#39;ve been done some thinking and researching for Forge 2.0 based on
    the last forge meeting we had and the current code in the 2.0
    branch, and it seems that the architecture we&#39;re looking for is very
    close to OSGi architecture itself (regarding to plugability and
    modularity). <br>
    <br>
    I&#39;m also afraid that we&#39;ll face the same problems that OSGi tries to
    solve. As my current experience with OSGi is next to minimal (and
    probably to better understand why and have some arguments if someone
    asks me about it), I would like some opinions about the
    advantages/disadvantages of why not having the Forge container as an
    OSGi compliant solution. <br>
    <br>
    Also, don&#39;t get me wrong: I am not trying to convince anyone of
    using OSGi into the forge core, just want to understand better why
    this architecture is not a viable solution so far. I know Lincoln is
    against using it, but I just want some arguments in case someone
    asks me in conferences and stuff :)<br>
    <br>
    Of course, we need to keep using CDI and annotations as well. So if
    it&#39;s possible to have that and at the same time the modularity (and
    plugability) offered by OSGi, it would be awesome.<br>
    <br>
    Looking forward for your answers !<br>
    <br>
    Best Regards,<span class="HOEnZb"><font color="#888888"><br>
    <br>
    -- <br>
    <div><b>George Gastaldi</b> | <i>Senior
        Software Engineer</i> <br>
      JBoss Forge Team<br>
      Red Hat<br>
    </div>
  </font></span></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><div>Dan Allen</div>Principal Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><div><a href="http://google.com/profiles/dan.j.allen" target="_blank">http://google.com/profiles/dan.j.allen</a><br>

<a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br></div><br>