You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
This follows up the discussion in quarkusio/quarkus-platform#560 (comment)
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:It would help to make the version optional, or even to allow using placeholders and even better multiple patterns, something like:
cc @maxandersen @gsmet
The text was updated successfully, but these errors were encountered: