recommendations.html

Svata Dedic <[email protected]> Thu, 22 May 2003 21:23:23 +0200
Newsgroups gmane.comp.java.netbeans.modules.projects.devel
Organization CollabNet Hosting
Message-ID <[email protected]>
Hello, group,

during a recent CVS update, I received this document:
<http://ui.netbeans.org/source/browse/ui/www/usability/April_21_03/recommendations.html>.

I would like to ask about the last section:

<quote>
General Project Complexity

# Allow only one compiled classes build target per-project (Java Project)
# Have only one classpath per-project (Java Project)
# Have only settings management concept (call it configuration and let 
it encompass what was in a profile as well) (Infrastructure): A 
configuration, by the current definition, is a snap shot of the settings 
on a project and that should remain true. Configurations can then be 
used to keep the functionality presented by the multiples of profiles, 
configurations, build targets and classpaths...
</quote>

* Given the use case of unit tests, which are typically built and 
executed in the same manner as the main application, I would like to see 
scenarios supporting removal of additional "compiled classes" build 
targets, suggested in the first item, and specifically analysis of 
negligible importance of the "unit/functional/integration test" and 
other similar scenarios (like multistep builds to cover Java 
Platform-specific issues - also a requirement).

* It has been given enough cases why mixing specific API implementations 
into build path (as opposed to use them at runtime only) is considered 
bad in many companies. Item #2 suggest to do such thing in order to have 
executable project.
I request scenarios and use cases backing the limitation present in #2 
to be published, especially since it discards use cases present in 
NetBeans 3.1-3. (EXECUTE capability of a filesystem).

* The third item requires the user to fork full configuration copies in 
order to establish several run environments for a project (e.g. several 
testing modes, used repeatedly). If a change is made to _BUILD_ options, 
it must be propagated manually since all the configurations are independent.
Again, lacking any scenarios that would support the proposal in this 
respect and counter-analysis of scenarios which are dropped or rendered 
unusable.

-Svata