I believe it makes sense to tell a module that it is going to be used or that it is used no more. Of course, I prefer [[Declarative Programming]], but sometimes there is just no other way and some parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!

I believe it makes sense to tell a module that it is going to be used or that it is used no more. Of course, I prefer [[Declarative Programming]], but sometimes there is just no other way and some parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!

That would be a dangerous situation. It would mean one cannot put any initialization logic into the ''activator/installer'' at all. Peter Kriens spent significant amount of his time and patience to explain me the rationale behind this behavior and possible fix:

That would be a dangerous situation. It would mean one cannot put any initialization logic into the ''activator/installer'' at all. [[Peter Kriens]] spent significant amount of his time and patience to explain me the rationale behind this behavior and possible fix:

# Just add '''Activation-Policy: lazy''' into your bundle which performs important initialization in ''BundleActivator'' and it is guaranteed that as soon as somebody loads a class from your bundle, it is going to be started

# Just add '''Activation-Policy: lazy''' into your bundle which performs important initialization in ''BundleActivator'' and it is guaranteed that as soon as somebody loads a class from your bundle, it is going to be started

# This is not the default to keep things backward compatible - OK, I can understand the value of [[BackwardCompatibility]]. Through at this case it might have been better to change the semantics when the [[PropertyFiles|bundle manifest version]] was changed to two (or change it to three). The [[NetBeans]] {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''use'' a module (by having a [[dependency]] on it and trying to get enabled). Although it is recommended to use [[Declarative Programming|declarative registrations]], when ''activator/installer'' is present calling it as soon as the bundle is being ''used'' is the natural/expected behavior.

# This is not the default to keep things backward compatible - OK, I can understand the value of [[BackwardCompatibility]]. Through at this case it might have been better to change the semantics when the [[PropertyFiles|bundle manifest version]] was changed to two (or change it to three). The [[NetBeans]] {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''use'' a module (by having a [[dependency]] on it and trying to get enabled). Although it is recommended to use [[Declarative Programming|declarative registrations]], when ''activator/installer'' is present calling it as soon as the bundle is being ''used'' is the natural/expected behavior.

=== Start/Stop a Bundle ===

=== Start/Stop a Bundle ===

I believe it make sense to tell a module that it is going to be used or that it is no longer being used. Of course, I'd prefer [[Declarative Programming]], but sometimes there is just no other way and some parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!

I believe it makes sense to tell a module that it is going to be used or that it is used no more. Of course, I prefer [[Declarative Programming]], but sometimes there is just no other way and some parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!

What kind of crazy idea is that? It basically means I cannot put any initialization logic into the ''activator/installer'' at all. I need to be ready for somebody using my module without starting me! I really don't get the purpose of this construct at all. The [[NetBeans]] {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''enable'' a module, or ''use it'' (by having a [[dependency]] on it and trying to get enabled). This sounds logical to me.

That would be a dangerous situation. It would mean one cannot put any initialization logic into the ''activator/installer'' at all. Peter Kriens spent significant amount of his time and patience to explain me the rationale behind this behavior and possible fix:

# Just add '''Activation-Policy: lazy''' into your bundle which performs important initialization in ''BundleActivator'' and it is guaranteed that as soon as somebody loads a class from your bundle, it is going to be started

# This is not the default to keep things backward compatible - OK, I can understand the value of [[BackwardCompatibility]]. Through at this case it might have been better to change the semantics when the [[PropertyFiles|bundle manifest version]] was changed to two (or change it to three). The [[NetBeans]] {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''use'' a module (by having a [[dependency]] on it and trying to get enabled). Although it is recommended to use [[Declarative Programming|declarative registrations]], when ''activator/installer'' is present calling it as soon as the bundle is being ''used'' is the natural/expected behavior.

# Peter (as far as I understand) rather advocates splitting the [[API]] and the implementation into separate bundles however. The service should rather be registered by independent implementation. I still don't know how my code using the [[API]] will force the system to initialize the implementation too, but I expect the answer to be [[OSGi]] ''declarative services'' (which I am not familiar with).

Obviously these misconceptions complicate the [[OSGiAndNetBeans]] bridge. Basically it means there is no 1:1 mapping between ''enabling'' a module in the [[NetBeans]] sense and ''starting'' a bundle in the [[OSGi]] sense. As we discover more and more [[OSGi]] based systems (like [[JDeveloper]]), we need to add more and more flexibility to cover all the possible ways people deal with the dichotomy between ''used'' and ''started''. [[OSGi]] is more flexible, but not logical.

