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

["dominic" <dominic@xxxxxxxxxx>]

This looks really promising. I hope it does not get moded down because of
the NIH virus. The plugins versioning of eclipse is really retarded it
reminds me of mfc days {remember mfc42,msvcrt6 ,gtk2 etc.. } that still
prevails these days. When are people going to understand that the major plus
of a component architecture lies in the *versioning*.
I was mulling over alternatives ways of doing components based in eclipse.
How do you solve components distributed by other applications ? for now
there is just no way one can discover/(re)use components shiped with other
applications. So much for components !

"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
>
>