Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You might like to consider using <a href="http://www.osgi.org/" rel="nofollow">OSGi</a> as your plugin loading mechanism.</p> <p>The Eclipse <a href="http://www.eclipse.org/virgo/" rel="nofollow">Virgo</a> open source project provides an OSGi runtime environment that is suited to your project because it has Spring built in. Virgo offers Tomcat and Jetty based servers and a standalone kernel which can be used on its own or to construct other types of server. See the Virgo web site for <a href="http://www.eclipse.org/virgo/" rel="nofollow">features</a> and <a href="http://www.eclipse.org/virgo/benefits" rel="nofollow">benefits</a>.</p> <p>OSGi has quite a different design point than you may be used to in Java. It gives you controlled isolation between plugins, known as <em>bundles</em>, unlike a linear classpath. Bundles are wired together in a dependency graph and support versioning and dynamic life cycle operations.</p> <p>The preferred means for a bundle to use the facilities of other bundles is via the OSGi service registry. The <a href="http://www.springsource.org/osgi" rel="nofollow">Spring DM</a> project enables normal Spring beans to be published to the service registry and looked up from the service registry. Spring DM is also built in to Virgo. Spring DM has been donated to Eclipse as the <a href="http://www.eclipse.org/gemini/blueprint/" rel="nofollow">Gemini Blueprint</a> project.</p> <p>To use Virgo, you would add some Spring DM configuration to each of your plugins in the META-INF/spring directory. This configuration, which is a normal XML Spring configuration file, can reference beans in your other Spring files and publish those beans in the service registry, or can provide beans for services looked up in the service registry which may then be referenced by, and injected into, beans in your other Spring files.</p> <p>You would then deploy your plugins into Virgo using any of the supported mechanisms. You could simply drop them in dependency order into the pickup directory. Or you could use the web admin console or shell console to deploy then.</p> <p>Alternatively, and this would seem to fit your requirement rather well, you could place plugins providing packages for other plugins in the Virgo repository by dropping them into repository/usr and then deploy the plugins which depend (transitively) on the repository plugins via the pickup directory or web admin console. Virgo will automatically deploy the dependencies from the repository as the dependent plugins are deployed.</p> <p>You could also group plugins together either in an archive, known as a <em>PAR</em>, or by storing them in the Virgo repository and then referencing them in an XML file, known as a <em>plan</em>. You would then deploy the PAR or plan as describe above. You can even put some of the dependencies in the Virgo repository and reduce the PAR or plan to contain just the dependent plugins.</p> <p>If you would like further information about Virgo, just ask on the <a href="http://www.eclipse.org/forums/index.php?t=thread&amp;frm_id=159" rel="nofollow">Virgo community forum</a>.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload