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.
Created attachment 98307 [details] minimal suite which demonstrates the problem One of our platform application uses Web services and the specific implementation causes a conflict with the NetBeans JAXB library. The workaround for this is simply -- we just excluded NetBeans JAXB library from the suite. While this works fine at runtime, we've found that this library is still present when we execute functional tests, causing the application to fail under test even when it would succeed in production. In researching this problem further, I believe I am able to demonstrate that the NbModuleSuite.Configuration class loads more modules than it should. This could explain why JAXB is getting loaded during tests even when it should be excluded. The validation.OverallTest functional test of the Paint module in the attached suite project illustrates this. When I run the suite, the IDE's output window shows that 38 modules are loaded. The favorites module, as one example, is not among these modules as it is excluded from the suite. I defined the modules String in the OverallTest class as a regular expression which should match all the modules which are loaded when running the suite (the "favorites" module is also not in this list. Therefore, I should expect the same 38 modules to be loaded when I execute the test (plus the four modules listed in the Functional Test Libraries folder). When I run the OverallTest, the IDE's output window shows that 54 modules are loaded. I was not able to find any examples in the NetBeans codebase which defines a set of modules to load, so it's possible I just don't understand how it's supposed to work. In this case, I would appreciate knowing the correct way to exclude modules from being loaded in a functional test. I promise to document this in the Wiki so you should never be asked about this again.
The Configuration is not a builder pattern, but cumulative factory. As such you need to write testConfig = testConfig.addTest("testBrushSize", "testPainting"); not just testConfig.addTest("testBrushSize", "testPainting"); The above could help you eliminate the JaxWS module. Additional advice I can give is to use testConfig = testConfig.honorAutoloadEager(true); Which will for sure disable everything that is autoload and there are no dependencies on it. However favorites module is not autoload. For that there is no cure right now, as far as I know. Should that be a blocker for you, reopen. I could add disableModules(...) method to explicitly remove unneeded modules.
I do not believe that this is an invalid ticket. We've created a new own Platform Application which only depends on some of the NetBeans Platform modules (the Runtime Container plus only a litte more). The Application starts up well, if launched via Application->Run and only the required modules are loaded. Next, we created a sample test based on NB Junit using NbModuleSuite in order to run the test inside the environment of the application. When running that test (which basically does nothing but starting the testing environment), the whole platform cluster (e.g. including org.netbeans.core.windows) instead of only the required modules specified in the application's project properties dialog is started. (even if honor autoload is set to true) I would think that NbModuleSuite and associated Tests should be run in the environment specified by the application, whih makes be believe that this is a valid bug.
OK, in such case please create some small suite that demonstrates the problem. The current attachement is flawed as I pointed out in comment #1.
Created attachment 102071 [details] a second demo suite Attached a demo suite. On running it normaly only selected modules will be loaded. When running a test on some.module.test.NewTestSuite also the core packages from platform will be loaded.
Dear Alibaba, I guess you want me to execute the NewJUnitTest. I've simplified it to: package some.module.test; import java.util.Collection; import junit.framework.Assert; import org.netbeans.junit.NbTestCase; import org.openide.util.Lookup; import org.openide.windows.WindowManager; public class NewJUnitTest extends NbTestCase{ public NewJUnitTest(String s) { super(s); } public void testFramework() { final Collection<? extends WindowManager> arr = Lookup.getDefault().lookupAll(WindowManager.class); Assert.assertEquals("" + arr, 1, arr.size()); } } but as far as I can tell it fails with: Testcase: testFramework(some.module.test.NewJUnitTest): FAILED [] expected:<1> but was:<0> junit.framework.AssertionFailedError: [] expected:<1> but was:<0> You need to fix that, if you really want to reopen this bug.
Created attachment 105262 [details] new demo with fixed test Hi Jaroslav, of course you are right. The test und test suite must be one class. I changed it. The test failed with Testcase: testFramework(some.module.test.NewJUnitTest): FAILED [] expected:<1> but was:<0> junit.framework.AssertionFailedError: [] expected:<1> but was:<0> because the framework must be present to find the WindowManager. To load the framework I added public static junit.framework.Test suite() { Configuration config = NbModuleSuite.createConfiguration(NewJUnitTest.class); return NbModuleSuite.create(config); } to the test class, what does what I want now (I think). What I expect from the test: My WindowManager (interface is from Window System API) is implemented in the demo environment in module my.windowsys and is added to the lookup via @ServiceProvider annotation. The module Core - Windows in cluster platform contains the default WindowManager implemention. Because I do not want the default one to be loaded, I excluded this module from the project. My test just determines how many WindowManager classes are present in lookup. Because I excluded the default implementation I expect only my implemention there. Please run the test by clicking some.module -> test. The test succeeds, but the wrong WindowManager is in the lookup as you can see in the output of the test. Now please run the test by clicking Demo -> test all. The test fails with both implementations in lookup. Why does the default impl shows up although it is excluded? Why is my impl not available after the first procedure? I can't answer these questions. All this let me guess it's a bug.
OK, I can see the problem now.
Created attachment 112832 [details] hideExtraModules(true) If you use the new method, only your window manager will be enabled.
Test, comment and remind me to integrate next week before 7.1 is code frozen.
*** Bug 197719 has been marked as a duplicate of this bug. ***
Confirmed that patch makes test case from comment #6 work. After core-main #932333f59e08 plus patch I can finally get bug #197719 comment #0 to work, albeit with some difficulty: .clusters("ide").enableModules("platform", ".*").enableModules("ide", ".*javascript.*|.+diff|.+(modules|spi).editor(?!.kit).*|.+projectui|.+options.editor|.+jumpto|.+html.editor|.+css.editor").hideExtraModules(true) [JG01] Does not work from a Maven-based functional test that I can tell. Test case used <dependency> <groupId>org.netbeans.modules</groupId> <artifactId>org-netbeans-core-windows</artifactId> <version>SNAPSHOT</version> </dependency> <dependency> <groupId>org.netbeans.modules</groupId> <artifactId>org-netbeans-core-ui</artifactId> <version>SNAPSHOT</version> </dependency> <dependency> <groupId>org.netbeans.api</groupId> <artifactId>org-netbeans-modules-nbjunit</artifactId> <version>SNAPSHOT</version> <!-- (patched) --> <scope>test</scope> </dependency> and NbModuleSuite.createConfiguration(XTest.class).enableModules(".*", "NOTHING").hideExtraModules(true) yet enables everything: INFO [org.netbeans.core.startup.NbEvents]: Turning on modules: .... org.netbeans.core/2 [3.28 201111030600] org.netbeans.modules.options.api/1 [1.24 201111030600] org.netbeans.insane/1 [1.15.0.1 1 201111030600] org.netbeans.libs.junit4 [1.14 201111031841] org.netbeans.modules.nbjunit/1 [1.72 20111104-9dff038e54c8] org.netbeans.core.windows/2 [2.41 201111030600] org.netbeans.core.ui/1 [1.29 201111030600] From a debugger, the problem seems to be in disableModules; new File(new File(new File(ud, "config"), "Modules"), c.getName()) always exists, e.g. ---%<--- .../userdir0/config/Modules/org-netbeans-core-ui.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE ...> <module name="org.netbeans.core.ui"> <param name="autoload">false</param> <param name="eager">false</param> <param name="enabled">true</param> <param name="jar">.../org/netbeans/modules/org-netbeans-core-ui/SNAPSHOT/org-netbeans-core-ui-SNAPSHOT.jar</param> <param name="reloadable">false</param> </module> ---%<--- I tried diff --git a/nbjunit/src/org/netbeans/junit/NbModuleSuite.java b/nbjunit/src/org/netbeans/junit/NbModuleSuite.java --- a/nbjunit/src/org/netbeans/junit/NbModuleSuite.java +++ b/nbjunit/src/org/netbeans/junit/NbModuleSuite.java @@ -1193,9 +1193,12 @@ continue; } File udC = new File(new File(new File(ud, "config"), "Modules"), c.getName()); - if (!udC.exists()) { - File hidden = new File(udC.getParentFile(), c.getName() + "_hidden"); - hidden.createNewFile(); + if (udC.exists() && !udC.delete()) { + throw new IOException("Cannot delete " + udC); + } + File hidden = new File(udC.getParentFile(), c.getName() + "_hidden"); + if (!hidden.createNewFile()) { + throw new IOException("Cannot create " + hidden); } } } without success - then with .hideExtraModules(true), *all* regular modules are suppressed even if moduleRegExp is ".*" (core.startup and platform autoloads are loaded). Not surprising, since disableModules does not pay attention to the include list. I do not really grasp NbMS internals strongly enough to fix that. Note that implementing this feature for Maven-based apps is a much lower priority, since modules excluded from the app never appear to NbModuleSuite at all; in other words, the only use case would be for a test which wishes to turn off some modules which normally _are_ enabled in the app.
Re. JG01 - hideExtraModules does not hide anything that is on classpath, as those modules are by default enabled. Thus (if I understand the maven example) it is correct that core.ui and core.windows are enabled, as they are nothing "extra". Good to know this bug is not particulary important for maven usecase.
So the new method is useless under Maven? If so, please document that fact.
It is not completely useless, it could be useful in combination with enableClassPathModules(false).
(In reply to comment #14) > it could be useful in combination with enableClassPathModules(false) OK, probably this is what should be mentioned. I was able to get a subset of the Platform loaded in a test using the patched NbModuleSuite even in a Maven-based app declaring a dep on the whole org.netbeans.cluster:platform using the following suite expression: NbModuleSuite.createConfiguration(ApplicationTest.class). gui(true). hideExtraModules(true). enableModules("(?!org.netbeans.modules.autoupdate|org.netbeans.modules.core.kit|org.netbeans.modules.favorites).*"). enableClasspathModules(false). suite(); Tip: to test under Maven, create a new Maven > NetBeans Application, selecting SNAPSHOT for the version; Build with Dependencies. Edit application/pom.xml according to comments to enable a test dep on nbjunit and pass app & platform clusters to Surefire plugin; optionally also edit contents of app, e.g. removing dep on complete platform cluster and replacing with selected items. Run ant -f nbjunit/build.xml patch-for-maven. Create application/src/test/java/p/SomeTest.java using NbModuleSuite, turn off Compile on Save for tests, and run it using Test File or Test Project.
OK, I'll mention that and integrate tomorrow.
ergonomics#336ad8a2904c
Integrated into 'main-golden', will be available in build *201111140600* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/336ad8a2904c User: Jaroslav Tulach <jtulach@netbeans.org> Log: #185291: hideExtraModules(boolean)