JaroslavTulach at 10:36, 7 June 2013 - 2013-06-07 10:36:43

←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 - 2010-07-13 09:30:12

←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 - 2010-07-13 07:10:18

←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 - 2010-05-07 07:53:42

←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 - 2010-02-03 07:25:52

←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 - 2009-10-12 10:59:29

←Older revision Revision as of 10:59, 12 October 2009
Line 18: Line 18:
<comments/>
<comments/>
 +
 +
{{:Talk:Equinox}}

JaroslavTulach: /* Equinox is not OSGi Framework */ - 2009-10-06 07:33:42

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 */ - 2009-10-06 07:32:24

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 */ - 2009-10-04 19:57:33

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 - 2009-10-04 19:57:17

←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]].