Equinox - Revision history

JaroslavTulach at 10:36, 7 June 2013

JaroslavTulach — Fri, 07 Jun 2013 10:36:43 GMT

←Older revision		Revision as of 10:36, 7 June 2013
Line 20:		Line 20:

	{{:EquinoxCompatibility}}		{{:EquinoxCompatibility}}
-
-	~~<comments/>~~

	{{:Talk:Equinox}}		{{:Talk:Equinox}}
		+
		+	[[Category:OpenSourceContribution]]

JaroslavTulach at 09:30, 13 July 2010

JaroslavTulach — Tue, 13 Jul 2010 09:30:12 GMT

←Older revision		Revision as of 09:30, 13 July 2010
Line 1:		Line 1:
-	[[wikipedia::Equinox_OSGi\|Equinox]] is another implementation of [[OSGi]] specification. Can be used together with the [[NetBeans Runtime Container]] via the [[Netbinox]] subproject of the [[Netigso]] effort and it yields surprisingly [[NetbinoxTutorial\|good results]] (in spite [[BootstrappingEquinox\|Equinox not being ready]] for execution in modular environment).	+	[[wikipedia::Equinox_OSGi\|Equinox]] is another implementation of [[OSGi]] specification. Can be used together with the [[NetBeans Runtime Container]] via the [[Netbinox]] subproject of the [[Netigso]] effort and it yields surprisingly [[NetbinoxTutorial\|good results]] (in spite [[BootstrappingEquinox\|Equinox not being ready]] for execution in modular environment and has [[EquinoxCompatibility\|own compatibility]] problems).

	== Equinox is not [[OSGi]] Framework ==		== Equinox is not [[OSGi]] Framework ==

JaroslavTulach at 07:10, 13 July 2010

JaroslavTulach — Tue, 13 Jul 2010 07:10:18 GMT

←Older revision		Revision as of 07:10, 13 July 2010
Line 1:		Line 1:
	[[wikipedia::Equinox_OSGi\|Equinox]] is another implementation of [[OSGi]] specification. Can be used together with the [[NetBeans Runtime Container]] via the [[Netbinox]] subproject of the [[Netigso]] effort and it yields surprisingly [[NetbinoxTutorial\|good results]] (in spite [[BootstrappingEquinox\|Equinox not being ready]] for execution in modular environment).		[[wikipedia::Equinox_OSGi\|Equinox]] is another implementation of [[OSGi]] specification. Can be used together with the [[NetBeans Runtime Container]] via the [[Netbinox]] subproject of the [[Netigso]] effort and it yields surprisingly [[NetbinoxTutorial\|good results]] (in spite [[BootstrappingEquinox\|Equinox not being ready]] for execution in modular environment).
-

	== Equinox is not [[OSGi]] Framework ==		== Equinox is not [[OSGi]] Framework ==
Line 17:		Line 16:

	As a result [[Felix]] seems to be the right framework for those who start with modularity and want to be as close as possible to the [[OSGi]] specification ([[Glassfish]] comes to my mind). [[Equinox]] on the other hand is much more friendly to those who want to experiment with new technologies or already have some notion of modularity themselves and need to [[bridge]] it to [[OSGi]]. Just like I have to do in my [[Netbinox\|Netigso sub-project]].		As a result [[Felix]] seems to be the right framework for those who start with modularity and want to be as close as possible to the [[OSGi]] specification ([[Glassfish]] comes to my mind). [[Equinox]] on the other hand is much more friendly to those who want to experiment with new technologies or already have some notion of modularity themselves and need to [[bridge]] it to [[OSGi]]. Just like I have to do in my [[Netbinox\|Netigso sub-project]].
		+
		+	== Upgrading [[Equinox]] ==
		+
		+	{{:EquinoxCompatibility}}

	<comments/>		<comments/>

	{{:Talk:Equinox}}		{{:Talk:Equinox}}

JaroslavTulach at 07:53, 7 May 2010

JaroslavTulach — Fri, 07 May 2010 07:53:42 GMT

←Older revision		Revision as of 07:53, 7 May 2010
Line 1:		Line 1:
-	[[wikipedia::Equinox_OSGi\|Equinox]] is another implementation of [[OSGi]] specification. Can be used together with the [[NetBeans Runtime Container]] via the [[Netbinox]] subproject of the [[Netigso]] effort and it yields surprisingly [[NetbinoxTutorial\|good results]].	+	[[wikipedia::Equinox_OSGi\|Equinox]] is another implementation of [[OSGi]] specification. Can be used together with the [[NetBeans Runtime Container]] via the [[Netbinox]] subproject of the [[Netigso]] effort and it yields surprisingly [[NetbinoxTutorial\|good results]] (in spite [[BootstrappingEquinox\|Equinox not being ready]] for execution in modular environment).
		+

	== Equinox is not [[OSGi]] Framework ==		== Equinox is not [[OSGi]] Framework ==

JaroslavTulach at 07:25, 3 February 2010

