Difference between revisions of "Tycho/Release Notes/2.0"

Revision as of 01:44, 8 July 2020

SNAPSHOT builds

Tycho 2.0.0-SNAPSHOT is currently in development. To try out the most recent snapshot build, simply add the following snippet to your (parent) pom.xml or settings.xml, and set the property for the Tycho version (e.g. tycho-version) to 2.0.0-SNAPSHOT.

<pluginRepositories>
    <pluginRepository>
      <id>tycho-snapshots</id>
      <url>https://repo.eclipse.org/content/repositories/tycho-snapshots/</url>
    </pluginRepository>
</pluginRepositories>

SNAPSHOT site docs

Refer to the latest SNAPSHOT site docs for Tycho and Tycho Extras.

New and Noteworthy

Complete list of bug fixes and enhancements in 2.0.0-SNAPSHOT

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.

Proper BREE handling may require setting executionEnvironment in target-platform-configuration

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.

This extra step is actually a best practice 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.

No more extra a.jre.javase nor config.a.jre.javase units generated during dependency 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.

Tycho now support other (file-based) Target Platform Locations

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.