Should building projects really require exclusive access of the workspace?

[danthe1st]

If someone thinks this suggestion is "scary"/breaks (behavioral) compatibility too much, feel free to state that.

Nobody likes seeing the "User operation is waiting" when a project is built in the background.

Looking at the Rules class, this is because the buildRule() (which decides what can run when a build is running) returns the workspace root i.e. no operations acting on the workspace can do anything while a scheduled task with that rule is running.

Should there be an option to set rule to something else (when possible), e.g. one global "build" rule that conflicts with every other build rule but nothing else? Or alternatively create an additional buildRule(IProject) method that only requires exclusive access on the project and use that in places where this is possible?

Of course, this might need to be guarded by a preference (probably initially disabled to use the old behavior) since that may have some impact (though we could maybe enable it for a milestone build and then disable it again).

It might be better to "only" try to change something like this on the m2e side only but I think having a discussion about that topic in general wouldn't hurt either.

The motivation is that some Maven projects (e.g. with Quarkus) take some time to build and changes to the POM (as well as some other things AFAIK) trigger a rebuild/reconfiguration which uses the build rule so saving a file or performing another action needs to wait for the operation to finish.

Note: This does not just happen when saving a file but it can also happen during state validation in the main thread when typing in the editor while a build is running ("Building"/AutoBuildJob). Maybe that DocumentProviderOperation can be changed to not conflict with the AutoBuildJob?

Alternatives

There are the following alternative approaches I considered:

• Change m2e (ProjectConfigurationManager which is used by UpdateMavenProjectJob to not use the global build rule but something project-specific. This could e.g. lock the project or its project.build.directory/target folder during the "Update Maven Project" (and possibly prevent multiple concurrent project updates if that is really needed).
  • I think just changing m2e would not be sufficient as there's also the "Building" job that also uses the workspace root. I am not sure whether that one can be changed to only affect the relevant projects or in another way that improves that situation.
• Change the save (and possibly some other actions) to be able to run asynchronously (i.e. save whenever the build is finished), possibly if a preference is enabled

Example reproducer

If you want to reproduce that, you can use the following POM that just sleeps for 30s (at least on Linux). If you change the execution ID, save the POM and then save another file (in another project), it will wait.

<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>io.github.danthe1st</groupId>
	<artifactId>mavenwaiter</artifactId>
	<version>0.0.1-SNAPSHOT</version>

	<build>
		<plugins>
			<plugin>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>exec-maven-plugin</artifactId>
				<version>3.6.3</version>
				<executions>
					<execution>
						<id>wait</id>
						<phase>validate</phase>
						<goals>
							<goal>exec</goal>
						</goals>
						<configuration>
							<executable>sleep</executable>
							<arguments>30s</arguments>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
</project>

Of course, waiting like this is a silly example but there are Maven projects where the build just takes a bit of time because of some plugins and Maven is not the only case where this might happen.

CC @HannesWell @laeubi since you are working on m2e.