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.
I did not have time to fully review issue #58866 before, so the following is a belated comment, but we are not yet in feature freeze and it is better to address these things earlier rather than later, so: Why are ProjectOperations and ProjectOperationsImplementation public and in the Project API? As far as I can tell, these things are used only from ant/project. I.e.: there is now a COMMAND_DELETE, which is fine, and as far as I can tell the project infrastructure simply asks ActionProvider whether it supports DELETE, and if so, to do it. So far so good, and consistent with other actions. But why do we need anything else in the Project API? All of the details having to do with collecting metadata files vs. data files, cleaning the project, etc. are all used only by DefaultAntProjectOperations (via AntProjectHelper) anyway, if I am not mistaken. So why not just put these SPIs (intended to be implemented by projects) in the ant/project module? And for that matter, why force a project to add a DeleteOperationImplementation to its lookup? Surely you could simply have e.g. J2SEActionProvider.invokeAction on COMMAND_DELETE call project.getAntProjectHelper().performDefaultDeleteOperation(new J2SEProjectOperations(project)); with J2SEProjectOperations implementing org.netbeans.spi.project.support.ant.DeleteOperationInfo or similar. This style would give the same behavior for current project types, but would more clearly differentiate the required API - "delete this project" - from the suggested UI implementation - "collect metadata and data files, clean the project, prompt the user, delete". The only possible justification for having DOI in the Project API is if CommonProjectActions.deleteProjectAction() worked with multiple projects selected, and collected data files etc. for the *union* of all those projects, and displayed a single dialog and progress bar. But it doesn't work that way, anyway, and I don't see a real need for such a UI. Nor is it clear that *every* possible project would follow the same pattern for what is done when the project is deleted. E.g. "clean" may be nonsense for some project types. On the other side, it does not appear that DefaultAntProjectOperations actually does anything specific to Ant-based projects! (performDelete takes an AntProjectHelper param but seems to ignore it.) If true, this means that it would be better for the whole default deletion impl to live in an Ant-neutral module: Project UI API, in a **.spi.support.* package. That would make it accessible to a broader range of project types. (AntProjectHelper.notifyDeleted is of course still needed since it interfaces with ProjectState.)
Again, sorry for late notice, but better to do a little refactoring now than be stuck with the wrong design decision permanently.
No problem regarding the late notice. As you noted, better change it now. I will try to answer in the order of importance: 1. Re putting the DeleteOperationImplementation into the project lookup: this is to support the API part (ProjectOperations). The reason for ProjectOperations is the J2EE project (and similar, if any), which may encapsulate EJB project and Web project (these projects may be created by the New Project wizard altogether with the J2EE project). If the delete action is called on the J2EE project, a special dialog allowing the user to delete also the EJB and web projects should appear. If this could be solved in an another way, the API part should be deleted and AntProjectHelper.performDefaultDeleteOperation(DeleteOperationImplementation) should be used instead. 2. Regarding placing of ProjectOperations, ProjectOperationsImplementation: these are not related to ant/project (probably make at least some sense to any project type), so I placed them into Projects API. Can be moved into ant/project if you think it is a better place. But I would rather move the default delete operation into projectuiapi as you mentioned. 3. Re performClean name: I would like to change the name of this method to notifyDeleting (or some similar name), so there would be pair notifyDeleting-notifyDeleted like in Window listener: windowClosing-windowClosed.
Re. #1 - OK, I did not know about this aspect of it. If you decide to keep PO/POI where they are, probably it would make sense to document this use case: a container project which wishes to delete contained projects in one step and thus expects to find POI.DOI in lookups of the contained projects. It should just be clarified in Javadoc that a project is under no obligation to use these classes for implementing AP.COMMAND_DELETE. If the standard infrastructure were all moved to projectuiapi in a .spi.support package, that would also make things clearer, I think. Re. #3 - makes sense, and also note ModuleInstall.{closing,closed}. Some other nits: a. ProjectOperations should probably not be instantiable at all; can just make every method static. b. ProjectOperationsImplementation could be deleted and its nested interfaces made into top-level source files. (Generally we try to avoid exposing nested classes in APIs.) c. POI.* interfaces need to document that they should be added to Project.lookup in order to be used, I guess (depending on what you want the style to be re. #1).
I did some adjustments as specified in issue #61546. Please let me know if you have another ideas.