Skip to main content
Jump to: navigation, search

Eclipse Oomph Authoring

Revision as of 07:07, 12 October 2016 by (Talk | contribs) (How to extract the constituent parts that comprise the Windows self-extracting installer executable)

Getting Started

What is Oomph?

Please read Eclipse Installer.

Installing Oomph

  1. Download and install the Eclipse Installer as outlined in Eclipse Installer.
  2. Make sure that the Oomph setup SDK is installed in your IDE. Either:
    1. That's already the case because your IDE is a Mars M5 or later Eclipse Package, or
    2. Start the installer and install an IDE of your choice (select on the first installer page), or
    3. Use p2 to install "Oomph Setup SDK" from

Creating a Setup Project Model

Using the Setup Project Model Wizard

  1. Create an empty project in your workspace or select a folder in an existing project. You'll create the new "Setup Project Model" in the selected folder.
  2. Open the New... dialog and select the "Setup Project Model" wizard:
  3. Select one of the provided templates (e.g.,,, or Simple) and adjust the displayed values:
  4. Some values are automatically derived from your input to fields higher up.
  5. Open the Preview>>> to understand the impact of changes to the current field.

Using the Setup Editor

  1. Open the resulting setup file with Oomph's Setup Editor:
  2. Configure the tasks in the Properties view. Note that there are "Expert" properties available.
  3. Add setup tasks to your project and/or to your project streams and configure them, too.
  4. The Outline view displays a preview of the executable model with resolved variables.

