chore(deps): update tycho-version to v3 (major) - autoclosed

[renovate]

This PR contains the following updates:

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

---

Release Notes

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

v3.0.5

Backports

• inject source folders into maven model
• improve CI friendly versions
• Report download speed to the caller
• redirectTestOutputToFile for OsgiSurefireBooter

v3.0.4

Backports

• Include smartbuilder (but disabled by default), can be enabled with -Dtycho.build.smartbuilder=true
• tycho-bnd-plugin support
• Version Mojo Bugfixes

v3.0.3

Dependency upgrades and Maven 3.9.0 support

This release includes some dependency upgrades and a fix to run Tycho 3 with Maven 3.9.0.

Parameter enhancements for tycho-apitools-plugin:generate goal

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

v3.0.2

Fixed support for the generation of a source feature from a maven target-location template

The generated source feature now properly includes the source bundles.

EclipseRunMojo argLine and appArgLine are reintroduced and no longer deprecated.

The argLine and appArgLine options have long been deprecated and were removed in Tycho 3.0.0.
They are generally inferior to the list-based jvmArgs and applicationArgs respectively.
However there are use cases where the arguments need to be extensible via property expansion, in which case the list-based approach is not always a suitable alternative.
As such, these two options have been re-introduced for Tycho 3.0.2 and are no longer marked deprecated though jvmArgs and applicationArgs remain the preferred mechanism.

Backports

• Maven Loockup can become really slow and should cache previous requests #​1969
• Provide a "verify-pom-resolves" mojo #​1451
• JUnit 5.9 support in Tycho 3.0.x #​1943
• Consumer-POM should use packaging-type jar instead of eclipse-plugin #​2005
• Mirroring of packed artifacts must be disabled
• Target platform resolved multiple times
• Support resolving of target projects from the reactor

v3.0.1

Fix for java.lang.NoSuchMethodError: 'void org.eclipse.equinox.internal.p2.repository.helpers.ChecksumProducer

If you face the following error with using Tycho 3.0.0 update to 3.0.1 to fix it.

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-p2-repository-plugin:3.0.0:assemble-repository (default-assemble-repository) on project XXXX: Execution default-assemble-repository of goal org.eclipse.tycho:tycho-p2-repository-plugin:3.0.0:assemble-repository failed: An API incompatibility was encountered while executing org.eclipse.tycho:tycho-p2-repository-plugin:3.0.0:assemble-repository: java.lang.NoSuchMethodError: 'void org.eclipse.equinox.internal.p2.repository.helpers.ChecksumProducer.<init>(java.lang.String, java.lang.String, java.lang.String)'

v3.0.0

Tycho now support forking of the Eclipse Java Compiler

Previously forking was not supported, now forking is possible and will be used if a custom java home is specified.

New option to transform P2 dependencies into real maven coordinates

The tycho-consumer-pom mojo has a new option to resolve p2 introduced dependencies to 'real' maven coordinates now, when enabled it queries maven-central with the SHA1 of the file to find out what are the actual maven central coordinates
and place them in the generated pom consumer-pom.

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-packaging-plugin</artifactId>
    <version>${tycho-version}</version>
    <configuration>
        <mapP2Dependencies>true</mapP2Dependencies>
    </configuration>
</plugin>

New tycho-p2-plugin:dependency-tree mojo

Sometimes it is useful to find out how dependencies of a project are actually pulled in. Tycho now supports a new tycho-p2-plugin:dependency-tree mojo that outputs a tree view of the P2 dependecies of a tycho project.

Example with Tycho integration test project:

tycho-its/projects/reactor.makeBehaviour$ mvn org.eclipse.tycho:tycho-p2-plugin:3.0.0-SNAPSHOT:dependency-tree

...

[INFO] --- tycho-p2-plugin:3.0.0-SNAPSHOT:dependency-tree (default-cli) @​ feature2 ---
[INFO] tycho-its-project.reactor.makeBehaviour:feature2:eclipse-feature:1.0.0-SNAPSHOT
[INFO] +- feature2.feature.group (1.0.0.qualifier) --> [tycho-its-project.reactor.makeBehaviour:feature2:eclipse-feature:1.0.0-SNAPSHOT]
[INFO]    +- bundle2 (1.0.0.qualifier) satisfies org.eclipse.equinox.p2.iu; bundle2 0.0.0 --> [tycho-its-project.reactor.makeBehaviour:bundle2:eclipse-plugin:1.0.0-SNAPSHOT]
[INFO]    +- feature1.feature.group (1.0.0.qualifier) satisfies org.eclipse.equinox.p2.iu; feature1.feature.group 0.0.0 --> [tycho-its-project.reactor.makeBehaviour:feature1:eclipse-feature:1.0.0-SNAPSHOT]
[INFO]       +- bundle1 (1.0.0.qualifier) satisfies org.eclipse.equinox.p2.iu; bundle1 0.0.0 --> [tycho-its-project.reactor.makeBehaviour:bundle1:eclipse-plugin:1.0.0-SNAPSHOT]
...

