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.
If you want to delete a project, you have to close it, delete its files on disk, and refresh (if deleted from outside the IDE, or you can use the All Files tab); there is no GUI gesture to do so.
Not for D.
*** Issue 44324 has been marked as a duplicate of this issue. ***
"If you want to delete a project, you have to close it, delete its files on disk" That's not entirely true. The project is still not deleted. I created 3 web projects. One of the project name is z, for trying out routines. The other two projects are namely, AliBaba & FortyThieves. Then I decided to get rid of project z by, 1. Closing project z in NB. 2. Removing its directory with Windows File Explorer. 3. Exit NB. 4. Start NB. 5. Run index.jsp of project AliBaba. The Tomcat output window of project AliBaba shows Tomcat startup issue: SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Document base .....\z\build\web does not exist or is not a readable directory. at org.apache.naming.resources.FileDirContext.setDocBase (FileDirContext.java:138) at org.apache.catalina.core.StandardContext.resourcesStart (StandardContext.java:3910) at org.apache.catalina.core.StandardContext.start (StandardContext.java:4138) at org.apache.catalina.core.ContainerBase.addChildInternal (ContainerBase.java:823) at org.apache.catalina.core.ContainerBase.addChild (ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild (StandardHost.java:595) at org.apache.catalina.core.StandardHostDeployer.addChild (StandardHostDeployer.java:903) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:582) at org.apache.commons.beanutils.MethodUtils.invokeMethod (MethodUtils.java:252) at org.apache.commons.digester.SetNextRule.end (SetNextRule.java:256) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement (Digester.java:1058) at org.apache.catalina.util.CatalinaDigester.endElement (CatalinaDigester.java:76) at org.apache.xerces.parsers.AbstractSAXParser.endElement (Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement (Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentD ispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument (Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse (Digester.java:1567) at org.apache.catalina.core.StandardHostDeployer.install (StandardHostDeployer.java:488) at org.apache.catalina.core.StandardHost.install (StandardHost.java:863) at org.apache.catalina.startup.HostConfig.deployDescriptors (HostConfig.java:482) at org.apache.catalina.startup.HostConfig.deployApps (HostConfig.java:427) at org.apache.catalina.startup.HostConfig.start (HostConfig.java:968) at org.apache.catalina.startup.HostConfig.lifecycleEvent (HostConfig.java:349) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java:1091) at org.apache.catalina.core.StandardHost.start (StandardHost.java:789) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java:1083) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java:478) at org.apache.catalina.core.StandardService.start (StandardService.java:480) at org.apache.catalina.core.StandardServer.start (StandardServer.java:2313) at org.apache.catalina.startup.Catalina.start (Catalina.java:556) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:582) at org.apache.catalina.startup.Bootstrap.start (Bootstrap.java:284) at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:422) Aug 18, 2004 6:44:43 PM org.apache.catalina.core.StandardContext start SEVERE: Error in resourceStart() Aug 18, 2004 6:44:43 PM org.apache.catalina.core.StandardContext start SEVERE: Error getConfigured Aug 18, 2004 6:44:43 PM org.apache.catalina.core.StandardContext start SEVERE: Context startup failed due to previous errors Aug 18, 2004 6:44:43 PM org.apache.catalina.core.StandardContext start SEVERE: Exception during cleanup after start failed LifecycleException: Container StandardContext[/z] has not been started at org.apache.catalina.core.StandardContext.stop (StandardContext.java:4466) at org.apache.catalina.core.StandardContext.start (StandardContext.java:4371) at org.apache.catalina.core.ContainerBase.addChildInternal (ContainerBase.java:823) at org.apache.catalina.core.ContainerBase.addChild (ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild (StandardHost.java:595) at org.apache.catalina.core.StandardHostDeployer.addChild (StandardHostDeployer.java:903) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:582) at org.apache.commons.beanutils.MethodUtils.invokeMethod (MethodUtils.java:252) at org.apache.commons.digester.SetNextRule.end (SetNextRule.java:256) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement (Digester.java:1058) at org.apache.catalina.util.CatalinaDigester.endElement (CatalinaDigester.java:76) at org.apache.xerces.parsers.AbstractSAXParser.endElement (Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement (Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentD ispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument (Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse (Digester.java:1567) at org.apache.catalina.core.StandardHostDeployer.install (StandardHostDeployer.java:488) at org.apache.catalina.core.StandardHost.install (StandardHost.java:863) at org.apache.catalina.startup.HostConfig.deployDescriptors (HostConfig.java:482) at org.apache.catalina.startup.HostConfig.deployApps (HostConfig.java:427) at org.apache.catalina.startup.HostConfig.start (HostConfig.java:968) at org.apache.catalina.startup.HostConfig.lifecycleEvent (HostConfig.java:349) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java:1091) at org.apache.catalina.core.StandardHost.start (StandardHost.java:789) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java:1083) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java:478) at org.apache.catalina.core.StandardService.start (StandardService.java:480) at org.apache.catalina.core.StandardServer.start (StandardServer.java:2313) at org.apache.catalina.startup.Catalina.start (Catalina.java:556) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:582) at org.apache.catalina.startup.Bootstrap.start (Bootstrap.java:284) at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:422) Aug 18, 2004 6:44:43 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8084
Sure, if other projects refer to it, then generally you will need to remove those references as well. I know absolutely nothing about the stack trace you mention; something to do with web apps. Any distinct problems you may have such as this should be filed separately (in this case assigned to 'web' or 'tomcatint' components, probably).
*** Issue 47412 has been marked as a duplicate of this issue. ***
*** Issue 47611 has been marked as a duplicate of this issue. ***
*** Issue 47661 has been marked as a duplicate of this issue. ***
Jesse, how hard is to implement it for NB4.0 ? We have 3 duplicates and I saw some problem if you open/close and detele the project outside IDE ....
Marian, what problem did you see? Is it related to #47436? If not please file issues. Thanks.
No, I saw some exceptions after delete project outside the IDE, if project was already opened/closed in IDE ... I think it's reported already, but I haven't issue number in hands now...
People are also mentioning deleting project from IDE on NetCAT mailing list.
FYI : issue 47662 "assertion error when os deleted unmounted proj"
Would rather not risk this for 4.0. Potentially complicated - need to find references in other projects and remove them. Also requires an API change (issue #42421) which is not trivial.
For NB4.0b1, to effectively delete a project, I did this ... Create a dummy project AliBaba to test deletion. To delete project AliBaba, close AliBaba. Exit NB. Remove nb directories in, or rename, AliBaba project directory. At directory <your profile path>/.netbeans/4.0beta1, delete the directory "var". Restart NB. Now that it'd lost its cache, it took some time to re- scan. Now, I was able to recreate project AliBaba without the annoying exception message - "Project AliBaba already exists in master ....". If I deleted cache subdir in var, it would not do. Removing the var dir completely seems to trigger a re-scan. Perhaps a re-scan would cause the loss of detection of "unmounted" project AliBaba. Whatever (aka throwing my hands up in the air).
Weird, AFAIK there should be no need to delete anything in var/cache/. (Do NOT freely delete all of var/. Only var/cache/ is dispensable.) Of course the scanner information for the old source dir will remain as one database entry in var/cache/mdrstorage/, but this should be harmless; not something a user should have to deal with directly. All you should need to do is close the project, remove any references to it from other projects, and delete either just the nbproject/ directory and other artifacts, or the whole directory. Should not even need to shut down the IDE, AFAIK.
*** Issue 51095 has been marked as a duplicate of this issue. ***
Shouldn't this be 'buildsys-e-cand'?
No, we do not have time to do this in E, considering all the other things with higher priority.
Cf. also #49915.
*** Issue 51960 has been marked as a duplicate of this issue. ***
*** Issue 48835 has been marked as a duplicate of this issue. ***
*** Issue 53804 has been marked as a duplicate of this issue. ***
This issue should be treated with more attention in next release, it's really bad if user closes project deletes the project from disk and then creates new with the same name and exceptions are poping-up.
Is there a similar issue for Project | Rename? I suspect it may be equally complicated to solve considering all potential inter-project dependencies.
This issue was also reported through NetCAT 4.1 program.
I suggest to increase the priority of this issue because there are so many duplicates and NetCatters ask for it. IMO we should prevent users from deleting files manually outside IDE if possible.
*** Issue 57301 has been marked as a duplicate of this issue. ***
I know I am becoming annoying (sorry for that), but I've crossed this issue again. I've deleted a project on hard disc and then tried to close the project. This lead to a deadlock: #57326. This is not the correct use case, but I think it's what some users will actually try to do. If I were a dumb user, I would: 1. Try to delete the project from IDE using context menu on project. 2. I wouldn't find the action so I would be slightly annoyed and go delete the project on my hardrive. 3. Once it is deleted I would close the project in the IDE. Which mostly leads to exceptions. The workaround is simple, just exchange steps 2 and 3. But I don't think it goes like this for many people, because what the user wants is to *delete* the project, not *close* it.
Roman: how about the following scenario? 1. Open a text file in OpenOffice. 2. Try to delete the file from OpenOffice using File | Delete. Surprisingly, there's no such option. ;-) 3. Couldn't find the option, so slightly annoyed, go to delete the file from your hard drive. (Won't work on Windows as the file will be locked, but you might have better "luck" with other platforms.) 4. Once the file is deleted, go back to OpenOffice and try to edit/close the file and see what happens. Sorry, I couldn't resist.
Honza, I got your point. What keeps me wondering I never had such problem with OpenOffice but I have it at least once a month with NetBeans. Am I really the only one?
Created attachment 22225 [details] Implementation of project delete for J2SE Project.
I must say I don't like this patch. The problem is that this patch does not solve the problem, it solves 14% of the problem. A similar patch would have to be applied to Web Project, EJB project, J2EE App project, Mobile project, WebStart project and UML project, not speaking of all freeform projects and Creator project. From the diff it is apparent that the UI is not specific at all to J2SE project - Bundle.properties contains very general string that would be used unchanged in all other project types. Same for the implementation - only a very small part of the implementation is specific to J2SE project. We should find a way to reuse most of this code for all projects. I disagree with a solution that fixes a small fraction of the problem.
To pjiricka's comments: we need to start somewhere. If we have something that does what it is supposed to do for j2seproject, then we can work on generalizing that to other project types and discussing a convenience SPI for it. But that needs to come later.
In fact, the "Operation Delete" consits of two parts: 1. GUI - question to the user, distiction between metadata and project sources. I do not think this is very general among (java-like) projects - the Web project may want to add more options than only "delete metadata" and "delete metadata and sources". Also, the distiction between project metadata and sources depends strongly on the project type. 2. Main "delete" loop. The delete itself is rather trivial, but each project type may want to do some special things before the project is delete (for example undeploy the application from the server). So, it is not clear to me what should be the SPI between infrastructure and project types. Although I am not strongly against such API, I do not want to propose something that won't help anybody. So I propose to implement the project delete per project type now, and potentially define some SPI when the exact requirements are known. Note: the patch attached to issue #58866 is required for the project delete to work reliably. BTW: I think I will be able to do "Project Delete" for all freeform projects on one place (ant/freeform). The freeform project structure should allow this.
> the Web project may want to add more options Don't speculate, ask us. Adding Radko Najman to cc, talk to him. > So, it is not clear to me what should be the SPI between infrastructure > and project types Again, if you are not sure, talk to the other project type owners, i.e. Radko on the Web/J2EE side. > So I propose to implement the project delete per project type now, and > potentially define some SPI when the exact requirements are known. If we copy/paste the code 7 times now, you will never define this SPI. Such is the experience. For the requirements, you don't need to work for a month on a huge document. Just walk around and talk to people. Besides, it is much easier to later add a method to SPI than to maintain 7 copies of several hundred lines of code.
Implemented for J2SE projects and freeform projects as part of issue #58866. See issue #58866 for integration log.
Why is this still open? Just make sure J2EE projects did it (file issues as needed) and close this, I guess.
Implemented.