NetBeans 5.0 JNLP installer
This is a living document that describes the effort of creating a WebStartable
version of NetBeans 5.0. If you are looking for information about JNLP support
for older versions of NetBeans please follow to jnlpInstaller2.
$Revision: 1.29 $
Changes: available in
CVS
This document describes deployment of the NetBeans platform using
JNLP protocol. As the WebStartable NetBeans
are already reality,
first of all a quick how-to is given, describing the steps needed to convert
a NetBeans platform application to be webstartable. However as we plan to
provide more advanced support for people wishing to use this technology, the
document then continues with analysis of more enhanced scenarios and description
of ways, how they are (going to be) achieved.
Goals
[assembly - HIGH]
The configuration is available only to application administrators. They can
assemble their application tailored to needs of their users from
available netbeans.org or their own modules. In the simple case, the administrator
just selects the set of modules to form the application and the system
generates the desirable JNLP file ready to deploy to web or application server.
[demo - WAIT]
A few demo applications is going to demonstrate on netbeans.org the
ease of use and beauty of webstartable NetBeans based solutions. Candidates
for the demo app include
html editor,
instant messaging
application or a sample client to
yahoo maps written using
their maps API.
[size - LOW]
Download size matters. When multiple applications
are based on NetBeans Platform share some libraries, the
shared bits shall be downloaded just once, making the user experience much
better. Because after initial download of NetBeans Platform, getting new
application based on the same technology is going to be matter of downloading
just the extension modules. Also the download size of upgrades to new
versions shall be optimized. The server providing the JAR files
shall be able to use the
JAR diff
protocol.
[same - MEDIUM]
Make the behaviour of NetBeans based application executed under the
webstart as close as possible to the behaviour of standalone counterpart.
[allpermissions - HIGH]
The solution is primary going to support bigger - IDE like applications - that
need bigger (nearly all) privileges to access local files, execute local
processes and last but not least to store and persist user configuration
on local disk. Generating such applications must be easy from the UI, most
of the configuration options must have acceptable defaults.
[writenothing - LOW]
The platform shall be executable in a mode when it does not access local
files, create caches, etc. A possibility to provide own
persistence of user configuration
in a central place accessible from any computer on a network shall be
allowed. Moreover given the state our competition is in it may be very
tempting to support also network
applications
that run with
minimum privileges.
[codingsupport - HIGH]
The coding, building and assembly of NetBeans modules designed for
webstart usage has to be easy. Converting an existing module that works
with NetBeans Platform that uses the standard project.xml without
custom modifications to build.xml script to webstartable version shall be
matter of few minutes. Generating and deploying the global app
composed of webstartable
scripts shall be also easy. Debugging of such applications has to be
supported and easily integrated into the whole apisupport.
Non Goals
[modulemanagement]
WebStart is one of the supported installation scenarios according to the
installation document
. However its deployment technology makes it a bit special. It is clear
that there is no place for NetBeans specific autoupdate technology
and also enabling/disabling of modules during runtime makes no sense
in a webstarted application. Users simply click on a link on a website, they
get the application and use it. No further advanced configs possible.
Implementation
Status: Is identified by the background colors in the text -
red means not done yet
and planned for 5.0,
yellow means doing it now,
green is for done items.
Items not planned for 5.0 have regular background for the page.
Preparing a module for JNLP basically means to sign its JAR file,
give it the right name, put it into the desired location and generate
correct JNLP file for it. This is easy for those modules that
have just one JAR file. However for other modules this can be much more
complicated. To enumerate possible problems here is example grouping of
NetBeans module types:
- 0. Only
module.jar
- 1. Modules that use
ClassPath: extensions in manifest
- 2. JavaHelp case which contains signed extension and as such needs separate JNLP file for that
- 3. More modules that contain the same class
- 4. Modules that contain additional files like tomcat and ant
- 5. Modules that need tools.jar like jpdadebugger
- 6. Modules with JNI extensions
It seems to be possible to implement 0, 1, 2 just on
top of binary distribution of the platform. We are going to do that for 5.0.
There will be a task that given the set of module JAR files creates
appropriate JNLP files and signed version of their JARs and works correctly
for modules of 0, 1 and 2 groups.
Support for 3 will be possible with extensions developed in
installer/jnlp/modules
, but will not be part of the release. The part of the release shall
be the patch in
issue 58750
which allows the above code to plug in.
Modules which bundle added JAR files not in their classpaths can be supported
as of NB 6.0 using ${jnlp.indirect.jars} (q.v. harness/README).
The rest is going to be unsupported now. Althrough there is a proposal
for enhancements of
InstalledFileLocator
we are not going to address these problems in 5.0 version as we will
only allow modules to plug-in their own behaviour. There will be a
target jnlp
in nbbuild/templates/common.xml and
this one will be overridable in actual module build files. So if there
is a module which wants to take control over generation of its JNLP files,
it can. This is similar to other targets (nbm, jar, release) which already behave
this way.
Here is simple
patch implementing that target.
The NetBeans.org project is going to provide a repository of
JNLP component extensions for every release. That way all applications
can share the same components, including sample apps release on netbeans.org
as well as applications assembled and distributed from different sources.
The URL for 5.0 repository is
http://www.netbeans.org/download/5_0/jnlp/ and this is the
line that is needs to be put into suite's platform.properties to use it:
# share the libraries from common repository on netbeans.org
# this URL is for release50 JNLP files:
jnlp.platform.codebase=http://www.netbeans.org/download/5_0/jnlp/
On the other hand, nobody is prevented from keeping its own repository,
to generate such repository one uses
ant -f nbbuild/build.xml build-jnlp which creates the
JNLP files in the nbbuild/build/jnlp directory.
Also similar process to generating
own repository will happen by default when building a JNLP app for a suite
on top of binary platform. However this is going to work only for modules
of groups 0, 1 and 2.
Checking whether a module
is really from this group can be a bit tricky, but with the help of
update_tracking files it should be possible. However currently
these files are not present on JDS package distributions to
prevent autoupdate from trying to modify these directories. We shall
find another way how to prevent autoupdate from working on these directories
- e.g. $cluster/.noautoupdate file.
In addition to repository for a release, there shall be a development
version available. It should be filled on everyday basis and its purpose is
to deliver latest improvements in similar way the development update center does.
In ideal state this repository should support jar diff protocol
updates, so download size of for change are going to be minimal. That is why
the structure of the JAR repository has to follow the needed pattern
suitable for the
download servlet. However for initial release we may end up just with
the static repository.
5.0 version of the webstartable NetBeans application will very likely require
AllPermissions to run. It will use the caches and userdir the way
regular NetBeans apps use it. Userdir location shall be negotiated with
WebStart.
Later it is really desirable to give our users a choice
and do the necessary changes
to it to start without any permissions. That may require separation of
important calls into an interface with two implementations - the default
one and the one provided only when run in the JNLP container. On the other
hand any native library needs all permissions and as such as soon as one
uses native browser, the all permission mode will have to be requested
at least once for all applications sharing the native library.
A simple workaround around the browser problem is the usage of native
JDK 1.6 calls to open a browser window or native JNLP service calls to
do so. But of course this works only as a standalone window, as soon
as one needs embeded browser, there does not seem to be other way than
to go with JDIC one.
The support for creating own webstartable applications shall be associated
with a suite. Each suite customizer shall contain panels that can enable
and configure the webstart support (enable, possibly UI for keystores).
When enabled, the JNLP files for all
submodules would be generated.
The file will represent a JNLP component extension (JNLP spec 3.7.1)
for a NetBeans module. The final
webstartable NetBeans application is then going to refer to such individual
library descriptors and assemble everything that needs to be assembled into
master JNLP file referring to
all needed JNLP component extensions. For this to work on level of
ant scripts, there is a need for a way how to get list of all
code name bases for all modules that shall be included in the
resulting application, it is expected that all module dependencies
are already resolved and just including these modules will create
successfully linked application.
The suite build script shall first generate a signed version of platform JARs for
modules from groups 0, 1 and 2, fail if a module
from other category is requested and then iterate over suite module
build scripts
and call their jnlp
target. This is going to give every suite
module to do special work - e.g. handle JNI extensions.
In future versions the build script and UI could offer a shared location
of a repository for the NetBeans Platform
and the master JNLP
file would then by default refer to shared ones available on netbeans.org.
Execution of the suite will generate the JNLP file and content of the
suite repository and invoke the javaws command.
Debugging of JNLP enabled suite would invoke the javaws with open sockets
or mimic the invocation of it with plain java command and then connected
to the running application from the NetBeans IDE.
References
Contact
The WebStart support still needs more work, so if you have anything to add, please
contact us at
nbdev@ mailing list.