JaroslavTulach — Wed, 03 Feb 2010 07:25:52 GMT

←Older revision		Revision as of 07:25, 3 February 2010
Line 1:		Line 1:
-	~~Another~~ implementation of [[OSGi]]. Can be ~~merged~~ with [[NetBeans Runtime Container]] via the [[Netigso]] ~~project~~ and it yields surprisingly [[~~Netbinox~~\|good results~~]]. Standard info at [[wikipedia::Equinox_OSGi~~]].	+	[[wikipedia::Equinox_OSGi\|Equinox]] is another implementation of [[OSGi]] specification. Can be used together with the [[NetBeans Runtime Container]] via the [[Netbinox]] subproject of the [[Netigso]] effort and it yields surprisingly [[NetbinoxTutorial\|good results]].

	== Equinox is not [[OSGi]] Framework ==		== Equinox is not [[OSGi]] Framework ==

JaroslavTulach at 10:59, 12 October 2009

JaroslavTulach — Mon, 12 Oct 2009 10:59:29 GMT

←Older revision		Revision as of 10:59, 12 October 2009
Line 18:		Line 18:

	<comments/>		<comments/>
		+
		+	{{:Talk:Equinox}}

JaroslavTulach: /* Equinox is not OSGi Framework */

JaroslavTulach — Tue, 06 Oct 2009 07:33:42 GMT

Equinox is not OSGi Framework

←Older revision		Revision as of 07:33, 6 October 2009
Line 15:		Line 15:
	It seems to me that [[Equinox]] is not by itself an [[OSGi]] container. It is prefabricate made for others (Eclipse & co.) to create their own [[OSGi]] containers. This is quite a different approach compared to the one taken by the [[Felix]]. While [[Felix]] adheres to the spec, avoiding ''containerisms'' as much as possible, majority of [[Equinox]] are various [[API]] extensions to tweak or enrich the standard [[OSGi]] behaviour.		It seems to me that [[Equinox]] is not by itself an [[OSGi]] container. It is prefabricate made for others (Eclipse & co.) to create their own [[OSGi]] containers. This is quite a different approach compared to the one taken by the [[Felix]]. While [[Felix]] adheres to the spec, avoiding ''containerisms'' as much as possible, majority of [[Equinox]] are various [[API]] extensions to tweak or enrich the standard [[OSGi]] behaviour.

-	As a result [[Felix]] seems to be the right framework for those who start with modularity and want to be as close as possible to the [[OSGi]] specification (Glassfish comes to my mind). [[Equinox]] on the other hand is much more friendly to those who want to experiment with new technologies or already have some notion of modularity themselves and need to [[bridge]] it to [[OSGi]]. Just like I have to do in my [[Netbinox\|Netigso sub-project]].	+	As a result [[Felix]] seems to be the right framework for those who start with modularity and want to be as close as possible to the [[OSGi]] specification ([[Glassfish]] comes to my mind). [[Equinox]] on the other hand is much more friendly to those who want to experiment with new technologies or already have some notion of modularity themselves and need to [[bridge]] it to [[OSGi]]. Just like I have to do in my [[Netbinox\|Netigso sub-project]].

	<comments/>		<comments/>

JaroslavTulach: /* Equinox is not OSGi Framework */

JaroslavTulach — Tue, 06 Oct 2009 07:32:24 GMT

Equinox is not OSGi Framework

←Older revision		Revision as of 07:32, 6 October 2009
Line 11:		Line 11:
	Nevertheless, some people are asking for [[Equinox]] support in [[Netigso]]. I was a bit reluctant to start [[Netbinox\|such project]]. My attitude towards [[OSGi]] is still not through-fully positive and thus I thought support for one [[OSGi]] container is enough. But today was Friday, there was nothing better to do, so I gave [[Equinox]] a try.		Nevertheless, some people are asking for [[Equinox]] support in [[Netigso]]. I was a bit reluctant to start [[Netbinox\|such project]]. My attitude towards [[OSGi]] is still not through-fully positive and thus I thought support for one [[OSGi]] container is enough. But today was Friday, there was nothing better to do, so I gave [[Equinox]] a try.

