-
Notifications
You must be signed in to change notification settings - Fork 10
Managing Feature and Plugin Versions
For OSATE plugins use semantic versioning following mostly the versioning scheme used in eclipse. This is necessary to manage version compatibility between additional features developed at the SEI and elsewhere and specific OSATE versions. Also, when installing an additional feature p2 can pick compatible versions of additional plugins from an update site.
The are two tools that support API versioning: Eclipse PDE API Tools and Oomph Version Management.
API tools are included in the Eclipse Plugin-in Development Environment, which is installed when setting up a development environment using the Eclipse installer. The API tools compare the projects on the workspace with an "API Baseline." For OSATE this baseline is given by a target file, which points to the features and plugins of the previous OSATE version. The API tools recognize API changes the require changes to plugin and feature versions. Error markers indicate the necessary changes, and quick fixes are provided to make the changes.
The API baseline is set up by Oomph in the new OSATE API Baseline setup task. The baseline must be updated whenever the target file osate.target in project org.osate.build.target changes. This can be done by running setup tasks manually (Help -> Perform Setup Tasks), and it should happen automatically after a restart of the development Eclipse.
You can check the baseline in the preferences under Plug-in Development -> API Baselines.
API tools must be enabled for each new project. To enable them right click on the project in the project explorer or package explorer. In the context menu select Plug-in Tools -> API Tools Setup.... This adds the API nature and API analysis builder to the project configuration.
Functionality of the API tools is documented in the Eclipse help text. There's also a video of a recent talk available.
API tools are not yet enabled for the maven build.
see recent new and noteworthy for how to do this
Oomph also has a version management tool that provides additional functionality. In particular, we use it to make sure that the micro version must be incremented if the content of a plugin changes. It enforces that the lower bound of a dependency in a manifest matches the latest plugin version. It also checks version consistency between the manifest and pom files.
Oomph version management is part of the setup file, so it will be installed when running the setup tasks.
This tool does not work with an API baseline but creates its own release management files. For OSATE these are in releng/version-management. The releng project must be imported into the workspace for this to work.
Version management must be set up for each new project: right click on the project in the project explorer or package explorer. In the context menu select Configure -> Add Version Management.... Use the following settings:
- Path to release specification file:
/releng/version-management/release.xml - Select the following five options
- Ignore schema builder
- Ignore feature content redundancy
- Check feature closure completeness
- Check feature closure content
- Check Maven POM
what's to be done after an osate release to prepare for the next release
A clean build deletes all code generated from Xtend. After that the Xtend Builder generates Java code and the API Analysis Builder analyzes the API. For some reason the generated Java code confuses the API builder, it looks like it is running before the Java code is generated, and there seems to be no easy way to fix this.
There is a workaround:
- Open
Preferences->Plug-in Development - Check
Disable API analysis builder - Click
Applyand clickNot nowin the following dialog - Uncheck
Disable API analysis builder - Click
Applyand clickBuildin the following dialog
This should get rid of the bogus errors. In general we recommend to avoid clean builds.
Dependencies in org.osate.build.coverage.report must be updated when the version of a plugin project changes. New projects must be added as dependencies in the pom file to include them in the coverage report.
Version numbers are updated automatically as part of the build in Jenkins. However, these updates are not committed to git.
Versions for this plugin are managed using maven dependencies in the project's pom file. Updates can be done manually or with the following maven command which should be run in directory <GIT_ROOT>/osate2.
mvn org.codehaus.mojo:versions-maven-plugin:use-reactor -DgenerateBackupPoms=false -Dtycho.mode=maven
There is also a launch configuration Update coverage report dependencies that runs this maven command in Eclipse.
See Use Reactor Mojo for details.
This happens if the entry Bundle-SymbolicName is deleted from the MANIFEST.MF of any of the OSATE plugins. Oomph version management breaks without this entry.