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 52258 - Review of OpenProjects extensions
Summary: Review of OpenProjects extensions
Status: CLOSED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Tomas Zezula
URL:
Keywords: API, API_REVIEW_FAST
Depends on:
Blocks: 49641
  Show dependency tree
 
Reported: 2004-12-09 14:15 UTC by Tomas Zezula
Modified: 2006-03-24 12:54 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Diff (1.20 KB, patch)
2004-12-09 14:18 UTC, Tomas Zezula
Details | Diff
apichanges (1.16 KB, patch)
2004-12-14 16:21 UTC, Tomas Zezula
Details | Diff
Added usecases (2.37 KB, patch)
2004-12-14 17:39 UTC, Tomas Zezula
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2004-12-09 14:15:55 UTC
The change should address a lack of methods for
opening and closing projects. 
Change: Adding of the following two methods into
org.netbeans.api.project.ui.OpenProjects.

public void open (Project[] projects, boolean
openRequiredProjects);

public void close (Project[] projects);

Stability Category: Official
Comment 1 Tomas Zezula 2004-12-09 14:18:01 UTC
Created attachment 19233 [details]
Diff
Comment 2 Jaroslav Tulach 2004-12-09 15:23:29 UTC
Change is ok. Do not forget @since and apichanges, etc.
Comment 3 Jesse Glick 2004-12-09 15:38:47 UTC
As Yarda said, @since tag and apichanges.xml patch should be included
in the diff given here.


Should clarify behavior if

- some projects to be opened are already open

- some projects to be closed are not currently open

- list of projects contains duplicates


Should use "openSubprojects" rather than "openRequiredProjects", for
consistency.


Always use {@link ...} for reference to other API classes or methods
or constants.


Please apply standard JavaSoft formatting conventions to all newly
added code, for consistency.


Should have a "use cases" addition to arch.xml, or more simply a <div
class="nonnormative"> section of the Javadoc for these methods,
describing when you might want to call such methods - and, more
importantly, when you would *not* and what you should do instead.

In particular, at this time AFAIK we only expect the new methods to be
called in response to actions performed on nodes inside the logical
views of already-open projects: e.g. "Open" on a subproject node.


A note to other reviewers: this change will also require an
incompatible change in a friend API interface in a non-public package
used only to communicate between the projectui and projectuiapi
modules (using an impl dep). I assume this kind of change requires no
review since it is not exposed to other components - correct me if I
am wrong.
Comment 4 Jaroslav Tulach 2004-12-10 09:09:57 UTC
Updates to private contract between projectui and projectuiapi is
probably out of scope of api review until they change the module
dependencies. Which they probably do not:

<dependency>
  <code-name-base>org.netbeans.modules.projectuiapi</code-name-base>
  <build-prerequisite/>
  <compile-dependency/>
  <run-dependency>
    <release-version>0</release-version>
    <!-- XXX declare the impl dep somehow... -->
  </run-dependency>
</dependency>
Comment 5 sigalduek 2004-12-14 08:51:22 UTC
One more use case: I'm writing end2end module
for Mobile Edition. The user (his current main project is mobile
project ) needs to choose one web project he'd like to interact with.
He gets the list of all web projects that are opened. If his web
project is not opened , he will get a JFileChooser with all project's
folders. After choosing one  - the project should be opened.
Comment 6 Tomas Zezula 2004-12-14 16:21:04 UTC
Created attachment 19286 [details]
apichanges
Comment 7 Tomas Zezula 2004-12-14 16:22:13 UTC
The module dependencies is not changed.
Comment 8 Jesse Glick 2004-12-14 16:33:26 UTC
Note to Sigal (not directly related to this issue): making your own
Open Project dialog is probably a bad idea; a lot of work went into
the current dialog which you would not want to do without (or have to
copy). Perhaps ProjectChooser.projectChooser will do what you want.
Comment 9 Tomas Zezula 2004-12-14 17:39:47 UTC
Created attachment 19290 [details]
Added usecases
Comment 10 Pavel Buzek 2004-12-15 10:22:03 UTC
I have no comments. If you solved all Jesse's and Jarda's issues
please go ahead and commit.
Comment 12 Jaromir Uhrik 2005-07-14 16:19:26 UTC
Verified.