This page describes the noteworthy improvements provided by each release of Eclipse Tycho.
The assemble-maven-repository mojo now supports embedding the PGP signature of maven artifacts to allow additional verifications and trust decisions.
Tycho supports the new m2e-pde features regarding multiple dependencies per target and specifying extra repositories in the target.
It is now possible to resolve the JDT 'JUnit Classpath Container', for this do the following:
- add the 'JUnit Classpath Container' to the classpath of your eclipse project
- make sure you check in the .classpath file
- Now you can use the Junit classes without explcitly adding them to your bundle via require-bundle/import package
For an example take a look at the integration tests
Before unit-tests are only executed for eclipse-test-plugin packaging types. Beside that it was only possible to execute them as part of tycho-surefire (what executes them inside an OSGi runtime) in the integration-test phase (making them actually some kind of integration test).
From now on this restriction is no longer true and one is able to execute unit-test with maven-surefire as well as integration-tests with tycho-failfast plugin. This works the following way:
- create a source-folder in your eclipse-plugin packaged project and mark them as a contains test-sources in the classpath settings:
- Create a unit-test inside that folder, either name it with any of the default-pattern maven-surefire plugin of or configure them explicitly.
- Include maven-surefire plugin configuration in your pom to select the approriate test-providers
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M5</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit47</artifactId>
<version>3.0.0-M5</version>
</dependency>
</dependencies>
</plugin>
- run your it with
mvn test
Tycho also includes a new tycho-failsafe mojo, that is similar to the maven one:
- it executes at the integration-test phase but do not fail the build if a test fails, instead a summary file is written
- the outcome of the tests are checked in the verify phase (and fail the build there if neccesary)
- this allows to hook some setup/teardown mojos (e.g. start webservers, ...) in the pre-integration-test phase and to safely tear them down in the post-integration test phase (thus the name 'failsafe' see tycho-failsafe-faq for some more details
Given you have the above setup you create an integration-test (executed in an OSGi runtime like traditional tycho-surefire mojo) as following:
- create a new test that mathes the pattern
*IT.java(or configure a different pattern that do not intersects with the surefire test pattern) - run your it with
mvn verify
-Dtest=.... on the root level of your build tree it might now be necessary to also include -Dsurefire.failIfNoSpecifiedTests=false as maven-surefire might otherwise complain about
No tests were executed! (Set -DfailIfNoTests=false to ignore this error.)
for your eclipse-plugin packaged project if they do not match anything (the error message is a bit misleading, this is tracked in SUREFIRE-1910).
tycho-surefire now support to set .options files for debugging through the new debugOptions parameter, example:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-surefire-plugin</artifactId>
<version>${tycho-version}</version>
<configuration>
<showEclipseLog>true</showEclipseLog>
<debugOptions>${project.basedir}/../../debug.options</debugOptions>
</configuration>
</plugin>
Tycho now correctly supports repository references in category.xml: in the previous versions, the content XML generated by Tycho only contained a reference to the metadata referred repository, but not to the artifacts referred repository, resulting in failures in installations (the verification phase went fine, but the actual installation could not be performed by p2).
A new mojo tycho-gpg-plugin:sign-p2-artifacts-mojo was added to add GPG signatures to artifacts metadata. Those GPG signatures are later expected to be used by p2 during installation to verify integrity and build trust in installed components.
Tycho now understands the additional.bundles directive in the build.properties file and properly resolves them during dependency resolution.
A new mojo tycho-p2-repository-plugin:assemble-maven-repository was added to enable creation of p2 repositories directly from Maven artifact references. This removes the usual need to create a target definition and a category.xml for this task.
To speed up Maven clean-only builds, Tycho's dependency resolution is now skipped, if the only phase specified is one from the clean lifecycle, namely clean,pre-clean,post-clean.
Previously one had to specify the property -Dtycho.mode=maven to skip dependency resolution.
Official Equinox Resolver used for dependency resolution (stricter and can produce errors for split packages)
{{bug|570189}} Tycho now uses the same resolver as Equinox uses at runtime. This resolver is stricter and more correct than the previous one, and as a result should provide resolution results that are much more consistent with actual dependency resolution at runtime.
However, this change makes {{bug|403196}} more visible in some cases with split package, for example
Unresolved requirement: Require-Bundle: org.eclipse.equinox.security
-> Bundle-SymbolicName: org.eclipse.equinox.security; bundle-version="1.3.600.v20210126-1005"; singleton:="true"
org.eclipse.equinox.security [1]
Unresolved requirement: Import-Package: org.eclipse.core.runtime; registry="split"
which means that the p2 resolution succeeds while it actually failed at providing the Import-Package: org.eclipse.core.runtime; registry="split" and later OSGi resolution will find it's missing and complain.
In such case, the workaround/solution is to ensure that the bundle that provides Import-Package: org.eclipse.core.runtime; registry="split" gets added as part of p2 resolution despite {{bug|403196}}, typically by adding org.eclipse.equinox.registry to the Required-Bundle of the bundles being built, or by adding it to target-platform-configuration as described in https://www.eclipse.org/tycho/sitedocs/target-platform-configuration/target-platform-configuration-mojo.html#dependency-resolution .
{{bug|570477}}, The tycho-eclipserun-plugin now has a configuration-parameter named clearWorkspaceBeforeLaunch to specify if the workspace should be cleared before running eclipse or not (default is true, matching the behavior until now). If the value is false, the workspace of the previous run is reused (if present), if the value is true the workspace-directory (i.e. the 'data' directory within the work-directory) and its content is deleted.
A mojo to "fix" modified metadata in artifact repository (artifacts modified after after aggregation)
The [https://ci.eclipse.org/tycho/job/tycho-sitedocs/lastSuccessfulBuild/artifact/target/staging/tycho-p2/tycho-p2-repository-plugin/fix-artifacts-metadata-mojo.html org.eclipse.tycho:tycho-p2-repository-plugin:fix-artifacts-metadata] was added. It updates the artifact repository metadata checksums and size of modified artifacts in the given folder. This can be used if some other mojo (e.g. jar-signer) modifies the repository artifacts after the assemble-repository step. An example could be found in the [https://github.com/eclipse/tycho/tree/master/tycho-its/projects/jar-signing-extra jar-signing-extra] integration test
The [https://ci.eclipse.org/tycho/job/tycho-sitedocs/lastSuccessfulBuild/artifact/target/staging/tycho-p2/tycho-p2-repository-plugin/remap-artifacts-to-m2-repo-mojo.html org.eclipse.tycho:tycho-p2-repository-plugin:remap-artifacts-to-m2-repo] was added. It modifies the artifact metadata of the provided p2 repository by adding extra mapping rules for artifacts the can be resolved to Maven repositories so the URL under Maven repository is used for fetching and artifact is not duplicated inside this repo. See [https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-its/projects/p2Repository.mavenRepo/pom.xml#n28 this example].
{{bug|571520}} allow to specify a target file as an alternative to a target artifact
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<target>
<file>jetty.target</file>
</target>
</configuration>
</plugin>
{{bug|572082}}, allow applications to use bundle pools in order to have a "cross platform" installation structure without duplicating the bundles. To activate the multi-platform package, simply add true to the product definition in the pom.xml file.
{{bug|568729}}, {{bug|569481}} m2e includes a new feature that allows the usage of regular maven artifacts to be used in PDE target platforms. Support for this new location type was also added to tycho, you could read more about this new feature in the following article.
{{bug|568446}} When using parallel builds the initial dependency resolution is now also executed in parallel.
{{bug|567760}} Tycho now stops downloading p2 artifacts from remote sources too early and relies mostly on p2 metadata to compute target platform and build order without downloading the artifacts. Downloads are then instead delayed to when the artifact files are really necessary (to compute compilation build path, to generate a p2 repository...). As a result performance will be improved as less artifacts may be downloaded, and some steps like mvn clean or mvn validate can avoid downloading artifacts to process, and the most probable build failures will be reported faster.
Note that this is specifically visible for eclipse-feature and eclipse-repository modules; other module types like eclipse-plugin or eclipse-test-plugin do still require to downlaod artifacts early to create the build path. Further improvements remain possible on that topic.
{{bug|568359}} Historically the tycho-source-feature-plugin was located in tycho extras but could be confusing because they often are used in conjunction with to each other because a source-bundle is hardly useful without corresponding source-feature. With the merge of tycho-core and tycho-extras these separation becomes even more obsolete.
From now on, the tycho-source-plugin also includes the tycho-source-feature-plugin, the old one is deprecated and will be removed in the next major release.
Migration is rather simple, just add a new execution to the tycho-source-plugin
<source lang="xml">
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-source-plugin</artifactId>
<version>${tycho-version}</version>
<executions>
<execution>
<id>plugin-source</id>
<goals>
<goal>plugin-source</goal>
</goals>
</execution>
<execution>
<id>feature-source</id>
<goals>
<goal>feature-source</goal>
</goals>
<configuration>
<!-- put your configuration here -->
</configuration>
</execution>
</executions>
</plugin>
</source>
Beside this, the new mojo does support one additional configuration option 'missingSourcesAction' that can have one of the following two values:
- FAIL: this is like the old mojo works, any missing source bundle that is not excluded will fail the build
- WARN: this is the default, a warning will be omitted listing all missing plugins/features that are not excluded
{{bug|398238}} Tycho now supports in target files and in elements URLs of the form mvn:groupId:artifactId:version[:packaging[:classifier]] to be used for a repository.
For example
<repository>
<id>activiti</id>
<layout>p2</layout>
<url>mvn:org.activiti.designer:org.activiti.designer.updatesite:5.11.1:zip</url>
</repository>
{{bug|568623}} Tycho now supports in build properties files to exclude files in library.
For example
output.mycodelib.jar = bin/
bin.includes = META-INF/,\
mycodelib.jar
source.mycodelib.jar = src/
exclude.mycodelib.jar = **/*.txt