1. Is Eclipse OSGi-compatible now, or is this just a future goal? For
instance does it mean that if we write an OSGi Modeler plugin, can we
deploy it in Eclipse, even if it is a separate Swing frame?
Eclipse is an implementation of OSGi, but not a full implementation at least as of 3.1. Not sure if 3.2 brought it into full OSGi compliance, and if so, what version. I think OSGi v3 was released not too long ago while v4 is being worked on? The thing is, Eclipse, being so well supported, will indeed progress with more OSGi support, and is part of the consortium of OSGi I believe. This would mean that IF you wanted to use OSGi, I would say use the Eclipse plugin engine in its headless form. It is a bit more complicated to use than our engine, but you do gain OSGi and some other things that our engine will never be. I do not know the size of the Eclipse OSGi plugin engine, but I am guessing it's not too small.
2. What are the core differences between OSGI and Platonos (and
corollary to that - is it possible to make Platonos a tight subset of
OSGi, or are they totally incompatible).
I am not an expert on OSGi, but OSGi as I recall allows for "bundles" where you generally place the plugin info in the manifest, its distributed as a .jar file, and so forth. Eclipse as I recall as of the 3.2 milestones was still allowing you to use plugin.xml to interconnect plugins, but was preferring to use the OSGi bundle/manifest format over their older plugin.xml.
First off, with our engine we were not aiming to be an OSGi compatible engine primarily because of size, but also because our goal was to make something capable but simple. The Eclipse engine in the 2.x days (and probably prior) was genious. The notion of extension points and extensions was easy to grasp, and was a simple, effective yet powerful way to easily add dynamic plugins to an application of any type. I had worked on a couple of incarnations prior that were "similar" but never had a clear way of intersecting and making use of other plugins.
We feel that our engine is very simple to use, yet offers similar flexibilities and power that the present OSGi compatible engines do. It takes nothing at all to copy/past a plugin.xml, and a few minutes to fill it out, as well as copy the base plugin lifecycle class (if you need one) and boom, you got a plugin. The same could probably be said for OSGi bundles, but my point is, its very simple to get going. Again our emphasis was on a small library that was effective and easy to use. I think we have established that. We have dozens of projects out there using our 1.0 engine, and others that started to use ours and went to Eclipse primarily for its RCP being ready to use.
So, just to be clear, while Evert and I would love for you to use our engine and we believe within an hour or less you could be off and writing plugins for your app, we are not going to throw a fit if you decide otherwise. I just want to present to you as much as possible reasons you may decide to use our engine. Plus, we do answer emails quite quickly thus support the engine, and the work on the 2.0 engine is still going on, so we haven't abandoned the project, just not working on it as much these days due to time constraints with family/jobs. If you choose the Eclipse route, you'll get help on the Eclipse forums, but I am willing to bet it will be more complicated to get it integrated and learn the OSGi plugin format and such. It sounds like Felix is not really a good option if you ask me, given its status.
Keep the questions coming, happy to answer. :)
Thanks.
---------------------------------
Groups are talking. We´re listening. Check out the handy changes to Yahoo! Groups.
This archive was generated by hypermail 2.0.0 : Thu Jul 27 2006 - 12:48:15 EDT