The application context Kevin mentioned is an object that can be used by
plugins to find other plugins, find services and access the evenbus to
send events or register too, to listen for event send by others.
This object was introduced in 2.0 to separate these things I metioned
above for the more internal stuff of the engine such as call the load
methods on the PluginEngine to load plugins and the start and shutdown
to start and shutdown the engine.
In 2.0 the services part has been extended a bit to allow the plugin
that defines a servicepoint to specify a helper class to handle the
standard things when using the services that are connected to the
servicepoint.
For example if you have a servicepoint for reading files you could
provide a helper class that has methods to find readers for files based
on a file extension, so plugins that use this servicepoint don't have to
write that common code them self.
Kevin Duffey wrote:
Hey all,
I joined the list after reading a few replies with regards to the plugin engine
direction for the project. I am one of the two developers on the Platonos
project.
First of all, thank you for considering our project as your plugin engine of
choice. JPF and the other one are both good candidates. Having worked on the
engine for over 3 years (several incarnations before the 1.0 was release), I've
studied most of the available engines including the JEdit engine, Eclipse (back
when I started, the Eclipse engine was known as a subproject titled Equinox,
that later got rolled into Eclipse and merged with the OSGi framework for the
3.0 release), JPF and some others.
JPF is built off of the old Eclipse plugin engine, prior to OSGi. If I recall, the author
either used parts of the Eclipse engine directly, or wrote it from scratch but mimicked
the Eclipse class names and such. I think he used part of Eclipse tho. Regardless, Evert
and I had a bad experience with the author. We actually tried to "merge" our
projects with him and he wasn't a very nice guy to say the least. Maybe he's better to
those using his project as opposed to those with a similar project. I don't want to sound
like I have any hard feelings either. I'm not making a sale here. :). Just a heads up
from our dealings with him.
So.. the OSGi implementations are generally quite large from what I have seen.
I don't recall JPF's size either, but a few factors come in to mind for me.
First, I was a hard core C developer years ago and to me everything was about
size, speed and optimizations. I've had a hard time letting that go. We've
strived to some extent in making our engine small, fast yet robust enough for
pretty much any application use. As the 2.0 jar file stands now, its like 68K
in size. It will get larger no doubt, but it's pretty small all things
considered. If you are looking for a smaller library that gets the job done,
then Platonos may be the right engine for you. If you want the industry support
behind OSGi (Bill is correct in that OSGi is the brains behind Eclipse and has
decent industry momentum behind it, mostly for set top boxes and such, but many
OS projects are also using it as well), and don't mind the potentially large
implementations, it offers a lot of frills. Then again, if
the OSGi route, or JPF, is of interest, you may want to consider the headless
Eclipse engine. It's available and is not tied to SWT or the RCP project.
Here's what I can tell you about our engine for those of you who havent looked
at the code, or read the getting started guide for the 1.0 engine. It mimics
Eclipse in that it is based on plugins contributing extension points, and other
plugins attaching to those contributions through extensions. There is almost no
difference between JPF, Eclipse and our engine in this regard. With the 1.0
engine we actually do have an xml-schema validation in place for those that
want to include a validating parser for JDK 1.4, or use JDK 1.5 which has it
built in. Give or take a few minor things, they are almost identical in how
they work. Extension points can provide an interface that extensions must
implement, or not, its optional. As an example, a Help plugin can provide
extension points that other plugins can contribute HTML files to to build up a
help system. There is no java code at all involved, thus the optional
interface.. not needed in this case.
A few things we added that I don't think the others have... maybe they do and I haven't delved into
them enough. The 2.0 engine has added this notion of an application context. Through this context
plugins can share stuff, such as objects, services and such. I honestly don't know the details,
Evert recently put this in and I have yet to explore it. It is something I toyed with a while back
and removed from our 1.0 code base due to not enough time to develop it before we could release.
Another thing I added in the 1.0 CVS head (not 1.0 release) was a simple but effective
implementation of an Event bus. It allows any plugin to add a generic event type to fire events to,
and other plugins to subscribe to that "channel" or "listener".
If you haven't worked with these types of plugin engines that you are
considering, there are some caveats to watch out for. Namely, the two big
issues are the way plugin dependencies work, and the process of loading and
unloading plugins at runtime. Both of which will require some bit of discussion
that I would rather do in another thread or on our mail list for those of you
that may want to join our list if you choose our engine.
I'd like to squash the notion that our engine is not supported. Evert and I almost
immediately reply to emails on the list. Yes, we haven't actively developed on the 1.0
branch for some time, but Evert has been working on and off again with the 2.0 code base
for a while now before recently committing it, so he has been active. I've started a new
startup job and have been super busy but I check email about 20 times a day (no lies) and
always reply within a day or less to emails on the mail list. We would love to see our
engine used in more projects, and still have hopes of finishing our Swing framework one
day, which is now moving over to the 2.0 codebase. Think of our Swing framework as sort
of like the Eclipse RCP, with our engine, and various 3rd party Swing widgets we've found
and have been able to provide. It's far from complete, but it "was" usable
enough to build on top of the 1.0 branch. We are updating the head of the framework
project with 2.0 engine usage now, so
its now unstable at this point.
So all that said, I am going to watch this list as well as ours for any
replies, and am happy to answer any questions I can regarding our engine, how
it works, examples, how best to use the engine in your project, etc. As a side
not, as a long time Swing developer, after our engine was released I generally
like to work off of an empty RCP like shell and make everything plugins. In a
nutshell, you have a simple launcher that starts up the engine and loads the
entire UI, app, etc as plugins. That's just me. Most apps that are already
created don't have this luxury, but our engine (as well as the others) can
easily integrate into existing apps as well.
Lastly, there's many future enhancements that can easily be added. For example,
it was said our code is not documented. Last I checked the 1.0 release had
extensive JAvaDoc in most classes with examples in it. Even so, I can see a
simple plugin add-on (or separate utility) that could easily go through all the
plugin (.par or .jar) files, pull out the plugin.xml file and generate a nice
API that other plugin developers coudl use to discover plugisn they can code
to, what extensions, etc are available. That's just one of many avenues that we
can explore and with a few more people helping, maybe realize sooner than later.
Thank you. I look forward to any replies/questions/comments.
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free.
