Add per-builder build events to IResourceChangeEvent#2802
Conversation
| Bundle-Name: %pluginName | ||
| Bundle-SymbolicName: org.eclipse.core.resources; singleton:=true | ||
| Bundle-Version: 3.24.100.qualifier | ||
| Bundle-Version: 3.25.100.qualifier |
There was a problem hiding this comment.
New API, hence the bump.
There was a problem hiding this comment.
The bump shouldn't include service segment!
There was a problem hiding this comment.
The point is that a bump of the minor version sets the service version back to zero so it should be 3.25.0 not 3.25.100
There was a problem hiding this comment.
I think in the past we had the rule to use 100 in the end to allow downports. Is that obsolete? https://github.com/eclipse-platform/eclipse.platform/blob/master/docs/VersionNumbering.md#when-to-change-the-service-segment
There was a problem hiding this comment.
Forget this comment, this is for the first change of the third segment. Not the other one, so 3.25.0 would be correct.
I leave this as it is for now as we anyhow want tracing and not new API.
Introduce PRE_PROJECT_BUILD and POST_PROJECT_BUILD event types on IResourceChangeEvent, fired once per builder execution from BuildManager.basicBuild around the SafeRunner.run that invokes the builder. Listeners receive the IProject as source, the builder id (from the project's build spec) via the new getBuilderName() default method, and the build kind via getBuildKind(). No resource delta is attached; the surrounding workspace-level PRE_BUILD/POST_BUILD pair continues to carry the aggregated delta. Events fire above the needsBuild short-circuit so every builder that is considered reports a matched PRE/POST pair; builders whose project has no delta produce near-zero durations but still appear to listeners, giving tools complete visibility of the build sequence. The POST_PROJECT_BUILD broadcast runs from a finally around the lock and rule handoff, so a matched pair is delivered even if that handoff throws. Dispatch goes through a new NotificationManager.broadcastProjectBuildEvent path that skips delta computation and does not update lastPostBuildTree, so per-builder events remain pure timing/metadata signals nested inside the workspace build. ResourceChangeListenerList.hasListenerFor was a hard-coded switch over bitmasks 1..32 and silently dropped anything else; extend its counter bookkeeping to include 64 and 128 so listeners registered for the new event types actually receive them. Bumps org.eclipse.core.resources to 3.25.100. Adds ProjectBuildEventTest covering FULL, CLEAN, INCREMENTAL-with-no-delta, nesting order against the enclosing workspace events, and the getBuilderName() contract. Fixes eclipse-platform#2801
vogella
force-pushed
the
per-builder-build-events
branch
from
dd12d64 to
05a9001
Compare
|
Have you considered providing tracing information instead? For the reasons mentioned in #2801 it should be sufficient. There is also "Event view" in runtime thac can be extended for that, or just create something similar based on that. My main concern with the proposal here is that except for occasional performance checks it is not needed (it wasn't obviously requested by anyone since 20 years of resources API), however it will always generate lot more events (per builder & per project). |
|
Thanks @iloveeclipse for the suggestion I look into tracing as an alternative. This might take a bit longer, as I soon will vanish into summer vacation and because I use this in a similar version already since a while in my custom aggregator build so my personal pressure is not that high to rework that approach. |
3 participants
Adds two event types to
IResourceChangeEvent,PRE_PROJECT_BUILDandPOST_PROJECT_BUILD, fired once per builder execution with theIProjectas source plus the builder id (newgetBuilderName()) and the build kind.Today only the aggregated workspace-level
PRE_BUILD/POST_BUILDevents exist, so tools cannot attribute build time to an individual builder or project; these per-builder events make the full build sequence visible and enable build-monitor and profiling tooling.The events are cheap: dispatch is gated by
hasListenerForand skips resource-delta computation entirely, so builds with no listener registered are unaffected.A matched pair is guaranteed even if the lock/rule handoff throws, and
ProjectBuildEventTestcovers full, clean and no-delta incremental builds, event nesting inside the workspace build, and the builder-name contract.