# Scopes

A `scope` is the course-grained unit for grouping related tasks. Scope are hierarchically structured and tasks are gathered from them based on this hierarchical structure. They are stored in resources. Scopes

Each scope has the following properties:

- A required `attribute` which should be a lower case name, i.e., like a single component of a qualified Java package name. The hierarchical `containment` structure of scopes induces a `qualified` name attribute, based on the '.' separated names of the scopes, hence the recommendation to use a lower case scope name.
- An optional `label` attribute, which should be a title case name that may include spaces and punctuation.
- An optional `description` attribute which description can be arbitrary descriptive log.

## 1 Product Catalogs

A `product catalog` is a `container` for products as well as a `container` for all the tasks to install any of those products. For example, there is an Eclipse product catalog generated for all the packages available on Eclipse's download page. In other words, you can use Oomph to install any version of any package that you'd normally download and unzip from Eclipse.org. In the case of a product that has Oomph installed, but wasn't actually installed by Oomph, there always exists a synthetic so called self product catalog that contains the self product. It is stored in a project catalog resource.

### 1.1 Products

A `product` is a `container` for product versions as well as a `container` for all the tasks to install any of those product versions. For example, there is a product in the Eclipse product catalog for each Eclipse package. In the case of a product that has Oomph installed, but wasn't actually installed by Oomph, there always exists a synthetic so called self product in the self product catalog that contains a self product version.

#### 1.1.1 Product Versions

A product `version` is a `container` for all the tasks to install a specific version of a product. For example, there is a product version in the Eclipse Standard product in the Eclipse product catalog for installing the Eclipse Standard Luna package.

In the case of a product that has Oomph installed but wasn't actually installed by Oomph, there always exists a synthetic so called product version in the self product int the self product catalog. It captures, via a p2 task, all the information about the installable units that of that product installation as well as all the update p2 sites that are available for updating those units within that product installation.

## 2 Project Catalogs

A `project catalog` is a `container` for projects as well as a `container` for both the tasks to provision a workspace with any of those projects and the tasks to install the tools needed to work with any of those projects. For example, there is an Eclipse project catalog for provisioning various projects hosted at Eclipse.org. It is stored in a project catalog resource.

### 2.1 Projects

A `project` is a `container` for streams as well as a `container` for both the tasks to provision a workspace with any of those streams and the tasks to install the tools needed to work with any of those streams. For example, there is a project in the Eclipse project catalog for provisioning the Oomph project itself. Projects can optionally {contain nested projects. It is stored in a project resource.

Projects can optionally contain `nested` projects which may be stored in a separate project resource or in the same resource as the `containing` project.

#### 2.1.1 Streams

A `stream` is a `container` for both the tasks to provision a workspace with for that particular stream and the tasks to install the tools needed to work with that particular stream. For example, there is a stream in the Oomph project in the Eclipse project catalog for provisioning the source code of the Git master branch of the Oomph project.

## 3 Installations

An `installation` is a `container` for the tasks to provision a specific installed Eclipse product. Its primary function, however, is that it specifies a reference to a product version. The tasks gathered for that product version are performed to that installed product. The installer wizard creates an instance based on the selected product version on the product page. Even if the product installation hasn't been installed by Oomph, when Oomph is present, an installation instance is automatically created to refer to the synthetic self product version.

## 4 Workspaces

A `workspace` is a `container` for the tasks to provision a specific Eclipse workspace. Its primary function is that it specifies zero or more references to project streams. The tasks gathered for each of those project streams are performed for that workspace as well as for the installed product used to open that workspace. The installer wizard creates an instance based on the selected project streams on the project page. The installer and project wizards

## 5 Users

A `user` is a `container` for the tasks to provision every installed Eclipse product and every opened workspace ever used by the end-user. It provides an opportunity to customize all aspects of a user's experience with all their Eclipse products and workspaces. It also provides support for the following:

- Recording the `accepted license` of each of the tools automatically installed tools, i.e., once a license is accepted, it can be recorded to avoid any future prompts involving that particular license.
Recording the `policy` with regard to handling of unsigned content, i.e., once unsigned content is accepted, that acceptance can be recorded to avoid any future prompts involving unsigned content.
- Recording configuration options, so called `attribute rules`, that tailor where and how repositories, workspaces, and installations are physically stored.

Copyright (c) 2014 Eike Stepper (Loehne, Germany) and others.
All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html