Testing the Setup Model

  1. To test/execute your new setup model:
    1. Start the installer and, if necessary, switch to the Advanced Mode via the dialog menu.
    2. Pick any product on page 1 and click the Next button to proceed to page 2.
    3. Drag and drop your .setup file onto one of the top-level catalogs ( or in the projects tree. Your project will appear as a subproject of the special <User> project.
    4. Double-click your project to add it to the table at the bottom of the page. There you can select a project stream in the Stream column. Press the Next button to proceed to the Variables page.
    5. Fill in the empty fields and press the Next button to proceed to the Confirmation page.
    6. Click Finish to start the installation process. The installer will first bootstrap a new IDE and then launch it to complete the installation at startup time.
  2. Chances are that your first model contains errors. Always turn on live validation in the Setup editor to get early feedback. If the installation fails early and the new IDE doesn't come up go back to Using the Setup Editor. If the IDE comes up but the initial configuration fails continue with step 3.
  3. In the new IDE (whether the initial configuration was successful or not) open your model file from the main menu, Navigate → Open Setup → Branch.png. Find the problems and fix them. Then start the setup process from within this IDE via the main menu, Help → Update.png Perform Setup Tasks…. This "manual trigger" will pop up a confirmation dialog before starting the setup process so that you can review what tasks are scheduled for execution.

Contributing to a Project Catalog

When you are done authoring your model file (including testing the installation) commit/push it to the master branch of one of your Eclipse Git repositories. Find the plain URL of this file in and submit a bugzilla asking for the inclusion of your model into the main index. Paste the Git plain URL of your model into the bug description.

The same can be done if your project is not an Eclipse project, but hosted on GitHub. Simply state this fact in the bug description and paste the "raw" content URL to the file instead.

Understanding the Setup Engine

Understanding Setup Tasks and Scopes

The setup engine collects the setup tasks that are needed for a particular installation from a number of places called scopes. Some scopes can be nested and nested scopes generally inherit the tasks of their parent scopes. A setup is fully described by the following local entry scopes:

  • The Installation scope is located in eclipse/configuration/org.eclipse.oomph.setup/installation.setup and contains tasks that are specific to this installation. In addition (and more importantly) the Installation scope points to exactly one Product Version scope (see below) in order to make all tasks (including inherited tasks) of that product version apply to this installation, too.
  • The Workspace scope is located in workspace/.metadata/.plugins/org.eclipse.oomph.setup/workspace.setup and contains tasks that are specific to this workspace. In addition the Workspace scope can optionally point to a number of Stream scopes (see below) in order to make all tasks (including inherited tasks) of those streams apply to this workspace, too.
  • The User scope is located in user.home/.eclipse/org.eclipse.oomph.setup/setups/user.setup and contains tasks that are common to all installations and workspaces (unless they're restricted to particular installations or workspaces).

The following additional scope types exist, so they can be referenced by the entry scopes:

  • The Catalog Index is the root scope and contains nested Product Catalogs and Project Catalogs.
  • A Product Catalog contains nested Product scopes and possibly a small number of tasks that are common to all nested scopes. Nested products may be contained directly or be linked in from separate files.
  • A Product contains nested Product Version scopes and possibly some tasks that are common to all nested scopes.
  • A Product Version contains no nested scopes but tasks that are specific to that product version.
  • A Project Catalog contains nested Project scopes and possibly a small number of tasks that are common to all nested scopes. Nested projects may be contained directly or be linked in from separate files.
  • A Project contains nested Stream and/or (Sub-) Project scopes and typically some tasks that are common to all nested scopes.
  • A Stream contains no nested scopes but tasks that are specific to that stream.

The resulting list of tasks is then flattened, that is, compound tasks (folders) are recursively replaced by their contained tasks. Disabled tasks (see the editors context menu) are removed from the list. Tasks that are restricted to scopes that are not chosen for the current installation/workspace are also removed. Tasks that are excluded from the current trigger (one of Bootstrap, Startup or Manual) are also removed.

The remaining list is then partially reordered according to a number of criteria such as task priority (hardcoded), variable references or explicitly authored task requirements (successors and predecessors in the expert properties). If no such criteria apply the tasks are kept in their authored order as much as possible.

Some types of tasks allow only one instance in the list of tasks. For example only one variable task (see below) with a given variable name is allowed to execute. To specify several of them (with the same name) is perfectly okay, but you should notice that the earlier (according to the established order; see above) tasks are replaced/overridden by the later ones. This way, for example, a user can always override such tasks from any high/early scope, e.g., the Project or Stream scope, in his local User scope.

Now variable references in all String attributes of the tasks and their child elements are resolved and replaced by their expanded values. For details see Declaring and Using Variables below.

Then the engine calls the isNeeded() method on each task in the list and removes those that are not needed (possibly according to the state of the running IDE).

If now the list of needed tasks is not empty a confirmation dialog is displayed and when the user presses Install the perform() method is called on that tasks. The progress of the installation process is then displayed in a progress dialog. The installation can be canceled at any point in time.

Declaring and Using Variables

Variables play a very important role in the execution process. While a project model can perfectly work without the declaration or use of variables the model is typically more flexible with them. A variable must always be declared with a Variable Task somewhere in the model. It must have a name and can have a value or a default value.

If a variable is declared without a value a prompt dialog is displayed early in the execution process. The user can enter the missing variable values, which are then stored as variable tasks in the User scope (see above). These stored variable tasks are restricted to the scope that originally declared the variable. At execution time these User-scoped variable tasks override the respective variable tasks that you have declared in your project model.

Important: Prompted values of variables that are declared with the type PASSWORD are not stored in user.home/.eclipse/org.eclipse.oomph.setup/setups/user.setup but rather in an Equinox Secure Storage node. The setup framework ensures that they are never shown in the user interface.

You can use variables (refer to them) in any String-typed or URI-typed attribute of your model. The general syntax is:


To prevent a variable reference from being expanded (e.g. you actually want to have the value '${var}' and not the value of "var"), you need to escape the variable syntax with an extra double dollar character. So "$${var}" will result in "${var}".

In addition to the variables that are declared by VariableTasks you can refer to all of the following:

  • Attribute values of setup tasks with a defined ID. The reference syntax is ${taskID.attributeName}.
  • System properties as returned by System.getProperties()
  • Environment variables as returned by System.getenv()
  • Predefined variables as determined by the setup engine from the user input to the installer (see below)

Predefined Variables

The following variables are predefined by the setup engine: The value of the name attribute of the current installation scope.
scope.installation.label The value of the label attribute of the current installation scope.
scope.installation.description The value of the description attribute of the current installation scope. The value of the name attribute of the current workspace scope.
scope.workspace.label The value of the label attribute of the current workspace scope.
scope.workspace.description The value of the description attribute of the current workspace scope. The value of the name attribute of the current user scope.
scope.user.label The value of the label attribute of the current user scope.
scope.user.description The value of the description attribute of the current user scope. The value of the name attribute of the current product catalog scope.
scope.product.catalog.label The value of the label attribute of the current product catalog scope.
scope.product.catalog.description The value of the description attribute of the current product catalog scope. The value of the name attribute of the current product scope. The concatenated value of the name attributes of the current product scope and its parent scopes.
scope.product.label The value of the label attribute of the current product scope.
scope.product.description The value of the description attribute of the current product scope. The value of the name attribute of the current product version scope. The concatenated value of the name attributes of the current product version scope and its parent scopes.
scope.product.version.label The value of the label attribute of the current product version scope.
scope.product.version.description The value of the description attribute of the current installation scope. The value of the name attribute of the current project catalog scope.
scope.project.catalog.label The value of the label attribute of the current project catalog scope.
scope.project.catalog.description The value of the description attribute of the current project catalog scope. The value of the name attribute of the current project scope. The concatenated value of the name attributes of the current project scope and its parent scopes.
scope.project.label The value of the name attribute of the current project scope.
scope.project.description The value of the name attribute of the current project scope. The value of the name attribute of the current stream scope. The concatenated value of the name attributes of the current stream scope and its parent scopes. The value of the label attribute of the current stream scope. The value of the description attribute of the current stream scope.

Variable Extensions

You can also extend variable references that evaluate to file system paths by adding a forward slash notation of the nested path before the closing brace. The advantage is that the full resulting path is formatted in the OS-specific form, e.g.:

  ${installation.location/git/myproject} evaluates to C:\develop\installation1\git\myproject on Windows

After the path extension part you can add filter calls with pipe symbols. Filter names are generally case-insensitive. Multiple filters can be chained. Example:

  ${installation.location|uri}/git/myproject evaluates to file:/C:/develop/installation1/git/myproject

Variable Filters

The following filters are currently available:

file Converts a file: URI to an OS-specific file system path.
fileExtension Extracts the file extension from a URI or a file system path.
path Extracts the path segments from a URI.
basePath Removes the last segment from a file system path.
lastSegment Extracts the last segment from a file system path.
uri Converts a file system path to a file: URI.
uriLastSegment Extracts the last path segment from a hierarchical URI or the authority from an opaque URI.
canonical Canonicalizes a file system path.
gitRepository Extracts the name of the repository from a Git URI (excluding a possible .git suffix).
upper Converts all characters of a String value to upper-case.
lower Converts all characters of a String value to lower-case.
cap Capitalizes the first word of a String value.
allCap Capitalizes all words of a String value.
camel Converts a qualified name to camel case notation.
qualifiedName Converts a camel case String value name to a qualified name.
preferenceNode Escapes all forward slashes (/) of a String value, so that the result can be used as a value in preference nodes.
property Escapes all double back slashes (\\) of a String value, so that the result can be used as a value in properties.
propertyValue Interprets the String value as a preference property path and returns the value of that property.
username Escapes all "at" symbols (@) of a String value, so that the result can be used in URI that contain a username.
length Converts a String to a String that contains the alpha-numerical representation of the length of the original String.
trim Removes all whitespace from the beginning and the end of a String.
trimLeft Removes all whitespace from the beginning of a String.
trimRight Removes all whitespace from the end of a String.
trimTrailingSlashes Removes all slashes and backslashes from the end of a String.

Variables from Outer Scopes

When looking for declared variables that you can use in your model also have a look at the Outline view that displays variables from the outer scopes. For example the current Project Catalog file for projects contains declarations for some useful variables:

  • jre.location-1.4 --> The folder containing a 1.4 compatible JDK/JRE for architecture ${os.arch}
  • jre.location-1.5 --> The folder containing a 1.5 compatible JDK/JRE for architecture ${os.arch}
  • jre.location-1.6 --> The folder containing a 1.6 compatible JDK/JRE for architecture ${os.arch}
  • jre.location-1.7 --> The folder containing a 1.7 compatible JDK/JRE for architecture ${os.arch}
  • jre.location-1.8 --> The folder containing a 1.8 compatible JDK/JRE for architecture ${os.arch}
  • --> The Eclipse user ID for Git/Gerrit commits
  • --> The Eclipse author name for Git/Gerrit commits
  • --> The Eclipse author email for Git/Gerrit commits
  • --> The Eclipse user ID for Bugzilla/Hudson
  • eclipse.user.password --> The Eclipse password for Bugzilla/Hudson

The advantage of having these variables be declared in a project-independent scope is that their prompted values will be stored in the User scope without a project restriction. Hence users will not be required to enter these values more than once even when they install additional environments. Of course they can be edited in the User model at any time.

Environment Variables

The recommended form of variable names is the dot-separated notation. Note that it is typically not possible to define environment variables with dots in their name. If you want to define variables in your process/system environment use underscores instead of the dots; you can still refer to them via dot-notation in your models.

Tips and Tricks

Getting Early Feedback

Why didn't the model editor tell me earlier that I've made a silly mistake? Please enable Live Validation in the editor menu to get early feedback.

Copying Tasks and Other Elements

The Setup Editor supports the export and import of any model elements by using copy to or paste from the clipboard. The clipboard will/must contain a valid XML document. With this method, for example, you can easily copy task snippets from your model directly into a forum post when you ask for help (or into a Skype window when you chat with your collegues). Or you can easily paste such XML snippets from forum replies directly into your Setup Editor.

You have access to many example setups from within your IDE! Use Navigate->Open Setup->Parent Models->Open Catalog Index to investigate everything within the index. The context menu provides a way to open elements in a text editor. This is particularly handy for finding out where a particular setup is hosted (hrefs are resolved in the Setup editor) - one use case is checking and repairing links to project setups added to your user projects.

Hosting your own index / catalogs

If you want to host your own product or project catalog, you must provide a URI mapping to the installer to locate the root setup file (the "index"). Open the eclipse.ini file and add an oomph.redirection.<some_id> where some_id is any unique identifier. The root EMF model is an Index and must be stored in the file org.eclipse.setup. Use as a starting point. All of your other setup models can be stored in any file name you desire. You must also copy all of the model files in to your redirection <path>/models/


The source URI may be abbreviated to index:/ and the target URI may also be a file URI, e.g. on a shared file server.

Bug 481580 has introduced empty redirectable catalogs for products (redirectable.products.setup) and projects (redirectable.projects.setup) to the Oomph index. These allow providing your own catalogs without replacing the entire index or disabling the catalogs shipped with Oomph (by redirecting them). The following steps are necessary to make use of those setups.

  • Create your own catalog setup file. Project setups should be referenced using absolute URIs only, otherwise redirection will become very messy.
  • Add a redirection task as described above to the eclipse.ini file (e.g. -Doomph.redirection.myProjectCatalog=index:/redirectable.projects.setup->...).
  • Your catalog setup file must contain an EclipseIni task creating the same redirection! Otherwise your catalog will not be visible in the Eclipse created by the installer and hence the projects selected from it cannot be installed.
  • The first time, you may have to enable your new catalog by selecting it in the folders icon of the drop-down in the upper right hand corner of the wizard's Projects page, otherwise it will be invisible.

To debug the processing of -Doomph.redirection.* if needed, set a breakpoint in org.eclipse.oomph.setup.internal.core.util.SetupCoreUtil.configureResourceSet(ResourceSet) within if (((String)key).startsWith(SetupProperties.PROP_REDIRECTION_BASE)).

Shipping your own index

If you want to include your own product or project catalog, you may ship the root setup file (the "index") relative to the installer directory. Then you can redirect the index as explained in Hosting your own index / catalogs. For example, you can place all setup files in an eclipse-installer/setups/ folder and then redirect access to it with a relative target URI:


Note that shipping the index rather than maintaining it in a central location (accessible to all parties interested) has the following disadvantage. As each user has her own copy of the index, updates in the setup files will not be distributed automatically.

Generating PDE Target Definition files (*.target) and their use by Tycho

Oomph can automagically generate a *.target files compatible with the PDE target definition file format (*.target) for you from your *.setup model. This is particularly useful if used in combination with Tycho's support for them, see, as it allows you to maintain p2 Repositories and Requirements in one single place, and have that be used both for workspace set-up and builds.

To generate a *.target file, add an Annotation similar to the example found in Oomph's own setup model (see here, like so:


Note that the *.target file will be updated (or initially generated if first time) each time that Oomph Performs Setup Tasks (and not every time you only "touch" your *.setup model). Any errors encountered while generating the *.target file are reported in the Setup Log as usual.

TODO Document what preferredRepositories, PomModulesUpdater & PomArtifactUpdater do...

Setting up WST Server Runtime and Instances in your Project Setup

Server Runtime Preference

1. Use an oomphed installation/workspace with preference recorder enabled.

2. Open your project and user setup editors.

3. Go to Preferences / Server / Runtime Environments and 'Add' it as usual.

4. Drag the selected '/instance/org.eclipse.wst.server.core/runtimes' from user to project setup.

Server Instance in Servers View

Requires server runtime to be setup first.

1. Open Servers View and create New server instance and deploy webapps as usual

2. Optionally open server instance editor and adapt configuration as usual.

3. Close Eclipse.

4. Start it again.

5. Open '.plugins/org.eclipse.wst.server.core/servers.xml' from your workspace/.metadata using a UTF capable editor

6. Add Resource Creation Task to your project setup:

     <?xml version="1.0" encoding="UTF-8"?>
       <description>tomcat server integration</description>

7. Use the resource task content dialog to put the servers xml content into the task.

8. Copy "Servers" project from this workspace into a suitable location of your branch checkout and add/commit/push.

9. Setup project import task that can pick the Servers project up from that committed location.

That's it. If you want to share it among fellows, be sure to agree on canonical paths for your server installations.

Suppress prompt for default workspace already upon very first start

Adjust the SHOW_WORKSPACE_SELECTION_DIALOG property to false via configuration settings org.eclipse.ui.ide.prefs ...

     <?xml version="1.0" encoding="UTF-8"?>
         excludedTriggers="STARTUP MANUAL"

Open default perspective already upon very first start

Examples below using Perspective ID for Java perspective.

Tell Eclipse which perspective to open initially, by adding option to eclipse ini:

     <?xml version="1.0" encoding="UTF-8"?>

Setting a perspective to be default, by adding preference task:

     <?xml version="1.0" encoding="UTF-8"?>

How to switch the current stream

If you would like to switch the current stream/s, you can re-use Oomph's initial "Eclipse Importer" wizard, available as "Import Projects..." in the drop-down of the Perform Setup Tasks reload action in the Oomph toolbar, or via the menu File > Import> Oomph > Projects into Workspace.

Note that it is currently not yet possible to remove the "current" project stream. As a workaround, use menu Navigate > Open Setup > Open Workspace (or if visible click the 'blue guy' icon in the Oomph toolbar) to Open Workspace workspace.setup, expand the first node, click on the Workspace entry, open Properties view, and change the last property named "Streams" and remove the current stream.

Bug enhancement may make this easier in the future.

How to install Eclipse plugins using the P2 Director and Repository Explorer

Oomph can install Eclipse plugins which you require. This also works for normal Java Projects set up models, not just for Eclipse plug in OSGi development, and is handy to install commonly used 3rd-party Eclipse plugins which are not all available from p2 sites (think e.g. Here's how:

1. add a P2 Director child task to your *.setup, if it doesn't already have one

2. add a Repository child in your P2 Director task

3. in the Properties of the Repository set the URL to a valid p2 repo (e.g.

4. right-click that Repository and choose Explore, to open the Repository Explorer view

5. in the Repository Explorer view change to [X] Compatible and (*) Minor at the lower-right hand corner

6. drag & drop the version from the Repository Explorer view into the P2 Director task of your *.setup editor, to create a Requirement child

Drag & Drop should normally work, but appears to be broken at least on Neon Milestone 6 on Linux; in that case:

6. manually create a new child Requirement inside the P2 Director task

7. in the Repository Explorer view use the brown (C) icon to switch to Expert Mode to see IDs instead of names

8. find the ID of the feature IU, it's the one with a PDE feature + folder kind of icon, often ending in (feature.)

9. in the Properties of the Requirement, type the Name to the ID found above (e.g.

10. in the Properties of the Requirement, Type should have automatically switched to Feature

PS: If you are looking for the URL of p2 repos to pre-install some of the the M2E connectors, see

How to create M2E lifecycle-mapping-metadata.xml to avoid littering your pom.xml with org.eclipse.m2e:lifecycle-mapping

Read & and apply as follows:

    <description>Initialize M2E's Maven Lifecycle Mappings, see &</description>

For "content" just open the popup using the [...] icon in the Properties and copy/paste the content from menu Window > Preferences > Maven > Lifecycle Mappings: Open workspace lifecycle mappings metadata. (This is easier than editing the content=".." in source view, because it will correctly do the XML escaping for you.)

Now whenever M2E whines about stuff like "Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack (execution: unpack-license, phase: generate-resources)" etc. just use the Quick Fix in the Problems view and choose the option to use workspace preferences (instead of letting the quick fix modify your pom.xml to add org.eclipse.m2e:lifecycle-mapping <lifecycleMappingMetadata>).

How to automatically pre-enable Gerrit

If you would like to save your end-users from having to manually enabling Gerrit for a repository in EGit, then you can use the follow magic variable which Oomph will recognize and act upon:


How to find a P2 repository at Eclipse using the Repository Explorer

Most projects don't document the locations of all their p2 update sites very well. This makes it hard to find the URL you need in order to install something or in order to specify a URL for your target platform definition. Oomph indexes all the p2 update sites available at to make this job easier. You can make use of this as follows:

  1. In the Quick Access control, type "Repository Explorer" to show Oomph's Repository Explorer view.
  2. In that view's toolbar, locate the tool item with the hover "Search Eclipse repositories by provided capabilities", i.e., the one that looks like a little search flashlight, and click it.
  3. This brings up the "Eclipse Repository Search" dialog. The index is very large so it takes a while to load it. But it's cached locally and updated on the server once per day.
  4. At the root of the displayed tree are p2's namespaces and under each of these are the capabilities in that namespace. They're organized hierarchically by their qualified name. It's all quite technical and the tree is very large. So while you can explore it, you'll most likely want to use the filter to find something quickly.
  5. Type the fully qualified name of a Java package or installable unit you wish to locate into the filter. Note that tree items for which there exist a concrete version in some repository are decorated as such. Keep in mind that many projects don't version their Java packages, so it's often better to look at the org.eclipse.equinox.p2.iu category. Here's what it looks like searching for "org.eclipse.emf.ecore.xcore":
  6. You can select a capability in the tree so that the lower panel displays all the versions of the capability that are available. Under each of those are nested the update sites that contain them. Composite update sites show their children hierarchically.
  7. Of course you can double click a repository to further explore its contents in the Repository Explorer itself.

How to extract the constituent parts that comprise the Windows self-extracting installer executable

The Eclipse Installer distribution for the Windows platform is effectively a self-extracting executable. It is extracted at runtime by the Bin Extractor. The pre-built version of this library, i.e., org.eclipse.oomph.extractor.lib-*.jar, is available in all Oomph-containing installations, i.e., in the installer itself and application installed by the installer. This library can also be used standalone to decompose the composed executable into its constituent parts. That can be accomplished if you run it with the correct magical program arguments as follow:

 java -classpath <path-to-extract-lib>\org.eclipse.oomph.extractor.lib-*.jar

The Java VM arguments need only specify the library along with the main class in that library. The first program argument is the location of the executable you wish to decompose, the 64 bit installer in this case. The remaining arguments are all best directed into a common folder, denoted as <target-path> in the example above. The second argument is extracted location of the zip file of the product/distribution. The third argument is the -export flag. The fourth argument is the extracted location of the text file containing the marker text that is used separate the parts of the composed executable from each other. The fifth argument is the extracted location of the small native executable itself. Sixth argument is the extracted location of the extractor library; the same one being used to extract the parts. The seventh and final argument is the extracted location of the product descriptor.

Of course you can edit these parts. Then you can recompose the executable using the following bash script executed within the common folder in which you have extracted the constituent parts:

 COPY /B extractor.exe + ^
   marker.txt +  ^
   extractorlib.jar + ^
   marker.txt +  ^
   product-descriptor + ^
   marker.txt +  ^ + ^
   marker.txt  ^

Note that the file names match the extracted target file names. From this is should be clear that the native executable is just a composition of parts. This structure is used at runtime as follows. The extractor.exe runs natively, reading its own executable file, using the marker text to find the parts. It checks the descriptor that if finds in order to see if an appropriate version of Java is already installed to launch the product; the native extractor consults the registry to find all installed JREs and JVMs. If an appropriate Java is not found, it opens a browser page prompting the user to install an appropriate Java version with the required bitness at the required minimum version. If there is already an appropriate version of Java, it launches a Java process to execute the BinExtract's main method. It unzips the product zip, to a temp folder, and launches the Java process for that.

Back to the top