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.

Bug 61137

Summary: Unnecessary API additions in Project API for Delete Project
Product: projects Reporter: Jesse Glick <jglick>
Component: Generic InfrastructureAssignee: Jan Lahoda <jlahoda>
Severity: blocker CC: abadea, mfukala, rnajman
Priority: P2 Keywords: API
Version: 5.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on:    
Bug Blocks: 58866    

Description Jesse Glick 2005-07-20 02:02:11 UTC
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


with J2SEProjectOperations implementing 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 *** 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.)
Comment 1 Jesse Glick 2005-07-20 02:03:39 UTC
Again, sorry for late notice, but better to do a little refactoring now than be
stuck with the wrong design decision permanently.
Comment 2 Jan Lahoda 2005-07-20 16:44:39 UTC
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
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.
Comment 3 Jesse Glick 2005-07-20 18:53:00 UTC
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 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).
Comment 4 Jan Lahoda 2005-08-22 22:36:46 UTC
I did some adjustments as specified in issue #61546. Please let me know if you
have another ideas.