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.