Community
Participate
Working Groups
testUnusedFilter1I Failure Wrong number of problems expected:<1> but was:<0> junit.framework.AssertionFailedError: Wrong number of problems expected:<1> but was:<0> at org.eclipse.pde.api.tools.builder.tests.ApiBuilderTest.assertProblems(ApiBuilderTest.java:418) at org.eclipse.pde.api.tools.builder.tests.usage.UnusedApiProblemFilterTests.deployTest(UnusedApiProblemFilterTests.java:183) at org.eclipse.pde.api.tools.builder.tests.usage.UnusedApiProblemFilterTests.x1(UnusedApiProblemFilterTests.java:208) at org.eclipse.pde.api.tools.builder.tests.usage.UnusedApiProblemFilterTests.testUnusedFilter1I(UnusedApiProblemFilterTests.java:195) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:501) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:259) at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:36) at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:32) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386) at org.eclipse.core.launcher.Main.main(Main.java:34) testImportJavadocTestSource Failure the test project api component must exist in the workspace baseline junit.framework.AssertionFailedError: the test project api component must exist in the workspace baseline at org.eclipse.pde.api.tools.tests.AbstractApiTest.createProject(AbstractApiTest.java:147) at org.eclipse.pde.api.tools.util.tests.ProjectCreationTests.setUp(ProjectCreationTests.java:60) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:501) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:259) at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:36) at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:32) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386) at org.eclipse.core.launcher.Main.main(Main.java:34)
The possibility of these failures have existing for quite some time. They are surfaced more frequently now that the tests recreate the workspace projects for each test. The problem is that a required project, refproject, is not finished building before the Api Builder runs on usageproject. So our builder aborts. The JDT problem is: [sourceId, JDT, categoryId, 10, message, The project cannot be built until its prerequisite refproject is built. Cleaning and building all projects is recommended, severity, 2] I suspected that maybe some of the builder optmizations added in 3.7 were causing refproject to not be built, however I ran the current tests against older 3.6 api tools bundles and the tests still fail in the same manner. Olivier/Dani, can either of you comment on why refproject might not be built? I can only reproduce the issue consistently in Windows.
During all of the builds, no builder ever runs on refproject (when the test is failing). The tests also end up doing full builds three times 1) When we first create the environment (perhaps the JDT tests we extend are kicking this off) 2) When we finish importing the projects (controlled by boolean flag, some tests have it set to true) 3) When we deploy the test, after adding whatever file we are testing This seems like a waste.
Is Olivier away? Dani, can you help investigate?
(In reply to comment #3) > Is Olivier away? Dani, can you help investigate? yep, Olivier is on vacation. I'll see what I can do to help on Monday.
Maybe related to bug 305732? You could also try to disable auto-build and then do a full build when ready. Olivier should be back today for more detailed feedback.
Created attachment 201675 [details] Fix for performance issue This patch corrects a change in the setup method of usage tests that avoids re-importing refproject for each test. The usage tests clean up their actual test classes (from usageproject), so they do not contaminate each other. This fix vastly improves the time it takes to run the usage tests. Olivier had suggested I look into using JUnit4 annotations to only create the projects once for each test class. This fix makes that approach unnecessary for the usage tests. In bug 349706 I had to change several tests to create and cleanup their test projects for each test run (ProjectCreationTests, PreferenceTests, and ApiDescriptionProcessorTests). Taking this approach with these tests is possible, but would only increase performance of the whole suite by a few seconds and the tests would have to be much more careful about cleaning up any preferences/options they modify. I don't believe it is worthwhile to change them. I still have not been able to find the root cause of the failure to build refproject. If Olivier has some time on a WinXP machine he will take a second look. For now, I am applying this fix to HEAD to see if it allows the tests to pass in the next nightly build. If so, we should release it to 3.7.1 before RC2.
Olivier, do you have time today to review the performance fix for 3.7.1 inclusion?
(In reply to comment #6) > For now, I am applying this fix to HEAD to see if it allows the tests to pass > in the next nightly build. If so, we should release it to 3.7.1 before RC2. The tests passed in the nightly builds. We had one intermittent failure on the MAc machine unrelated to this bug.
This change is fine, but I don't think this is sufficient. It doesn't hurt to release that code. We might have to do more changes in the past to get more reliable test results.
The fix is in the R3_7_maintenance.
This bug was cloned for 3.7.1 inclusion. Correcting the milestone.
Applying this fix has stopped the intermittent failures for many builds. Marking as VERIFIED.
