Jump to: navigation, search

Eclipse Oomph Authoring

Revision as of 05:23, 14 June 2017 by Anders.g.hammar.gmail.com (Talk | contribs) (Setting up WST Server Runtime and Instances in your Project Setup)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


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 http://download.eclipse.org/oomph/updates/latest.

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., Eclipse.org, Github.com, 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 (Eclipse.org or Github.com) 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 http://git.eclipse.org/c 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:

scope.installation.name 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.
scope.workspace.name 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.
scope.user.name 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.
scope.product.catalog.name 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.
scope.product.name The value of the name attribute of the current product scope.
scope.product.name.qualified 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.
scope.product.version.name The value of the name attribute of the current product version scope.
scope.product.version.name.qualified 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.
scope.project.catalog.name 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.
scope.project.name The value of the name attribute of the current project scope.
scope.project.name.qualified 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.
scope.project.stream.name The value of the name attribute of the current stream scope.
scope.project.stream.name.qualified The concatenated value of the name attributes of the current stream scope and its parent scopes.
scope.project.stream.label The value of the label attribute of the current stream scope.
scope.project.stream.description 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 Eclipse.org 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}
  • git.user.id --> The Eclipse user ID for Git/Gerrit commits
  • git.author.name --> The Eclipse author name for Git/Gerrit commits
  • git.author.email --> The Eclipse author email for Git/Gerrit commits
  • bugzilla.id --> 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.

Conditional Tasks

All setup tasks support filters. Oomph reuses p2's implementation of LDAP filters. I.e., it supports a string a representation of LDAP Search Filters, RFC 1960, UMich, 1996, http://www.ietf.org/rfc/rfc1960.txt

The filter property of a setup task is an advanced property. To display this property, ensure that the "Show Advanced Properties" is enabled in the Properties view tool bar. The properties of a filter expression can generally refer to any system property or any environment variable. For example, the following filter expression on a task will ensure that it is included only when performing a task on a Linux operating system.


The latest version of Oomph allows filter properties to refer to the values of variables as defined in the setup itself. For example, this idiom can be used to express if-then-else.

 <?xml version="1.0" encoding="UTF-8"?>
 <xmi:XMI xmi:version="2.0"
       label="Example Filter">
     <description>An example of a variable used to conditionally filter tasks</description>
       name="Filter True">
         label="Property A">
       <description>The value use for system.property.a</description>
     <description>Tasks that will be present only when example.filter is true</description>
       name="Filter False">
         label="Property B">
       <description>The value used for system.property.b</description>
     <description>Tasks that will be present only when example.filter is false.</description>

On the Variables page of the setup wizards, any variable that is used in property of a filter will be displayed in bold. It is significant to note that the value of a so-called filter variable can conditionally affect the presence of other variables. In this example, either variable example.variable.a or example.variable.b (but not both) will be present on the Variables page, depending on the value of the example.filter variable, which is displayed as a checkbox because it is of type BOOLEAN.

Note that Oomph setup editors support textual copy and paste, so you can copy the above XML and paste it into your setup editor to try it out.

Automation and Specialization with Configurations

As of Oomph 1.6, released with Neon.2, there is support for Configurations. A Configuration is not a Scope (is not a container for setup tasks) but rather a container for an Installation and a Workspace; each is optional, but a Configuration with neither is in effect useless. The Installation and Workspace of a Configuration are effectively used as a template to initialize the Installation and Workspace created by the Eclipse Installer, i.e., the setup resources that you can open with Navigate → Open Setup → Installation and Navigate → Open Setup → Workspace in your IDE. So you can specialize the installation with additional installation-specific tasks, e.g., a p2 task to install additional features, and you can specialize the workspace with workspace-specific tasks, e.g., a variable task to specify the value of a variable so you won't be prompted for that value.

Configurations are not only useful for specifying installation-specific and workspace-specific tasks but also for automating the selection process in the setup wizards, including the installer. The Configuration's Installation can reference a specific Product Version and the Configuration's Workspace can optionally reference several specific Project Streams. Both the simple mode and the advanced mode of the installer support dragging and dropping a Configuration to the title area. You can drag to the title area either a file (i.e., a file from the file system or from an Eclipse IDE), a URL (i.e., a link from a browser), or a copy of a Configuration's XMI serialization. This will apply the Configuration to the wizard with the effect that the Installation's Product Version is selected in the wizard and the wizard advances to the next page. Similarly, the Workspace's Project Streams are selected in the wizard and the wizard advances to the next page. If you apply a Configuration with a Workspace to the simple mode of the installer, you will be prompted to switch to advanced mode because only the advanced mode supports Project selection. So in simple mode, applying a Configuration advances to the final page, and in advanced mode, applying a Configuration with an Installation and a Workspace advances to the Variables page.

As an alternative to drag and drop support, rather than dragging a file, link, or XMI serialization, you can copy it to the clipboard and apply the clipboard contents to the wizard. In simple mode this is done via the Apply Configuration menu item. In advanced mode this is done via the Apply Configuration toolbar button on the Product or Project page; the menu item or toolbar item is visible only if the clipboard contains applicable content.

The installer application supports command line arguments so you could also specify a Configuration's file path or URL link on the command line to apply it automatically.

Creating a Configuration

The simplest way to create a new Configuration is from the context menu of the folder where want to locate the resource to contain it. From the context menu, use New → Other... and then locate Oomph → Setup Configuration Model in the wizard. You can then edit the new Configuration with the Setup Editor. You can delete the Installation or Workspace if you don't need that aspect. You can use the Properties view to set the Installation's Product Version or the Workspace's Project Streams. And of course you can create any other setup tasks in either Scope.

