Explore the possibility of loading NB modules, including at least the contents of the platform cluster as well as user-developed modules/bundles, in an OSGi container such as Felix. The container would handle all class loading and lifecycle management rather than the NB module system.
I plan to merge what I have so far into the trunk tomorrow so there will be something in M1 that people can play with and give feedback on. See the wiki page for details. I will try to keep the last section updated as I fix open issues, and at some point these ought to be turned into blocking issues in BZ.
Created attachment 93638 [details]
Initial implementation in trunk: core-main #2e8d6798bfc3
I can see there is just one general BundleActivator in core.netigso. This is good for future performance improvements and makes me happy.
(In reply to comment #5)
> This is good for future performance improvements
It may be. For now it is barely more efficient than an activator per module. I will however investigate whether the framework listener can be used to _reliably_ activate all modules in one step, even if all NB-related bundles are installed after the initial startup set.
Using a single activator unfortunately introduced a problem (listed in the issues section) that if you accidentally neglect to include core.netigso in the module set, nothing happens. I need to figure out how to cause all modules (at least all with layers and/or installers and/or URL handlers) to require core.netigso to be loaded, without using Import-Package. Perhaps Require-Bundle can work even with no exported packages, I will check.
Re. improvements. At least there is a way to turn on all normal module and only later start core.netigso. Then the core.netigso can verify its caches and use them. Thus one can configure its container to start effectively.
But if you change the dependencies, so every bundle depends on core.netigso, the above will be impossible again... I don't know what to do about that.
(In reply to comment #7)
> there is a way to turn on all normal module and only
> later start core.netigso.
Sure, if I can depend on bundles being activated at certain times then optimization is easy. For example, when running java felix.Main -b <bundledir>, I know what the sequence of events will be and could consolidate startup.
The problem is rather to ensure correct behavior for an arbitrary policy: bundles being activated in an unspecified order (as is permitted in the absence of a management agent using the Start Level service), during or after "framework start", some possibly much later than the rest. The intent is to support any deployment workflow without configuration.
Integrated into 'main-golden', will be available in build *201002040200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <email@example.com>
Log: Issue #179473: ability to run NB modules in an OSGi container.
(In reply to comment #8)
a. Any order of activation steps needs to result in correct behavior.
b. There needs to be at least one order of activation steps that will result in fast and effective behavior.