fix(devloop): keep resource edits made since app start when re-seeding

[totally-not-ai]

Summary

If you edit a pom and application.properties at the same time while the app runs, the dev loop could lose the properties edit. It never restarted the app to pick it up. With this fix, resource files changed after the app started are no longer marked as already handled when the baseline is rebuilt.

Fixes #25956

What changed

• Behavior change: A pom edit that changes the module set rebuilds the change baseline while the app runs. During that rebuild, Compile.seedResources now skips resources modified after the app started. Before, only sources and frontend files were skipped. So a resource edit in the same batch was treated as done. The Maven re-resolve had already copied it onto the classpath, apply reported "Stable" without a restart, and no later apply saw the edit again. Now the edit shows up as a startup resource change and triggers a restart. This only affects dev loop users who edit resources together with the pom.
• The no-argument seedResources() works as before (it seeds everything).
• Internal change only: Compile is package-private, so there are no public API changes.

Test summary

Resource re-seeding (Compile):

• Config edited after app start reported as a startup change after re-seed, even when its classpath copy is up to date
• Resources the app started with stay seeded (no live changes reported)

[github-actions]

Test Results

 1 551 files  ±0   1 635 suites  ±0   1h 37m 49s ⏱️ - 3m 33s
12 466 tests +1  12 394 ✅ +1  72 💤 ±0  0 ❌ ±0 
12 865 runs  +1  12 793 ✅ +1  72 💤 ±0  0 ❌ ±0 

Results for commit 7dc87e1. ± Comparison against base commit a6533c6.

♻️ This comment has been updated with latest results.

[tltv]

@totally-not-ai is the issue already fixed in #25851 pull request?

[totally-not-ai]

@tltv No, #25851 doesn't fix this, although it touches the same method.

#25851 changes what the resource baseline stores: a content digest next to the stamp, so a build that rewrites a file with identical bytes is no longer counted as a change. But its seedResources() still records every resource on disk as already acted on, and it doesn't touch the re-seed after a module-set change in TransactionEngine.compileFor. In the scenario from #25956, the edited application.properties would be seeded with its new stamp and digest, and its classpath copy already holds the same bytes. So staleResources() would still report nothing, and apply would still end in Stable without a restart.

This PR adds what's missing: the start-time cutoff that sources and frontend files already have (seedResources(startedAtMillis)). The two PRs will conflict in seedResources(), and whichever lands second needs both parts: the digest from #25851 and the modified <= startedAtMillis filter from here.

One detail for whoever merges them: #25851 keeps unreadable resources in the inventory on purpose, so deletions can still be reported. Following that idea, resources newer than the app's start could also be kept as inventory keys, but with a marker that can never match (no stamp or digest), rather than left out entirely. Then a file edited and deleted before the next apply would also be reported as a deletion. That edge case isn't handled today, and I haven't changed code for it in this PR.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Documentation Bot: No documentation needed for this change.

This is a bug fix in the dev loop daemon's internal, package-private Compile class: when a pom edit changes the module set and the resource baseline is rebuilt, a resource file (e.g. application.properties) edited in the same batch is no longer incorrectly marked as already handled, so it now correctly triggers a restart instead of being silently dropped. The existing dev loop documentation already describes this contract — batched edits are detected and reported honestly, and application.properties changes require a restart — the fix just makes the narrow pom+resource edge case match that documented behavior. There is no public API change and no new user-facing capability.

Nothing was opened in vaadin/docs. If you disagree, the change has to be documented by hand there.

Generated by Documentation Bot for #25958 · agent · 37.2 AIC · ⊞ 11.7K · ◷

[vaadin-bot]

This ticket/PR has been released with Vaadin 25.4.0-alpha1.