Share the set of banned dependencies and their replacements with Quarkus ecosystem

[ppalaga]

Description

This follows the discussion in quarkusio/quarkus-platform#521

Quarkus does some conscious choices when it comes to preferring some artifacts and banning the alternatives.

Jakarta spec jars are the most prominent example: Generally the jakarta spec artifacts are preferred and the obsolete alternatives coming from JBoss, Glassfish, javax and Geronimo are be banned. There are exceptions to this general rule (Quarkus in some cases prefers jboss or glassfish artifacts) and typically not all existing alternatives are banned (not sure why).

It is similar with logging backends: some third party artifacts are banned in favor of some JBoss logging artifacts.

It is generally beneficial for Quarkus Platform participants to stick with the policies adopted in Quarkus Core. On one hand this increases the chances to get working selection of artifacts in end user applications and on the other hand it may save time and cognitive load with deciding which alternative to choose.

From the platform participant PoV, it is easy to overtake the bans from Quarkus poms, but it is less easy and obvious to implement replacements towards the preferred alternatives.

I wonder whether Quarkus Core maintainers, esp. @gsmet would be ready to maintain this kind of rules in structured form, so that platform participant projects and Quarkus Platform itself can observe/enforce them automatically.

Implementation ideas

I do not have any specific format or tool in mind. Enforcer plugin forks well for enforcing bans, but I am not aware that it would also allow enforcing replacements. I'd be thankful for any suggestions.

[ppalaga]

cc @aloubyansky @mjurc @tqvarnst

[gastaldi]

Sounds like something we could include in our Maven/Gradle plugins (or even in the CLI) (something like quarkus:enforce-dependencies)

[ppalaga]

Any opinion on this @gsmet @aloubyansky ?

[gsmet]

Sorry, I'm quite busy these days with the Jakarta migration.
The enforcer doesn't allow us to provide replacements (even as a hint) and that's a bit of a bummer but if we want something done quickly, maybe we should keep using it?
I haven't found at a quick glance if we could use rules stored in a published XML file. If not, maybe we will end up having a custom rule that can get the info from a YAML file that contains both the banned dependency and the replacement and we could push the replacement as a hint in the error message?

@famod maybe you have some ideas about that?

[ppalaga]

An idea: Maybe we could add the replacement functionality to the existing enforcer ban rule?

having a custom rule that can get the info from a YAML file that contains both the banned dependency and the replacement

But yes, such a custom yaml bans+replacement definition file would be easier to share within the ecosystem.

[gastaldi]

There is the independent-projects/enforcer-rules module which publishes custom enforcer rules.

I think we could move the bannedDependencies in the build-parent to a custom rule to facilitate reuse

[gastaldi]

FWIW I created https://issues.apache.org/jira/browse/MENFORCER-422 asking for reading a list of banned dependencies from an external file/URL

[ppalaga]

Thanks @gastaldi, an artifact containing the bans solves a substantial part of the problem.
Any idea how we could maintain and ideally also enforce the preferred replacements?

[gastaldi]

@ppalaga we can come up with a custom rule in the enforcer-rules project that would check against a predefined list of banned dependencies (defined in the same project, for example)

[famod]

Yeah, this could/should work.

Are we talking about rules enforced by the main repo or are we talking about multiple sets of rules?

[gastaldi]

@famod my understanding is that this request is for reusing this rule: https://github.com/quarkusio/quarkus/blob/main/build-parent/pom.xml#L494-L599

[ppalaga]

Are we talking about rules enforced by the main repo or are we talking about multiple sets of rules?

We (Camel Quarkus) are primarily interested in getting a way to consume the bans defined by Quarkus.

Secondarily, it would be nice be able to define more bans and replacements in a similar way on our side, so that projects (such as Camel K) based on Camel Quarkus can consume them.

[ppalaga]

Any progress here? I am reviewing the dependency management in quarkus-cxf and having a list of banned artifacts and their replacements would be extremely useful.

[gastaldi]

No progress so far, but I can have a look if it's urgent

[gastaldi]

@ppalaga I created https://github.com/gastaldi/descriptor-rule as the initial prototype. It is a custom enforcer rule that executes other enforcer rules declared in a shared descriptor (much like what was proposed in https://issues.apache.org/jira/browse/MENFORCER-422)

Take a look and let me know how that works for you. My plan is to release an alpha version so we can use it right away and then submit a PR to the maven-enforcer-plugin repository to incorporate as a built-in rule

[gastaldi]

I have also created a PR upstream: apache/maven-enforcer#180