Community
Participate
Working Groups
N20120121-2000. It fails when creating the Java 7 test project in org.eclipse.jdt.debug.tests.AbstractDebugTest.assert17Project() The failure message (null) is not helpful. Running the tests locally works for me.
Mike, can you take a look?
(In reply to comment #1) > Mike, can you take a look? Certainly. The failures are present in: http://fullmoon.ottawa.ibm.com/downloads/drops/N20120121-2000/testresults/html/org.eclipse.jdt.debug.tests_win32.win32.x86_7.0.html Looks like the Java 7 test project is failing to be created and the rest just cascade: testUnderscoreDoubleVarAssignment Failure null junit.framework.AssertionFailedError: null at org.eclipse.jdt.debug.tests.AbstractDebugTest.assert17Project(AbstractDebugTest.java:376) at org.eclipse.jdt.debug.tests.AbstractDebugTest.get17Project(AbstractDebugTest.java:555) at org.eclipse.jdt.debug.tests.core.LiteralTests17.getProjectContext(LiteralTests17.java:42) at org.eclipse.jdt.debug.tests.AbstractDebugTest.getType(AbstractDebugTest.java:1709) at org.eclipse.jdt.debug.tests.AbstractDebugTest.createLineBreakpoint(AbstractDebugTest.java:1317) at org.eclipse.jdt.debug.tests.core.LiteralTests17.doEval(LiteralTests17.java:78) at org.eclipse.jdt.debug.tests.core.LiteralTests17.testUnderscoreDoubleVarAssignment(LiteralTests17.java:245) at org.eclipse.jdt.debug.tests.AbstractDebugTest.runBare(AbstractDebugTest.java:2268) at org.eclipse.jdt.debug.tests.DebugSuite$1.run(DebugSuite.java:55) at java.lang.Thread.run(Thread.java:722)
Running the tests locally also does not fail for me, so I added some extra error message handling to try and find out why the test project is failing to be created. See: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=f57e0d40978e0ecc90902e92560a0b585973928d
(In reply to comment #3) > I added some extra > error message handling to try and find out why the test project is failing to > be created. This didn't help much. I've added more info now for the next I-build.
Fixed in master: 83afbfbb14907721c727a808e00d33c356e1f71e The problem was that the 'java7' folder wasn't added to the 'build.properties' and hence missing when the bundle was built.
(In reply to comment #5) > Fixed in master: 83afbfbb14907721c727a808e00d33c356e1f71e Actually the commit was in 'integration'. Merged into master now.
Kim, something looks fishy here: 'master' contains the correct build.properties: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/tree/org.eclipse.jdt.debug.tests/build.properties?id=83afbfbb14907721c727a808e00d33c356e1f71e and when I export the bundle, the 'java' folder is in it. However, when looking at the built test plug-in: http://download.eclipse.org/eclipse/downloads/drops/N20120130-2000/download.php?dropFile=eclipse-Automated-Tests-N20120130-2000.zip The 'java7' folder is not there. Can you check whether the build machine is correct and whether the source is really from master for eclipse.jdt.debug.git org.eclipse.jdt.debug.tests
Also verified that it's not a upper/lowercase issue: "java7" is used at all places.
Yes Dani, the build machine doesn't reflect this content. I think the problem is because I implemented the changes in bug 363603 on Friday to cache the git repos so that we don't have to fetch them each time. This makes the build 50+ minutes faster. However, it doesn't seem to be updating the local content as expected. I'll revert this change, and also restart the integration build so this doesn't happen. When I tested this, it appeared to be working and updating content but perhaps there are intermittent problems I didn't detect in the test build.
(In reply to comment #9) > ... > I'll revert this change, and also restart the integration build so > this doesn't happen. Thanks Kim!
Verified in I20120131-0910. Waiting for the next N-build results...
Also verified in N20120131-2000.
