First off, thanks Kevin for the in depth explanation of the Platonos
stuff!
So if I could try to summarize;
Platonos -> small, flexible, what you need and no more
OSGi (Felix or other) -> bigger, not as flexible, what you need and
lots more
I tend to lean towards OSGi because its standard and will afford us
the opportunity to replace the impl with a different impl if needed.
Also we can use plugins that are not intended for our stuff in our
stuff if we have OSGi. I'm sure its not as easy as grabbing the jar
but it would be cool to be able to integrate some of the eclipse
plugins (GEF, GEM etc).
I did some digging on Felix and it seems to be an old impl that is
being migrated to Apache. I could not tell for sure.
My $0.02 worth.
TTFN,
-bd-
On Jul 25, 2006, at 12: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:14:33 EDT