smallrye-parent pulls in Maven 3.6.3 parent POM

[aloubyansky]

Given that Maven 3.6 had a CVE, some companies may block Maven 3.6 artifacts resulting in errors resolving dependencies that appear to have smallrye-parent in their POM hierarchy. It would be good to refactor the smallrye-parent to not pull the Maven 3.6.3 parent POM. Here is an example:

[INFO] io.quarkus:quarkus-devtools-message-writer:jar:2.2.5.Final
[INFO] - io.smallrye.common:smallrye-common-os:jar:1.6.0:compile

The parent/BOM POM hierarchy:

https://repo1.maven.org/maven2/io/smallrye/common/smallrye-common-os/1.6.0/smallrye-common-os-1.6.0.pom
https://repo1.maven.org/maven2/io/smallrye/common/smallrye-common-parent/1.6.0/smallrye-common-parent-1.6.0.pom

https://repo1.maven.org/maven2/io/smallrye/smallrye-parent/26/smallrye-parent-26.pom (the arquillian BOM version is still the same in the current main branch, 1.7.0 hasn't been released yet and so far it still has the same issue)
https://repo1.maven.org/maven2/org/jboss/arquillian/arquillian-bom/1.6.0.Final/arquillian-bom-1.6.0.Final.pom
https://repo1.maven.org/maven2/org/jboss/shrinkwrap/resolver/shrinkwrap-resolver-bom/3.1.4/shrinkwrap-resolver-bom-3.1.4.pom

The resolver BOM directly imports the maven 3.6.3 POM.

[radcortez]

Seems to be caused by this:
https://github.com/shrinkwrap/resolver/blob/master/bom/pom.xml#L49

There are no new versions of the shrinkwrap-resolver-bom with a never Maven version. Either we have to update it or think about how can we drop it. In reality, Arquillian is only used for testing, so it does make sense to not include it in the Parent POM. If we remove it right now, we are just going to break all SR projects.

[gsmet]

If we remove it right now, we are just going to break all SR projects

Agreed but probably better than the current situation. It would need to be properly coordinated though.

[radcortez]

Do we have someone blocking the artifacts at the moment?

@aloubyansky do you have any tips on how we can do this in a less intrusive way?

[aloubyansky]

Last year we had such a customer. There were a couple of issues created to track it:
https://issues.redhat.com/browse/QUARKUS-1025 (still open, following which I create this issue)
https://issues.redhat.com/browse/QUARKUS-994 (closed)

I am not sure there is an easy fix here. In general, it looks like a leak of "internal" SmallRye project testing bits (Arquillian, ShrinkWrap POMs, etc) into the end user application builds. Those BOMs and POMs aren't actually contributing anything to the end user apps using SmallRye components but they are still resolved as part of the POM hierarchy.
One way to isolate those POMs would be to create a dedicated SmallRye test parent POM (or BOM) that only the test modules would inherit from. That would mean moving tests to their own modules though, which may turn into a huge refactoring of SmallRye projects.

[radcortez]

Arquillian is only required to run the TCKs, which is most SR project is already a separate module, so we should be fine there (but needs confirmation).

This is included in the Parent to POM to make sure that all the testing dependencies are aligned for all SR projects, but we can probably move this to a separate BOM, that is only included in the TCK modules/test modules.

Let me investigate. Thanks!

[radcortez]

Ok, I've submitted a PR that moved the TCK based dependencies into a Testing BOM. The plan is to release it, update SmallRye projects to use the BOM for the TCK modules, and then release the Parent POM without the problematic dependencies.

[radcortez]

Even with the move, we still end up with the Arquillian BOM being resolved because it is included in weld-core-parent and we use weld-junit a lot for testing. Usually, the CDI integration is available in a separate module, and Quarkus depends on the core implementations, so I think it should still be possible to remove the Arquillian BOM resolution, but it may require additional restructuring of SmallRye implementations.

[radcortez]

Ok, we hit a roadblock. Even after removing any resolutions from our side, in the end, the Arquillian BOM gets pulled by MicroProfile POM's. Here is an example: https://github.com/eclipse/microprofile-config/blob/2.0.1/pom.xml#L129-L135.

I guess that the best option would be to make a fix on Shrikwrap and override the version on our side.

[dmlloyd]

Could an exclusion work? I don't know if they can override BOM imports or not...

[radcortez]

Not sure either. I'll try.

[aloubyansky]

BOM versions imported in parent POMs can't be overridden, afaik.

[radcortez]

Regardless, there is still a lot to improve on our side, so I'll still move with our changes. One interesting one is the code rules project depending on the build POM.