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 199824

Summary: "Resolve" button present but disabled
Product: apisupport Reporter: Geertjan Wielenga <geertjan>
Component: ProjectAssignee: Martin Kozeny <mkozeny>
Status: NEW ---    
Severity: normal CC: javydreamercsw, jglick, jrechtacek
Priority: P4 Keywords: UI
Version: 7.0   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:

Description Geertjan Wielenga 2011-07-01 14:28:04 UTC
A class of 6 people, 3 <ac/Linux, 3 Windows 7. On Windows 7, the "Resolve" button in Project Properties of suite projects is visible but cannot be clicked. It is therefore impossible to resolve missing dependencies.
Comment 1 Jesse Glick 2011-07-01 14:56:12 UTC
Odd indeed. But I have no access to Windows 7 for testing. If you can debug it a bit and find out what the difference is from other platforms, I can suggest a fix.
Comment 2 Geertjan Wielenga 2011-07-01 15:06:04 UTC
Possibly it has something to do with Junit 4. The last resolve message is (we were doing an exercise with functional testing), strangely, code name base only, no display text:

"Module Jelly Tools Platform in harness depends on an unknown module named org.netbeans.libs.junit4"
Comment 3 Jesse Glick 2011-07-01 15:28:16 UTC
(In reply to comment #2)
> code name base only, no display text

If the module is not there, it is logically impossible to determine its display name.

> "Module Jelly Tools Platform in harness depends on an unknown module named
> org.netbeans.libs.junit4"

Meaning you neglected to install the "JUnit" plugin in the target platform.
Comment 4 Geertjan Wielenga 2011-07-01 18:02:52 UTC
But why Windows 7 only? Someone who was on Mac and switched to Windows 7 on VirtualBox had no problem on Mac, but encountered this problem on Windows 7 on VirtualBox.

And, whether or not JUnit is installed, surely the "Resolve" button's functioning should not depend on JUnit?
Comment 5 Jesse Glick 2011-07-01 18:10:30 UTC
(In reply to comment #4)
> But why Windows 7 only?

Possibly has nothing to do with the OS - you just happened to not install JUnit on the Windows 7 machine.

> whether or not JUnit is installed, surely the "Resolve" button's
> functioning should not depend on JUnit?

jellytools.* pseudomodules depend on libs.junit4, so if you include these in your app's cluster/module config (so they can be used in tests), then libs.junit4 must also be included. "Resolve" attempts to ensure that all dependencies of suite modules are in fact included, and it cannot do this if some of the transitive dependency closure is not physically present.
Comment 6 Geertjan Wielenga 2011-07-01 18:17:38 UTC
> But why Windows 7 only?

>>Possibly has nothing to do with the OS - you just happened to not install JUnit
>>on the Windows 7 machine.

All 4 Windows 7 machines didn't have it, while two Macs and a Linux happened to have it? Seems unlikely.

I've still not seen any explanation for why the "Resolve" button can not be clicked under the above conditions. I.e., you see the button, you move your mouse to it, but the button is disabled, and therefore you cannot click it.
Comment 7 Jesse Glick 2011-07-01 18:28:52 UTC
(In reply to comment #6)
> All 4 Windows 7 machines didn't have it, while two Macs and a Linux happened to
> have it? Seems unlikely.

This is something you can easily verify yourself rather than speculating.

> I've still not seen any explanation for why the "Resolve" button can not be
> clicked under the above conditions. I.e., you see the button, you move your
> mouse to it, but the button is disabled, and therefore you cannot click it.

The button is visible iff there are any problems to be fixed, and enabled iff the problems _can_ be fixed using the modules actually present in the platform.
Comment 8 Geertjan Wielenga 2011-07-01 18:46:59 UTC
From a user's point of view, isn't it strange to see a button (a red one at that) which cannot be clicked?
Comment 9 Jesse Glick 2011-07-01 19:08:42 UTC
The UI could probably be improved.
Comment 10 Jiri Rechtacek 2011-07-04 15:14:19 UTC
In my point of view it's not a stopper for NB701.
Comment 11 Geertjan Wielenga 2011-07-04 15:22:52 UTC
A big red button that cannot be clicked looks extremely unprofessional.
Comment 12 Jesse Glick 2011-07-06 13:33:34 UTC
As of 5f3fcb87f264 there will be no warning about a dep on org.netbeans.libs.junit4 when this module is not present at all; the 7.0+ harness tries to use ~/.m2/repository/junit/junit/4.8.2/junit-4.8.2.jar for running JUnit tests if it is absent, so it is not crucial. (If that JAR is missing then a message should be printed explaining how to install it using Maven.)

Note: you may get warnings in the log of functional tests that pseudomodules such as org.netbeans.modules.jellytools.platform cannot be enabled due to the missing dep, but this does not affect their ability to be used as test libraries: it is incidental that they are packaged as modules and so the module system tries to enable them, but without a ModuleInstall or layer.xml there is nothing to turn on, and their classes are still accessible to test classes at runtime.

Anyway this issue only affects people who refused to install JUnit normally from the NB installer or whatever, if using the "default platform"; could also affect people using a separate Platform installation lacking JUnit.

As to the general UI, the Resolve button will still be displayed as disabled when there is a declared dependency on some other CNB that does not match any known module, since there is no obvious recovery from such problems. This is as designed. The UI could be altered to enable the button but display some error message, perhaps, but I do not consider it a priority.
Comment 13 javydreamercsw 2011-08-03 14:41:17 UTC
I just installed 7.0.1 and agreed to install JUnit, still the same issue.
Comment 14 Jesse Glick 2011-08-03 16:58:58 UTC
(In reply to comment #13)
> I just installed 7.0.1 and agreed to install JUnit, still the same issue.

JUnit must be installed in the target platform, which may be different from the development IDE.
Comment 15 ArthurB 2011-09-26 20:43:31 UTC
This bug occurs when Netbeans is installed on Windows 7 in a directory that requires elevation for write access.  When Netbeans starts up the first time it will install the JUnit Module in the user's directory instead of the install directory.  The platform is unable to find the junit module in the user's directory.

Work around: 

Copy the following files (note that the 'to' directory is the platform that you are using which may not be the same directory as the IDE):

C:\Users\user\.netbeans\7.0\modules\ext\junit-3.8.2.jar
C:\Users\user\.netbeans\7.0\modules\ext\junit-4.8.2.jar
C:\Users\user\.netbeans\7.0\modules\org-netbeans-libs-junit4.jar
C:\Users\user\.netbeans\7.0\modules\org-netbeans-modules-junitlib.jar

Place them in their respective directories:

C:\Program Files\NetBeans 7.0.1\platform\modules\ext\junit-3.8.2.jar
C:\Program Files\NetBeans 7.0.1\platform\modules\ext\junit-4.8.2.jar
C:\Program Files\NetBeans 7.0.1\platform\modules\org-netbeans-libs-junit4.jar
C:\Program Files\NetBeans 7.0.1\platform\modules\org-netbeans-modules-junitlib.jar
Comment 16 Jesse Glick 2011-10-18 23:55:49 UTC
(In reply to comment #15)
> This bug occurs when Netbeans is installed on Windows 7 in a directory that
> requires elevation for write access.  When Netbeans starts up the first time it
> will install the JUnit Module in the user's directory instead of the install
> directory.  The platform is unable to find the junit module in the user's
> directory.

Please see bug #198739 on this topic. Leaving this issue open only for the UI of a disabled button vs. some more explanatory message.