Possibly [[Eclipse]] is using [[OSGi]] in wrong way. The [[singleton]] initialization in activator complicates the [[OSGiAndNetBeans]] bridge. Basically it means we don't have 1:1 mapping between ''enabling'' a module in the [[NetBeans]] sense and ''starting'' a bundle in the [[OSGi]] sense. As we discover more and more [[OSGi]] based systems (like [[JDeveloper]]), we need to add more and more flexibility to cover all the possible ways people deal with the dichotomy between ''used'' and ''started''. [[OSGi]] is very flexible and people tend to use it in many ''innovative'' ways.

 

=== Stopping Order ===

=== Stopping Order ===

On the other hand, this is not complete fault of [[RangeDependencies]]. [[RangeDependenciesAnalysed|Recent analysis]] shows that it depends how the [[RangeDependencies]] are used. If they are used properly, the [[NP-Complete]] problems can be eliminated.

On the other hand, this is not complete fault of [[RangeDependencies]]. [[RangeDependenciesAnalysed|Recent analysis]] shows that it depends how the [[RangeDependencies]] are used. If they are used properly, the [[NP-Complete]] problems can be eliminated.

Looking from this point of view: [[OSGi]] high shot (decision to use powerful [[dependency]] system) missed the sweet spot (produced underspecified system with corners full of bad consequences).

Looking from this point of view: [[OSGi]]'s high shot (decision to use powerful [[dependency]] system) missed the sweet spot (produced underspecified system with corners full of bad consequences).

== Executive Summary ==

== Executive Summary ==

=== Range Dependencies ===

=== Range Dependencies ===

One of characteristics of [[OSGi]] is use of [[RangeDependencies]] which seems like a clever good idea supporting [[cluelessness]] in its way, but if not done properly it is just a way to mess around with [[NP-Complete]] problems. And yes, there are such problems in [[OSGi]] as demonstrated by [[Equinox]] coming with a [[3SAT]] solver.

One of the characteristics of [[OSGi]] is use of [[RangeDependencies]] which seems like a clever good idea supporting [[cluelessness]] in its way, but if not done properly it is just a way to mess around with [[NP-Complete]] problems. And yes, there are such problems in [[OSGi]] as demonstrated by [[Equinox]] coming with a [[3SAT]] solver.

On the other hand, this is not complete fault of [[RangeDependencies]]. [[RangeDependenciesAnalysed|Recent analysis]] shows that it depends how the [[RangeDependencies]] are used. If they are used properly, the [[NP-Complete]] problems can be eliminated.

On the other hand, this is not complete fault of [[RangeDependencies]]. [[RangeDependenciesAnalysed|Recent analysis]] shows that it depends how the [[RangeDependencies]] are used. If they are used properly, the [[NP-Complete]] problems can be eliminated.

Looking from this point of view: [[OSGi]] shooted high (decided to use powerful [[dependency]] system), but missed the sweet spot (produced underspecified system with corners full of bad consequences).

Looking from this point of view: [[OSGi]] high shot (decision to use powerful [[dependency]] system) missed the sweet spot (produced underspecified system with corners full of bad consequences).

== Executive Summary ==

== Executive Summary ==

=== Range Dependencies ===

=== Range Dependencies ===

One of characteristics of [[OSGi]] is use of [[RangeDependencies]] which seems like a clever good idea supporting [[cluelessness]] in its way, but at the end it is just a way to [[NP-Complete]] problems. An example when simple, less powerful systems would be more effective. Looking from this point of view: [[OSGi]] is over designed.

One of characteristics of [[OSGi]] is use of [[RangeDependencies]] which seems like a clever good idea supporting [[cluelessness]] in its way, but if not done properly it is just a way to mess around with [[NP-Complete]] problems. And yes, there are such problems in [[OSGi]] as demonstrated by [[Equinox]] coming with a [[3SAT]] solver.

 

On the other hand, this is not complete fault of [[RangeDependencies]]. [[RangeDependenciesAnalysed|Recent analysis]] shows that it depends how the [[RangeDependencies]] are used. If they are used properly, the [[NP-Complete]] problems can be eliminated.

 

Looking from this point of view: [[OSGi]] shooted high (decided to use powerful [[dependency]] system), but missed the sweet spot (produced underspecified system with corners full of bad consequences).

== Executive Summary ==

== Executive Summary ==

<comments/>

<comments/>

=== Start/Stop a Bundle ===

=== Start/Stop a Bundle ===

I believe it make sense to tell a module that it is going to be used or that it is no longer being used. Of course, I'd prefer [[Declarative Programming]], but sometimes there is just no other way of solving the problem that parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!

I believe it make sense to tell a module that it is going to be used or that it is no longer being used. Of course, I'd prefer [[Declarative Programming]], but sometimes there is just no other way and some parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!

