Bind update of Spring Modulith metadata to a full project build

[odrotbohm]

The metadata held for Spring Modulith projects can currently be updated manually by right-clicking the Project > Spring > Update Spring Modulith metadata. I would appreciate it if this was automatically triggered when a full build for the project is triggered (for example, via Project > Clean…, also transparently triggered by a Maven project refresh).

Such operations usually take a few seconds anyway so that the additional few milliseconds for the Spring Modulith metadata refresh shouldn't cause any issues.

[BoykoAlex]

@odrotbohm I recall you were initially asking for metadata re-generation once new java files are added... The problem with this was that class files are not generated at the same time and hence may not be around when metadata json is produced. However, if the trigger is .class files created in the output folder of a modulith dependent project this would be essentially what you were asking initially. Furthermore, it will cover the case of "project clean" (coming from the Eclipse UI) and might cover maven refresh. I noticed that file events in LS come in batches. Usually project build results in a single batch of .class files created in the output folder. We can skip .class files deletion as types wouldn't be resolved in the IDE anyway. The change to .class file might be too much as these would be fired after java files saved and incremental build done.
Then once .class file creation event received we could debounce the metadata regeneration for 500ms in case there is another event that triggers metadata regeneration comes in (i.e. classpath changes).
How does this sound @odrotbohm and @martinlippert ?

(I have implemented what I described above - seems to work)

[martinlippert]

I totally get the enhancement request from @odrotbohm, makes super sense to somehow automate the update of the modulith metadata when users change things. However, it feels to me like doing this on every random .class file creation event (even when debounced) is doing this very very often when - as a result - the produced metadata didn't really change. Since this would have to trigger a full revalidation of the entire project, we would - at least - need to check whether the metadata is really different from the one that was used for the previous validation run.

For some background: since the spring language server is somewhat separate from the build server (e.g. executing the maven build) and the java tooling (maybe also executing builds), we don't really know when the user build system is executed to do a full project build, an incremental one, or anything like that. We have no information about that. We can only observe possible results of this (like file events, etc.).

From this separation of concerns perspective (that the language server architecture introduces here), it would be a lot nicer if the regular build of the project (some maven plugin or whatever) would produce the metadata file automatically - and only when necessary (on incremental builds when something changed that would result in changed metadata). Then, the tooling would watch for changes to this metadata file and re-trigger validations based on that.

Another option to re-triggger validation (and re-create the metadata file in the way we do this at the moment) could be to watch out for changes to specific annotations or files that are the source of the information that ends up in the metadata file. So the tooling could wach out for changes to those annotations and in such a case, re-create the file and re-trigger validation. It would still require to somehow wait for the build to finish (between changes in source code and re-creating the metadata file). Probably possible via watching for .class file changes for those changed java source files only. Maybe this is an optimization for the mechanics that @BoykoAlex described above.

Just some additional thoughts on this... :-)

[BoykoAlex]

The newly generated metadata is always checked against the cached one before issuing re-validation, thus, I'd say, this is the least of our concerns for now. The primary concern is executing the metadata generation and minimizing the number of these re-generations.

I agree that the best solution from the tooling perspective would be the build (maven/gradle plugin) generating the metadata. Then, we could follow the steps of boot properties on the IDE side. Does this sound like something doable @odrotbohm ?

I'm thinking of optimizing the solution I have with listening to .class files and perhaps putting something to try post 4.21.1

[odrotbohm]

Oh, wow, I didn't realize I would kick off such a detailed discussion. Thanks for that, guys! That said, I didn't want to rehash the original conversation about the fine-grained update of the file. I just realized during a demo last week that it would be nice to attach the functionality that I currently have to trigger through that context menu entry to an overall build. And I had naively hoped that this wouldn't cause much hassle. There's an extension point for everything in Eclipse, isn't there? ;)

While I see the appeal of STS simply being able to pick up a file created by the build, I currently do not have the bandwidth to dive into the rabbit hole of build plugin creation.

[BoykoAlex]

Lets try this fix for Modulith metadata regen on the tools side: 263930d
It has some logic to optimize regen on .class file create/change

[BoykoAlex]

Preference setting to tun on/off automatic Modulith metadata refresh: 8349671
Lets close this for this release and see how it works out for @odrotbohm

[odrotbohm]

Lovely, I'll give this a spin ASAP.