Kevin,
Thanks for the thoughtful overview. I have no experience with other
engines mentioned in this discussion, but my impression of Platonos
matches your description pretty well. In particular I was very
impressed with the small size of the library (something you almost
never find in the java world). All the "not documented, not
supported" comments smell of FUD.
I guess we'll drag our foot on that for some time, and get back to
this discussion after the Maven switch is complete, and I finish some
JPA related tasks, freeing up some bandwidth to do more evaluation
and make the final decision.
Andrus
On Jul 25, 2006, at 2:57 PM, 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.
