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.

Project Features

About this Project

openide was started in November 2009, is owned by Antonin Nebuzelsky, and has 85 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close