PathModularizationCache needs to be public because it's an argument t…

[elharo]

…o a public constructor in DefaultDependencyResolverResult. It only hasn't failed yet because we're only passing null for this argument but there's a TODO to change that.

Alternatively, we could remove PathModularizationCache from the DefaultDependencyResolverResult.

[desruisseaux]

Alternatively, we can make the constructor package-private and add another constructor without the PathModularizationCache argument, which would delegate to the package-private constructor with a null argument.

A few months ago, a started a branch where I tried to reduce the visibility of some Maven internal classes. It required moving some classes to a common package (in this case, we would need to move DefaultProjectBuilder). I did not explored further because of conflict with other changes, but generally I would prefer going in the direction of removing some public items instead of adding more.

[elharo]

Yes, if we can move more classes into the same packages we can reduce visibility of a lot of things. Excessive proliferation of subpackages is a major antipattern in Java that leads to excessive visibility. It's probably second only to IDEs that mark classes and methods public by default.

[gnodet]

The DefaultDependencyResolverResult does not really respect the @Immutable contract which is on Result<REQ>.
It may be better refactored in a different class that would be package protected, contains the addDependency and addOutputDirectory, while the DefaultDependencyResolverResult would be kept immutable.