Support for inclusion of all source bundles in an update-site

The tycho-p2-repository-plugin:2.7.0:assemble-repository now support a new property includeAllSources that,
when enabled, includes any available source bundle in the resulting repository.

Support for Eclipse-Products with mixed Features and Plugins

Tycho now supports building mixed Products. In mixed Products both the listed features and listed plug-ins are installed.
Therefore the Product attribute type is now supported, which can have the values bundles, features and mixed and takes precedence over the boolean-valued useFeatures attribute.

New API Tools Mojo

Tycho now provides a new API Tools Mojo, see https://github.com/eclipse/tycho/tree/master/tycho-its/projects/api-tools for an example how to use it.

new sisu-osgi-connect

The new sisu-osgi-connect provides an implementation for plexus according to the Connect Specification that allows to run an embedded OSGi Framework from the classpath of a maven-plugin.
As both, the maven plugin and the embedded framework, share the same classlaoder you can use the best of both worlds and interact seamless with them.

This can be used in the following way:

@​Component(role = MyPlexusComponent.class)
public class MyPlexusComponent {
    @​Requirement(hint = "connect")
    private EquinoxServiceFactory serviceFactory;

    public void helloConnect() {
        serviceFactory.getService(HelloWorldService.class).sayHello();
    }
}

For the setup you need to do the following:

1. include any bundle you like to make up your plexus-osgi-connect framework as a dependency of your maven plugin
2. include a file META-INF/sisu/connect.bundles that list all your bundles you like to have installed in the format bsn[,true], where bsn is the symbolic name and optionally you can control if your bundle has to be started or not
3. include the following additional dependency

<dependency>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>sisu-osgi-connect</artifactId>
    <version>${tycho-version}</version>
</dependency>

Deprecated Features

The tycho-compiler:compile and tycho-compiler:testCompile option requireJREPackageImports is deprecated now and will produce a warning when used, bundles currently rely on this option should migrate to proper importing packages from the non java.* namespace.

Tycho compiler support for java.* imports

The tycho-compiler:compile and tycho-compiler:testCompile has a new option requireJavaPackageImports (defaults to false) that allows to assert importing of packages from the java.* namespace.
This is allowed since OSGi R7 and considered ǵood practice since the evolving of modular VMs there is no guarantee what packages a JVM offers,

Eclipse M2E lifecycle-mapping metadata embedded

All Tycho plugins are now shipped with embedded M2E lifecycle-mapping-metadata files.
Therefore M2E now knows by default how to handle them and it is not necessary anymore to install any connector (usually org.sonatype.tycho.m2e was used) for them.

Support for BND in tycho-build extension (aka pomless builds)

The Tycho Build Extension (aka pomless build) now detects bnd.bnd files in the root of a pomless bundle and automatically generates an appropriate maven execution automatically.
This can be used to generate any content by the BND plugin, e.g. declarative service xml or JPMS infos see here for an example:

https://github.com/eclipse/tycho/tree/master/tycho-its/projects/pomless/bnd

Tycho no longer ships JVM profiles

Because of modular VMs the profiles shipped by Tycho has never been complete and actually are already partly generated in regards to available packages.
From now on, Tycho do not ship any profiles and thus you can use any VM in the toolchains or as a running VM and Tycho will generate a profile for it.

Enhanced Support for Maven CI Friendly Versions

Starting with Maven 3.8.5 Tycho now supports an enhanced form of the Maven CI Friendly Versions beside the standard properties names one could also use:

• releaseVersion
• major
• minor
• micro
• qualifier

These uses the usual semantics that you can use them in a version string e.g. <version>${releaseVersion}${qualifier}</version> and pass them on the commandline.

Beside this, Tycho supports some useful default calculation for qualifier if you give a format on the commandline with -Dtycho.buildqualifier.format=yyyyMMddHHmm
(or any other format supported). Tycho will also make the build qualifier available in your Maven model!

That way you can configure your pom in the following way:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>...</groupId>
    <artifactId>...</artifactId>
    <packaging>pom</packaging>
    <version>1.0.0${qualifier}</version>
    <properties>
        <!-- Defines the default Qualifier if no format is given-->
        <qualifier>-SNAPSHOT</qualifier>
        ...
    </properties>
    ...
</project>

What will result in the usual 1.0.0-SNAPSHOT for a regular mvn clean install, if you want to do a release, you can now simply call mvn -Dtycho.buildqualifier.format=yyyyMMddHHmm clean deploy
and your artifact will get the 1.0.0-<formatted qualifier> version when published! This also is supported if you use pomless build.

