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 <bdelacre...@apache.org> > Hi Jörg, > > On Tue, Jan 14, 2014 at 10:13 AM, Jörg Hoh <jhoh...@googlemail.com> 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
