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.

[HeikoKlare]

I really like the proposal, as it addresses a real usability issue. We also sometimes experience builds blocking user interaction and thus progress for longer periods of time. I cannot say anything about feasibility yet but want to contribute some thoughts on the motivational user experience part (also related to the mentioned alternatives):

• I am not sure if this issue is too specific to Maven projects. We also face the situation that the lock via the build rule prevents users from actually doing work (such as changing and saving files) for longer periods of time. That's why a solution/improvement at the root (locking) may be preferable over an m2e-specific solution.
• Making execution of operations that are blocked by a build asynchronous may mitigate the issue in terms of not blocking the user progress anymore. On the other hand, queueing operations like saving files for asynchronous execution that may happen several minutes later is probably not so good from a UX perspective either. I assume that users usually expect such operations to be executed synchronously, so they may do follow-up work that, e.g., assumes a file to be saved, without noticing that the operation is actually still queued.

[danthe1st]

I am not sure if this issue is too specific to Maven projects

m2e is just one project that uses the workspace root for locking with e.g. "Update Maven Projects". Eclipse Platform does it as well for "Building".

m2e also runs Maven goals with that lock active (and sometimes wants to build multiple projects one after another) so I think that's a good example and possibly something that could be addressed "first".

[laeubi]

Thanks for writing this up, @danthe1st - the problem is real and I think the
general direction (not treating every build as "touches the whole
workspace") is the right one to explore.

The reason the current model is so coarse is mostly defensive: it's often
hard to synchronize or even statically know in advance exactly which
projects/resources a given builder (or a Maven plugin execution, in m2e's
case) is actually going to touch, so locking the whole workspace has been the
safe default rather than a deliberate design choice against finer rules.

I've run into similar problems before and found an "update lock" model
useful there: readers/writers that can be scoped (e.g. per project), with the
ability to escalate to a full exclusive lock only when needed - see
concurrent-locks' UpdateLock
for a concrete implementation of that idea. Something along those lines could
let a build hold a narrow lock most of the time and only escalate when it
genuinely needs workspace-wide exclusivity.

@HeikoKlare's point is also valid, though: quietly deferring something like a
save until a build finishes trades one UX problem (waiting) for another
(users assuming completion that hasn't happened yet). Any fix needs to keep
that contract honest, e.g. by surfacing the deferral rather than hiding it.

That said, this is a non-trivial undertaking - redesigning the resources
locking model touches a lot of sensitive code and would need careful design,
testing and migration. I don't think it will happen as a drive-by
contribution; it likely needs either dedicated funding or someone willing to
drive the implementation across several iterations. I'd be happy to help
review/guide such an effort if someone wants to pick this up.

[danthe1st]

As a first step, do you think it may be useful to try to take a look at e.g. m2e and try to use more fine-grained locking there (while keeping it for the "normal" non-m2e building process) to see what's possible?