[news.eclipse.technology.equinox] Re: OSGi?

["Kevin" <kduffey@xxxxxxxxxxxxx>]

Hell, why we are at it we should use my engine! It is similar to Eclipse,
only that it unloads, reloads, and handle dependency reloading, along with
the ability to look up plugins at runtime, activate them as needed, etc.
Plus, at its core including xml parser its only 50K or so. So it could be a
candidate for J2ME. I am confused, is this Equinox to be built on Eclipse? I
am not sure how OSGi comes into the picture if this project is to build upon
Eclipse. Seems to me OSGi and Eclipse are now vying for the same space. At
least my engine is completely generic for any purpose. :D It's not quite as
robust, but does pretty much the same thing.


"ted stockwell" <ted.stockwell@xxxxxxxxxx> wrote in message
news:b390gp$h5t$1@xxxxxxxxxxxxxxxx
> Hi All,
>
> First, I think that Equinox is a very timely and needed effort.
>
> When I read the description of what the Equinox project is intended to
> deliver I immediately thought of OSGi (http://www.osgi.org for those not
> familiar with it).
> It seems to me that the OSGi specification already covers all of the
desired
> functionality in spades...
>
> ...Dynamic plug-ins - OSGi's got it.  Bundles can be installed, loaded,
> started, stopped, unloaded and uninstalled all without stopping the
server.
> ...Component management  - OSGi's got it.  OSGi provides a facility for
> controlling access to code based on who is trying to run the code.  OSGi
> doesn't have anything equivalent to extension-points and extensions but
> Eclipse covers that.
> ...Dependency management  - OSGi's got it.  Dependencies are nicely
managed
> through manifest files.  If I remember correctly there is also a way to
> query for dependencies at runtime.  This doesn't reduce dependency chains
> but it provides a facility for managing them.
> ...Services model -  OSGi's got it, big time.  Interface based services.
> Attribute based Service lookup, etc.
>
> I can imagine an OSGi plugin for Eclipse that provides an OSGi
compatibility
> layer on top of the Eclipse core runtime.  The OSGi plugin could define
> extension points that enable plugins to register OSGi bundles with the
OSGi
> server.  The OSGi plugin could also provide a GUI facility for managing
OSGi
> bundles.  And of course the OSGi plugin would implement the core OSGi
> interfaces.  Strict compliance to the OSGi model could be abandoned when
> convenient.  For instance, I'll bet that it would be more convenient to
> always wrap OSGi bundles in plugins and use the Eclipse Update facility
> instead of implementing the standard OSGi update facility.
>
> Once upon a time I built an open source OSGi 1.0 server,
> http://servicetango.sf.net.  I would be very excited about helping to
build
> such a compatibility layer for Eclipse.
>
> Is there is any reason for not adopting OSGi as the solution to the
problems
> that you want to solve?
> I think that you should immediately consider whether OSGi provides the
> solution to the problems that you want to solve.  Is so, then we can
> immediately get to work to implement the solution!
>
> ted stockwell
> jlense.sf.net
>
>