This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
We are developing a Netbeans RCP application that includes NB modules, and OSGi modules. Focus of the problem is within the OSGi bundles. So I will explain about the details with the OSGi bundles. In this RCP application, OSGi bundles are formed as Netbeans clusters. And these clusters are included in Netbeans Platform application. Everything is okay until now. We can run OSGi bundles in Netbeans platform app with success. But, when we try to untick a specific OSGi bundle in included cluster( in Netbeans Platform App project ), Netbeans platform application does not simply turns off the OSGi module. It still continues to load it with application. When the same action is done with a Netbeans module(not an OSGi bundle), this problem does not occur, simply module is disabled and unloaded. We have tried cleaning cache, suite build etc.. But no success. I have to mention also that OSGi declarative services are used( one of the possible suspects also )
- Developed Netbeans Platform App - Cluster1 - NetbeansModule1 [ Enabled ] - NetbeansModule2 [ Enabled ] - Cluster2 - OSGiModule1 [ Enabled ] - OSGiModule2 [ Disabled ] ..... In this scenario, OSGiModule2 is still loaded when application starts. Note : OSGi declarative services are used in this scenario
This case is also valid for Netbeans 7.4
To reduce the load on our side, I would expect you to provide sample that reproduces the problem. I don't even know if you are using Ant or Maven to build your application and, honestly, I don't want to spend my time finding that out. Come up with sample project and reopen.
Created attachment 142796 [details] Zipped project files for test case
As in the following attachment, i deliver sample project file for testing bug. Scenario is described below in terms of attached projects : "SamplePlatformApp" includes a "UsingModule" OSGi project to consume implementations of an interface("ProviderInterface" module) provided by other OSGi bundles("ProviderSuite1" and "ProviderSuite2"). "ProviderInterface, "ProviderSuite1" and "ProviderSuite2" is placed under another suite named as "OSGiSuite". And "SamplePlatformApp" uses this suite for including implementations. The bug here is that even if ProviderSuite1 or ProviderSuite2 is disabled via "Properties->Libraries" section of the "SamplePlatformApp" they are still loaded and executed. This can be simply verified by System.out code in ConsumerClass.java
All this samples and explanations should be enough for providing a robust ground for solving the bug...
If I correctly understand the problem, then when running SamplePlatformApp, both services are found: DEBUG: WIRE: Service added:com.test.providersuite1.ImplementationProvider1@1b47245 Service added:com.test.providersuite2.ImplementationProvider2@ef6611 while only the first one should be. However if I do "Package as/Build ZIP" then the behavior is correct: DEBUG: WIRE: Service added:com.test.providersuite1.ImplementationProvider1@6c71f5 so the report is "only" about the development build enabling more than necessary. I believe this is more "fault" of apisupport, then module system. Passing to apisupport. The difference is that in the final ZIP there is just: ./OSGiSuite/config/Modules ./OSGiSuite/config/Modules/com-test-providersutie1.xml ./OSGiSuite/config/Modules/com-test-providedinterface.xml while in the prepackage application one can also see: OSGiSuite/build/cluster/config/Modules OSGiSuite/build/cluster/config/Modules/com-test-providersutie1.xml OSGiSuite/build/cluster/config/Modules/com-test-providedinterface.xml OSGiSuite/build/cluster/config/Modules/com-test-providersuite2.xml there should be a hidden file for the OSGi bundle: SamplePlatformApp/bld/cluster/config/Modules/com-test-providersuite2.xml_hidden but it is missing. There are others, but only for regular modules: SamplePlatformApp/bld/cluster/config/Modules/org-jdesktop-layout.xml_hidden The problem is likely in nbbuild/**/ModuleSelector.java
ergonomics#761830dab9f5
(In reply to Jaroslav Tulach from comment #7) Problem is correctly understood. But i didn't check that packaged version correctly eliminates unticked modules. It will be also good to see that it is only a development problem. But why bug's state seems as resolved. Is it actually ? > If I correctly understand the problem, then when running SamplePlatformApp, > both services are found: > > DEBUG: WIRE: > Service added:com.test.providersuite1.ImplementationProvider1@1b47245 > Service added:com.test.providersuite2.ImplementationProvider2@ef6611 > > while only the first one should be. However if I do "Package as/Build ZIP" > then the behavior is correct: > > DEBUG: WIRE: > Service added:com.test.providersuite1.ImplementationProvider1@6c71f5 > > so the report is "only" about the development build enabling more than > necessary. I believe this is more "fault" of apisupport, then module system. > Passing to apisupport. The difference is that in the final ZIP there is just: > > ./OSGiSuite/config/Modules > ./OSGiSuite/config/Modules/com-test-providersutie1.xml > ./OSGiSuite/config/Modules/com-test-providedinterface.xml > > while in the prepackage application one can also see: > > OSGiSuite/build/cluster/config/Modules > OSGiSuite/build/cluster/config/Modules/com-test-providersutie1.xml > OSGiSuite/build/cluster/config/Modules/com-test-providedinterface.xml > OSGiSuite/build/cluster/config/Modules/com-test-providersuite2.xml > > there should be a hidden file for the OSGi bundle: > > SamplePlatformApp/bld/cluster/config/Modules/com-test-providersuite2. > xml_hidden > > but it is missing. There are others, but only for regular modules: > > SamplePlatformApp/bld/cluster/config/Modules/org-jdesktop-layout.xml_hidden > > The problem is likely in nbbuild/**/ModuleSelector.java
> But why bug's state seems as resolved. Is it actually ? Yes, it is. You just need the 761830dab9f5 changeset. Wait for an automatic message to be inserted here if you want to download binary bits. Given the overall stability of builds I would expect the change to be propagated by end of this year.
Had to refine the fix in 5671da4a3536, but it should still work for the previous case.
Ok thanks for the information