Update tycho-version to v4 (major) - autoclosed

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
org.eclipse.tycho:tycho-surefire-plugin (source)	3.0.5 -> 4.0.3
org.eclipse.tycho:tycho-p2-repository-plugin (source)	3.0.5 -> 4.0.3
org.eclipse.tycho:tycho-versions-plugin (source)	3.0.5 -> 4.0.3
org.eclipse.tycho:tycho-maven-plugin (source)	3.0.5 -> 4.0.3
org.eclipse.tycho:target-platform-configuration (source)	3.0.5 -> 4.0.3

---

Release Notes

eclipse-tycho/tycho (org.eclipse.tycho:tycho-surefire-plugin)

v4.0.0

Maven 3.9 required

Tycho 4.x requires Maven Version 3.9.

creating maven p2 sites with Tycho packaging

There is already a way to create a p2 maven site with Tycho for plain jar based projects.
This support is now enhanced to being used in a Tycho based setup so it is possible to build a full maven deployed updatesite automatically with all bundles of the current build.
You can find a demo here:

https://github.com/eclipse-tycho/tycho/tree/master/demo/p2-maven-site

New document-bundle mojo

There is now a new mojo that replaces the usual ant-based workflow to generate the help index, it can be used like this:

<plugin>
    <groupId>org.eclipse.tycho.extras</groupId>
    <artifactId>tycho-document-bundle-plugin</artifactId>
    <version>${tycho-version}</version>
    <executions>
        <execution>
            <id>index</id>
            <goals>
                <goal>build-help-index</goal>
            </goals>
        </execution>
    </executions>
</plugin>

New API-Tools Mojo

There is now a new mojo that replaces the usual ant-based workflow to call the PDE-API tools, it can be used like this:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-apitools-plugin</artifactId>
    <version>${tycho-version}</version>
    <configuration>
        <baselines>
            <repository>
                <url>... your baseline repo ...</url>
            </repository>
        </baselines>
    </configuration>
    <executions>
        <execution>
            <id>generate</id>
            <goals>
                <goal>generate</goal>
            </goals>
        </execution>
        <execution>
            <id>verify</id>
            <goals>
                <goal>verify</goal>
            </goals>
            <configuration>
                 <baselines>
                     <repository>
                         <url>${previous-release.baseline}</url>
                     </repository>
                 </baselines>
            </configuration>
        </execution>
    </executions>
</plugin>

Building Multi-Release-Jars

Tycho now supports building of Multi-Release-Jar in a Manifest-First-Way,
a demo can be found here https://github.com/eclipse-tycho/tycho/tree/master/demo/multi-release-jar

Building BND Workspace Projects pomless

The tycho-build extension can now also build projects with a BND Workspaces layout in a complete pomless way,
details can be found here: https://tycho.eclipseprojects.io/doc/master/BndBuild.html

Handling of local artifacts can now be configured through the target platform

Previously it was only possible to influence the handling of local artifacts with the -Dtycho.localArtifacts=<ignore/default> option, from now on this can be configured through the target platform as well like this:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>target-platform-configuration</artifactId>
    <version>${tycho-version}</version>
    <configuration>
        <dependency-resolution>
            <localArtifacts>ignore</localArtifacts>
        </dependency-resolution>
    </configuration>
</plugin>

the supported values are:

• include - (default) local artifacts are included and may override items from the target,
• default - for backward-compatibility with older documentation, equivalent to include
• ignore - local artifacts are ignored

new tycho-versions-plugin mojos

bump-versions mojo

When using version checks it can occur that a version bump is required. This manual and error prone task can now be automated with the tycho-versions-plugin:bump-versions mojo, it allows configuration of an automatic version bump behavior in combination with the org.eclipse.tycho.extras:tycho-p2-extras-plugin:compare-version-with-baselines goal or similar.

It works the following way:

• You can either configure this in the pom (e.g. in a profile) with an explicit execution, or specify it on the command line like mvn [other goals and options] org.eclipse.tycho:tycho-versions-plugin:bump-versions
• If the build fails with a VersionBumpRequiredException the projects version is incremented accordingly
• One can now run the build again with the incremented version and verify the automatic applied changes

set-property mojo

Updating properties in a project can now be automated with the tycho-versions-plugin:set-property mojo. It is very similar to the tycho-versions-plugin:set-version mojo but only updates one or more properties, for example:

