Installer3rdPartyDistrosNBIImplementation

__Implementation Details for "NetBeans + 3rd party modules" Installer (NitroInstaller)

Contents

Description

This page contains defails regarding possible implementation of "NetBeans+3rdParty Modules" Instraller that can be done using NBI engine.
NBI Installers are available for

  • Windows
  • Linux
  • Solaris
  • Mac OS X (not used as the official NetBeans IDE Installer)

UI mock-ups

How the NitroInstaller would differ from source NetBeans Installer for the end users in tearms of UI?
It really depends on which NetBeans disribution is used - singlepack (Cpp/Ruby/JavaSE/PHP/Mobility), packs + servers (JavaEE) or full (All).
The possible solutions (mock-up) are :

  • Single Pack : Place plugin info to first "Welcome" panel
    Mockup
  • Single Pack : Place plugin info to first "Welcome" panel, with checkbox
    Mockup
  • Java EE Pack : Place plugin info to first "Welcome" panel besides the servers
    Mockup
  • Any distribution : Place plugin info on the separate panel
    Mockup
  • All distribution : Place plugin info to first "Welcome" panel
    Mockup
  • All distribution : Customization panel view
    Mockup


Transmutative Self-Recreating Installer

This way of installer implementation is of easy usage for NitroInstaller developers, but requires a lot of implementation work by Installer Team

Creating Installers Overview

The typical use case in this way is that the developer, who creates NitroInstaller, run installer from command-line with a certain list of parameters with the main one - the path to module descriptor.
The module descriptor is likely the XML file that includes the following information:

  • path to modules (nbms)
  • target cluster (extra for default)
  • dependencies on netbeans packs (nb-base, nb-javase, nb-javaee, nb-soa, nb-uml, nb-php, nb-ruby, nb-cnd, nb-javame)
  • minimum JDK version (if it is not that same as NetBeans requirement - JDK5)
  • module name and description (with I18N support)
  • short identifier (
    [AZ\-]+
    )
  • version (
    [[09 | 0-9]]+.[[09 | 0-9]]+.[[09 | 0-9]]+.[[09 | 0-9]]+.[09]+
    )
  • NetBeans distribution id

Notes

  • The installer would read this file, handle the data provided, prepare modules for including in installer and then assemble everything in the new installer file.
  • This scenario require having 4(5) platforms for build - Windows, Linux, Solaris x86, Solaris Sparc and Mac OS X, if necessary.
  • This requirement comes from the fact that GlassFish is platform-dependent : if developer would use non-glassfish bundles (javase/ruby/cpp/php), then it is possible to create 4(5) installers at once having only the one developer system.
  • The same thing for mobility - currently it bundles WTK2.5.2 that is platform dependent and works only for Windows/Linux.


Tasks to be solved by Installer Team

  • Create a DTD/Schema for plugin descriptor and means to parse it
  • Find out the way to include "create NBI component from data + descriptor" functionality in the engine itself (ant tasks, scripts, etc) and invoking it on demand
  • Create a panel (extend existing ones) to show users that particular plugin is been installing together with NetBeans with providing its name, description and checkbox for disabling.


Tasks to be solved by NitroInstaller Team

  • Create the descriptor


Pros and cons

Pros:

  • Almost no pain for our Customers (NitroInstaller developers)
  • Can be tested by NetBeans Installer QE thus we can even control external installers that we don`t create

Cons:

  • Too much development for Installer Team
  • Requirement to have 4(5) build machines for Full distributions
  • Unified experince for all customers (no much ways to customize L&F, panels, etc)


Extended NetBeans Installer

This way of installer implementation is of easy implementation by Installer Team, but more work is required for NitroInstaller developers.

Creating Installers Overview

This scenario means that NitroInstaller developers should create "wrap" their plugin with NBI infrastructure and build NetBeans Installer the same way that NetBeans does.
In brief, they should create NBI component description, build infrastructure, implement configuration logic and set up the build. They should use binary builds of the NetBeans - thankfully they are available in public.

Notes

  • The risky points here are that some of NetBeans componenents (glassfish images, OpenESB builds?) are not available publically but it is solvable.
  • The developer requirements are : Ant 1.7.0, any recent JDK5 update and Unix system for building (building on Windows is possible but result in loss of permissions information that is critical on unixes).
  • It is also under investigation but, in theory, it is possible to publish NBI components for NetBeans (including glassfish/openesb/tomcat) - they can be used for NitroInstaller building.


Task to be solved by Installer Team

  • Create a panel (extend existing ones) to show users that particular plugin is been installing together with NetBeans with providing its name, description and checkbox for disabling.
  • Provide ExtendInstaller Team with instructions and possibly stubs/examples/templates how to configure, extend and build their installers.
  • Update wiki with various developer information, tips and tricks, best practices, etc ...


Task to be solved by NitroInstaller Team

  • Create NBI product infrastructure for the plugin based on the templates provided
  • Extend installer according to their needs


Pros and cons

Pros:

  • In brief : it is a good chance for NBI adoption for community (extend NBI, update docs, and, provide with ready-to-use developer kit ("make installers for NetBeans and your plugin"))
  • Customers can create installers how they like and can include things they like (e.g. create JavaSE+UML bundle or JavaEE+JBoss).

Cons:

  • Setting up the build infrastructure can be not trivial for Customers (anyway it is less pain that have 5 build machines...)
  • We don`t control the Installer that include NetBeans... thus could (very unlikely anyway) violate the NetBeans quality.


Developement Kit (DevKit)

Creating Installers Overview

This scenario means that the developer, using DevKit, will run DevKit installer. During its installation the developer will be asked for entering various information (see descriptor details above) and the result of installation would be the ready-to-run infrastructure to build everything.

Task to be solved by Installer Team

TBD

Task to be solved by DevKit Team

TBD

Notes

This infrastructure would contain nbi sources and infra (made from templates) for the new component (plugin).
It is also possible to ask user where NetBeans cluster zip files are located (either on web or locally). It is also possible that user can enter NBI registry with ready-to-use NBI components for NetBeans so that not to rebuild NetBeans.
It is also possible that at the end of installation user would be able to run (build) NitroInstaller even from this DevKit installer and see the progress.
This Kit can also be a usual NetBeans plugin (likely some kind of new project or maybe extension of current "NetBeans Module" project), not obligatory the installer. Then all the information will be configurable on its panels.

Pros and cons

Pros:

  • Easy to use

Cons:

  • A big amount of work to do.. interesting work :)
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