Hi Carsten >> snip snap > > Failed tests: > > > test_daily_rotation(org.apache.sling.commons.log.internal.slf4 > j.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?
It's WinXP SP3. I digged into it and found that test.setLastModified(july21) (line 190 of SlingLogWriterTest) doesn't change the modified date of the file. So the test fails at line 195. But I can't imagine why it doesn't change the date of the file. > > 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. What I mean is that the integration tests should test the latest source. If something breaks the tests (even the integration tests) we should notice that immediately. > > 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. Yes, something like this would be very good and would meet the desired functionality, that an integration test would fail immediately. But that would imply, that we have to maintain a copy of the launchpad/base/pom.xml pointing to the newest versions which was the argument not to do it. And as far as I know the launchpad/base was designed to make it easier to maintain this dependecies for the launchpad/app und the launchpad/webapp... best regards mike
