Tycho 0.24.0 is currently staged for release. To try it out, 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 0.24.0.
<pluginRepositories> <pluginRepository> <id>tycho-0.24.0-staged</id> <url>https://oss.sonatype.org/content/repositories/orgeclipsetycho-1028/</url> </pluginRepository> </pluginRepositories>
New and Noteworthy
POM-less Tycho builds
- A maven core build extension has been added to support (almost) pom-less builds of eclipse plugins and features (bug 462531).
To enable it,
- Requires maven 3.3+
- Add a .mvn/extensions.xml descriptor to the root of your build:
<?xml version="1.0" encoding="UTF-8"?> <extensions> <extension> <groupId>org.eclipse.tycho.extras</groupId> <artifactId>tycho-pomless</artifactId> <version>0.24.0</version> </extension> </extensions>
- The parent pom for features and plugins must reside in the parent directory
- features and plugins do not require pom.xml anymore. If no pom.xml is provided, the maven project model is derived as follows:
- groupId: inherited from parent
- arifactId: Bundle-SymbolicName from META-INF/MANIFEST.MF or feature id from feature.xml
- version: Bundle-Version from META-INF/MANIFEST.MF or feature version from feature.xml (with .qualifier suffix replaced by -SNAPSHOT)
- eclipse-plugin if META-INF/MANIFEST.MF found
- eclipse-feature if feature.xml found
- eclipse-test-plugin if Bundle-SymbolicName ending with .tests found in META-INF/MANIFEST.MF
- At minimum a parent (and aggregator) pom is still required which configures Tycho, the modules to build, the p2 repositories used etc. as this cannot be derived from feature.xml or MANIFEST.MF
- you can still use pom.xml for plugins and features in case you want to configure more than the above defaults
- See the sample build used by the integration tests
org.eclipse.tycho.extras:tycho-p2-extras-plugin plugin features a new compare-version-with-baselines mojo that allows to verify that the version of the just-build artifacts doesn't break some basic rules of OSGi versioning. It will make the build of your artifact fail if:
- artifact has lower version than what exists in baseline
- artifact has same major.minor.micro version than what exists in baseline
- artifact has same fully qualified (major.minor.micro.qualifier version) than what exists in baseline, but with different binary content.
This is used in order to guarantee necessary version bumps have been applied, and this is compliant with the Tycho/Reproducible Version Qualifiers strategy.
See IT tests for an example of usage.