To use this new feature you need to enable the tycho-build extension with the .mvn/extensions.xml file in the root of your project directory:

<?xml version="1.0" encoding="UTF-8"?>
<extensions>
    <extension>
        <groupId>org.eclipse.tycho</groupId>
        <artifactId>tycho-build</artifactId>
        <version>${tycho-version}</version>
    </extension>
    <!-- possibly other extensions here -->
</extensions>

Please note that we use another new feature from Maven 3.8.5 here, where you can use properties from the file .mvn/maven.config in your .mvn/extensions.xml file, so if you put in this:

-Dtycho-version=3.0.0-SNAPSHOT
(probably add more here ...)

You can now control your Tycho version for .mvn/extensions.xml and your pom.xml in one place and still override it on the commandline with -Dtycho-version=...

Support for non-modular JVMs no longer top tier

Support for compilation for pre-Java 11 JVMs bytecode is no longer considered first class nor tested. Actual support is not removed but people facing issues with it will have to come with fixes on their own.

Support for PDE Declarative Component Annotation processing

One can enable either global or per project the generation of component xmls in PDE. Until now it was required for Tycho to still import the annotation package even though classpath=true was set, beside that one needs to check in the generated xmls.

Tycho now has improved support for this with the following:

1. if there is a .settings/org.eclipse.pde.ds.annotations.prefs in the project, tycho adapts the settings there and if classpath=true is set no more imports are required.
2. one can enable a new tycho-ds-plugin where global default settings can be configured if project settings are not present, the below shows an example with default values:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-ds-plugin</artifactId>
    <version>${tycho-version}</version>
    <configuration>
        <classpath>true</classpath>
        <dsVersion>1.3</dsVersion>
        <enabled>false</enabled>
        <path>OSGI-INF</path>
        <skip>false</skip>
    </configuration>
</plugin>

If the tycho-ds-plugin is enabled for a project it generates the necessary xml files if not already present in the project.

Improved P2 transport for more efficiently http-cache handling and improved offline mode

P2 default transport is more designed as a weak cache that assumes the user is always online.
While for an IDE that might be sufficient as target resolution is only performed once in a while and updates are triggered by explicit user request, for Tycho this does not work well:

• Builds are often trigger on each code change, requiring repeated target resolution.
• Builds might be asked to run in an offline mode.
• If there is a temporary server outage one might want to fall back to the previous state for this build instead of failing completely.
• Build times are often a rare resource one doesn't want to waste waiting for servers, bandwidth might even be limited or you have to pay for it.

Because of this, Tycho now includes a brand new caching P2 transport that allows advanced caching, offline handling and fallback to cache in case of server failures. The transport is enabled by default so nothing has to be done, just in case you want the old behavior you can set -Dtycho.p2.transport=ecf beside that the following properties might be interesting:

Force cache-revalidation

If you run maven with the -U switch Tycho revalidates the cache.
This is useful if you have changed an updatesite in an unusual way (e.g. adding new index files) as tycho now also caches not found items to speed-up certain scenarios where many non existing files are queried.

Configure minimum caching age

Some servers don't provide you with sufficient caching information. For this purpose, Tycho by default assumes a minimum caching age of one hour. You can switch this off, or configure a longer delay by using -Dtycho.p2.transport.min-cache-minutes=<desired minimum in minutes>.
Choosing a sensible value could greatly improve your build times and lower bandwith usage.
If your build contains a mixture of released and 'snapshot' sites you have the following options:

1. Consider adding a mirror to your settings.xml for the snapshot page that points to a file-local copy (e.g. output of another build).
2. Configure the webserver of your snapshot site with the Cache-Control: must-revalidate header in which case Tycho ignores any minimum age.
3. Use -Dtycho.p2.transport.min-cache-minutes=0. This will still improve the time to resolve the target.

Automatic generation of PDE source bundles for pom-first bundles

PDE requires some special headers to detect a bundle as a "Source Bundle", there is now a new mojo tycho-source-plugin:generate-pde-source-header that supports this, it requires the following configuration:

1. Enable the generation of a source-jar with the maven-source-plugin. Please note that it needs to be bound to the prepare-package phase explicitly!

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-source-plugin</artifactId>
    <executions>
        <execution>
            <id>attach-sources</id>
            <goals>
                <goal>jar</goal>
            </goals>
            <phase>prepare-package</phase>
        </execution>
    </executions>
</plugin>

2. Enable the generation of the appropriate PDE header:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-source-plugin</artifactId>
    <version>${tycho-version}</version>
    <executions>
        <execution>
            <id>generate-pde-source-header</id>
            <goals>
                <goal>generate-pde-source-header</goal>
            </goals>
        </execution>
    </executions>
</plugin>

