Community
Participate
Working Groups
Builder scheduling rule can be the cause of workspace lock. For example, if a builder requires the workspace root scheduling rule, every other action, even in unrelated projects (let's imagine an HTML file in a totally independent project that doesn't even have any relationship with Maven) will be blocked until builder completes. This for example prevents from saving unrelated files while building. It also prevents the parallel builds strategy from being triggered. Like many other builders, the MavenBuilder does use the default scheduling root (workspace root), which cause all those troubles. I looked at the code of MavenBuilder and it seems like there is no strong need for locking the whole workspace. Nor actually for locking anything (builders don't need to lock source or target trees as they can be notified of deltas on those to react accordingly). I suggest we repalce the MavenBuilder scheduling rule by null, that wouldn't lock anything. If you're worried about it, this could be implemented as a preference (not necessarily shown to end-users) to help testing for some time?
New Gerrit change created: https://git.eclipse.org/r/128448
m2e shouldn't enable/allow parallel builds by default, but having clearly marked experimental (or hidden) preference is probably okay. Three reasons 1. m2e was developed under assumption that access to embedded maven runtime is serialized. local repository will access will almost certainly misbehave in multithreaded mode, and very likely other parts of m2e, embedded maven runtime and integration between the two. 2. Maven runs single-threaded builds by default, many maven plugins are not well used/tested in multithreaded mode as a result. 3. Many maven plugins don't even claim multithreaded support, so we need to figure out how to accommodate those.
(In reply to Igor Fedorenko from comment #2) > m2e shouldn't enable/allow parallel builds by default, but having clearly > marked experimental (or hidden) preference is probably okay. Cool. I'll update the patch to introduce the preference. >Three reasons > > 1. m2e was developed under assumption that access to embedded maven runtime > is serialized. local repository will access will almost certainly misbehave > in multithreaded mode, and very likely other parts of m2e, embedded maven > runtime and integration between the two. I think having the preference and trying to have fun with it can highlight which parts of the build can be made parallel or not. For example, there is a lot of logic in the builder that is mostly read-only on project and not accessing the Maven runtime. This can probably be made parallel with low change. If this seems profitable and want to move forward, the parts invoking invoke the Maven runtime could be guarded against running in parallel, for example by impementing a concurrent producer/consumer approach. > 2. Maven runs single-threaded builds by default, many maven plugins are not > well used/tested in multithreaded mode as a result. > 3. Many maven plugins don't even claim multithreaded support, so we need to > figure out how to accommodate those. OK. Similarly, we could try to guard those parts against running concurrently but have the null scheduling rule anyway. So the build would be scheduled in parallel, but the risky plain Maven operations wouldn't. Thanks to your answer. I'll add the preference and this will hopefully reveal potential ways to have some parallelization, even if it's minimal.
New Gerrit change created: https://git.eclipse.org/r/128622
Gerrit change https://git.eclipse.org/r/128622 was merged to [master]. Commit: http://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=db323d61161a055a1e5f200eada456650e2adddb
Thanks Fred for the review. I'll have fun with that and probably report some potential improvements.
Eclipse m2e is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse-m2e/m2e-core/issues/ instead. If this issue is relevant to you, your action is required. 0. Verify this issue is still happening with latest Eclipse Platform and m2e release if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done if issue is still present when latest release: * Create a new issue at https://github.com/eclipse-m2e/m2e-core/issues/ ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) ** In the GitHub description, start with a link to this bugzilla ticket ** Optionally add new content to the description if it can helps towards resolution ** Submit GitHub issue * Update bugzilla ticket ** Add to "See also" property (up right column) the link to the newly created GitHub issue ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" ** Set status as CLOSED MOVED ** Submit All issues that remain open will be automatically closed next week or so. Then the m2e component for m2e will be made read-only.
Moved to https://github.com/eclipse-m2e/m2e-core/issues/
