introduce transitiveremediation for maven

[cforce]

What would you like Renovate to be able to do?

Add support for https://docs.renovatebot.com/configuration-options/#transitiveremediation for maven as well.

If you have any ideas on how this should be implemented, please tell us here.

Maven supports to render the effective pom and so does pin for the run what versions are used even in a dependency tree which allows following upward and check if deps are effected.

If a (future) upgrade of a explicit (still outdated) dependency will also cover to upgrade to a newer transitive dependency version with a fixed issue (e.g. vulnerability) will help to reduce the number of PR's created.

In case a transitive dependency version can not be covered by an upgrade of an explicit dependency specified in pom, there shall be an defaulted to "false" option to add an explicit overriding "pinning" of the transitive childs deps as .... which are marked as to be updated

Is this a feature you are interested in implementing yourself?

No

[rarkins]

This is not practical for two related reasons:

• Maven does not use a lock file
• GitHub vulnerability alerts don't support transitive vulnerabilities

[cforce]

Maven evaluates the version on each run deterministically. You can create a transitive tree of deps with https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html.

[rarkins]

We don't plan to use package managers during our extraction phase. e.g. we don't plan to run any maven x, gradle x, npm x, etc.

[cforce]

What about to support a two phase custom extraction phase which can take advantage of dedicated package managers

• Execute the package manager or a specific task, to export the dependency information and provide this as input
• Parse the exported dependency information using renovator

If renovator would operate on a completely transitively resolved pom.xml instead of the the one which "hides" the transitive deps.
That would open renovator for support of "deep scanning" of vulnerabilities without dedicated package manager know how .

Can you describe the design principle how far package manager logic is ok to be integrated and where not any more. I mean renovator already understands maven pom files and even modifies them. Why is it a nogo to use the manager in extractions phase or a phase before that. How do you draw that line you do not want to cross?

[rarkins]

The line we don't want to cross is running package managers to extract dependencies. We used to do it, and it makes things difficult, so now we don't and we don't wish to resume that either.