: The path where the installed product shall be stored in the archive, e.g. <tt>eclipse</tt>. By default, the product is stored in the archive root.

: The path where the installed product shall be stored in the archive, e.g. <tt>eclipse</tt>. By default, the product is stored in the archive root.

+

* <tt>rootFolders</tt>

+

: OS-specific installation root folders, overriding <tt>rootFolder</tt>. Allowed children are <tt><macosx></tt>, <tt><win32></tt> and <tt><linux></tt> or any other OS available in P2.

* <tt>installFeatures</tt>

* <tt>installFeatures</tt>

: true (default): Include the feature JARs in installation. (Technically, this sets the p2 profile property <tt>org.eclipse.update.install.features</tt> to true.)

: true (default): Include the feature JARs in installation. (Technically, this sets the p2 profile property <tt>org.eclipse.update.install.features</tt> to true.)

Line 272:

Line 278:

'''Note:''' See [[#eclipse-feature]] for details on unpack limitations.

'''Note:''' See [[#eclipse-feature]] for details on unpack limitations.

+

+

==== Creating Mac OS X .app bundles ====

+

Starting from Tycho 0.18 you can create Mac OS X .app bundles by specifying a rootFolder in the director configuration which ends with <tt>.app</tt>. Tycho will then automatically properly formant the product.

== eclipse-application ==

== eclipse-application ==

Revision as of 04:29, 17 July 2013

This page documents the packaging types available in the latest Tycho release.

Values of artifactId and version elements must match corresponding values from bundle manifest (also see "-SNAPSHOT versions" below).

Since Tycho uses OSGi bundle manifest to determine project dependencies, pom.xml file should NOT contain <dependency> section, and any dependencies inherited from parent project will be ignored by the build.

eclipse-test-plugin

Maven projects typically have separate test source directories in the same project. The Eclipse convention, however, is to have a separate test bundle (often a fragment of the host/target plugin with the suffix ".tests"). Tycho introduces new eclipse-test-plugin packaging type to represent such projects. Build behavior is like regular Eclipse plugins, but these are treated specially at test-time.

org.eclipse.tycho:tycho-surefire-plugin:test mojo executes plug-in unit tests and it is bound to integration-test build phase. Internally, tycho-surefire-plugin uses the same Surefire test framework as other maven projects and test mojo supports most of the parameters of standard maven-surefire-plugin. maven-surefire-plugin supports both headless and UI-based tests, but use of UI test harness has to be explicitly enabled, as follows:

The OSGi runtime for the test execution consists of the test bundle/fragment and its dependencies. If needed, you can add more features ("eclipse-feature"), bundles/fragments ("eclipse-plugin"), or installable units ("p2-installable-unit"), each including their transitive dependencies, to the test runtime. Versions are interpreted as version ranges, so for example "1.3.0" stands for version 1.3.0 or later. Example:

Tests typically fail if implicit dependencies are missing, e.g. if your bundle or a referenced bundle makes use of declarative services, but there is no explicit reference to the bundle org.eclipse.equinox.ds. The same problem can occur when your users install your bundles with p2. Therefore it is a good idea to make the implicit dependencies of your bundles explicit through the feature used to ship your bundles, e.g. by adding a dependency to org.eclipse.equinox.ds in the feature. Configuring this feature in the tycho-surefire-plugin configuration should then also make the test runtime complete.

In order to add native fragments for several target environments, e.g. the SWT fragments, add a feature that contains all of them, e.g. the feature org.eclipse.rcp.

eclipse-feature

This packaging type corresponds to Eclipse Feature project and requires the following minimum pom.xml:

Similar to eclipse-plugin projects, artifactId and version attributes must match id and version attributes of feature.xml file.

Tycho supports root properties in the build.properties file, which can be used to add files to the root of a product installation. (Limitation: root.folder properties are currently not supported. Wildcard patterns are supported since Tycho 0.17.0.)

Limitation: The unpack attribute in the feature.xml is ignored. If you need a bundle to be installed in unpacked form, specify Eclipse-BundleShape: dir in the manifest of the bundle. If this is a third party bundle, it will mean repackaging it to include this Eclipse proprietary value.

eclipse-repository

This packaging type creates a p2 repository (the "update site" replacement of p2) which can contain features, bundles, categories, and product definitions. To include features, list them in a category.xml file in the project root. The same file allows to define categories. To include a product definition, place a *.product file into the project root. (Note: The p2.inf file for a product definition example.product needs to be called example.p2.inf). By default, all bundles and features that are contained in a product definition or included feature are also included in the p2 repository. Through a configuration parameter (see below for details) the p2 repository can be extended to also contain all features and bundles that are required by included features and bundles.

"included" means listed as inclusion in the metadata files, i.e. in a feature.xml these are the <plugin> and <includes> elements; in product files, these are the <plugins> and <features> elements. Note that product installations (see below) contain both included and referenced artifacts, so if you want the same result as for the product installation, you should use includeAllDependencies=true.

Only optional, greedy dependencies are assembled with includeAllDependencies=true. (Optional, greedy dependencies are marked with greedy='true' in the p2 metadata.) Optional, non-greedy dependencies are ignored for assembly.

Note: Due to bug 359090, either of the following warnings actually break the build:

"The product specifies bundles although useFeatures is true. These bundles are ignored."

"The product specifies features although useFeatures is false. These features are ignored."

The workaround is to remove leftover plugins/features which are ignored due to the useFeatures attribute (see bug report for details).

Creating Product Zip Files

The packaging type eclipse-repository creates a p2 repository, which may contain product definitions. By configuring additional goals, these products can be installed (with the p2 director) and zipped to create ready-to-use product installations.

If the p2 repository contains more than one product definition, you need to choose which ones shall be materialized. And if you choose to materialize (and archive) more than one product, you need to specify the attachId (which becomes a part of the classifier) to make the classifiers unique. Similarly, you can specify the root folder in the product zip files.

Warning:

If you are using Tycho version 0.11.0, 0.11.1, or 0.12.0, do not specify more than one product per eclipse-repository module. These releases contain the critical bug 346532 which leads to in-deterministic and broken results if more than one product is defined in one eclipse-repository module. The issue does not occur if products are defined in a separate eclipse-repository module each, so this the the recommended workaround.

Creating Mac OS X .app bundles

Starting from Tycho 0.18 you can create Mac OS X .app bundles by specifying a rootFolder in the director configuration which ends with .app. Tycho will then automatically properly formant the product.

eclipse-application

This packaging type will soon be deprecated and we recommend using packaging type eclipse-repository instead. See bug 348586 for details.

This packaging is used in Tycho to represent a Product and doesn't have a corresponding project at Eclipse (Since Product Configurations are only a file at Eclipse, not a project kind) and requires the following minimum pom.xml