The central place for architectural enhancements$Revision: 1.2 $
Changes: available in CVS
Status: issue 30370 or status page
Abstract:During the work on release 3.5 we described the NetBeans Architecture by answering a set of questions for each module/component that is part of NetBeans Platform (see overview) and properly identified and categorized everything that could be considered an API. These documents are written to improve documentation - it describes all used properties for example, and also serve as a base for evaluation of the whole architecture. During the last phase of release 3.5 we have asked a group of architecture experts to look at our documents and give us some advices, how to improve the NetBeans Platform to better integrate with host operating systems, to be ready for future evolution, to scale and etc, etc. This document is a place describing the work that will need to be done.
Installation and Deployment
- 32081 - Distribute the platform in RPMs and Solaris packages (addressed in installation proposal).
- 32080 - Better organization of the file layout in the distribution (addressed in installation proposal).
- 32054 - Warn user when a second instance of the application is started using the same user dir. (addressed in CLI proposal).
- Command line options shall be POSIX compatible. E.g.
-brandingetc. should be
--brandingetc. (addressed in CLI proposal).
Compatible developmentNew release of any part of the system cannot break other parts that might have been distributed in a different time. Discussed as part of installation proposal.
The good practices for doing compatible development are highlighted here:
- Backward compatibility. Whenever an offical API is introduced it is necessary to keep its compatibility in future versions. We have to define what an official API is and build an infrastructure to keep compatibility of all such APIs. See versioning policy.
- API and Implementation Modules. As discussed between Jesse and Martin Matula it is not enough to have just some API, it is necessary to correctly lookup appropriate implementation. Issue 17776.
- Autoupdate support. Looking up the proper implementation needs to be supported by autoupdate too. So one can enable a module and than search on update centers for some implementation of API the other module needs.
- Thin OpenAPI. The current API should be separated into smaller parts and non-general API (debugger, compiler, java) become voluntary, so when new modules, that do not use them, are used those APIs JARs are not even touched.
- Core as a module. Core is in some kind an implementation
OpenAPIs. That is why it should be treated as such - offer services but only when necessary and allow those to be replaced by other modules (logger to provide error manager).
Comments to email@example.com.