mvn org.eclipse.tycho:tycho-versions-plugin:set-property --non-recursive -Dproperties=releaseVersion -DnewReleaseVersion=1.2.3

This is mostly useful with Tycho CI Friendly Versions where one can define version by properties the mojo can be used to update the defaults.

set-parent-version mojo

Updating the parent version in a project can now be automated with the tycho-versions-plugin:set-parent-version mojo. Similar to the tycho-versions-plugin:set-version mojo, this just updates the version of the parent pom, for example:

mvn org.eclipse.tycho:tycho-versions-plugin:set-parent-version --non-recursive -DewParentVersion=5.9.3

new bnd-test mojo

Tycho now has a new mojo tycho-surefire-plugin:bnd-test to easily execute tests using the bnd-testing framework.
This is similar to tycho-surefire-plugin:plugin-test but uses the BND testing framework, integrates nicely with the OSGi Testing Support
and allows to execute prebuild test-bundles.

Additional information and a demo can be found here:
https://tycho.eclipseprojects.io/doc/master/TestingBundles.html#bnd-testing

new tycho-baseline-plugin

Tycho now has a new mojo to perform baseline comparisons similar to the bnd-baseline-plugin but takes the tycho-dependency model into account.

A usual configuration looks like this:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-baseline-plugin</artifactId>
    <version>${tycho.version}</version>
    <executions>
        <execution>
            <id>baseline-check</id>
            <goals>
                <goal>verify</goal>
            </goals>
            <configuration>
                <baselines>
                    <repository>
                        <id>optional, only required for proxy setup or password protected sites</id>
                        <url>URL of P2 repository that should be used as a baseline</url>
                    </repository>
                </baselines>
            </configuration>
        </execution>
    </executions>
</plugin>

Any baseline problems will then be reported to the build:

Also feature baselining is supported according to Versioning features

Class loading changes for Eclipse based tests

Due to reported class loading clashes, the ordering of class loading has been modified in Eclipse based tests.
The previous loading can be restored by a new classLoaderOrder parameter.
This applies to tycho-surefire-plugin:test and tycho-surefire-plugin:plugin-test.

define targets in repository section

From now on one can define targets also in the repository section of the pom, only the URI variant is supported, but actually you can write everything as an URI already, this then looks like this:

<project ...>
    ...
    <repositories>
        <repository>
            <id>jetty</id>
            <layout>target</layout>
            <url>file:${project.basedir}/jetty.target</url>
        </repository>
    </repositories>
    ...
</project>

You might also use https:

<url>https://git.eclipse.org/c/lsp4e/lsp4e.git/plain/target-platforms/target-platform-latest/target-platform-latest.target</url>

or reference a maven deployed artifact

<url>mvn:org.eclipse.lsp4e:target-platform-latest:0.13.1-SNAPSHOT</url>

or anything that can be resolved to a valid URL in your running build.

Parameter enhancements for tycho-apitools-plugin:generate goal

The parameters of the tycho-apitools-plugin:generate goal have been completed and improved.

New parameter for tycho-p2-repository-plugin:assemble-repository

The tycho-p2-repository-plugin:assemble-repository mojo has now a new configuration parameter filterProvided that (if enabled) filter units and artifacts that are already present in one of the referenced repositories.
That way one can prevent including items that are already present in the same form in another repository.

If you want to include repository references automatically, there are two other new options:

• addPomRepositoryReferences - all P2 repositories from the pom are added as a reference
• addIUTargetRepositoryReferences - all P2 repositories defined in target files IU-location types are added as a reference

so now one can produce a self-contained update-site that only includes what is not already available from the target content used by specify:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-p2-repository-plugin</artifactId>
    <version>${tycho-version}</version>
    <configuration>
        <includeAllDependencies>true</includeAllDependencies>
        <filterProvided>true</filterProvided>
        <addPomRepositoryReferences>true</addPomRepositoryReferences>
        <addIUTargetRepositoryReferences>true</addIUTargetRepositoryReferences>
    </configuration>
</plugin>

Building OSGi Repositories with tycho-p2-repository-plugin:assemble-repository

OSGi defines an own repository serialization format Tycho can now produce such repositories to ease integration with these format, the only thing required is specifying the following configuration options:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-p2-repository-plugin</artifactId>
    <version>${tycho-version}</version>
    <configuration>
        <generateOSGiRepository>true</generateOSGiRepository>
    </configuration>
