>How reusable are your plugins? Can an adopter take just the pieces they need from your Feature set and only use select pieces in their own Feature set? Does the plugin inherit a lot of additional and possibly unneeded (by the adopter) functionality?
I’ve been running into several of these issues during the work on XSL Tools in one shape or form. It’s come from many different plugins projects from the eclipse platform, jdt, emf, dltk, and wtp. How we create the plugins and how we design their inter dependencies directly affects how consumable our plugins are by the community and adopters building projects and applications. In many ways the Principles of Object Oriented Design also apply it to plugins. In fact, you could replace the word “Object” with the word “Plugin” in many cases. There are several that I think need some more attention when committers and contributors are designing their plugin architecture. All of the articles below are PDFs.
- Single Responsibility Principle and The Open Closed Principle
- Granularity – covers The Release Reuse Equivalency Principle, The Common Closure Principle, and The Common Reuse Principle. All of these are related to packaging.
While the above are directly talking about Object Oriented Design, they also equally apply to plugin design. One of the items I’ve been running into from JDT is that there is a need to have the Java Runtime configuration, launching support, some debugging support, but not necessarily the Java Editor, Package Explorer, and other items included. However, it is near impossible with the tight coupling of the packages to currently pull just the plugin features you want into your system. If you just wanted to build an IDE or and RCP application that just leveraged the Launching support for Java related JVM applications written in JRuby or Jython, you would also currently need to bring in everything in org.eclipse.jdt.ui as well. Oh and you would still get (but may not want) the ability to launch java applets, and java programs. The dependency on jdt.ui also means you inherit everything that focuses on the java editor and its dependencies as well. Do not get me started on the ANT editor and launching support, this also requires org.eclipse.jdt.ui.
The same thing happens in many eclipse plugins. How many have seperated their Perspective code out of their main UI plugin? Not many. With out the seperatation an adopter is forced to bring in that UI when they may not necessarily need or want it. Plugin design evolves just as an application design evolves. We need to make sure that when we design or plugins that we aren’t having them do to much. What are the reasons for the classes and packages with in the plugins to change? How easily would it be for an adopter to just take a piece of functionality? How easy is it for them to extend and add their own items (like content assistance) to existing plugins?
In XSL Tools I’m noticing we are violating these items as well. The XML Perspective is in the org.eclipse.wst.xsl.ui plugin when it should probably be in an org.eclipse.wst.xml.ui.perspective plugin since it relates to general XML use not just XSL. I’ve run into some similar issues with the way the Web Standard Tools is packaged. Why does an HTML editor necessarily need to bring in XML items? What if I just wanted to distribute an HTML editor that didn’t require me to bring in org.eclipse.wst.xml.core as well? The current HTML editor extends parsing functionality provided by the XML editor, but it’s an added dependency that probably should be refactored out. For the most part WTP has done a pretty good job of separating the plugins to make them as reusable as possible, but there is still further refactoring to do.
Another question, why does the XML Content Assistance include JSP specific functionality and parsing? This functionality should be in the JSP content assistance classes not in the XML content assistance classes.
DLTK is another item that I would like to use, but with the way it is currently designed, I can’t just pull in pieces and parts, I have to pull in large core and ui plugins. If I wanted the ability to add Include and Build Path functionality for XSL Tools, I have to pull in the full DLTK UI plugin which I may or may not need. The same with their launching and debugging support.
EMF is actually pretty good. The emfruntime itself can even be used with out eclipse as a standalone jar library! Compare this to the ANT tasks that are provided by PDE and the eclipse platform UI. You have to have a large batch of eclipse plugins to use these, where with a little more thought in the design and reuse department, they could be used outside of eclipse. This was the approach I took with the XInclude Ant Task that is contributed by XSL Tools. It can be used within eclipse or as it’s own standalone jar outside of eclipse with no code changes to the plugin.
So the more thought that we can put into the design and architecture of our plugins, the more consuemable they will be for adopters as well as across eclipse projects.