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.
This archive was generated by hypermail 2.0.0 : Wed Jul 26 2006 - 07:49:35 EDT