gnodet commented on PR #1144: URL: https://github.com/apache/maven-compiler-plugin/pull/1144#issuecomment-5984278965
You're right to call out both the factual error and the design point. The answer to feedback 1 was incorrect. The `DEPENDENCIES` aspect detects that a classpath JAR changed (by mtime) and triggers a **full rebuild** of all sources — it is not a dependency graph. There is no tracking of which source files use which classes. The response conflated two different things and was wrong. Your two axes are correct and orthogonal: - **Dependency graph**: replace the module-level "recompile everything" with selective recompilation — track which source files transitively depend on a changed class, recompile only those. Change detection is still by content hash or mtime; any change to a class cascades to all its source-level consumers. - **ABI fingerprinting**: prune the cascade further — only recompile consumers of a class whose *public API surface* actually changed. Private body changes produce no cascade. Both are genuinely useful independently. A dependency graph without ABI is already a significant improvement over today's module-level rebuild for projects where most changes touch isolated classes. To make the review more tractable, I'm splitting this into three PRs: 1. **MRJAR infrastructure** — `BytecodeAnalyzer` with `java.lang.classfile` on JDK 24+, ASM fallback on older JDKs, proper multi-release JAR packaging. No behavior change. 2. **Dependency graph strategy** (`incrementalStrategy=graph`) — post-compilation bytecode walk to extract class-level deps, content-hash change detection, cascade on any class change. No ABI. 3. **ABI fingerprinting** (`incrementalStrategy=abi`) — adds the public API surface comparison on top of the graph; private body changes no longer cascade. On merging `.abi-incremental-state` with the existing timestamp state file: the two formats currently serve different strategies and have different contents (the graph/ABI state is richer). Happy to discuss a unified format — the key question is whether the graph strategy should *replace* the timestamp strategy or coexist alongside it as a separate opt-in. I'd lean toward coexistence for now, with a migration path later. -- 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]
