In progress
This page is work in progress, feel free to ask on dev@sling if anything seems incorrect or is unclear
Problem statement and goals
As summarised by Stefan Seifert:
Currently we have only one launchpad in trunk, which contains a mixture of release dependencies and snapshot dependencies. this makes it difficult to release new versions because one has to release all snapshot projects first, and perhaps the last relese version is fine as well.
We came up with a new proposal to fulfill the different needs:
- the launchpad maintained in trunk should always be the "stable" launchpad, referencing only released dependencies of the sling bundles and oft the integration tests project
- the "unstable" launchpad is created dynamically from this stable launchpad by using the same bundle list, but for each dependency the latest snapshot version that is available in the maven repo, including the latest snapshot version oft he integration tests. perhaps the slingstart plugin could be extented to generate this.
- not sure what to do with new bundles which are not released yet thus are not referenced in the stable launchpad.
Implementation
For converting release versions to SNAPSHOT ones, Bertrand Delacretaz has come up with a shell script that sets all dependency versions to SNAPSHOT , although it seems to not work in all situations. This script would be run on Jenkins or locally to convert the 'release' (stable) launchpad to a 'snapshot' (unstable) one.
We also discussed how to handle tests deployed under the launchpad which test functionality which is only present in SNAPSHOT versions. The proposals where:
- Create an annotation/assumption related to the bundles deployed in the Sling launchpad, e.g. \@NeedsBundleVersion(name="org.apache.sling.api", version="2.10.0") or Assume.asumeThat(bundleVersionPresent("org.apache.sling.api", "2.10.0"));
- Use a simple exclusion lists for deactivating tests, ideally using the same mechanism as the one used to switch to snapshot versions
A new pair of Jenkins jobs need to be created, to cover building the unstable launchpad and running the integration tests against it. The launchpad should be deployed with a different classifier, to prevent any mix-ups on repository.apache.org.
Related concepts
Maven 3.5.0 has introduced a concept of CI-friendly-versions ( see more information at https://maven.apache.org/maven-ci-friendly.html ), but it's not clear if we can benefit from this feature.