On Fri, 2016-10-14 at 15:45 +0200, Carsten Ziegeler wrote: > Bertrand Delacretaz wrote > > On Mon, Oct 3, 2016 at 3:20 PM, Robert Munteanu <romb...@apache.org > > > wrote: > > > ...If we make building an unstable launchpad really simple, e.g. > > > an addition > > > profile or a mojo property, I don't think we lose anything... > > > > I've committed an experimental script [1] which modifies the > > launchpad/builder provisioning model files to remove the version > > numbers for all Sling artifacts. See comments in the script for > > details (and enjoy the sed regexp ;-) > > > > When doing so, the Slingstart plugin uses the latest snapshot > > instead > > of a specified version, IIUC. > > > > The script doesn't fully work yet (see comments in the script - > > patches or hints welcome) but once it does the process for running > > our > > integration tests on this all-snapshots launchpad would be: > > > > 1) Run this script in launchpad/builder, build and deploy that, > > with a > > specific classifier or other marker > > 2) Run the launchpad/testing build using that special launchpad jar > > 3) Revert the code changes caused by step 1), unless working in a > > throwaway folder > > > > Would that work for you guys? > > > > Sorry I already replied to your commit as I didn't see this mail :( > > I think a script is fine and thanks for taking it up. > My initial thoughts were to do this in the slingstart maven plugin > This would give a little bit more control - if required, like > enabling > snapshots only for a single feature or something. Or having a > blacklist. > > But maybe that's not needed anyways
How would we handle launchpad tests that rely on functionality introduced in a SNAPSHOT dependency? These would fail with the stable launchpad. We could make then run conditionally just with the unstable launchpad but OTOH we need to remember to remove that check after the bundle which provides the new functionality ( or the bug fix ) is released and included in the launchpad. Robert
