See: Description
| Package | Description |
|---|---|
| org.netbeans |
The heart of NetBeans Runtime Container. Handles lifecycle of installed modules and OSGi bundles.
Launcher does not provide netbeans.system_http_proxy and
netbeans.system_http_non_proxy_hosts properties anymore.
Proxy settings are now detected in Core Network module.
See org.netbeans.CLIHandler.server for details.
NetBeans Module system is optimized to eliminate useless I/O operations on start (as a result the embedded OSGi container is fastest on the planet -- with respect to application start up time). This is achieved by caching information known to have been needed in previous starts and using it rather than obtaining it again from the module JAR files.
There are various caches (like all-layers.dat, all-manifests.dat, all-resources.dat, netigso-bundles, etc. ) provided by the module system or by other subsystems of the application. Together, working in orchestration, they eliminate the need to touch the disk (which is very slow operation especially during morning launch). Btw. there is a test which verifies the caching system really works -- it is recommended for each product built on top of NetBeans Platform to copy and adjust it to verify the caches are really used.
Of course, the caches may get out of date, for example when an external tool modifies the installation layout. How can the system detect whether the caches are valid and still be usable? The only way to verify the caches are 100% correct is to regenerate them and compare whether the cached bits are the same. However that would be terribly slow and defeat the whole purpose of using caches.
As such we have the lastModified API.
Every cluster (as enumerated by netbeans.dirs
and netbeans.home properties)
is supposed to contain such file. Whenever an external tool changes something
inside some cluster, it is supposed to touch the file and change its
timestamp. That will tell the system that caches are invalid
(as their timestamps will become older than newest .lastModified file).
The caches (as introduced in invalidating caches section) are optimized to reflect the state of previous start. However that means, the very first start runs without them. This may not be a problem (if the start follows immediately after installation), however in multi user environment (when the installation is done by administrator), the first start may be slow.
To mitigate that the system offers support for shared caches. As part of installation, one can also copy certain cache files into the shared location. Those files will then be used on a first start of the system (when the user directory is empty).
To generate the shared cache files start NetBeans with an empty, temporary user directory and then copy the desired files into first cluster directory:
$ netbeans --userdir /tmp/nb -J-Dnetbeans.close=true -J-Dorg.netbeans.core.WindowSystem.show=false
$ cd /tmp/nb
$ zip -r $INSTALL/$first_netbeans_dirs_dir/var/cache/populate.zip var/cache/netigso
$ cp var/cache/* $INSTALL/$first_netbeans_dirs_dir/var/cache
$ rm -r /tmp/nb/
The meaning of populate.zip and list of known cache
files is described here.
Additional modules and subsystems may add new files however. The
ultimate knowledge is available only to those who understand overall
product installation structure.
|
|
|
|
|
|
The sources for the module are in the NetBeans Mercurial repositories.
XXX no answer for deploy-dependencies
Read more about the implementation in the answers to architecture questions.
Built on June 18 2013. | Portions Copyright 1997-2013 Oracle. All rights reserved.