</plugin>

This will generate an additional repository.xml file in the root of the produced p2 repository representing the content as an OSGi Repository.

New parameter in tycho-packaging-plugin:package-plugin

The tycho-packaging-plugin:package-plugin mojo has now a new configuration parameter deriveHeaderFromSource (default true), that allows Tycho to discover additional headers declared in the source (e.g. from annotations).
The following headers are currently supported:

• Require-Capability is enhanced with additional items, if osgi.ee capability is found, it replaces the deprecated Bundle-RequiredExecutionEnvironment

This can be disabled with the following configuration in the pom:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-packaging-plugin</artifactId>
    <configuration>
        <deriveHeaderFromSource>false</deriveHeaderFromSource>
    </configuration>
</plugin>

Variable resolution in target repository location

URI in <repository location="..."> in *.target files can contain:

• Environment variable as ${env_var:MY_VARIABLE}
• System variable as ${system_property:myProp} passed at build time as -DmyProp
• Project location as ${project_loc:ProjectName}

Migration guide 3.x > 4.x

New delayed target platform resolving

Tycho has already introduced a new mode in Tycho 3.0.0 that was activated with -Dtycho.resolver.classic=false that was finalized in Tycho 4.x this new mode has several advantages:

• resolve dependencies is delayed until the project is build, this allows more parallelization and even make Tycho start the build faster
• pom dependencies are considered by default, this behaves more like one would expect from a maven perspective
• mixed reactor builds are now fully supported without any special configuration
• Tycho detects if the current project requires dependency resolution and skip resolving the target platform if not needed

If you see any issues please let us know so we can fix any problem with it, this new mode is now configured through the target platform configuration
and if you like the old behavior it can be configured in the following way:

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

Tycho-Build Extension uses smart builder

The Tycho-Build Extension now uses the Takari Smart Builder which has superior parallel performance when executing with -T.

To retain the maven default, or if you even want to use a different builder, you can pass -Dtycho.build.smartbuilder=false to your build.

skipExec parameter remove from test mojos

The test-mojo previously defined a (deprecated) skipExec parameter, this parameter is now removed and one should use skipTests instead.

allowConflictingDependencies parameter removed

The parameter allowConflictingDependencies was removed from the target platform configuration. It solely relied on deprecated and outdated stuff, if there are still use-cases please let us know about them so we can provide alternative ways to archive this.

Choosable HTTP transports

Tycho uses a custom P2 transport to download items from updatesites, previously URLConnection was used for this but now the Java HTTP 11 Client is the new default because it supports HTTP/2 now.
To use the old URLConnection one can pass -Dtycho.p2.httptransport.type=JavaUrl to the build.

Valid values are:

• JavaUrl - uses URLConnection to retrieve files
• Java11Client - uses Java 11 HttpClient

PGP Signing Enhancements

The tycho-gpg::3.0.0:sign-p2-artifacts mojo has been significantly enhanced.

The following properties have been added:

• skipIfJarsignedAndAnchored - This is similar to skipIfJarsigned but is weaker in the sense that the signatures are checked in detail such that the PGP signing is skipped if and only if one of the signatures is anchored in Java cacerts. The default is false. Set skipIfJarsignedAndAnchored to true and skipIfJarsigned to false to enable this feature.
• skipBinaries - Setting this to false will enable the signing of binary artifacts, which are of course not jar-signed.
• pgpKeyBehavior - Specify skip, replace, or merge for how to handle the signing of artifacts that are already PGP signed.
• signer - Currently supported are bc and gpg where the former is a new implementation that uses Bouncy Castle for signing, which is significantly faster and allows signing to proceed in parallel. This can also be configured by the system property tycho.pgp.signer.

mixed reactor setups require the new resolver now

If you want to use so called mixed-reactor setups, that is you have bundles build by other techniques than Tycho (e.g. bnd/felix-maven-plugin) mixed with ones build by Tycho,
previously this was only possible with enabling an incomplete resolver mode and using pomDependencies=consider.

From now on such setups require the use of the new resolver mode (-Dtycho.resolver.classic=false) supporting the usual resolver mode and thus incomplete resolver mode was removed completely.

pom declared dependencies handling has slightly changed

With the new resolver mode (-Dtycho.resolver.classic=false) pom dependencies are considered by default, also the way how they are handled have slightly changed:

