Which plugin architecture to use

Question

I want to create a plugin extensibility mechanism for a very generic application which has many facets and lots of different functionality.

A little bit more detail about what I develop:

• I have a GUI application and want to provide a lot of extension points. I want to add menus, actions, toolbar buttons etc.
• I have some non GUI services, which monitor changes to edited data, etc. I want to register such services.

I am considering Equinox (as an example, I can't use it because of application constraints) and its very nice extensibility mechanism which involve extensions and extension points. What are the problems with this approach? What alternative solutions for this problem are available?

Answer 1

For UI extensibility, eclipse RCP will certainly provide lots of capability in that area.

For lower layers, it sounds like you are looking at OSGi, of which Equinox is simply one of many possible runtime environments. If you stick to coding to the specification, then you can use Equinox, Felix ... or any other implementation for your application.

You haven't really defined what you are looking for when you talk of extensibility, and with such an open ended question you are rising it being closed.

Answer 2

What kind of application do you write? The eclipse mechanism of extensions and extension points is a proprietary concept of eclipse rcp. So if you write an eclipse rcp gui then this is the way to go.

If you write a server application then OSGi services are much more suitable. In the case of a server application I recommend using Apache Karaf instead of Equinox. Karaf can run Equinox as OSGi framework but it also provides a lot of additional functionality like deploying from maven repos and logging support. here is a small tutorial of how to write a simple server application using OSGi and Apache Karaf. It shows how to use OSGi services to decouple api and implementation.

For extensibility you will probably like to use one API and more than one service implementation. This is also possible. You can get the list of services for an interface and can also be notified of added and removed services.

Answer 3

One problem to be aware of when going for OGSi is, that it uses a class loader for each bundle (=module) to isolate bundles from each other. This is often a pain especially when working with libraries which where not designed to be used in an OSGi environment. In the end, almost all of the resulting class loading issues can be solved, but it can be quite time-consuming to figure things out.

You could also use spring to make your program modular and extensible. Spring's application contexts can be nested, so that a "module" can use the spring beans of it's parent but not vice versa. Spring can be told automatically discover application context files of all jars on the classpath. To model the eclipse extension points with this approach, one module could provide a bean that has a "register" method which other modules can use to hook in.

Using a service from another module would be as simple as getting a reference to the service bean in spring (assuming that the application context hierarchy is set up accordingly).