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.

Bug 185291 - NbModuleSuite.Configuration enables too many modules
Summary: NbModuleSuite.Configuration enables too many modules
Alias: None
Product: platform
Classification: Unclassified
Component: NB JUnit (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 normal (vote)
Assignee: Jaroslav Tulach
: 197719 (view as bug list)
Depends on:
Blocks: 197719
  Show dependency tree
Reported: 2010-04-29 22:11 UTC by tomwheeler
Modified: 2011-11-14 15:44 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

minimal suite which demonstrates the problem (70.79 KB, application/x-zip)
2010-04-29 22:11 UTC, tomwheeler
a second demo suite (28.95 KB, application/zip)
2010-09-19 12:17 UTC, alibabashack
new demo with fixed test (25.86 KB, application/zip)
2011-01-21 21:23 UTC, alibabashack
hideExtraModules(true) (19.14 KB, patch)
2011-11-04 12:27 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description tomwheeler 2010-04-29 22:11:39 UTC
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.
Comment 1 Jaroslav Tulach 2010-05-06 09:22:52 UTC
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.
Comment 2 betasheet23 2010-09-16 18:58:07 UTC
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 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.
Comment 3 Jaroslav Tulach 2010-09-18 13:39:28 UTC
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.
Comment 4 alibabashack 2010-09-19 12:17:35 UTC
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.
Comment 5 Jaroslav Tulach 2010-11-08 09:53:43 UTC
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;

public class NewJUnitTest extends NbTestCase{

    public NewJUnitTest(String 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.
Comment 6 alibabashack 2011-01-21 21:23:38 UTC
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.
Comment 7 Jaroslav Tulach 2011-01-31 20:55:47 UTC
OK, I can see the problem now.
Comment 8 Jaroslav Tulach 2011-11-04 12:27:13 UTC
Created attachment 112832 [details]

If you use the new method, only your window manager will be enabled.
Comment 9 Jaroslav Tulach 2011-11-04 12:28:52 UTC
Test, comment and remind me to integrate next week before 7.1 is code frozen.
Comment 10 Jaroslav Tulach 2011-11-04 12:30:28 UTC
*** Bug 197719 has been marked as a duplicate of this bug. ***
Comment 11 Jesse Glick 2011-11-04 20:34:40 UTC
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

    <version>SNAPSHOT</version> <!-- (patched) -->


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 201111030600]
	org.netbeans.libs.junit4 [1.14 201111031841]
	org.netbeans.modules.nbjunit/1 [1.72 20111104-9dff038e54c8] [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>

I tried

diff --git a/nbjunit/src/org/netbeans/junit/ b/nbjunit/src/org/netbeans/junit/
--- a/nbjunit/src/org/netbeans/junit/
+++ b/nbjunit/src/org/netbeans/junit/
@@ -1193,9 +1193,12 @@
                 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.
Comment 12 Jaroslav Tulach 2011-11-07 08:14:04 UTC
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 are enabled, as they are nothing "extra".

Good to know this bug is not particulary important for maven usecase.
Comment 13 Jesse Glick 2011-11-07 14:46:32 UTC
So the new method is useless under Maven? If so, please document that fact.
Comment 14 Jaroslav Tulach 2011-11-07 19:59:21 UTC
It is not completely useless, it could be useful in combination with enableClassPathModules(false).
Comment 15 Jesse Glick 2011-11-07 22:00:40 UTC
(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:


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/ using NbModuleSuite, turn off Compile on Save for tests, and run it using Test File or Test Project.
Comment 16 Jaroslav Tulach 2011-11-10 08:26:01 UTC
OK, I'll mention that and integrate tomorrow.
Comment 17 Jaroslav Tulach 2011-11-11 08:58:13 UTC
Comment 18 Quality Engineering 2011-11-14 15:44:00 UTC
Integrated into 'main-golden', will be available in build *201111140600* on (upload may still be in progress)
User: Jaroslav Tulach <>
Log: #185291: hideExtraModules(boolean)