maven [MNG-8696] Hide the cache from DefaultDependencyResolverResult constructor

This is an alternative to pull request #2219 resolving the same issue, but with more emphasis that PathModularizationCache should not be created in the DefaultDependencyResolverResult constructor, and that doing so is a temporary hack that may be removed in a future version. More specifically:

Make package-private the DefaultDependencyResolverResult constructor having a PathModularizationCache argument, because the latter is package-private.
Add a public constructor without the cache argument for codes in other packages that need to instantiate DefaultDependencyResolverResult directly.
- Put a warning in the javadoc saying that this constructor may be removed in a future version.
Add PathModularizationCache private field in DefaultDependencyResolver. This is partially for performance reasons (see below), but also for expressing the intend that the cache has a longer lifetime than DependencyResolverResult.

Rational

Initializing PathModularizationCache inside the DependencyResolverResult constructor is close to useless, because a cache is useful only when the cached values are reused. The way that the DependencyResolverResult is coded, the same result instance is unlikely to ask the same cached value twice. The cache become useful only when many DependencyResolverResult are instantiated while reusing the same cache.

The "useless" approach is nevertheless used by DependencyResolverResult, but this is only because I do not yet know how to manage a session-wide cache. The current way to create the cache was intended to be temporary.

I'm not sure if it happens often that the same DependencyResolverResultBuilder is reused for creating more than one DependencyResolverResult. If not, moving the cache inside DependencyResolverResultBuilder, as done in this commit, may not bring real performance improvement. However, it makes clearer that PathModularizationCache is expected to have a longer lifetime than DependencyResolverResult. The discussion in #2219 gives the impression that such clarification is worth to do.

May 18 '25 17:05 desruisseaux

@desruisseaux for consistency and to honor the fact that the {{DepfaultDependencyResolverResult}} implements {{DependencyResolverResult}} which is annotated with {{@Immutable}}, I'd rather have {{DepfaultDependencyResolverResult}} being immutable. Is there a way to use a temporary intermediate class to store the computation data, and only keep the final computed state in this class ?

May 19 '25 20:05 gnodet

Is there a way to use a temporary intermediate class to store the computation data (…snip…)?

Yes, ideally the cache should be in some session-wide place. The only reason why the cache is declared in DefaultDependencyResolver is because I do not know if there is a central place in Maven 4 where we can put stuff that we would like to cache for the duration of the session.

Regarding DefaultDependencyResolverResult this class is conceptually unmodifiable. The add methods are package-private and used only a construction time. I will add Collections.unmodifiable(…) wrappers in the getter methods for safety.

May 19 '25 21:05 desruisseaux

Resolve #9351