You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Andreas Hartmann <an...@apache.org> on 2009/01/21 14:38:31 UTC
Test failures in jcrinstall extension
Hi Sling devs,
I just did a fresh checkout of the trunk (Mac OS X, Java 1.5.0_16).
The command
mvn -s /dev/null clean install
resulted in
Failed tests:
testWebServerRoot(org.apache.sling.jcr.jcrinstall.integrationtest.HttpPingTest)
test404(org.apache.sling.jcr.jcrinstall.integrationtest.HttpPingTest)
testStopAndRestart(org.apache.sling.jcr.jcrinstall.integrationtest.StopAndRestartTest)
testInstallAndRemoveBundles(org.apache.sling.jcr.jcrinstall.integrationtest.InstallClonedBundlesTest)
testStopAndRestart(org.apache.sling.jcr.jcrinstall.integrationtest.StopAndChangeBundlesTest)
The log files contain this error:
unit.framework.AssertionFailedError: Sling services not available.
Already checked in earlier tests.
at junit.framework.Assert.fail(Assert.java:47)
at
org.apache.sling.commons.testing.integration.HttpTestBase.waitForSlingStartup(HttpTestBase.java:156)
Any hints what might be going wrong?
TIA!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
Re: Test failures in jcrinstall extension
Posted by Felix Meschberger <fm...@gmail.com>.
ok, so for now, I just switch them off, while I try to fix them
Regards
Felix
On Wed, Jan 21, 2009 at 3:53 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Wed, Jan 21, 2009 at 3:49 PM, Felix Meschberger <fm...@gmail.com>
> wrote:
> > ...How about this: We integrate the JCRInstall integration tests with the
> > main integration tests by means of a build profile. You may then switch
> > on or off this profile to run the integration tests with or without
> > JCRInstall....
>
> That sounds good, but as said before I'd like those tests to run by
> default (I can maybe reduce the default number of iterations/bundles
> to make them quicker), unless they run regularly in a continuous
> integration system.
>
> I won't be able to do this change soon though, as I'm travelling most
> of next week and quite busy until then.
>
> -Bertrand
>
Re: Test failures in jcrinstall extension
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jan 21, 2009 at 3:49 PM, Felix Meschberger <fm...@gmail.com> wrote:
> ...How about this: We integrate the JCRInstall integration tests with the
> main integration tests by means of a build profile. You may then switch
> on or off this profile to run the integration tests with or without
> JCRInstall....
That sounds good, but as said before I'd like those tests to run by
default (I can maybe reduce the default number of iterations/bundles
to make them quicker), unless they run regularly in a continuous
integration system.
I won't be able to do this change soon though, as I'm travelling most
of next week and quite busy until then.
-Bertrand
Re: Test failures in jcrinstall extension
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> On Wed, Jan 21, 2009 at 3:22 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> ...ok, how about removing jcr install from the default build ? Like for
>> example create a new inactive-by-default profile for jcrinstall ?...
>
> I'd be ok with that if we have a continuous integration setup where
> those jcrinstall tests run regularly. Otherwise we tend to forget to
> run those tests, until it's too late.
It depends on what you want to have: JCRInstall as part of the build or
not. If we want to integrate JCRInstall into the main build, I suggest
we also integrate the JCRInstall integration tests with the rest of the
integration tests.
Or the other way around: If I build the whole stuff, I am fine with
building, what's there. If it includes JCRInstall, fine. If it doesn't
fine, too. But if JCRInstall is included, it should be properly
integrated like any other module we have.
The problem basically is maintaining all these launchpad modules like
app, webapp, jcrapp, testing and jcrinstall/testing tends to turn into a
massive task. So reducing the number of these launchpad modules, would
probable be something very helpful. It is much better now with the new
structure, but it still is kind of a "mess" to set this up and we might
want to come up with something better.
How about this: We integrate the JCRInstall integration tests with the
main integration tests by means of a build profile. You may then switch
on or off this profile to run the integration tests with or without
JCRInstall.
WDYT ?
Regards
Felix
>
> I'm not sure about the status of that - we used to have a Continuum
> setup IIRC, but I don't remember seeing messages from that lately.
>
> -Bertrand
>
Re: Test failures in jcrinstall extension
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jan 21, 2009 at 3:22 PM, Felix Meschberger <fm...@gmail.com> wrote:
> ...ok, how about removing jcr install from the default build ? Like for
> example create a new inactive-by-default profile for jcrinstall ?...
I'd be ok with that if we have a continuous integration setup where
those jcrinstall tests run regularly. Otherwise we tend to forget to
run those tests, until it's too late.
I'm not sure about the status of that - we used to have a Continuum
setup IIRC, but I don't remember seeing messages from that lately.
-Bertrand
Re: Test failures in jcrinstall extension
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> On Wed, Jan 21, 2009 at 3:02 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> ...I have a question anyway: Shoulnd't the jcrinstall install integration
>> tests not be integrated with the launchpad integration tests anyway ?...
>
> I created a separate testing module for jcrinstall as we were
> experiencing concurrency issues that might need a lot of
> passes/bundles/whatever to reproduce, that's not quite the same
> testing pattern as the launchpad/testing module.
>
> I'm not convinced of merging the two, both test suites take quite a
> some time to run, being able to disable them separately sounds useful
> to me. And, maybe more important, not everybody needs jcrinstall
> whereas the launchpad/testing tests test a list of much more common
> components.
ok, how about removing jcr install from the default build ? Like for
example create a new inactive-by-default profile for jcrinstall ?
Regards
Felix
Re: Test failures in jcrinstall extension
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jan 21, 2009 at 3:02 PM, Felix Meschberger <fm...@gmail.com> wrote:
> ...I have a question anyway: Shoulnd't the jcrinstall install integration
> tests not be integrated with the launchpad integration tests anyway ?...
I created a separate testing module for jcrinstall as we were
experiencing concurrency issues that might need a lot of
passes/bundles/whatever to reproduce, that's not quite the same
testing pattern as the launchpad/testing module.
I'm not convinced of merging the two, both test suites take quite a
some time to run, being able to disable them separately sounds useful
to me. And, maybe more important, not everybody needs jcrinstall
whereas the launchpad/testing tests test a list of much more common
components.
-Bertrand
Re: Test failures in jcrinstall extension
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Hmm, looks like I forgot to migrate the jcrinstall integration test
module to the new launchpad.
I have a question anyway: Shoulnd't the jcrinstall install integration
tests not be integrated with the launchpad integration tests anyway ?
Regards
Felix
Andreas Hartmann schrieb:
> Hi Sling devs,
>
> I just did a fresh checkout of the trunk (Mac OS X, Java 1.5.0_16).
>
> The command
>
> mvn -s /dev/null clean install
>
> resulted in
>
> Failed tests:
> testWebServerRoot(org.apache.sling.jcr.jcrinstall.integrationtest.HttpPingTest)
>
> test404(org.apache.sling.jcr.jcrinstall.integrationtest.HttpPingTest)
> testStopAndRestart(org.apache.sling.jcr.jcrinstall.integrationtest.StopAndRestartTest)
>
> testInstallAndRemoveBundles(org.apache.sling.jcr.jcrinstall.integrationtest.InstallClonedBundlesTest)
>
> testStopAndRestart(org.apache.sling.jcr.jcrinstall.integrationtest.StopAndChangeBundlesTest)
>
>
> The log files contain this error:
>
> unit.framework.AssertionFailedError: Sling services not available.
> Already checked in earlier tests.
> at junit.framework.Assert.fail(Assert.java:47)
> at
> org.apache.sling.commons.testing.integration.HttpTestBase.waitForSlingStartup(HttpTestBase.java:156)
>
>
>
> Any hints what might be going wrong?
>
> TIA!
>
> -- Andreas
>
>