It's been a while since I geeked out, so I thought I best do another round, if merely for the purposes of keeping those interested in my adventures into the land of the software plugin updated. The short summary is:
Progress is good, plugins are a great way to develop software, and I am still very much liking this new development mentality.
To expand on that last point: programming is no longer a matter of trying to design everything at once - you can simply say "I'll make an extension point here, and later on decide on how the stuff happens on the other side of this point". This is great for my programming style, where I tend to get a basic version written up, and then I can go back and go "hey, why not rip this part out into it's own plugin?". Doing this is easy, and allows for easy reconfiguration.
For example, I could have a static logging class that outputs to the console, or to file, email, etc - but how do I configure it on a per-customer basis? Configuration files? Sure, but I believe my solution is even better: drop the plugins you want into the plugins folder, and they'll just work.
This is very true - my build script compiles all files in a plugin into a single file, so each plugin truly is one file - making per-customer configuration simply a matter of reading the file names of the plugins.
So how does this work? I define a logging interface, and a logging extension point. Any plugin that wants to be a logger says it wants to be an extension to the logging extension point, and then simply implements the logging interface. Logging will then work regardless of the number of plugins I have that extend the logging extension point.
Clearly there may be instances where I only want one plugin to extend a certain extension point, such as only allowing one extension to the GUI extension point. This is also easily handled - simply state that the extension point multiplicity for this particular plugin is 'one'. Easy.
Ah well, That'll do for now,
Exams soon, so good luck to everyone for that,
Cheers,
Jonathan Giles.
5 comments:
I am doing some similar work at the moment on the WebOfPattern project. I am using Eclipse as a framework and have decomposed WOP using two extension points: one to plug in rule engines to select "good" repositories, and one to plugin is servers (there are two actual plugins based on blogger and delicious, both using the respective network apis).
All this stuff is public, you can pull it from the SF Subversion server: https://svn.sourceforge.net/svnroot/webofpatterns.
Some questions I have encountered are:
- sometimes I want to enable all plugins, sometimes only one of a certain kind. How do I organise this ? (right now, I have just written code and preference pages for this purpose but I wonder whether there is a better way to do this).
- How do I organise many plugins into deployable units. I guess this is what features are all about but I still have to explore this.
- Several plugins require the same library (like the Apache hhtp client). Should I pull this lib into the parent plugin to remove redundancies although the parent plugin does not need it?
To answer your first question (if I understand it correctly): In JPF (and likely in eclipse), you can specify a multiplicity for extension points - you can state that there is to be only one plugin for a particular extension point for example.
Hm, but how do you select the one I want if there are multiple candidates?
In terms of JPF, I think it's pretty much up to the creator to ensure that only one plugin is available, such that the selection is automatic.
JPF in fact gives an error if the multiplicity is not correct, and this actually stops the system from booting (as an integrity check is run prior to the application loading).
For your third question, I'm assuming each extension to the particular extension point you are talking about has its own copy of the library. If so, yes, I would say it would make sense to move it to the extension point to cut back on the duplication of library files.
In JPF it is possible in the plugin.xml file to export everything contained in a library to extensions, and then all that each extension will need to do (and it will obviously already be doing this), is include a statement in the plugin.xml that it requires the extension point plugin.
Post a Comment