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.
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.
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.
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"
(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.
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?
(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.
> 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.
(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.
From a user's point of view, isn't it strange to see a button (a red one at that) which cannot be clicked?
The UI could probably be improved.
In my point of view it's not a stopper for NB701.
A big red button that cannot be clicked looks extremely unprofessional.
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.
I just installed 7.0.1 and agreed to install JUnit, still the same issue.
(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.
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
(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.