Product Version: NetBeans IDE Dev (Build 201101140000)
Java: 1.6.0_25-ea; Java HotSpot(TM) 64-Bit Server VM 20.0-b08
System: Windows 7 version 6.1 running on amd64; Cp1252; en_CA (nb)
Netbeans is locking "target\endorsed\javaee-endorsed-api-6.0.jar" in Maven Web projects even though nothing is running. I believe opening the project is sufficient to lock this file, even if no server is running.
"clean and build" on the project always fails as a result.
An effect of the hack used in http://jira.codehaus.org/browse/MARCHETYPES-35 I guess. The only workaround I can think of would be to make a temp copy of the endorsed JAR and add that to the in-IDE classpath rather than the original. Or try to find the original JAR in the local M2 repo.
Jesse, have a look also at issue 188514 which was about jdk_bug_6558476.
(In reply to comment #2)
> have a look also at issue 188514
I think that's a bit different - something about javac as run from builds. (Seems a poor solution because it will be wasteful when run on JDK 7 or anything else where javac properly closes the loaders it creates.)
In this case target/endorsed/*.jar are in the IDE's own ClassPath.BOOT, so the in-IDE parser opens these JARs and I suppose holds them open, making them undeletable. It is poor practice to include build products in the IDE CP for this very reason, and normally this would not happen; it is just a workaround for a limitation in Maven: http://jira.codehaus.org/browse/MNG-4752
(In reply to comment #1)
> try to find the original JAR in the local M2 repo.
Will take this approach. Then the endorsed classpath will use the more correct location once (1) the project is built, (2) there is an index for the right repository (java.net in this case). Note that bug #190621 until fixed can necessitate an IDE restart.
Integrated into 'main-golden', will be available in build *201103090000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <email@example.com>
Log: #195195: javaee-endorsed-api-6.0.jar is locked
I thought I was still hitting this issue on NetBeans 7.0 RC1 and filed this report:
However, after seeing that the issue was already thought to be resolved in the RC1 build I did a bit more testing using SysInternals handle.exe and found something really odd:
Nokia Ovi Suite likes to open handles to libraries containing jar files and keep them open. The issue is actually Nokia Ovi Suite, not NetBeans. NokiaOviSuite.exe and nokiaserver.exe both have an open handle on:
on my system. It's that, not the endorsed jar, that's causing the problem with cleaning projects now, though I certainly had the issue with the endorsed jar earlier.
For others having this or a similar problem: A short term fix is killing ovi suite. Exiting it from the taskbar isn't enough, you'll need to kill the process in task manager. A longer-term one appears (so far) to be changing the file associations so that Ovi Suite doesn't try to open jar files.
*** Bug 197306 has been marked as a duplicate of this bug. ***
*** Bug 191350 has been marked as a duplicate of this bug. ***
I can reproduce this on Windows 7 . The nokia OVI suite mentioned is not installed on this machine
NB build 201104080000
Java version 1.6.0_21 64bit
Windows 7 Professional 6.1
1.)create new project
2.) Add a framework ( choose spring MVC 3.0.2 )
3.) select clean and build
The maven clean plugin 2.4.1 reports unable to delete javaee-endorsed-api-6.0.jar.
Attempting to manually delete (from windows explorer reports that file is still in use by Netbeans
Problem occurs in both local and domain accounts ( I created a new local account while troubleshooting ).
The problem does not occur for me under OS X 10.6.
Restarting the IDE does not fix the problem.
(In reply to comment #10)
> I can reproduce this on Windows 7 . The nokia OVI suite mentioned is not
> installed on this machine
> NB build 201104080000
> Java version 1.6.0_21 64bit
> Windows 7 Professional 6.1
> To reproduce
> 1.)create new project
> 2.) Add a framework ( choose spring MVC 3.0.2 )
> 3.) select clean and build
> The maven clean plugin 2.4.1 reports unable to delete
> Attempting to manually delete (from windows explorer reports that file is still
> in use by Netbeans
> Problem occurs in both local and domain accounts ( I created a new local
> account while troubleshooting ).
> The problem does not occur for me under OS X 10.6.
> Restarting the IDE does not fix the problem.
correction when attempting to delete with windows explorer the file is reported to be in use by Java SE binary not netbeans.
Also I am running maven in offline line mode with all targets in my local repository.
stimpy may be running into some unrelated bug, or some specialized subcase (e.g. broken Maven repository indices not having any match for this JAR). Please do not reopen, as the originally reported test case is no longer reproducible on XP as far as I know. Better to file a fresh bug, with any possible steps to reproduce, plus the IDE's log file (includes exact build info among other things), and the result of running the "NetBeans Project Metadata Inspector" module on the project. But first try a nightly build once one gets a fix of bug #198936, in case your problem is handled by one of the miscellaneous tweaks covered there.
I reopened this because it closely matched the original bug report ( ie same error and version of the OS ). Apologies if that was not the correct action .
I tested a "clean" install of JDK ,netbeans on a new workstation with the same error.
I will test both 6.9.1 and the nightly builds and open a new bug if the issue is not resolved in the nightly build .
(In reply to comment #13)
> I will test both 6.9.1
Do not bother; the Maven integration has been substantially modified in 7.0.
> and the nightly builds
Just add yourself to CC on bug #198936; a comment will be added by the build uploader when the purported fix of that issue appears in a nightly, mentioning the build in which the fix first appears.
I did test 6.9.1 ( because I need an IDE to work with ) it works correctly even when pointed at my existing local repo.
I will add myself to 198936.
I also tested 201105240400 and that did not solve the problem.