Ways to improve NBI

Better Maven integration

http://mojo.codehaus.org/nbm-maven/nbm-maven-plugin/build-installers-mojo.html allows you to run NBI from a Maven-based NetBeans Platform application. But the integration is crude, relying on unpacking and running complex Ant scripts from inside the Maven goal, and customization via templateFile and userSettings requires not just Ant scripting but detailed knowledge of NBI internals.

Ideally the installer creation would be done by a plain JAR with a clearly documented entry point and list of customizable inputs, and there would be a simple Ant task wrapping that, and a simple Maven mojo wrapping it as well.

Different platforms support

Current implementation of different platforms support makes it hard to extend the existing list (windows x86/64, linux x86/64, solaris x86/sparc, macosx x86/ppc) either in terms of the platform (freebsd, aix) or in term of hardware architechute (linux-ppc). One side is that this list is hardcoded in registry.xsd, the other side is infra/build - all possible platforms are list explicitely (good thing that they can be edited easily).
We should also distinguish between "Java" platform and "System" platform and make it clear which one is used.
E.g. as for now (27.08.2008) almost all architecture (exc. Windows) is taken from java os.arch that is wrong : we can (in most cases) run 32-bit Java on 64-bit system.
Another thing is that we should have both, say, JavaPlatform.java and SystemPlayform.java. JavaPlatform can be used e.g. when we set some specific system properties - in nb-base, we have dependency on JDK, and the minumum version is 1.5.0_06 on all platforms.
The thing is that IBM`s Java reports its version only 1.5.0 (or 1.6.0) and we shoudl accept it (on Linux/PPC, AIX and also Linux/x86 and Windows/x86 but only if this IBM`s jdk is used).
Now we use NbiProperties and we can certainly use minimum.jdk.version.aix=1.5.0 but it is not clear how to archive the same on windows : how to allow JDK >1.5.0_06 from Sun and >1.5.0 from IBM. At least, with the current implementation it is hard.

No property container for main wizard

We don`t have default property container for the main wizard (Issue 123866).
Kirill suggested that Registry should be such a container but is seems to be the wrong way : if we install some products and uninstall them, then the registry should be empty - but it should not be the case with such a strategy (using Registry as PC). The alternative solution is to have a default implementation of property container and use it in the wizard.

Cross-product integration

Now it is hard (and sometimes forces to double efforts) while integrating different products with each other (netbeans with tomcat, glassfish, appserver)

Backward compatibility

Adding/removing certain functionality from NBI core/NB.Ext can lead to exceptions.
The simliest example is adding class in NB.Ext that is used by the logic of any installable product. After installation of such a product and running uninstaller for previously installed products will lead to NCDFE when initializing the logic of the new product and validating the product installation. It is better described at Core vs. Extensions document.

Command-line arguments

There is hardcoded set of possible NBI engine command line arguments. It is not possible to extend them in the extensions.
Support for arguments should be made more general - e.g. providing special interface (and move all currently arguments to implementations) for setting command-line args and its functionality as well as registering those implementations.
Already done. Changesets 1,2,3,4,5
More info is available at this page.

Integration with system package managers and uninstallers

Currently there is no much means to customize uninstaller as well to get path to it (e.g. inside the product logic to make a shortcut to it in Start Menu).
Some more thoughts at Issue 148240 and Issue 148342.

Better support for product installation using their own silent installers

Currently the silent installer is placed to the installation location and then is executed.
Probably we should place it to a temporary location and point the installation directory to be used by this installer as the target one.
Additionally there should be some helpers to handle silent installation - similar to ProgressThread used in jdk and mysql.

Make product installation steps be customizable and more general

Now the flaw if product installation is all the same and lives in Product.install().
It can be useful to put all those steps into different classes and add the possibility for the each product to manage them and extend.

Create state file without installation

We should provide an option to create state file without actual installation.
It can be resolved by adding third ExecutionMode e.g. NO_INSTALL.

Split Registry into small parts

As for now Registry class is about 80K (2K lines) of pure Java code (there is almost now javadoc). It would be fine to split into small parts but keep in mind that all current public fields declarations should be left.

Console installation

Console mode installation is worth to be introduced in addition to gui and silent.

Enhance downloader

Current downloader is well designed but purely implemented, e.g. multi-threaded download of the same file is not possible. We had another (initial) implementation in infra/sandbox, it`s worth to revisit its functionality for making the extension..

Revisit infrastructure scripts for native code compilation (jnilib, launcher, cleaner)

Current work with precompiled binaries is fine but we need to get back one day to check that compilation via satellite systems is still working perfectly.

Enhance shortcuts

Now we can create only two types of shortcuts - desktop and start menu (applications menu).
We can add support to Quick Launch (windows) and any other as well.

Mac OS X quit handler

Probably it`s a good idea to move Installer.initializeMacOS() method to SwingFrameContainer.initComponents() besides to addWindowListener call. The method contents should be likely the same - if cancel button is enabled then 'click' it. If not then maybe force critical exit or get wizard and call finish() as the method of the FinishHandler. Or probably do not even check if cancel is enabled.. (the problem is to get wizard instance from container.. and get it finish handler. Likely to call Wizard.getInstance().. or maybe put this initializeMacOS() code in Wizard.open()
NbiFrame is also can be such a place.
Partially done in changesets 1 and 2

Add tar(.gz|.bz2) support in infra/build

Already done Part 1, Part 2, Part 3.

Add symlinks support in infra/build and in the engine

Add support to iterate over platforms without writing explicit calls with each platform set in product`s build.xml file

See e.g. glassfish v2 build.xml.

Destination Panel (and others) checks

Now the destination panel performs a lot of checks on the text in the field. It would be fine to put them into separate classes (?) and give possibility for developers to use a subset of that checks or add their owns.

Free space check issue with bundled JVM

When JVM is bundled, the free space check does not work correcly on the launcher step: it does not check the space needed either to run the self-extracted archive or to unpack pack200-ed jars.

Exit codes

Exit codes values in Windows and Unix launcher should be consistent.

Reusing Java LogManager

Java has a brilliant log manager but we use our own. It required to anylize at this point which advantages gives us our own LogManager implementation.

Support for opening browser with required pages

Currently this functionality belongs to registration support but it should be moved to Utils.

No synchronizeTitles() method in CompositeProgress

There is no synchronizeTitles() method in CompositeProgress - I am not sure that it is intentionally or because of no need of this feature by NBI core.
In fact it result in the fact, that using progress.setTitle() within the product configuration logic install/uninstall methods does not result in showing the required title.

x64 bit : Java and System

Tracked as the Issue 143434.
Currently we using x64 bit of JVM to determine if system (and thus Platform.getHardwareArch()) is 64-bit or not. This is definitely wrong since it is possible to run 32bit JVM on 64bit system.
We should find a solution to check OS real 64-bitness in case of running on 32-bit JVM.

  • for Windows it can be done using WindowsRegistry.IsWow64Process()
  • for Linux - by checking 'uname -m/-p' == x86_64
  • for Solaris it can be done using e.g.
    'isainfo -b'
  • for Mac O SX it can`t be done using uname arguments, probably it can be solved by creating of 64-bit binary and executing on the platform... (unfortunately, this does not work:( I`ve created binary only with x86_64 and ppc64 arch and it was successfully executed on Tiger..)
  • for Generic Unix support - it is not clear as well... likely checking for the same 'uname -m/-p' / 'getconf LONG_BIT' and comparing it with some possible 64-bit values (x86_64, x64, amd64, ia64).
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo