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