Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revisit keepThirdpartyExclusions #114

Open
ppalaga opened this issue Jun 23, 2022 · 0 comments
Open

Revisit keepThirdpartyExclusions #114

ppalaga opened this issue Jun 23, 2022 · 0 comments

Comments

@ppalaga
Copy link
Contributor

ppalaga commented Jun 23, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant