-
Notifications
You must be signed in to change notification settings - Fork 110
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
Automatic BOM constraints collection #591
Comments
I'm generally open to adding something like this. My only concern would be project isolation incompatibility in the future because of |
Oooh good catch. Interrogating the project graph is gonna be bad for development, especially if it happens when we’re not actively building a BOM. How does the publish plugin coordinate multiple independent subprojects for closing the release? I assume it aggregates that somehow, though maybe it has an easier time because it can operate like a finalize task. The ultimate API for this would automatically add all published projects to the BOM without additional setup. |
The task to create the staging repo is tied to |
In Okio we love this plugin!
We use it to publish a BOM with Okio’s own dependencies. This build file used to look like this:
Unfortunately, this caused us to publish an incomplete BOM (issue). In particular, our dependencies lists
okio
but notokio-jvm
(sample incomplete module file). This is particularly problematic for us as we switched from being a JVM library to a multiplatform library.It also means we have to remember to add subprojects to our
okio-bom/build.gradle.kts
file when they are added. We forgot to add ourokio-assetfilesystem
artifact when we added that. Whoops!To address this I made a helper function
collectBomConstraints()
that collects up all the artifacts that belongs in the BOM and adds them. Our BOM build file now looks like this:Would you be interested in having a similar function in this plugin? I’m happy to contribute it, or have y’all write your own, or build upon the function in Okio (PR). Note that the Okio implementation is incomplete; it only knows how to collect targets of the types needed by Okio.
Thanks again!
The text was updated successfully, but these errors were encountered: