commons collections force to commons-collections4 is wrong on 2 points

[hazendaz]

What version of OpenRewrite are you using?

1.27.0 of this recipe rewrite-java-dependencies (this also might show from the rewrite-apache but think its here)

How are you running OpenRewrite?

maven plugin 6.0.5, no special configuration, just running a number of recipes that should typically just work to keep code clean.

What is the smallest, simplest way to reproduce the problem?

Just add commons-collections:commons-collections:3.2.2 which isn't vulnerable, its just old to a pom file, run the plugin, watch it change. Then realize no code existed to change and the scope of where it was changed would degrade the code and introduce a vulnerability.

What did you expect to see?

Nothing, my product is a pom file (super pom) and I'm overriding an actual vulnerable version of commons collections to 3.2.2 for a plugin from maven team that has not patched for that. There is no code here to change and commons collections and commons collections 4 are not the same. The imports are different and given there was no code changed, it should not have updated the pom.

What did you see instead?

The pom was updated stating it was 'resolve vulnerable library usage with relocated notice from the older version to newer version which would do nothing for my build. My build won't fail, but it would cause the plugin in question I override to start using vulnerable code again. Version 3.2.2 is not vulnerable so the its wrong on that point. Plus changing it here without any ability to change underlying code as no code is even here, would result in the class path containing both commons collections that then would be vulnerable and commons collections 4 that then would be unused.

What is the full stack trace of any errors you encountered?

no stack trace.

Are you interested in contributing a fix to OpenRewrite?

no.

The fix should be pretty easy. Don't patch libraries that are not compatible with one another when used to override dependencies of a maven plugin as there is no way to actually accept the change as it doesn't fix anything. I presume the fact it didn't change any code is also a problem here. The recipe should have known no code changed and the patch was therefore invalid.

[hazendaz]

If you want know which maven plugin specifically, its the servicedocgen-maven-plugin

<dependency>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>servicedocgen-maven-plugin</artifactId>
    <version>1.0.0</version>
    <dependencies>
        <groupId>commons-collections</groupId>
        <artifactId>commons-collections</artifactId>
        <version>3.2.2</version>
    </dependencies>
</dependency>

That patch has to entirely match the group and artifact to actually change behaviour of the plugin to not be vulnerable. While one might say, it would be great the plugin itself was fixed to use commons collections 4, that is out of scope here. By switching that to commons collection 4, it would mean the original is still what it was and now an unused dependency would be present. As the project this is in is further a super pom, there is no actual source code to change. Even if there was code to change, it would still be incorrect. I think this rewrite of dependencies stuff needs to stick to and sections only, not the further down ones inside of plugins.

And yes this sort of patching does in fact work, it can easily be confirmed by looking what is downloaded in the m2 repository cache in case of that ask.

I like the premise of what this recipe probably can do but in the driver pom we use to affect other builds running open rewrite, it fails at the start and would end up discarded for now.

[MBoegers]

Hi @hazendaz thanks for reporting. Applying OpenRewrite to just POMs is an interesting usecase.

Would you mind to provide parts of the build log? What I am looking for is the recipes making changes.

I expect that the recipe is missing a better precondition or has to check if it is a dependency block inside a plugin configuration, but to verify we need to know which recipe to check.