The central place for architectural enhancements
$Revision: 1.11 $
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).
- 32053
- Command line options shall be POSIX compatible. E.g.
-branding
etc. should be
--branding
etc.
(addressed in CLI proposal).
Compatible development
New 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.
Modularization
- 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
module for
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
nbdev@netbeans.org.
