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.
[ BUILD # : 200807170007 ] [ JDK VERSION : 1.6.0_06 ] Hi, Here's what to do to reproduce: - Create a default Enterprise project - Build the project - See that all build fine - Delete WAR-project with sources underneath - Clean-build Enterprise project - See: <WHEREVER THE PROJECT IS>\EnterpriseApplication1\nbproject\build-impl.xml:390: The following error occurred while executing this line: java.io.FileNotFoundException: <WHEREVER THE PROJECT IS>\EnterpriseApplication1\EnterpriseApplication1-war\build.xml (The system cannot find the path specified) BUILD FAILED (total time: 0 seconds) It is correct that the file could not be found, but it is incorrect that the project is still build. Iwan
-> j2ee
I'm not sure what you mean by "It is correct that the file could not be found, but it is incorrect that the project is still build." You deleted a project which is referenced by EAR and therefore EAR cannot be built. The real problem is that EAR project should become "red" to notify you that a project dependency is missing. That correctly happens if you restart IDE which gives you necessary pointer to resolve the problem. Btw. as you may know the packaging tab in proj properties is the place to remove WAR reference if needed.
I would expect that if I delete the project, the EAR project's references to it would be removed as well. I have for example an EAR project which reference 4 WAR projects. Now I want to get rid of one of them, as its functionality has been superceeded by a combination of the others. Just a matter of refactoring to be honest. So I delete that project which became obsolete. But it now requires manual actions to get rid of the references to it in the EAR project. I had a similar experience with deleting a JavaSE webservices client project from an EAR project that implemented some webservices. I had to remove the references to the client app by hand. I think these use-cases are relevant and P2 is warranted for them. Iwan
Re. "I think these use-cases are relevant and P2 is warranted for them" - the usecases are relevant but I lowered priority mainly because of frequently of deleting a project. How often do you delete a WAR from your EAR? Once a year, twice a year? If that happens it is annoying that IDE has not removed WAR from EAR automatically as you would expect but considering how frequently you have to manually amend this P3 is appropriate. There are more severe issues to address first and from that point of view this is IMO perhaps even P4.
Hmm, I see your point why not to make it a P2, although I encounter this problem more than once or twice as year, as I typically refactor my application break-up once the major functionality is working and tested. In those cases I am looking at how to modularize the whole set of functionality. I also refactor the application when it becomes very obvious that security contexts for specific types of users are warranting a different approach to what is part of what application. This sometimes becomes an issue when the application is already in production. As you can see, it is not that uncommon a use-case to shuffle around the projects. Iwan
Priority definitions say: P2 - Product feature doesn't work, a workaround may exist but it's difficult to use or impractical P3 - Part of a product feature is affected, a viable workaround exists This problem has simple and IMO obvious workaround. Restart of IDE marks project as broken. Re. "refactor my application" - granted. I'm not saying we are not going to fix this problem. I'm just saying that it is not high priority problem. If I look at my pile of P3s (35 of them) most of them if fixed brings user bigger benefit than fix of this issue. That's why I think it is P3 if not P4.
Report from old NetBeans version. Due to code changes since it was reported likely not reproducible now. Feel free to reopen if happens in 8.0.2 or 8.1.