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

io.quarkus:quarkus-bom's entries should exclude banned artifacts #30813

Open
ppalaga opened this issue Feb 2, 2023 · 6 comments
Open

io.quarkus:quarkus-bom's entries should exclude banned artifacts #30813

ppalaga opened this issue Feb 2, 2023 · 6 comments
Labels
kind/enhancement New feature or request

Comments

@ppalaga
Copy link
Contributor

ppalaga commented Feb 2, 2023

Description

This is a generalization of #26468 and #26468 where @rsvoboda is asking for moving some specific exclusions from extension modules to quarkus-bom.

Implementation ideas

It would be nice if the tool used for BOM flattening could take the banned dependencies defined in independent-projects/enforcer-rules/.../quarkus-banned-dependencies.xml into account and add the exclusions as needed to the BOM.

@ppalaga ppalaga added the kind/enhancement New feature or request label Feb 2, 2023
@ppalaga
Copy link
Contributor Author

ppalaga commented Feb 2, 2023

cc @aloubyansky

@gsmet
Copy link
Member

gsmet commented Feb 2, 2023

I think we need to be extremely cautious about that as it could become a nightmare for users. I agree it's better if they can exclude things but I'm worried it could be a major pain for some projects.

@aloubyansky
Copy link
Member

aloubyansky commented Feb 2, 2023

What we should take into account is that our BOMs are not enforced exclusively on our extensions but also on other libraries in application projects. We should probably categories excluded dependencies: those that are required to be excluded to guarantee the proper classpath for our extensions and those that won't hurt our extensions if still present. While a Quarkus extension may exclude a certain dependency because it's not relevant it may break other libraries in the app dependency tree. I'd be careful moving all the exclusions to the BOMs w/o further analysis.

@gsmet
Copy link
Member

gsmet commented Feb 2, 2023

Oh sorry, I misunderstood what you said.

@ppalaga
Copy link
Contributor Author

ppalaga commented Feb 6, 2023

What we should take into account is that our BOMs are not enforced exclusively on our extensions but also on other libraries in application projects.

Well, I'd see our BOMs as being there primarily for managing our extensions and their transitives for the sake of reliability and reproducibility. If end users want do do something beyond our scope, they are free to do it on their own (by managing or re-adding dependecies we exclude).

I agree that there may exist artifacts that are banned in Quarkus source tree (for good reasons) but do not necessarily be banned from end user apps. Javassist comes to my mind as an example. I believe these are rather rare. The vast majority of banned artifacts should be excluded from the BOM. It would be nice to have two separate rule files for the two categories.

@ppalaga
Copy link
Contributor Author

ppalaga commented Feb 25, 2023

#31414 is a tiny manual step towards the goal to automatically exclude all (or selected) banned dependencies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants