Description Mickael Istria 2017-12-05 07:35:57 EST

If one starts multiple project builds from different jobs/threads, then BuildManager can return an OK status whereas one of the build was actually skipped.

Here is a test to reproduce it:

	@Test
	public void testIndividualProjectBuildsInParallel() throws CoreException, OperationCanceledException, InterruptedException {
		JobGroup group = new JobGroup("Build Group", 5, getWorkspace().getRoot().getProjects().length);
		long duration = System.currentTimeMillis();
		for (IProject project : getWorkspace().getRoot().getProjects()) {
			Job job = new Job("Building " + project) {
				@Override
				public IStatus run(IProgressMonitor monitor) {
					try {
						project.build(IncrementalProjectBuilder.FULL_BUILD, monitor);
						return Status.OK_STATUS;
					} catch (CoreException e) {
						return new Status(IStatus.ERROR, "org.eclipse.core.tests.resources", e.getMessage(), e);
					}
				}
			};
			job.setJobGroup(group);
			job.schedule();
		}
		Assert.assertTrue("Timeout, most likely a deadlock", group.join(5000, getMonitor()));
		duration = System.currentTimeMillis() - duration;
		assertEquals(getWorkspace().getRoot().getProjects().length, TimerBuilder.getTotalBuilds());
	}

where all workspace projects have the TimerBuilder set, each of them counting a hit. Some are long running, some other immediate.
This test would typically fail to report that the TimerBuilder did run on all projects (only 3, 4 or 5 ones are actually run). This is a bug as per contract of project.build(...) which expects project to actually build or throw an exception, but not to silently skip the builder.

I went into details, and the very big culprit is the BuildManager.canRun(...) method which basically will skip any new build while one is running. This BuildManager and its methods have to be fixed to handle parallel builds (which are compatible with APIs/contracts and user expectations I believe).