At the moment, we kick-off a separate process to let Spring Modulith produce the metadata information from the running application on demand. We keep this information in memory for some time and have a manual action to trigger a re-creation of this modulith metadata information.
One approach to improve this would be:
- once we produce the JSON based metadata information, we store this in a cache for the project (on disc, similar to the index cache).
- instead of re-creating this metadata information at startup, we read this from the cache
- as a key for the cache, we create a hash value from:
- the types from the source codes (we can use the existing stereotype index elements for this, I think)
- a set of specific annotations on those types (those from Spring Modulith)
- as hash of the classpath of the project
That way, we can check whether the cache needs to be invalidated or not by computing the hash from the up-to-date index and classpath information and compare that to the data in the cache (on disc, for example).
In addition to that, we keep the action to manually trigger an update of this metadata.
At the moment, we kick-off a separate process to let Spring Modulith produce the metadata information from the running application on demand. We keep this information in memory for some time and have a manual action to trigger a re-creation of this modulith metadata information.
One approach to improve this would be:
That way, we can check whether the cache needs to be invalidated or not by computing the hash from the up-to-date index and classpath information and compare that to the data in the cache (on disc, for example).
In addition to that, we keep the action to manually trigger an update of this metadata.