Bug 58966

Summary: Rewrite external NBM project file layout
Product: apisupport Reporter: Jesse Glick <jglick>
Component: ProjectAssignee: Jesse Glick <jglick>
Status: RESOLVED FIXED QA Contact: issues <issues.netbeans.org>
Priority: P1 CC: mkrauskopf
Version: 5.x   
Target Milestone: 5.x   
Hardware: All   
OS: All   
Whiteboard:
Issue Type: TASK Exception Report:
Attachments: Commit log

Description Jesse Glick 2005-05-16 23:40:35 UTC
As written on dev@apisupport, what needs to be done:

1. GUI only supports platform definitions stored in the user directory (like
library and Java platform definitions for other project types); TBD whether
sharable external platform defs would be possible with manual editing of config
files. Keep NB Platform Manager dialog as the only way (in the GUI) to define
platform locations and associate sources and Javadoc. Continue to treat the
running IDE installation as the "default platform".

2. Introduce a suite project type, but make it optional, i.e. can still build
and use a standalone module without any suite.

2a. If a module belongs to a suite, its choice of platform is determined by the
suite - the suite's properties dialog permits the platform to be selected.

2b. Standalone modules may specify their platform directly.

2c. New Project wiz for module lets you either pick an existing suite, or make
module standalone and pick a platform.

2d. A module may belong to only one suite (unlike e.g. EJB-JAR projects which
may belong to multiple EAR projects).

2e. A standalone module may be retroactively added to a suite, probably via a
context menu item on the suite project. (This would remove its platform
selection.) TBD whether the reverse operation should be supported by the GUI
(remove module from suite), or whether move module from one suite to another
should be supported by the GUI; probably not.

2f. Opening a suite project or standalone module project referring to a
nonexistent platform (by name) would result in a Broken References dialog in the
usual way.

3. A module suite keeps an explicit list of all modules it contains, as
(relative or absolute) paths to project dirs, in lieu of the current two-level
automatic scanning. Each (non-standalone) module in turn keeps a backreference
to the suite. Module dependencies continue to be specified in project.xml as
code names (no path info), and the GUI continues to reflect this.

3a. Opening a suite (or non-standalone module) project which was created with
absolute reference(s) to contained module(s) (resp., containing suite) from
another VCS checkout would presumably need to be resolved using Broken
References as well.
Comment 1 Jesse Glick 2005-05-16 23:44:35 UTC
Creating a branch for it:

cvs rtag -b -r BLD200505161800 apisupport_format_58966 apisupport nbbuild
Comment 2 Jesse Glick 2005-05-17 00:20:49 UTC
Had to update base tag for apisupport module due to Martin's recent changes,
which would surely conflict with stuff I am doing. New base tag (only for
apisupport module): apisupport_format_58966_newbase_20050516

I.e.:

cd apisupport; cvs up -j BLD200505161800 -j
apisupport_format_58966_newbase_20050516; cvs ci
Comment 3 Jesse Glick 2005-05-19 18:42:58 UTC
Merging in more recent trunk changes, so have new base tag:

cd apisupport; cvs up -j apisupport_format_58966_newbase_20050516 -j
apisupport_format_58966_newbase_20050519
Comment 4 Jesse Glick 2005-05-19 22:34:39 UTC
And some more:

cvs up -j apisupport_format_58966_newbase_20050519 -j
apisupport_format_58966_newbase_20050519b

BTW Martin please try to keep changes to ModuleList in particular to a minimum
while this branch is active, as it takes some work to resolve merge conflicts.
So far nothing bad.
Comment 5 Martin Krauskopf 2005-05-19 22:54:27 UTC
I know. I'm watching your branch and trying to not make a lot of complications
:) I'll probably only enhance ModuleList.Entry and its implementations. Maybe we
should move implementation inner subclasses to their own classes after merge?
Since the ModuleList class is getting really large...
Comment 6 Jesse Glick 2005-05-20 20:49:34 UTC
Merged trunk changes; only minor conflicts in *Entry constructors:

cd apisupport; cvs up -j apisupport_format_58966_newbase_20050519b -j
apisupport_format_58966_newbase_20050520
Comment 7 Jesse Glick 2005-05-21 02:04:29 UTC
All unit tests finally pass so I think I am ready to merge soon.
Comment 8 Jesse Glick 2005-05-23 05:56:36 UTC
In trunk now.
Comment 9 Jesse Glick 2005-05-23 05:56:56 UTC
Created attachment 22247 [details]
Commit log
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo