Hi Mike Müller wrote: > Hi > > If you check out sling and try to build by mvn clean install, the > SlingLogWriterTest fails: > > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running org.apache.sling.commons.log.internal.slf4j.SlingLoggerTest > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079 sec > Running org.apache.sling.commons.log.internal.slf4j.SizeLimitedFileRotatorTest > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec > Running org.apache.sling.commons.log.internal.slf4j.SlingLogWriterTest > Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.141 sec <<< > FAILURE! > > Results : > > Failed tests: > > test_daily_rotation(org.apache.sling.commons.log.internal.slf4j.SlingLogWriterTest) > > Tests run: 17, Failures: 1, Errors: 0, Skipped: 0 > this works for me (and it seems to work for our Hudson instance as well). Can you give us more information about your environment?
> Wouldn't it be better to have a build process which really builds the latest > version > (testingversion for integration tests webapp and standalone launchers > included)? Hmm, not sure if I understand you correctly here. The reactor build builds the latest versions (like our Hudson instance does). We're not referencing the latest versions in our integration tests from the launchpad in all cases. > IMHO that would increase the quality of the code and makes it easier to test > something > again the newest version. If someone wants something more stable than the > snapshot she/he > would anyway go with the binary build which is available from the site and > not with the > newest source. I know I came up with this a few weeks ago, but like to > discuss it again > because it seems to be really errorprone the way it is today. Hehe, yes here we go again :) And I think the arguments why we are doing it this way still stand :) Now maybe we could add a new module for the integration tests which always runs the tests against the latest modules (like Gump does). I think this would be a nice addition. But I would like to keep the launchpad contract like it is today :) In this case, it doesn't make a difference as on your machine building a single module fails. Regards Carsten -- Carsten Ziegeler [email protected]