What kind of crazy idea is that? It basically means I cannot put any initialization logic into the ''activator/installer'' at all. I need to be ready for somebody using my module without starting me! I really don't get the purpose of this construct at all. The [[NetBeans]] {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''enable'' a module, or ''use it'' (by having a [[dependency]] on it and trying to get enabled). This sounds logical to me.

What kind of crazy idea is that? It basically means I cannot put any initialization logic into the ''activator/installer'' at all. I need to be ready for somebody using my module without starting me! I really don't get the purpose of this construct at all. The [[NetBeans]] {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''enable'' a module, or ''use it'' (by having a [[dependency]] on it and trying to get enabled). This sounds logical to me.

=== Start/Stop a Bundle ===

=== Start/Stop a Bundle ===

I believe it make sense to tell a module that it is going to be used or it is used no longer. Of course, I'd rather preffer [[Declarative Programming]], but sometimes there is just no way around. Parts of infrastructure need to be turned on programmatically. Thus it is makes sense to have a '''BundleActivator''' or {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} (in the [[NetBeans]] case). However then one finds out that people can use an [[OSGi]] bundle without starting it!

I believe it make sense to tell a module that it is going to be used or that it is no longer being used. Of course, I'd prefer [[Declarative Programming]], but sometimes there is just no other way of solving the problem that parts of the infrastructure need to be turned on programmatically. Thus, it is makes sense to have a '''BundleActivator''' or {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} (in the [[NetBeans]] case). However, then one finds that people can use an [[OSGi]] bundle without starting it!

What kind of crazy idea is that? It basically means I cannot put any initialization logic into the ''activator/installer'' at all. I need to be ready for somebody using my module without starting me! I really don't get the purpose of this construct at all. The [[NetBeans]] {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''enable'' a module, or ''use it'' (by having a [[dependency]] on it and trying to get enabled). This sounds logical to me.

What kind of crazy idea is that? It basically means I cannot put any initialization logic into the ''activator/installer'' at all. I need to be ready for somebody using my module without starting me! I really don't get the purpose of this construct at all. The [[NetBeans]] {{NB|org-openide-modules|org/openide/modules|ModuleInstall}} is guaranteed to be called whenever somebody tries to ''enable'' a module, or ''use it'' (by having a [[dependency]] on it and trying to get enabled). This sounds logical to me.

== [[OSGi]] Weirdness ==

== [[OSGi]] Weirdness ==

[[OSGi]] and [[NetBeans Runtime Container]] are similar, however the devil lies, as always, in the details! From time to time I manage to learn more about [[OSGi]] and then I just cannot help wondering what was the motivation behind designing such behavior! Maybe this is all caused by my preoccupation (as a designer of the [[NetBeans]] system), but I just cannot overcome the feeling that certain design decisions in [[OSGi]] are just weird.

[[OSGi]] and [[NetBeans Runtime Container]] are similar, however the devil lies, as always, in the details! From time to time I manage to learn more about [[OSGi]] and then I just cannot help but wonder what the motivation was behind designing such behavior! Maybe this is all caused by my preoccupation (as a designer of the [[NetBeans]] system), but I just cannot overcome the feeling that certain design decisions in [[OSGi]] are just weird.

I'll nitpick on [[OSGi]] here, hoping somebody will be able to explain the history and possibly also the rationale behind these (mis)behaviors.

I'll nitpick on [[OSGi]] here, hoping somebody will be able to explain the history and possibly also the rationale behind these (mis)behaviors.

== [[OSGi]] Weirdness ==

== [[OSGi]] Weirdness ==

[[OSGi]] and [[NetBeans Runtime Container]] are similar, however the devil lies, as always, in the details! From time to time I manage to learn more about [[OSGi]] and then I just cannot help wondering what was the motivation to design such behavior! Maybe this is all caused by my preoccupation (as a designer of the [[NetBeans]] system), but I just cannot overcome the feeling that certain design decisions in [[OSGi]] are just weird.

[[OSGi]] and [[NetBeans Runtime Container]] are similar, however the devil lies, as always, in the details! From time to time I manage to learn more about [[OSGi]] and then I just cannot help wondering what was the motivation behind designing such behavior! Maybe this is all caused by my preoccupation (as a designer of the [[NetBeans]] system), but I just cannot overcome the feeling that certain design decisions in [[OSGi]] are just weird.

I'll nitpick on [[OSGi]] here, hoping somebody will be able to explain the history and possibly also the rationale behind these (mis)behaviors.

I'll nitpick on [[OSGi]] here, hoping somebody will be able to explain the history and possibly also the rationale behind these (mis)behaviors.