Tycho Target Platform Configuration Plugin

Set to none to force the resolution to happen without any execution environment, typically when the module is supposed to use system packages coming from some dependencies (eg shipping a JRE inside products with Eclipse JustJ).

This for example allows to restrict the version of a bundle, or to select one particular provider for a package. Filtering is done as last step in the target platform computation, so the filters apply to all sources listed above.

The filters will only remove content from the target platform; they will not add new content. dependency-resolution should be used for addition of extra content. If you specify a restriction that is not fulfilled by any of the units from the target platform sources, all units that the filter applies to (i.e. units that match the filter.type, filter.id, and filter.version/versionRange criteria) will be removed from the target platform.

Package provider restrictions work by removing all other bundles exporting the package. This means that these other bundles (and the packages only exported by them) won't be available in your build.

Example:

<plugin> <groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version> <configuration> <filters>

<!-- example 1: restrict version of a bundle --> <filter>
<type>eclipse-plugin</type> <id>org.eclipse.osgi</id> <restrictTo>
<versionRange>[3.6,3.7)</versionRange> <!-- alternative: <version> for selecting
exactly one versions --> </restrictTo> </filter>

<!-- example 2: remove all providers of the package javax.persistence except the bundle
javax.persistence --> <filter> <type>java-package</type>
<id>javax.persistence</id> <restrictTo> <type>eclipse-plugin</type>
<id>javax.persistence</id> </restrictTo> </filter>

<!-- example 3: work around Equinox bug 348045 --> <filter>
<type>p2-installable-unit</type>
<id>org.eclipse.equinox.servletbridge.extensionbundle</id> <removeAll />
</filter> </filters> </configuration> </plugin>

If consider or wrapAsBundle, the effect is:

• First, Maven resolves the GAV dependencies according to the normal Maven rules. This results in a list of artifacts consisting of the specified artifacts and their transitive Maven dependencies.
• Tycho then checks each of these artifacts, and if the artifact is an OSGi bundle, it is added to the target platform. Other artifacts are ignored in case of consider, or get some OSGi metadata generated and an OSGi bundle created from them.
• OSGi bundles which become part of the target platform in this way are then available to resolve the project's OSGi dependencies.

📝 Tycho always attempts to resolve transitive dependencies, so if you need a POM dependency in the target platform of one module, you will also need it in all downstream modules. Therefore the POM dependencies (and the pomDependencies=consider configuration) typically need to be added in the parent POM.

• <artifact> to define a target GAV (either local to the reactor or a remote one)
• <file> to define a file local to the build
• <uri> to define a (remote) URI that specifies a target, currently only URIs that can be converted to URLs are supported (e.g. file:/.... http://..., )