Community
Participate
Working Groups
3.4 M5 - fup on bug 202490 APIDocumentationTests#test001 was only tested in local mode and I feared breaking the remote builds before getting it right for remote execution. Since we are now very close to M5, I prefer deferring the test tuning to early M6. Note that this kind of tests is new, which involves some risks, but desirable, as it already picked a few mismatches.
New Gerrit change created: https://git.eclipse.org/r/61523
Tests have been updated and run successful in the IDE. On Hudson, the source file JavaCore.java is not found, probably, because JavaCore.getJavaCore().getBundle() resolves to a jar below target/ which doesn't contain the sources. New experiment is running where we simply take the path to org.eclipse.jdt.core.tests.model and then navigate to ../org.eclipse.jdt.core/model/.../JavaCore.java. Looking at the workspace on Hudson this should be good, but then I don't know if the same also holds during SDK builds. --------- @David, do you have a hint how a test during SDK build can access a source file from another bundle? Can we rely on a specific workspace layout? If https://hudson.eclipse.org/platform/job/eclipse-aggregator-master/ is the job I need to look at, I don't seem to be able to see its workspace. Should we try to resolve bundle org.eclipse.jdt.core.source and peek inside? --------- syserrs are in place to document how we fare on Hudson.
Gerrit change https://git.eclipse.org/r/61523 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=7e04164b6ff5e1f953daad29cd865817aa19cb20
(In reply to Eclipse Genie from comment #3) > Gerrit change https://git.eclipse.org/r/61523 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=7e04164b6ff5e1f953daad29cd865817aa19cb20 > The gerrit job was happy. Note, that the test actually pointed out three mistakes in the javadoc, which have been fixed in this commit. I'm taking the risk of one test failure in the next nightly build. (In reply to Stephan Herrmann from comment #2) > syserrs are in place to document how we fare on Hudson. Here's their output: Bundle URL = bundleentry://87.fwk391359742/ Bundle path = /jobs/genie.platform/eclipse.jdt.core-Gerrit/workspace/org.eclipse.jdt.core.tests.model/ jdt.core path = /jobs/genie.platform/eclipse.jdt.core-Gerrit/workspace/org.eclipse.jdt.core JavaCore.java = /jobs/genie.platform/eclipse.jdt.core-Gerrit/workspace/org.eclipse.jdt.core/model/org/eclipse/jdt/core/JavaCore.java exists?true syserrs are still in place. Keeping this bug open until their removal.
(In reply to Stephan Herrmann from comment #2) > --------- > @David, do you have a hint how a test during SDK build can access a source > file from another bundle? > Can we rely on a specific workspace layout? > If https://hudson.eclipse.org/platform/job/eclipse-aggregator-master/ is the > job I need to look at, I don't seem to be able to see its workspace. > Should we try to resolve bundle org.eclipse.jdt.core.source and peek inside? > --------- > I do not have much of a hint, but can tell you the right place to look. Our production unit tests take place on the 'shared instance' of Hudson. Its URL is https://hudson.eclipse.org/shared/view/Eclipse%20and%20Equinox/ You can "drill down" into any specific job, with names like p4[IMN]-unit-[OS][BTNESS] and find fine the 'workspace' link for the most recent build. If you drill-down there, you can eventually find your way to the SDK as installed for a test. The one that is there, though, is only for the last test ran (but, should be similar to others). https://hudson.eclipse.org/shared/view/Eclipse%20and%20Equinox/job/ep46N-unit-lin64/ws/workarea/N20151128-1500/eclipse-testing/test-eclipse/eclipse/
(In reply to David Williams from comment #5) > You can "drill down" into any specific job, with names like > p4[IMN]-unit-[OS][BTNESS] > Sorry for typos. Should be more like ep46[IMN]-unit-[OS][bitness] such as ep46N-unit-lin64
(In reply to David Williams from comment #6) > (In reply to David Williams from comment #5) > > > You can "drill down" into any specific job, with names like > > p4[IMN]-unit-[OS][BTNESS] > > > > Sorry for typos. Should be more like ep46[IMN]-unit-[OS][bitness] > > such as ep46N-unit-lin64 Thanks! From there I saw that the nightly simply skipped the test in question, because JavaCore.java was indeed not found. I will upload a patch shortly, that alternatively looks up the file from within org.eclipse.jdt.core.source.jar (using PackageAdmin).
New Gerrit change created: https://git.eclipse.org/r/61632
Status: - caught 3 typos in the javadoc (corrected via commit 7e04164b6ff5e1f953daad29cd865817aa19cb20) - tests run in a development workspace, on gerrit and during SDK builds (I saw the expected results from the temporary syserrs). - test has been cleaned up (remove syserrs, give it a name that can be identified on test result page) If gerrit agrees we should be done here.
Gerrit change https://git.eclipse.org/r/61632 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=fe412add93d4cfbb83d610f46ca1de0e6d064ca7
Verified for 4.6 M4 using I20151207-2000 build
