Skip to content

Revisit keepThirdpartyExclusions #114

@ppalaga

Description

@ppalaga

This follows up the discussion in quarkusio/quarkus-platform#560 (comment)

The way I decided to do it is to add an option that would allow each member to keep their own exclusions for common dependencies. While aligning the common dependency version is critical, I am not sure whether it's a good idea to allow one member to control exclusions for others, especially if that member didn't do a proper research on that. So I added this, probably, controversial option keepThirdpartyExclusions element to member config (which is true by default) that allows members to keep their exclusions configured in their original BOMs.
This could make the order of member BOM imports in Quarkus apps significant, although that'll probably be an edge case.
So in this particular change the exclusion from the quarkus-amazon-services BOM is removed but for this same constraint in the quarkus-camel-bom it is still present.

I'd vote for removing keepThirdpartyExclusions completely. Having different exclusions in the generated participant BOMs would lead to ordering issues that would be very hard to even explain (and document!) to end users. IMO the Platform is there is to solve this kind of mismatches between the participants rather than propagating them to end users.

I think we have this kind of problem especially for artifacts, that are/should be banned completely on all (core, participant and platform) levels. Having a structured list of banned artifacts and their preferred replacement (a.k.a. quarkusio/quarkus#24880 ) would help. With #24880 in place, all participants could take the centrally maintained list of bans and mechanically add the needed exclusions to their BOMs. We could do the same on the Platform level.

For finer grained exclusion adjustments beyond the bans, I agree that the current <dependencySpec> settings are hard to maintain because of the versions. Here is an example how it currently works:

<dependencySpec>
    <artifact>com.github.java-json-tools:jackson-coreutils:2.0.0.redhat-00005</artifact>
    <exclusions>
        <exclusion>com.google.code.findbugs:jsr305</exclusion>
    </exclusions>
</dependencySpec>

It would help to make the version optional, or even to allow using placeholders and even better multiple patterns, something like:

<dependencySpec>
    <includes>org.foo:*,org.bar:*:2.*</includes>
    <exclusions>
        <exclusion>com.google.code.findbugs:jsr305</exclusion>
    </exclusions>
</dependencySpec>

cc @maxandersen @gsmet

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions