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.
