Hi, On 27.03.2025 17:44, Bear Giles wrote:
This makes it easy to update your dependencies - single point of truth - but it doesn't necessarily apply to transient dependencies. This is especially common if the transient dependency is resolved first since (iirc) it will default to its own version and the our explicit dependencies will use their own version.
You can add transitive dependencies to dependency management too if you want. This will effectively pin their versions and choose them over the versions recommended by their direct consumers.
Your consumers will never profit from the versions in dependency management, unless they explicitly import them in their dependency management. Importing depManagement only makes sense for artifacts of type "BOM" (which will actually be a type in Maven 4).
If you decide to pin transitive dependencies, you should use additional Maven Enforcer Plugin rules:
* dependencyConvergence helps you detect, which transitive dependencies need pinning. If the dependency appear more than once in your dependency graph and is not pinned, you'll get an error.
* requireUpperBoundDeps helps you keeping the pinned versions up-to-date: the version you specify must be higher than all the versions specified in your dependency graph.
*Possible solution #1* The optimal solution would probably be extending the pom, probably in the dependencyManagement stanza, that allows the developer to explicity specify a default groupId -> version mapping. This value would be the default in both dependencyManagement and dependencies. (Ditto with pluginManagement and plugins)
What you are suggesting is similar to a `package-lock.json`[1] in the NPM ecosystem. If you want your dependents to reuse it, I don't think it makes sense to add it to the POM or even Maven Central. It should be a separate file. The recommended versions for transitive dependencies will vary in time (e.g. if one contains a vulnerability).
Recommending (or requiring) only one version of dependencies is probably not enough. In order to reuse such a lock file in dependents I would:
* only provide recommendations for **direct** dependencies. Recommendations for transitive dependencies would be provided by the authors of direct dependencies.
* provide a **minimal** version of an artifact, which would be the oldest version that contains all the methods used in your project. If a dependent chooses an older version, he'll get runtime errors.
* provide a **recommended** version, which is the latest version that was tested and works.
* provide a **maximum** version, which is either a version that you tested and doesn't work any more or the next major version.
Piotr [1] https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json
