gnodet commented on PR #12576:
URL: https://github.com/apache/maven/pull/12576#issuecomment-5175598035

   Thanks @kwin and @laeubi for the feedback. I spent time going through the 
plexus-build-api rework and the referenced issues — very useful context.
   
   **On naming / separation of concerns (@laeubi point 1)**
   
   Agreed that the old plexus-build-api `BuildContext` was too broad. This API 
is already narrower — it's specifically about incremental input/output tracking 
(register inputs, detect changes, associate outputs, clean stale files). It 
doesn't do progress reporting or general context storage.
   
   That said, the diagnostic message part (`Resource.addMessage()` / `Sink` / 
`Message`) does overlap with #12572's `DiagnosticCollector` / `BuildReport` 
API, which already handles structured diagnostics with dedup, warning modes, 
and persistence. I'm open to stripping the message types from this PR and 
letting #12572 handle diagnostics entirely — that would make this API purely 
about incremental file tracking, which is one coherent concern.
   
   On the name itself: `BuildContext` has recognition from the Sonatype/Takari 
lineage, but I see the ambiguity point. Alternatives like `IncrementalContext` 
would be more precise. Open to suggestions.
   
   **On IDE delta detection (@laeubi point 2)**
   
   Fully agree — the implementation doesn't rely on IDE-driven deltas for 
correctness. `NORMAL` mode (the CLI default) does full filesystem scan with 
timestamp/size comparison. The `DELTA` workspace mode in the SPI is opt-in for 
IDEs as a performance hint, not a correctness requirement.
   
   Good point about `markDerived()` — we don't have that in the current SPI but 
it would be valuable for code generators. Worth adding.
   
   **On messages (@laeubi point 3, @kwin)**
   
   As noted above, the context-aware message API (`Resource.addMessage(line, 
column, ...)`) overlaps with #12572. The one unique capability here is 
*cross-build message persistence* — re-reporting errors from previous builds 
for unchanged files. Whether that's worth the additional API surface or is 
better handled at a higher level (build report) is a question I'd like input on.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to