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.
I got a message from a user referring to http://netbeans.org/projects/www/lists/netcat/archive/2011-04/message/70 who said he had similar issues. His problem is that he is using some kind of Debian package for the NB installation, in /usr/local which I presume he does not have write access to. So when he installs the "JUnit" plugin from AU, the IDE cannot put it in the normal places - /usr/local/netbeans/7.0/platform/ and /usr/local/netbeans/7.0/java/ - and instead is forced to put it in the user directory (~/.netbeans/7.0/). This is OK for use from a Java SE project, which merely requires that Library Manager have some definition for the junit and junit_4 libs. But for testing a NetBeans RCP project, the target NB platform must contain the org.netbeans.libs.junit4 module, including .../platform/modules/ext/junit-4.8.2.jar; and the user's "default platform", i.e. that from which the IDE is run, does not contain this module. Probably {libs.junit4,junitlib}/nbproject/project.properties should be amended to say: nbm.is.global=true so that the user is made to install these modules in the actual NB installation directory (in the platform and java clusters, resp.) - never in the user directory. In the meantime, possible corrections for the user's broken setup would be: 1. Use a fresh userdir, make /usr/local/netbeans/7.0/ writable, and install JUnit again. 2. Get a copy of NB as a ZIP or standalone installer, rather than a package, install it somewhere writable, add JUnit to it, and either 2a. Use that copy for developing plugins. 2b. Set that copy as the suite's target platform.
I think this is probably the same issue that I am having (and indeed the fix worked). I'm on an Ubuntu installation (v10.10) and Netbeans has been installed into "/usr/local/netbeans/7.0". However, I installed Netbeans using the stand-alone installer downloaded from www.netbeans.org - I did not install it using a Debian Ubuntu package. I took a slightly different approach than the one mentioned. I was concerned how I might change the permissions of /usr/local back to their original state after making them writable by all. So instead I did this: 1. Installed NetBeans using the stand-alone installer which installs it into "/usr/local/netbeans/7.0". (A place only writable by root). 2. Run NetBeans as root like so: sudo -i /bin/sh "/usr/local/netbeans-7.0/bin/netbeans" Netbeans runs for the root user, jUnit installs automatically as it supposed to when it is not found in the target platform. 3. After the jUnit install completes (watch the progress bar in the bottom right of the screen), close NetBeans. 4. Type exit to leave sudo mode. 5. If you have already run netbeans as a normal user then you need to clear the netbeans user data from your home directory. Either move or delete the directory "~/.netbeans/7.0" to somewhere else so that the directory will not be found when NetBeans runs. 6. Run NetBeans and everything should work. Running NetBeans as root does of course open your system to any malicious code that may be in a vanilla install of NetBeans so if your paranoid you may not like this idea. I for one though am quite happy to trust that running a vanilla install of netbeans, once as root, is opening my system up to any significant danger.
(In reply to comment #1) > 1. Installed NetBeans using the stand-alone installer which installs it into > "/usr/local/netbeans/7.0". (A place only writable by root). Interesting - is this the default location, or one you picked yourself? I guess you had to have run the installer as root. > 2. Run NetBeans as root like so: > sudo -i > /bin/sh "/usr/local/netbeans-7.0/bin/netbeans" > > Netbeans runs for the root user, jUnit installs automatically Yes, this is another acceptable fix if you are willing to run NB temporarily as root. > 5. If you have already run netbeans as a normal user then you need to clear > the netbeans user data from your home directory. Should suffice to delete just the JUnit-related files from the userdir: update_tracking/org-netbeans-{libs-junit4,modules-junitlib}.xml and all files listed in those files. The root issue here (excuse the pun!) is that in the current design, the installer asks whether you wish to include JUnit in the installation, but does not actually unpack the NBM itself - it leaves that to the IDE when first starting up. If the installer runs as root and the IDE does not, then the IDE may be unable to perform file operations that the installer could have. At the minimum, the installer should notice that it is running as root but the installation location is not writable by anyone other than root, and issue some sort of warning if the user asks to include JUnit. Setting nbm.is.global=true on the two modules may still be useful but is less friendly than either actually installing them in the global location while the installer runs, or explaining that when installed in the userdir they will not be available for NB Platform development.
*** Bug 199953 has been marked as a duplicate of this bug. ***
*** Bug 202593 has been marked as a duplicate of this bug. ***
This situation is a recurrent irritation and needs to be resolved.
7.0 already had a special provision to use junit-4.8.2.jar from the local Maven repository, when present, in lieu of a missing libs.junit4 (a6536dfe3b4b); but this only applied to the Ant build harness - while 'ant test' works when project.xml had the libs.junit4 dep even if that module is missing from the target platform so long as JUnit has been downloaded by Maven, the GUI would still complain. In core-main #520318d4fcd0 I made the IDE's NB platform scanner insert a placeholder entry "JUnit from Maven" when not otherwise present in a binary platform (whether or not the JAR has actually been downloaded yet). This better matches the harness's behavior, and is enough for "Add Missing Dependencies" to be happy. If and when the JAR is downloaded, error badges on tests will also go away (though no source/Javadoc association unless you also have those from Maven). So better than nothing, but it is still desirable for the JUnit plugin to be in the installation.
This leaves zip distro out of the fix.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/520318d4fcd0 User: Jesse Glick <jglick@netbeans.org> Log: #198739 amelioration: create a fake platform entry for libs.junit4 when necessary.
(In reply to comment #7) > This leaves zip distro out of the fix. I think users are much less likely to unpack the ZIP distro in a location which is not writable by their regular account; whereas the installer seems to do so regularly, especially on Windows 7, so this affects plenty of users. If the installer issue is fixed, then we could set nbm.is.global=true on libs.junit4 and junitlib, which would prevent you from accidentally installing to the userdir even when using a ZIP distro; and/or Plugin Manager could issue a stern warning if it is switching to the user directory for installation of an NBM with a defined cluster name because of lack of write access.
*** Bug 206723 has been marked as a duplicate of this bug. ***
It's still returning problem reported by IDE users. Should be addressed somehow. Increased the priority.
I think that a defect I raised http://netbeans.org/bugzilla/show_bug.cgi?id=209698 is the same as this one but on Win 7 I recall seeing a comment saying that the target Platform for the module being built should include Junit and I disagree. I am building an RCP which does not need the Java cluster at all, while I still want to Junit my project...
*** Bug 209698 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > I recall seeing a comment saying that the target Platform for the module being > built should include Junit Yes, org.netbeans.libs.junit4. > I am building an RCP which does not need the Java cluster at all The abovementioned module is not part of the java cluster, it is part of the platform cluster.
Oops ok platform, fair enough! Anyway, my RCP project includes junit4 anyway and I have the issue. (I still miss something: why would my RCP'dependencies influence the ability to junit my project inside Netbeans. I am probably mistaken)
(In reply to comment #10) > (In reply to comment #7) > > This leaves zip distro out of the fix. > > I think users are much less likely to unpack the ZIP distro in a location which > is not writable by their regular account; whereas the installer seems to do so > regularly, especially on Windows 7, so this affects plenty of users. > > If the installer issue is fixed, then we could set nbm.is.global=true on > libs.junit4 and junitlib, which would prevent you from accidentally installing > to the userdir even when using a ZIP distro; and/or Plugin Manager could issue > a stern warning if it is switching to the user directory for installation of an > NBM with a defined cluster name because of lack of write access. Autoupdate could show a warning about lack of privileges for writing into installation directory if install dir is read-only and hint affected users to run IDE as admin when install JUnit. Jesse, does it make sense? Thanks I have other place what could be improved. If an user invoke Create tests, IDE tries to download JUnit and install it into userdir in this case. After a while IDE shows "Resolve "junit" Reference Problem" dialog. So far so good. But, press "Try again" button but it does nothing, no feedback. Invoking Create tests again will show Download and Install JUnit dialog but pressing Download button quits the dialog only, also no feedback to users. I propose to: 1) make a FAQ page about this case 2) add a link to this FAQ from "Resolve "junit" Reference Problem" dialog 3) Popup "Resolve "junit" Reference Problem" dialog every time when Download&Install JUnit failed Jesse, could you review it again? Thanks
(In reply to comment #17) > Autoupdate could show a warning about lack of privileges for writing into > installation directory if install dir is read-only and hint affected users to > run IDE as admin when install JUnit. Jesse, does it make sense? Thanks See bug 211388.
(In reply to comment #17) > Autoupdate could show a warning about lack of privileges for writing into > installation directory if install dir is read-only and hint affected users to > run IDE as admin when install JUnit. Or when installing any NBM which specifies a target cluster. > If an user invoke Create tests, IDE > tries to download JUnit and install it into userdir in this case. Not if PM is fixed to install it in the right place or not at all. > press "Try again" button but it does nothing, no feedback. A bug for the junit component I guess. > I propose to: > 1) make a FAQ page about this case Better to fix problems than document them.
(In reply to comment #19) > (In reply to comment #17) > > Autoupdate could show a warning about lack of privileges for writing into > > installation directory if install dir is read-only and hint affected users to > > run IDE as admin when install JUnit. > > Or when installing any NBM which specifies a target cluster. I'm not sure. Most of NBM declares a target cluster thus AU will show such warning too often. I think it might be better to limit the warning for module which forced install dir only. > > If an user invoke Create tests, IDE > > tries to download JUnit and install it into userdir in this case. > > Not if PM is fixed to install it in the right place or not at all. > > > press "Try again" button but it does nothing, no feedback. > > A bug for the junit component I guess. Will do. > > I propose to: > > 1) make a FAQ page about this case > > Better to fix problems than document them. Right. But I'm afraid some people can fall to the broken state even though AU will warn them.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #17) > > > Autoupdate could show a warning about lack of privileges for writing into > > > installation directory if install dir is read-only and hint affected users to > > > run IDE as admin when install JUnit. > > > > Or when installing any NBM which specifies a target cluster. > I'm not sure. Most of NBM declares a target cluster thus AU will show such > warning too often. I think it might be better to limit the warning for module > which forced install dir only. Filed as issue 211777. > > > If an user invoke Create tests, IDE > > > tries to download JUnit and install it into userdir in this case. > > > > Not if PM is fixed to install it in the right place or not at all. > > > > > press "Try again" button but it does nothing, no feedback. > > > > A bug for the junit component I guess. > Will do. I tried to reproduce it in recent Dev build and it works much better, an user can create tests once downloaded JUnit regardless where. Decreased the priority. > > > I propose to: > > > 1) make a FAQ page about this case > > > > Better to fix problems than document them. > Right. But I'm afraid some people can fall to the broken state even though AU > will warn them.
(In reply to comment #21) > I tried to reproduce it in recent Dev build and it works much better, an user > can create tests once downloaded JUnit regardless where. This was always true for j2seproject's. Did you try for an Ant-based NBM project? 520318d4fcd0 should have improved the behavior though not entirely fixed it.
An user will be notified when JUnit libs cannot be installed in IDE installation directory.
Not exactly fixed as such, just rejected on the basis of other UI changes.
*** Bug 213937 has been marked as a duplicate of this bug. ***
Solved in NetBeans 7.3, NetBeans IDE installer can install JUnit into platform cluster during IDE installation if an user accepts JUnit license and the installer is connected to the internet. This way solves read-only installation of IDE. If rest of cases, users can use Project Broken References wizard.