Implementing Architecture Enhancements
$Revision: 1.2 $
Changes: available in
CVS
Status: issue
36663
The set of architecture enhancements that NetBeans received during architecture
reviews and which should be implemented allows various implementation.
The best one, according to the knowledge of all the NetBeans participants,
has been described in the Installation Structure
document.
The solution there describes more the ideal state than steps how to get there.
In order to move forward we need to identify the chain of steps that would
lead us to the ideal solution and would address most of the complaints as soon
as possible.
This document lists the important problem categories and offers three types of solutions:
the least effort one, the best one and the pragmatic. The last type is there in
case neither the minimal or maximal are suitable due to complexity,
possible future architecture lock-in or other reasons. For all problems bellow
one of the solutions is highlighted as the suggested one.
| Do not duplicate any files |
| Problem Description |
Minimal Solution |
Maximal Solution |
Pragmatic Solution |
Influences |
|
Use standard 3rd party libraries
packaged as native packages.
Status: 36757
|
On Unix platforms use symbolic links
to map /usr/shared/java/java-help-2.0.jar into
$nbplatform/modules/ext/jh-2.0.jar. This support
shall be part of native package post installation script or
installer.
On Windows keep the current state and carry own copy of libraries.
|
Create a support for
OS neutral
symlinks in module system and use that on all platforms
including Windows.
|
Let's use minimal, it can always be extended in future as everything
remains the same on Windows and on Unix we just need install time
improvements.
|
Platform needs to solve references to javahelp.
The rest of IDE has to do something for
tomcat and xerces and possibly other
libraries. We need to identify the owners of all libraries
(jpackage.org for Linux)
or become one, find the names of those packages and express
dependencies in those packages inside our. We need to update
installers
to carry those packages.
|
|
Products based on the same version of NetBeans should share
the same binaries of NetBeans (at least on Linux and Solaris).
Status: Done
|
Treat whole NetBeans IDE as one big cluster (in the meaning
described in installation proposal)
and package it into one big native package. Other products
using the NetBeans IDE will rely on that package as the
final deliverable from NetBeans team and will depend
on it, create own clusters and join them together in the final
product as proposed in the installation
proposal.
The major problem of this solution is that, if implemented,
NetBeans will use different style of execution (without clusters)
while any other product based upon them will
have to rely on this feature. Another problem is that whole IDE
is too big to form a compatibility domain.
|
Create multiple set of clusters covering the natural
compatibility
domains and package each of them into one or more
native packages.
Possible risks include the not still clear separation of things into
compatibility domains and also in the necessary changes
into build system as
suggested in appendix of installation proposal.
|
Let's use two cluster approach. One for platform,
one for rest of the ide.
The complexity of changes in build system is not high (see
issue
36634) and that way NetBeans will
rely and test the same mechanism as products based upon.
|
We have to produce native packages. Other teams have to use them
and not include NetBeans as part of their packages. That means
changes in their build processes if they are not correct.
We have to
update installer
and autoupdate.
|
|
| Command Line And Locking Of User Directory |
| Problem Description |
Minimal Solution |
Maximal Solution |
Pragmatic Solution |
Influences |
|
Warn user when more than one instance of NetBeans is running.
Status: Done
|
Create a lock file in $userdir
directory to signal that an instance of NetBeans is running.
|
Very close to minimal.
|
Minimal is fine, especially because it is already implemented.
|
None known.
|
|
Ability to run on multiuser machine
and provide solution to clashing TCP/IP ports.
Status: Done
|
Write the random number of just opened
socket server port to
the $userdir/lock file and make it the only
and major port for communication with the running IDE.
|
Similar to minimal, just with better
(more stable API - right now it is clasified as friend API)
support for other modules to talk to the running NetBeans.
|
Minimal is fine and it is already implemented. Stable API with
better documentation would
be perfect, but definitively is not a defining feature.
|
The teams build products around NetBeans core have to check
that they do not rely on opening sockets on fixed port and
if so, they have to use the major socket to negotiate the
actual port number they are looking for.
|
Command line options have to be getopts complient (e.g. start with
-- ).
Status: Done
|
We will rewrite the all command line handling code to accept
-- options (we may keep - variant working for
backward compatibility).
|
As various modules in NetBeans
need to extend the command line
we more over need a solid and stable API for such extensibility.
That API would allow extensibility as well as enforce
getopts complience with optional fallback to non-standard
options when no get-opt one was found.
|
The minimal is enough. Creating stable API is desirable but not
necessary, because most options are handled in platform anyway
(with the exception of --open ).
|
Every team has to update its options to be compliant.
|
|
| Layout Shall Match OS Conventions |
| Problem Description |
Minimal Solution |
Maximal Solution |
Pragmatic Solution |
Influences |
Do not put other things than binaries into bin
directory. Do not use name system
as it has other meaning on Unix.
Do not put architecture independent files into lib
but into share.
Status: Done
|
Let's cleanup the bin. Move config file and the
generic launcher as
suggested. Explain that the requests for the rest are not
reasonable.
|
Implement the full proposal.
|
Implement the changes in build system to support
flexible layout
and then choose between the minimal and maximal solution based
on the experiments and evaluation of their impact.
|
We will have to update build scripts to create files in new
locations (lib/core.jar, lib/ext,
launchers). We will have to fix high level testing tools to
invoke other launchers and hook into the system in different
places.
|
|
Map the logical layout into physical ones on various operating
systems.
Status: Skip
|
Do not do any mapping, Select a directory and under it use the
logical layout.
|
Implement the full proposal.
|
It should be ok to stay just with minimal proposal.
|
None.
|
|
Change user directory to match the logical layout.
Status: Done
|
Update the directory to match the logical layout, whatever
it will look like.
|
Implement the full proposal.
|
Use the minimal and at least separate logs from configuration
as right now they are mixed.
|
Will influence test tools and documentation, as logs are
referenced by them.
|
|
