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.
This archive was generated by hypermail 2.0.0 : Thu Jul 27 2006 - 10:15:40 EDT