Configuration Handling

The specific form of the serialized URLs that are used to reference a Product Version or a Project Stream are very important to correct behavior. Relative URLs in the serialization can only work relative to the location of the Configuration's resource, so will only work when you drag and drop a file or link because a dragging and dropping textual copy of the serialization provides no information about how to resolve relative references. This is not to say there is anything wrong with relative references, just be aware that they imply that the user must apply the overall file or link, not just the textual serialization.

Another very useful aspect of Configurations is that the wizards handle of the references intelligently. I.e., if a Installation references a Product Version that's not in any Product Catalog in the Index, the Product will automatically be added to the user-extensible Product Catalog. If the Installation references a Product Version via its containing Product Catalog and that Product Catalog is not in the Index, and the redirectable Product Catalog is not already redirected, it will be redirected to the referenced Product Catalog and an appropriate Eclipse Ini redirection tasks will be synthesized so that the installation produced by the installer will be able to resolve the Product Version reference in its Installation via the correct containing Product Catalog. Analogous processing is done for the Project Stream references with the additional processing of Project's a logical Project container which determines which Project Catalog's extensible Project container is used. In other words, Configurations can also be used to automate the addition of Products and Projects to the user extensible catalogs.

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 http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.setup as a starting point, or use the wizard to create it. 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 http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/models/ to your redirection <path>/models/. You can redirect to your own index with this redirection system property:


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.

In general it will be highly desirable to archive your setup, but documentation for that is TBD. The installer and other setup wizards support dragging and dropping an index or archived index onto the title area of the dialog. Documentation for that is also TBD.

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 project catalog setup file using the wizard. Project setups in the project catalog should typically be referenced using absolute URIs, otherwise redirection can become problematic. However, if the relative references are downward pointing to some uniquely named folder different from any of the file/folder names in the Eclipse.org index, i.e., no .. traversal to the parent folder is involved and some folder name <my-projects-folder>, then they will be resolved to absolute URIs of the form index:/<my-projects-folder>/<path> which can be handled as described below.
  • Add a redirection system property similar to that described above to the eclipse.ini file, e.g., -Doomph.redirection.myProjectCatalog=index:/redirectable.projects.setup->....
  • If the projects in that catalog are referenced by relative downward references with a unique folder, also add a folder redirection system property, e.g.,-Doomph.redirection.myProjectCatalog=index:/<my-projects-folder>/->.../, to redirect the locations of the referenced projects to the folder where they are physically hosted.
  • Your catalog setup file must contain an Eclipse Ini task creating the same redirection(s)! Otherwise your catalog (or the referenced projects) will not be visible in the Eclipse created by the installer and hence the projects selected from it cannot be provisioned.
  • 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 https://wiki.eclipse.org/Tycho/Target_Platform, 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 http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/setups/Oomph.setup), 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 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.

Note: It's unclear if the above actually works. Please see thread https://www.eclipse.org/forums/index.php/t/1086488/ in forum for details. For some servers there are extension tasks to handle configuration, see below.

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 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.

Extension tasks for specific servers

For some servers there are oomph extension tasks that can be used to handle the configuration:

https://github.com/gratex/oomph-task-server - Tomcat, WebLogic, and WebSphere

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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=476434 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 eclipse.org p2 sites (think e.g. http://eclemma.org). 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. http://update.eclemma.org)

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.)feature.group

9. in the Properties of the Requirement, type the Name to the ID found above (e.g. com.mountainminds.eclemma.feature.feature.group)

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 https://git.eclipse.org/c/m2e/m2e-discovery-catalog.git/tree/org.eclipse.m2e.discovery.oss/connectors.xml

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

Read https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html & https://wiki.eclipse.org/M2E_compatible_maven_plugins and apply as follows:

    <description>Initialize M2E's Maven Lifecycle Mappings, see https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html & https://wiki.eclipse.org/M2E_compatible_maven_plugins</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 download.eclipse.org 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 in applications 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 follows:

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

The Java VM arguments need only specify the extractor 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 the 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 to delimit the constituent parts of the composed executable. The fifth argument is the extracted location of the small native executable itself. The 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. Such a descriptor looks like this:

 Eclipse Installer

Of course you can edit these parts and 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 +  ^
   product.zip + ^
   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 to determine if an appropriate version of Java is already installed, i.e., one that will be able 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 and at the minimum required version. If there is already an appropriate version of Java, it launches a Java process to execute the BinExtract's main method. That process in turn unzips the product zip to a temp folder and launches the Java process for that for the product/distribution.

Oomph Configuration Options

Configuration Options for Installer .ini File

-Doomph.redirection.setups Redirects the location of setup files (index, catalog and products). The default URI is http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/ and my be abbreviated with index:/. The syntax of the redirection is index:/->[redirection URI]. Examples: -Doomph.redirection.setups=index:/->http://<hostname>/<path>/ (external server redirection) or -Doomph.redirection.setups=index:/->setups/ (path relative to installer executable). See also Hosting your own index & catalogs
-Doomph.setup.product.catalog.filter Only displays product catalogs matching the given prefix. The default is org\\.eclipse\\.products. Displays all catalogs if value is empty.
-Doomph.setup.product.filter Only displays products matching the given prefix. The default is (?\!org\\.eclipse\\.products\\.org\\.eclipse\\.platform\\.ide).*. Displays all products if value is empty.
-Doomph.setup.product.version.filter Only displays product versions matching the given prefix. The default is .*\\.neon. Displays all product versions if value is empty.
-Doomph.p2.pool Set to @none to disable bundle pools. See [1] for details.