3. Finally enable generation of P2 metadata so Tycho can use the source bundle in the build (you can omit this step if you don't want to reference the source bundle in a product, update-site or feature).

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-p2-plugin</artifactId>
    <version>${tycho-version}</version>
    <executions>
        <execution>
            <id>attached-p2-metadata</id>
            <phase>package</phase>
            <goals>
                <goal>p2-metadata</goal>
            </goals>
            <configuration>
                <supportedProjectTypes>
                    <value>bundle</value>
                    <value>jar</value>
                </supportedProjectTypes>
            </configuration>
        </execution>
    </executions>
</plugin>

Limit the number of parallel test executions across the reactor

You can specify a <reactorConcurrencyLevel> (default unlimited) for tycho-surefire:integration-test and tycho-surefire:test that limits the number of concurrently running tests.
This can be useful if you like to execute the build with multiple threads (e.g. -T1C) but want to run the integration tests in a serial manner (e.g. because they are UI based).

Migration guide 2.x -> 3.x

Java 17 required as runtime VM

From 3.x on Tycho requires Java 17 as a runtime VM, but you can still compile code for older releases.

Default value for archive-products has changed

Previously Tycho uses zip for all platforms when packaging a product, now .tar.gz is used for linux+mac. If you want you can restore old behaviour by:

<execution>
    <id>archive-products</id>
    <goals>
        <goal>archive-products</goal>
    </goals>
    <phase>install</phase>
    <configuration>
        <formats>
            <linux>zip</linux>
            <macosx>zip</macosx>
        </formats>
    </configuration>
</execution>

Remove tycho.pomless.testbundle switch from build.properties in favor of specification of project's packaging-type

The boolean property tycho.pomless.testbundle, which allowed to specify in the buid.properties if a Plug-in is a Test-Plugin or not, has been removed.
Instead one can specify the packaging-type of that Maven-project directly. To migrate simply apply the following replacements in the build.properties:

tycho.pomless.testbundle = true -> pom.model.packaging = eclipse-test-plugin

tycho.pomless.testbundle = false ->pom.model.packaging = eclipse-plugin

This already works in the Tycho 2.7.x stream (but the generated artifactId does not yet have a 'test'-prefix).

sisu-equinox is now sisu-osgi

The sisu-equinox module is now cleaned up and made more generic so it could be used in a wider area of use case, therefore the equinox part is stripped and some API enhancements are performed.
As sisu-equinox is a separate module used inside Tycho, users of Tycho itself are usually not affected, but plugin developers might need to adjust there code to conform to the changed API contracts.

publish-osgi-ee do not publish a fixed size of profiles anymore

The publish-osgi-ee previously has published a fixes list of "usefull" execution environments maintained by Tycho.
This is no longer true and Tycho do publish only those JavaSE profiles that are available to the build and have a version larger than 11 if not configured explicitly.

jgit-timestamp provider moved from org.eclipse.tycho.extras to org.eclipse.tycho

The tycho-buildtimestamp-jgit plugin has moved to the org.eclipse.tycho group id.

Removal of deprecated eclipse-update-site and eclipse-application packaging types

These packaging types have been deprecated since a long time and there is the replacement eclipse-repository.

Removal of tycho-pomgenerator:generate-poms

The tycho-pomgenerator:generate-poms mojo is no longer supported as it was useful only in the days where tycho-pomless was incomplete.
Today its usage is very limited and tycho-pomless is a much better (and supported) alternative now.

Removal of tycho-source-feature:source-feature

This mojo is replaced by the tycho-source-plugin with execution feature-source which offers equivalent and even enhanced functionality.

Pack200

Pack200 technology is obsolete and no longer supported after Java 13.
Tycho removed all support for dealing with pack.gz files including pack200 specific plugins, various options in Mojos and support for resolving fetching in core.

Omit any pack200 specific plugins, options and in any other way dealing with *.pack.gz files.
The following are removed:

• Plugins
  • tycho-pack200a-plugin
  • tycho-pack200b-plugin
• Mojo options
  • TargetPlatformConfigurationMojo' includePackedArtifacts
  • MirrorMojo's includePacked
  • PublishFeaturesAndBundlesMojo reusePack200Files

BuildQualifierMojo project.basedir option removed

It was totally ignored in all latest versions.

PublishProductMojo flavor option removed

It was hardcoded to "tooling" always and had no practical meaning to change.

EclipseRunMojo argLine and appArgLine options removed / applicationArgs option fixed

argLine and appArgLine have been replaced by list-based jvmArgs and applicationArgs respectively.

applicationArgs (previously known as applicationsArgs) has been corrected to not perform any
interpretation of whitepace and quotes anymore. Individual arguments are now used literally (just like jvmArgs).

---

Configuration

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

🚦 Automerge: Disabled because a matching PR was automerged previously.

♻ 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 was generated by Mend Renovate. View the repository job log.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud