Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 369409

Summary:	LiteralTests17 fail
Product:	[Eclipse Project] JDT	Reporter:	Dani Megert <daniel_megert>
Component:	Debug	Assignee:	Dani Megert <daniel_megert>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	daniel_megert, kim.moir
Version:	3.8
Target Milestone:	3.8 M5
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Dani Megert

2012-01-23 10:45:41 EST

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.

Comment 1 Dani Megert

2012-01-23 10:46:03 EST

Mike, can you take a look?

Comment 2 Michael Rennie

2012-01-23 13:12:47 EST

(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)

Comment 3 Michael Rennie

2012-01-23 16:23:06 EST

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

Comment 4 Dani Megert

2012-01-25 09:22:06 EST

(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.

Comment 5 Dani Megert

2012-01-26 04:22:05 EST

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.

Comment 6 Dani Megert

2012-01-30 03:13:59 EST

(In reply to comment #5)
> Fixed in master: 83afbfbb14907721c727a808e00d33c356e1f71e

Actually the commit was in 'integration'. Merged into master now.

Comment 7 Dani Megert

2012-01-31 06:49:57 EST

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

Comment 8 Dani Megert

2012-01-31 07:00:14 EST

Also verified that it's not a upper/lowercase issue: "java7" is used at all places.

Comment 9 Kim Moir

2012-01-31 09:04:41 EST

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.

Comment 10 Dani Megert

2012-01-31 09:36:35 EST

(In reply to comment #9)
> ...
> I'll revert this change, and also restart the integration build so
> this doesn't happen. 

Thanks Kim!

Comment 11 Dani Megert

2012-02-01 02:40:36 EST

Verified in I20120131-0910.

Waiting for the next N-build results...

Comment 12 Dani Megert

2012-02-01 07:51:13 EST

Also verified in N20120131-2000.