Kevin,
Thanks for answer. Ok, so the situation looks exactly how Bill
presented it before - if we want something simple that works - we use
Platonos, if we want to invest time in the Modeler-as-platform, we
use an OSGi engine.
Considering what I've seen so far my vote is to stay simple, leaving
OSGi implementation to the "revolutionaries" [1] :-)
Andrus
[1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
On Jul 27, 2006, at 12:47 PM, Kevin Duffey wrote:
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.
