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.
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.
Creating a branch for it: cvs rtag -b -r BLD200505161800 apisupport_format_58966 apisupport nbbuild
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
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
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.
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...
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
All unit tests finally pass so I think I am ready to merge soon.
In trunk now.
Created attachment 22247 [details] Commit log