Tycho Target Platform Configuration Plugin

No description.

Configure dependency resolution, for example by adding requirements. Example:

<plugin>
  <groupId>org.eclipse.tycho</groupId>
  <artifactId>target-platform-configuration</artifactId>
  <configuration>
    <dependency-resolution>
      <extraRequirements>
        <requirement>
          <type>eclipse-feature</type>
          <id>example.project.feature</id>
          <versionRange>0.0.0</versionRange>
        </requirement>
      </extraRequirements>
    </dependency-resolution>
  </configuration>
 </plugin>

Target environments (os/ws/arch) to consider.

Example:

<environments>
 <environment>
   <os>linux</os>
   <ws>gtk</ws>
   <arch>x86_64</arch>
 </environment>
 <environment>
   <os>linux</os>
   <ws>gtk</ws>
   <arch>ppc64le</arch>
 </environment>
  <environment>
   <os>linux</os>
   <ws>gtk</ws>
   <arch>aarch64</arch>
 </environment>
 <environment>
   <os>win32</os>
   <ws>win32</ws>
   <arch>x86_64</arch>
 </environment>
 <environment>
   <os>macosx</os>
   <ws>cocoa</ws>
   <arch>x86_64</arch>
 </environment>
 <environment>
   <os>macosx</os>
   <ws>cocoa</ws>
   <arch>aarch64</arch>
 </environment>
</environments>

Exclusions could be used together with pomDependencies setting to exclude certain maven dependencies from being considered. This is useful for example if there is an offending (transitive) dependency needed for compilation but not for the runtime that would cause problems otherwise.

Force an execution environment for dependency resolution. If unset, use the default JRE of your computer.

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

No description.

Selectively remove content from the target platform.

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>

Defines which strategy to apply to Maven dependencies.

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.

If no explicit value is configured Tycho uses org.eclipse.tycho.core.resolver.shared.PomDependencies.ignore if eager resolution is activated and org.eclipse.tycho.core.resolver.shared.PomDependencies.consider otherwhise.

Configures if referenced repositories should be included when fetching repositories. The default is ignore. To specify to use referenced repositories, pass include.

Configures when resolve of the project specific target platform happens. If the value is true the project platform is computed as early as when starting the build before the first mojo executes, if the value is false the resolving is delayed until the project is actually executed, this can considerably improve your build speed in parallel builds. The drawback is that there might be some tools making assumptions about the build being static from the start or having "hidden" dependency chains that point back to your build reactor. For these reason this can be configured here even though it is recommend to always use lazy resolve for best performance and maximum of features, e.g. using mixed maven builds require lazy resolving of that projects depend on the plain maven projects.

No description.

List of .target artifacts to use for dependency resolution.
Could either be

• <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://..., )
• <locations> to define target locations inline

No description.