Hi Jörg, I've created a maven plugin [1] and some common test classes [2] specifically to make this easier for CQ5. The Granite IT maven plugin is designed to work with the maven-failsafe-plugin by provided the readiness check functionality and by exporting HTTP configuration properties using the Sling Testing conventions. Instead of extending SlingTestBase, your unit tests can extend my SlingRemoteTestBase [3], which does not use a JarExecutor, and does not perform a server readiness check.
[1] http://adamcin.net/graniteit-maven-plugin/ [2] http://adamcin.net/net.adamcin.commons.testing/ [3] https://github.com/adamcin/net.adamcin.commons.testing/blob/master/src/main/java/net/adamcin/commons/testing/sling/SlingRemoteTestBase.java Maybe you will find something useful. Mark Adamcin http://adamcin.net/ On Tue, Jan 14, 2014 at 3:24 AM, Jörg Hoh <[email protected]> wrote: > Hi Bertrand, > > yes, the initialisation of the JarExecutor fails. But I figured out howto > workaround it. You need to provide these statements as configuration to > your maven-failsafe-plugin: > > <systemPropertyVariables> > <test.server.url>http://localhost:8080</test.server.url> > > > <jar.executor.jar.folder>${project.basedir}/target</jar.executor.jar.folder> > <jar.executor.jar.name.regexp>.*</jar.executor.jar.name.regexp> > </systemPropertyVariables> > > Then the JarExecutor constructor won't fail; and because test.server.url is > set, it will use the instance configured there and the JarExecutor is not > started. I will provide a patch to disable the creation of the JarExecutor > by configuration, thus avoiding the setting of other properties than > test.server.url. > > > Thanks for your help, > Jörg > > > > > > > > > 2014/1/14 Bertrand Delacretaz <[email protected]> > > > Hi Jörg, > > > > On Tue, Jan 14, 2014 at 10:13 AM, Jörg Hoh <[email protected]> > wrote: > > > ...I took your approach using SlingRemoteTestRunner and > > maven-failsafe-plugin, > > > and I got pretty far. The problem is now, that I SlingTestBase forks a > > new > > > server-process which runs the server-side tests. But on my side I have > an > > > already running Sling instance (CQ) and I want to leverage this > > instance... > > > > I agree that this should work, looking at [1] if you set > > launchpad.http.server.url that should prevent that class from starting > > its own instance, but maybe the JarExecutor setup fails if you do > > that? > > > > If that's correct we should fix that, you probably only need the > > server ready detection from SlingTestBase, so we might want to factor > > that out. I've been trying to avoid forcing such base class > > inheritance lately as that's not very convenient, we can probably > > improve that. > > > > -Bertrand > > > > [1] > > > http://svn.apache.org/repos/asf/sling/trunk/testing/tools/src/main/java/org/apache/sling/testing/tools/sling/SlingTestBase.java > > > > > > -- > Cheers, > Jörg Hoh, > > http://cqdump.wordpress.com > Twitter: @joerghoh >
