Community
Participate
Working Groups
This is related to bug 492580. I noticed that "failonError" for the p2.repoRunnable task is set to true (which, is the default). We should set that to "false". I suspect that is what causes the "whole test run" to exit, instead of causing some tests to fail.
Created attachment 261318 [details] patch to change "true" to "false".
I think there is another issue with the pde build tests that is at least wrong, if not related to bug 492580. There is section of the 'init' code says: <delete> <fileset dir="${eclipse-home}" includes="org*.xml"/> </delete> There is also an earlier variable that says <property name="eclipse-home" value="${basedir}\..\.."/> I am pretty sure that variable setting is ignored during our tests since 'eclipse-home' should have already been set by the outer test.xml. In fact, the main log says, to paraphrase, .. the value of eclipse-home is /opt/users/genie.shared/workspace/ep46I-unit-lin64/workarea/I20160427-1200/eclipse-testing/test-eclipse/eclipse So, I think that <delete> does nothing? It is not recursive, right? (At first, I thought it might be deleting the "artifacts.xml" file, but ... guess not since it starts with 'org'.) So, this comment can pretty much be ignored :) Unless someone thinks deleting things during 'init' is a bad idea like I do. But, it is not wrong as I thought at first. You might want to turn on "verbose", though, so we'd know for sure if it was deleting anything.
Resolved via http://git.eclipse.org/c/pde/eclipse.pde.build.git/commit/?id=53a4e6d1f42833a8f36e5406441a7444ae382c34 Thanks David.
(In reply to David Williams from comment #2) > <property name="eclipse-home" value="${basedir}\..\.."/> ... > <delete> > <fileset dir="${eclipse-home}" includes="org*.xml"/> > </delete> These things are present in all test.xml files and were used in pre-Maven times to allow running tests from your workspace, and to ensure that repeated runs produce new results each time. I don't know how much of this is still functional, but I don't see a point in messing with stuff that nobody fully understands and that doesn't hurt at all.
Verified on I20160428-0800 that the 'false' value prevented the "failure" from stopping the whole test process. The creation of the delta pack still failed, but, that's better than failing the whole test run! Thanks,
