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.
