Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
EPP/Obsolete/Wizard/RepositorySetup
Contents
EPP P2 Wizard Repository Setup
This document describes how to setup Equinox P2 repositories for use by the EPP P2 wizard installer. For terminology refer to Equinox_p2_Concepts and Provisioning_Terminology.
Overview
The EPP P2 wizard installer is basically a standard P2 installer (Equinox_p2_Installer) configured to work in conjunction with a specially generated EPP metadata repository. This metadata is generated from EPP P2 wizard eppmodel.xml and contains all the features (i.e. Installable Units, IUs) available in the wizard. These IUs refer to IUs in a secondary "classic" Metadata Repository. The IUs in this Metadata Repository contain references to the actual artifacts in the artifact repository. That means that in total at least two metadata repositories and one artifact repository are required. For deployment on eclipse.org the "classic" repositories should probably be "http://download.eclipse.org/eclipse/updates/3.4/,http://download.eclipse.org/releases/ganymede/".
EPP repository generation
The epp p2 metadata repository is basically just an aggregation of IUs. This makes IU component maintenance easier for the respective maintainers because the IUs are decoupled and can be edited and replaced independently. The wizard itself uses that same repository to obtain the component information, with the eppmodel.xml only providing structural information (i.e. what component is in which group on which page of the wizard). This enforces a separation of concerns (content vs. presentation) and makes maintenance much easier for all involved parties.
Automatic IU generation for EPP packages
The existing Package definitions (cf. EPP/Obsolete/Configuration File Format) created and used by the EPP can be transformed into IU definition files that can be consumed by the metadata generator to produce installer packages almost identical to the traditional "standard" package files. There currently exists a proof-of-concept implementation that performs such a transformation using xslt.