-	It is amusing to look at different implementation of the same [[API]]! Both [[Felix]] and [[Equinox]] are supposed to work the same, yet both are coded in quite a different way. While [[Felix]] seems to adhere to [[OSGi]] spec as close as possible, the [[Equinox]] is full of additional abstractions and hooks exposed as [[API]] for integrators. As a result I seem to be able to [[Netbinox\|\|integrate]] [[Equinox]] into [[Netigso]] without any wild tricks (like using reflection). One of the available hooks is actually exactly what I need.	+	It is amusing to look at different implementation of the same [[API]]! Both [[Felix]] and [[Equinox]] are supposed to work the same, yet both are coded in quite a different way. While [[Felix]] seems to adhere to [[OSGi]] spec as close as possible, the [[Equinox]] is full of additional abstractions and hooks exposed as [[API]] for integrators. As a result I seem to be able to [[Netbinox\|integrate]] [[Equinox]] into [[Netigso]] without any wild tricks (like using reflection). One of the available hooks is actually exactly what I need.

	It seems to me that [[Equinox]] is not by itself an [[OSGi]] container. It is prefabricate made for others (Eclipse & co.) to create their own [[OSGi]] containers. This is quite a different approach compared to the one taken by the [[Felix]]. While [[Felix]] adheres to the spec, avoiding ''containerisms'' as much as possible, majority of [[Equinox]] are various [[API]] extensions to tweak or enrich the standard [[OSGi]] behaviour.		It seems to me that [[Equinox]] is not by itself an [[OSGi]] container. It is prefabricate made for others (Eclipse & co.) to create their own [[OSGi]] containers. This is quite a different approach compared to the one taken by the [[Felix]]. While [[Felix]] adheres to the spec, avoiding ''containerisms'' as much as possible, majority of [[Equinox]] are various [[API]] extensions to tweak or enrich the standard [[OSGi]] behaviour.

JaroslavTulach: /* Equinox is not OSGi Framework */

JaroslavTulach — Sun, 04 Oct 2009 19:57:33 GMT

Equinox is not OSGi Framework

←Older revision		Revision as of 19:57, 4 October 2009
Line 16:		Line 16:

	As a result [[Felix]] seems to be the right framework for those who start with modularity and want to be as close as possible to the [[OSGi]] specification (Glassfish comes to my mind). [[Equinox]] on the other hand is much more friendly to those who want to experiment with new technologies or already have some notion of modularity themselves and need to [[bridge]] it to [[OSGi]]. Just like I have to do in my [[Netbinox\|Netigso sub-project]].		As a result [[Felix]] seems to be the right framework for those who start with modularity and want to be as close as possible to the [[OSGi]] specification (Glassfish comes to my mind). [[Equinox]] on the other hand is much more friendly to those who want to experiment with new technologies or already have some notion of modularity themselves and need to [[bridge]] it to [[OSGi]]. Just like I have to do in my [[Netbinox\|Netigso sub-project]].
		+
		+	<comments/>

JaroslavTulach at 19:57, 4 October 2009

JaroslavTulach — Sun, 04 Oct 2009 19:57:17 GMT

←Older revision		Revision as of 19:57, 4 October 2009
Line 1:		Line 1:
-	Another implementation of [[OSGi]]. Can be merged with [[NetBeans Runtime Container]] via the [[Netigso]] project and it yields surprisingly [[Netbinox\|good results]].	+	Another implementation of [[OSGi]]. Can be merged with [[NetBeans Runtime Container]] via the [[Netigso]] project and it yields surprisingly [[Netbinox\|good results]]. Standard info at [[wikipedia::Equinox_OSGi]].

-	~~Standard info~~ at [[~~wikipedia::Equinox_OSGi~~]].	+	== Equinox is not [[OSGi]] Framework ==
		+
		+	Recently I have upgraded my [[Netigso]] project to [[Felix]] 2.0. It took a while
		+	as I needed to find new tricks to convince [[Felix]] to do classloading the way
		+	I like. I had this working in 1.4 version, but as this was done via reflection,
		+	which is obviously not a public [[API]] of [[Felix]], the new tricks were
		+	quite different than those used in 1.4 version.
		+
		+	Nevertheless, some people are asking for [[Equinox]] support in [[Netigso]]. I was a bit reluctant to start [[Netbinox\|such project]]. My attitude towards [[OSGi]] is still not through-fully positive and thus I thought support for one [[OSGi]] container is enough. But today was Friday, there was nothing better to do, so I gave [[Equinox]] a try.
		+
		+	It is amusing to look at different implementation of the same [[API]]! Both [[Felix]] and [[Equinox]] are supposed to work the same, yet both are coded in quite a different way. While [[Felix]] seems to adhere to [[OSGi]] spec as close as possible, the [[Equinox]] is full of additional abstractions and hooks exposed as [[API]] for integrators. As a result I seem to be able to [[Netbinox\|\|integrate]] [[Equinox]] into [[Netigso]] without any wild tricks (like using reflection). One of the available hooks is actually exactly what I need.
		+
		+	It seems to me that [[Equinox]] is not by itself an [[OSGi]] container. It is prefabricate made for others (Eclipse & co.) to create their own [[OSGi]] containers. This is quite a different approach compared to the one taken by the [[Felix]]. While [[Felix]] adheres to the spec, avoiding ''containerisms'' as much as possible, majority of [[Equinox]] are various [[API]] extensions to tweak or enrich the standard [[OSGi]] behaviour.
		+
		+	As a result [[Felix]] seems to be the right framework for those who start with modularity and want to be as close as possible to the [[OSGi]] specification (Glassfish comes to my mind). [[Equinox]] on the other hand is much more friendly to those who want to experiment with new technologies or already have some notion of modularity themselves and need to [[bridge]] it to [[OSGi]]. Just like I have to do in my [[Netbinox\|Netigso sub-project]].