Previously all units where always added to the full target resolution result. This has often lead to undesired effects, especially when there are large (transitive) dependency chains
as things can easily slip in.

From now on the target platform is always queried first for a unit fulfilling the requirement and only if not found the pom dependencies are queried for an alternative.

pom declared dependencies are considered for compile

Previously dependencies declared in the pom are ignored by Tycho completely and even though one could enable these to be considered in target platform
this still requires them to be imported in the bundle manifest to finally be usable for compilation.

Now each pom defined dependency is always considered for compilation as this matches the expectation of most maven users and finally allows to have 'compile only' dependencies to be used,
for example with annotations that are only retained at source or class level.

One example that uses API-Guardian annotations can be found here: https://github.com/eclipse/tycho/tree/master/tycho-its/projects/compiler-pomdependencies

You can disable this feature through the tycho-compiler-plugin configuration:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-compiler-plugin</artifactId>
    <version>${tycho-version}</version>
    <configuration>
        <pomOnlyDependencies>ignore</pomOnlyDependencies>
    </configuration>
</plugin>

Properties for tycho-surefire-plugin's 'useUIThread' and 'useUIHarness' parameters

The configuration parameters useUIThread and useUIHarness parameter of the tycho-surefire-plugin can now be set via the properties tycho.surefire.useUIHarness respectively tycho.surefire.useUIThread.

Minimum version for running integration/plugin tests

Previously the osgibooter has claimed to be Java 1.5 compatible but as such old JVMs are hard to find/test against already some newer code was slipping in. It was therefore decided to raise the minimum requirement to Java 1.8 what implicitly makes it the lowest bound for running integration/plugin tests with Tycho.

This requires any tests using pre 1.8 java jvm to be upgrade to at least running on Java 1.8.

Using integration/plugin tests with eclipse-plugin packaging

Some improvements have been made for the test execution with eclipse-plugin packaging that probably needs some adjustments to your pom configuration or build scripts:

1. The property skipITs has been renamed to tycho.plugin-test.skip
2. the mojo integration-test has been renamed to plugin-test
3. the default pattern of the former integration-test has been changed from **/PluginTest*.class", "**/*IT.class to the maven default **/Test*.class", "**/*Test.class", "**/*Tests.class", "**/*TestCase.class
4. the former integration-test mojo is no longer part of the default life-cycle, that means it has to be explicitly be enabled to be more flexible and this is how standard maven behaves
5. the test mojo of the maven-surefire-plugin is no longer part of the default life-cycle, that means it has to be explicitly be enabled to be more flexible and to not pollute the test-phase.

To restore old behaviour you can add the follwoing snippet to your (master) pom:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>${surefire-plugin-version}</version>
    <executions>
        <execution>
            <id>execute-tests</id>
            <goals>
                <goal>test</goal>
            </goals>
        </execution>
    </executions>
</plugin>

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-surefire-plugin</artifactId>
    <version>${tycho-version}</version>
    <executions>
        <execution>
            <id>execute-plugin-tests</id>
            <configuration>
                <includes>**/PluginTest*.class,**/*IT.class</includes>
            </configuration>
            <goals>
                <goal>plugin-test</goal>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
</plugin>

New Maven dependency consistency check

Tycho has a new mojo to check the consistency of the pom used for your bundle.
To enable this add the following to your pom (or adjust an existing configuration):

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-packaging-plugin</artifactId>
    <executions>
        <execution>
            <id>validate-pom</id>
            <phase>verify</phase>
            <goals>
                <goal>verify-osgi-pom</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <archive>
            <addMavenDescriptor>true</addMavenDescriptor>
        </archive>
        <mapP2Dependencies>true</mapP2Dependencies>
    </configuration>
</plugin>

This will then:

1. add a new execution of the verify-osgi-pom mojo
2. enable the generation and embedding of a maven descriptor (optional if you fully manage your pom.xml with all dependencies)
3. map P2 dependencies to maven dependencies (optional, but most likely required to get good results)

Default value change for trimStackTrace

tycho-surefire-plugin had set the default value of the trimStackTrace option to true.
The default will now be aligned with maven-surefire-plugin at false and will need to be manually adjusted for users that really need the stack traces trimmed.

Old behavior can be restored through configuration of the tycho-surefire-plugin:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-surefire-plugin</artifactId>
    <configuration>
        <trimStackTrace>true</trimStackTrace>
    </configuration>
</plugin>

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.