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.
1. Create Web Application with "Visual Web JSF" framework. 2. Add EJB Set or Web Service to IDE. 3. Add EJB or Web Service to the application. 4. Rightclick project's root node and select Delete. 5. In appeared dialog set checkbox for removing project's folder checked. 6. Click OK button. Result: Project's folder isn't removed because it contains lib directory and jar file of EJB ot Web Service in it.
As I known, $proj_root/lib is not a right place to put the extra libraries.
Why not? Where is the right place? See another issue which has the same questions: http://www.netbeans.org/issues/show_bug.cgi?id=107000.
Because it is not a recognized place for web project, it then caused the non-delete issue: http://www.netbeans.org/issues/show_bug.cgi?id=106632
Where is the recommended place then? According to Jesse, it is the right place. See his comment on http://www.netbeans.org/issues/show_bug.cgi?id=107000.
Problem is that this folder also should be deleted when project's folder is deleting.
If you add a folder and the folder is not managed by the project, then you should be responsible for deleting the folder.
I just add W/S or EJB to a project, IDE place jar files to lib directory, I don't do this.
Romane, I'm sorry, I haven't thought you:). I though edwingo, that he is responsible for the folder.
I was thinking about it. Probably it's a problem of the project. What is exactly the usecase, when you need the ejb or web services jars in the project?
Hi Petr. In VWP, a user can add an EJB session bean to a project which will cause generated code packaged in jar files and metadata files to be copied to the project. These files are placed under the $projectdir/lib. In the case of EJBs they are in a subdirectory $projectdir/lib/ejb-sources/. This is part of a goal to migrate Creator users to using NB6. Something similar happens with web services and complibs. I agree in principle that the module that creates files should also clean them up, however, I do not understand how to implement this. If a user deletes a project, then the module that created the files needs to be notified. Is there a way to listen for when a user deletes a project? I don't see how the OpenProjects API can help here.
IMHO the project delete/rename/move infrastructure should check for any files/folders which are neither marked as definitely part of the project's sources, nor marked as belonging to some other project (usually meaning a nested project folder); and ask the user what to do with them, with the default behavior being to treat them as sources. (Consider the perfectly legitimate case of a user who manually creates a folder "libs" - not "lib" - in the Files tab and adds some JARs to it that he or she intends to use just in this project.) That is why I recommend this be treated as a bug in projects/code. Miloš?
In other IDEs I have used, "Delete Project" means to remove it from the IDE Projects Window and there is an additional radio option to also remove the contents. When "remove contents" is also selected, then everything is removed. This seems like a more intuitive UI and less surprising, and it also happens to be much easier to implement. I was confused by why the NetBeans version did not remove everything and I had to remove it manually afterward.
this issue doesn't block 107000. Once the "lib" folder is created only when needed it will decrease the likelihood of this bug occuring significatantly. re: jglick. the suggestion sounds reasonable, however I would like the UI to show up only for user-created content, not for something we (netbeans) have created automatically. So the "lib" folder or it's content that was added by us shall be handled automatically. I'll look into DeleteProjectOperationImplementation (or however the spi class is called) if it can support distributed responsibility for recognizing the project source content and meta content. The idea is to write a LookupMerger implementation that would delegate to the various implementations registered in project's lookup.
Why is the distinction between manually vs. automatically added folders relevant? Regardless of how or why the folder was added, it is now clearly part of the project. I don't see what UI purpose is served by treating these two cases differently. Regarding "Delete" vs. "Remove", "Close Project" in NetBeans just removes the project from view. "Delete Project" really means delete it.
mkleint: I agree that issue #107000 can be fixed without resolving this issue, but there is an unobvious dependency which is why I added it. The first part of fixing this bug is figuring out where the VWP EJB and Web service libraries or automatically maintained "binary sources" go for VWP. This also affects the visualweb/complib module. In Creator, these artifacts lived in $projectdir/lib, which causes this bug. One option would be to move the artifacts to another directory that web/project module does remove, but that has other disadvantages. I wanted to resolve the location for the artifacts first and then to resolve the issue of how to distribute this location to the 4 other modules that need it because I think that would be cleaner than duplicating the location in multiple modules. I cc-ed you in some email on the subject. I think the current consensus is to keep these artifacts under $projectdir/lib. The next question is to figure out how to distribute this location to other modules and then I will fix issue #107000.
*** Issue 90482 has been marked as a duplicate of this issue. ***
*** Issue 115919 has been marked as a duplicate of this issue. ***
Assigning to projects/code since the preferred long term approach is generic to all projects.
edwingo, potingwu: you can fix your ${basedir}/lib folder issue even now by providing an additional DataFilesProviderImplementation instance in the project's lookup. (via LookupProvider or directly in the default impl.) Alternatively the project type's default implementation of DataFilesProviderImplementation can dynamically resolve and include everything under the project root (if not owned by other projects) with the assumption that everything that is not metadata is data. any future UI regarding additional confirmation dialogs is an enhancement, not defect.
*** Issue 121028 has been marked as a duplicate of this issue. ***
*** Issue 140429 has been marked as a duplicate of this issue. ***
*** Issue 138048 has been marked as a duplicate of this issue. ***
*** Issue 151752 has been marked as a duplicate of this issue. ***
Change of default owner.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss