'. '

Talk:Equinox

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Comment provided by Netigso - via ArticleComments extension)
(Comment provided by Alex Blewitt - via ArticleComments extension)
Line 10: Line 10:
--Netigso 17:56, 5 October 2009 (CEST)
--Netigso 17:56, 5 October 2009 (CEST)
 +
</div>
 +
== Alex Blewitt said ... ==
 +
 +
<div class='commentBlock'>
 +
Actually, most of this post is a fabrication. Equinox is an OSGi framework, as evidenced by the fact that it passes the OSGi TCK, without which it couldn't be called an OSGi framework. So the assertion that 'equinox is not an OSGi framework' is incorrect.
 +
 +
It does highlight something that people often get confused by; OSGi is not meant to be an exclusive specification of 'you can only use this'. It's supposed to be *modular*. And as such, you can add modules to bring your own functionality on top of any system; you're not 'limited' in some arbitrary way to only use those modules as specified in the OSGi spec.
 +
 +
Equinox, by itself, is a standalone OSGi engine. The framework differs from Felix's implementation in that the console is bundled in the 'org.eclipse.osgi' framework bundle; whereas in Felix it's a separate engine.
 +
 +
But services like the extension registry are provided in their own bundle as a separate OSGi bundle. Just because the extension registry isn't defined in the OSGi core spec doesn't mean it's not OSGi - it's just another layer on top, much like the reference impl for remote services is handled by using different underlying bundles (e.g. ECF or SOAP).
 +
 +
Lastly, OSGi isn't a 'constraining' system which means that you are locked into precisely one way of working. In fact, until 4.2, there wasn't even a standard set of properties to bring up a framework; they were all non-standard properties in that way. At least that's starting to normalise.
 +
 +
--[http://alblue.blogspot.com Alex Blewitt] 12:11, 11 October 2009 (CEST)
</div>
</div>

Revision as of 10:11, 11 October 2009

Comments on Equinox <comments />


Netigso said ...

Hahahahahaha...Good one... "It seems to me..." Hahahahaha, and sad to see people like that.

--Netigso 17:56, 5 October 2009 (CEST)

Alex Blewitt said ...

Actually, most of this post is a fabrication. Equinox is an OSGi framework, as evidenced by the fact that it passes the OSGi TCK, without which it couldn't be called an OSGi framework. So the assertion that 'equinox is not an OSGi framework' is incorrect.

It does highlight something that people often get confused by; OSGi is not meant to be an exclusive specification of 'you can only use this'. It's supposed to be *modular*. And as such, you can add modules to bring your own functionality on top of any system; you're not 'limited' in some arbitrary way to only use those modules as specified in the OSGi spec.

Equinox, by itself, is a standalone OSGi engine. The framework differs from Felix's implementation in that the console is bundled in the 'org.eclipse.osgi' framework bundle; whereas in Felix it's a separate engine.

But services like the extension registry are provided in their own bundle as a separate OSGi bundle. Just because the extension registry isn't defined in the OSGi core spec doesn't mean it's not OSGi - it's just another layer on top, much like the reference impl for remote services is handled by using different underlying bundles (e.g. ECF or SOAP).

Lastly, OSGi isn't a 'constraining' system which means that you are locked into precisely one way of working. In fact, until 4.2, there wasn't even a standard set of properties to bring up a framework; they were all non-standard properties in that way. At least that's starting to normalise.

--Alex Blewitt 12:11, 11 October 2009 (CEST)

Personal tools
buy