Tycho/Release Notes/2.0

< Previous Version | Next Version >

New and Noteworthy

Complete list of bug fixes and enhancements in 2.0.0

Update requirements

Requires Java 11

• Tycho now requires Java 11 as a minimum runtime requirement
• The default execution environment (EE) for the tycho-eclipserun-plugin was also bumped to Java 11
• The default source and target settings for the tycho-compiler-plugin were also bumped to Java 11

Note that this is a requirement for Tycho itself to run. Tycho can still build bundle that require older Java versions and have those bundles targeting older Java versions.

Requires Maven 3.6.3 or more recent

Maven 3.6.3 has important bugfixes necessary for some Tycho use-cases.

Target platform resolution becoming more correct

Resolve system.packages from Execution Envionment against toolchain or current JRE, from Java 13

bug 563930 Since Java 9 and module JVM, JREs can now have different sets of system packages from the same version. As a result, the list of system packages cannot be built statically. So Tycho will now query the defined toolchains when to get the actual system packages when requested (mainly for the tycho-compiler-plugin when requireJREPackageImports=true). If no matching toolchain is found, a warning is emitted and the system packages from the current Java runtime are used as failback.

An error-prone workaround was implemented in Tycho 1.x for Java 9 and 11, with a static list of system packages. This workaround is still active for those Java version, but not for newer Java versions. It may be decided to remove the workaround in a near future (maybe even before 2.0 releases) to bring more consistency and correctness.

targetJRE in referenced target-definition file is used to derive Execution Environment

bug 564959 - If the target-platform-configuration is configured so that it references some target definition files via that <target> child element, and doesn't enforce an <executionEnvironment>, the the .target file will be inspected for a targetJRE declaration, and the first match will be used as execution environment for target platform resolution.
If executionEnvironment is set directly as a configuration of the target-platform-configuration in the pom.xml file, this will take priority and the targetJRE in target files are ignored. If no .target file defines a JRE, then the execution environment is chosen as usual.

Proper BREE handling may require setting executionEnvironment in target-platform-configuration or targetJRE in .target files

With recent change for better Execution Environment, BREE and system packages handling, only 1 execution environment is added to the context for dependency resolution (unless resolveWithExecutionEnvironmentsConstraints is set to false) and this EE is usually derived from the BREE of the bundle. This can lead to some dependency resolution error, for example when building a bundle with Bundle-RequiredExecutionEnvironment: JavaSE-1.5, hence using JavaSE-1.5 as default execution environment with a target-platform containing bundles requiring JavaSE-1.8 or JavaSE-11.

So, for dependency resolution to be reliable and relevant, it's best to enforce the executionEnvironment to be the higher one of the BREE requirement and the target-platform requirement. As Tycho cannot know in advance what is the required Java version for your target platform (ie your .target files and the referenced <repositories>), you'll probably need to upgrade manually the execution environment in case the EE required for the target-platform is higher than the bundle BREE. This can be achieved by explicitly setting the <executionEnvironment> configuration child of the target-platform-configuration block as explained in Tycho/Execution_Environments#Execution_environment_configuration.

Notes on settings <executionEnvironment> configuration child of the target-platform-configuration:

• This setting takes priority over the automatic choice by Tycho described above.
• Setting it explicitly can be useful as it allows to ensure what you're resolving and testing against better maps the actual content of your target environments. This will allow to catch issue like missing system packages when targeting newer Java version much earlier, during dependency resolution with a more explicit error message, rather than during the test execution.
• When setting it, make sure that this EE can actually be satisfied (i.e. when using <useJDK>SYSTEM</useJDK> the SYSTEM JRE matches, or when using <useJDK>BREE</useJDK> a matching toolchain is available). Otherwise this can lead to unexpected dependency resolution problems.

Support for <executionEnvironment>none</executionEnvironment>

bug 565298 To better support cases where the Execution Environment is already part of the target platform as installation units, such as runtime embedded with Eclipse JustJ, it's now possible to set <executionEnvironment>none</executionEnvironment> in the target-platform-configuration block. This will exclude the transient unit representing the execution environment from dependency resolution, leaving all room for other units to fulfill the EE requirements.

Remove non-matching a.jre.javase/config.a.jre.javase from resolution

Since execution environments and system packages are now correctly handled, and bug 387701 got fixed in Tycho 1.2; Tycho removes the extra (and error prone) a.jre.javase units that do not match current execution environment. Older products that have a hard requirement on those IUs instead of using an osgi.ee capability requirement will now face some issues at being resolved. The corresponding a.jre.javase units will need to be added to the target-platform for the product to resolve, or -better- the requirements on such units should be plainly removed.

target-platform-configuration has more built-in documentation

bug 563162 Some dummy no-op mojo was associated with the target-platfrom-configuration, to provide better assistance and documentation in the editor.

Support other (file-based) Locations in .target files

bug 538144 - Until now it was only possible to use P2 based Update-sites with Tycho, from now on the other location types (Directory, Feature, Installation) are also supported. Feel free to test and give feedback if there is something missing!

If using this feature the following things should be taken into account:

• Because of the nature of file based locations you probably always wan't to include the target project in the reactor build when you reference files from that project as the reactor build is the only source for tycho to find 'projects'. The same applies if you reference other projects.
• only a very small subset of the available variables are supported at the moment: Environment Variables, System-Properties and Project references, if you feel something essential is missing please open a bug so we can add support for this.

Support for multiple .target files in eclipse-target-definition modules, with classifier

bug 461284 - until now the target-packaging only has supported exactly one target file to be installed that must be named exactly like the artifactId this has now changed to the following contract:

• the target-packaging install all targets found in the root with the "primary artifact" as the artifact and all other files as additional artifacts with classifier
• if multiple targets are there to install, there must be one target named like the artifactId that is chosen as the "primary artifact"
• if only one target is present, it will be picked up as "primary artifact" regardless of the name of the target file
• using classifiers in the target platform-configuration one can select a different target to be used

<configuration>
	<target>
	<artifact>
		<groupId>org.eclipse</groupId>
		<artifactId>org.eclipse.project.target</artifactId>
		<version>1.0.0</version>
		<classifier>neon</classifier> <!-- Use filename, without .target -->
	</artifact>
	</target>
</configuration>

Unlink compiler levels from execution environemnt

The compilation levels are derived from explicit sources like Bundle-RequiredExecutionEnvironment or related settings in build.properties or pom.xml, and are not affected any more by the execution environment that is used to resolve dependencies. So you can set executionEnvironment to JavaSE-11, have a bundle with BREE=JavaSE-1.8, and Java 1.8 will be used as compile source/target level without extra configuration.

Define Maven Project properties in build.properties

bug 532575 - it is now possible to add pom.model.property.<property>=<value> to build.properties to define/override a property in the pom.xml

Pomless

Support multiple product files

bug 562887 - pomless now automatically discover multiple product files and generates appropriate configuration to build them in one step