Introduction General Questions What is openInstaller? This project introduces new set of tools and best practices for the delivery, installation and updating of Sun software. Several functional areas are addressed with well defined interface groupings: Installation Platform Data Model: This abstract model provides the metadata and design documentation necessary to produce most of the implementation described below. Packaging and Assembly: Definitions of platform-neutral package data model, tools used to build, assemble, and deliver products to customers. This includes a set of platform packaging abstractions and concrete implementations for supported formats (RPM, SvR4, MSI, etc.) Registry: Registry architecture, including updated software registry APIs, platform-specific registry adaptors, enhancements to existing Solaris registration mechanisms in support of a non-root install, and support for multiple instances of products on a single system. Configuration: initial install configuration APIs and product-specific config adaptors used to do basic product configuration and re-configuration. Install Engine runtime: Architecture of functional components making up the runtime. External control points used by client applications. What other open source projects does this project use? Various open source projects are used in this project. The runtime components include:
There are many more optional open source components used in this project (for example, the use of checkstyle to optionally check the health of the source code during the building of openInstaller). What is the overall technical approach taken by this project? This project's overall technical approach revolves around a declarative installer engine which takes, as input, a set of human-readable (and editable with widely available tooling) metadata, along with product content, and performs operations on the target host (usually installation, but also incremental install, and uninstall. Upgrade is potentially being added later but is not specifically part of this case.). The operations this project performs are defined in terms related to an abstract model used throughout the project, whenever possible. Operations are then mapped to concrete platform implementations as late as possible during the execution phases. In addition, it is expected that there will be follow-on projects to implement tooling for management of this metadata (e.g. GUI Install Builders), or management of the products themselves (e.g. distributed installers). While no specific interfaces are part of this proposal, the overall architecture is designed to be modular and flexible enough to support such an arrangement. What OS Platforms and/or Hardware Platforms is this project designed for? This project is cross-platform and as such can be supported across popular Unix's and Windows OS releases. There is very minimal platform-specific code (for example, a small shell script to discover the installed OS patches). What locales/languages are supported? Currently, translations are included in the product for the following languages/locales:
- C (Posix)
- American English (en_US)
- German (de_DE)
- French (fr_FR)
- Japanese (ja_JP)
- Korean (ko_KR)
- Simplified Chinese (zh_CN)
- Traditional Chinese (zh_TW)
Additional translations may be supplied by developers in the future. What interfaces are exposed to me, when creating an installer? There are many interfaces (e.g. features) of openInstaller that you can use to create your installer. There are too many to list here. The Documentation Depot contains all the user documentation one would need, and a quick start is available for the impatient. How do I run openInstaller? It is important to first understand that openInstaller is a framework, not a standalone application. That is, it makes no sense to run openInstaller on its own. You, as an install author, would use openInstaller to create a standalone application which is used to install your software product/project. Having said that, the main entry point for the install engine is called engine-wrapper (engine-wrapper.vbs on Windows). It is effectively a wrapper around the Java VM invocation, saving the user from discovery and invocation of the often complex and lengthy java VM command line. However, end users will rarely if ever invoke this command. Instead, projects/products which ship will most often supply wrappers around this command, exporting their own CLIs as necessary for the product. In addition, Java Webstart can also be used to supply a web-enabled startup mechanism. For example, users can simply visit your project's webpage, and click on a link to install and use your product. Downloading openInstaller Where can I get openInstaller? Download the latest version from the downloads page. What should I download? If you are interested in building an installer for your application, you should download the "Sample Installer" from the downloads page. This sample installer contains a fully-functional installer which installs a fake product. Since openInstaller is fully declarative, all of the files that make up the sample installer are easily editable in-place. Once a file is edited, the install application can be re-run to see the effects of the edits. In this way, one can take the sample installer, change a few strings (e.g. the names of the product, and/or the names of the zip files), and create a new, working installer for a different product! If you have downloaded openInstaller before, and/or have a working installer application, you probably want to download the latest binary istribution of openInstaller (which is also included in the sample product above). This allows you to simply swap in a newer version of openInstaller without changing your metadata. If you are interested in building and changing openInstaller, then you'll need to download the source code code snapshots and follow the build instructions. Also, check out the other section of this FAQ, #Questions for Developers of openInstaller. Using openInstaller OK, I've downloaded it. Now what? If you have downloaded the sample installer, simply extract to a temporary folder, and run the product-installer (double-click on product-installer.vbs on windows). This will run the sample installer, and you can install the sample product into a different temporary folder. After you've done that a few times, you may want to start playing with the install metadata. For example, go into the Metadata/dependency directory, open up TestProductA.xml using your favorite text or XML editor, and change the name of the product:
<Description>My New Test Product A Name</Description>
save the changes to the file, then re-run the installer to see your changes. The structure of this sample product is a typical structure containing a top-level product script (product-installer), which is a simple wrapper around the openInstaller entry point (engine-wrapper). Questions for Developers of openInstaller |
