On Thursday 21 July 2016 19:06:37 Robert Munteanu wrote: > On Thu, 2016-07-21 at 13:59 +0200, Oliver Lietz wrote: > > On Wednesday 20 July 2016 17:24:15 Robert Munteanu wrote: [...] > > That can be done always by editing SlingVersionResolver.java > > directly. > > Using feature.xml should ensure (tests in bootstrap) that all bundles > > are > > compatible (form a runnable Sling instance) and updates don't have to > > be done > > twice. > > Right, I think that's the toughest part - making sure the bundle versions > are in sync. > > Also, a couple of suggestions related to further reducing the boilerplate. > > 1. Simpler HTTP port detection > > If no http port is specified we can just pick a random one and log it, or > otherwise we have > > withHttpPort(int port); > > method which takes a specified HTTP port. > > 2. Automatic management of the working directory > > In the event ITs we manually manage: > > - the working directory > - sling.home > - repository.home ( or alternatively the OSGi configs for the segment node > store and the lucene index provider ) > > Could we also move these inside the module? I don't think we even need a > config option here, just auto-manage them. > > If you agree, I'll file enhancement requests.
See my latest commits in Testing PaxExam (SLING-5893 and SLING-5894) and Scripting Thymeleaf. There is now test support (similar to what I've done for Launchpad Karaf ITs) and a default configuration. I've tried to find the perfect balance between automation and adaptability. Let me know if it works for you. Regards, O. > Thanks, > > Robert [...]
