[
https://issues.apache.org/jira/browse/FLINK-14444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954633#comment-16954633
]
Michael Holler commented on FLINK-14444:
----------------------------------------
[~chesnay] I only really have personal experience using BOMs, rather than
creating them. That being said, I do think the JDBI maintainers do the right
thing more often than not, and this is how they manage it:
https://github.com/jdbi/jdbi/tree/master/bom
So basically, it's just a special POM file, but you do have to list each
artifact. However, unless the Flink project is in the practice of adding and
removing published artifacts frequently, this should just be a one-time thing
to put together, and then there's another step to add a line to the BOM
whenever a new project gets added to the Flink project. As far as automating
creation, one could probably just scrape Maven Central for everything with the
"org.apache.flink" group and the current version (to help exclude some outliers
that may have fallen out of maintenance or be on a different versioning
scheme), then just use some VIM macros or a quick script to format the results.
There may be an easier way, but again I'm not experienced at actually creating
these things, just using them. Thanks for taking interest in this issue! :)
> Publish BOMs for Flink
> ----------------------
>
> Key: FLINK-14444
> URL: https://issues.apache.org/jira/browse/FLINK-14444
> Project: Flink
> Issue Type: Improvement
> Reporter: Michael Holler
> Priority: Trivial
>
> Hey there! Love the project, but I would love it if there was a BOM file that
> is published for each version. If you're not familiar with a BOM, it stands
> for "Bill of Materials" it helps your Gradle (in my case, but it's originally
> a Maven thing) file look like this (using JDBI's implementation as an
> example):
> {code:java}
> dependencies {
> implementation(platform("org.jdbi:jdbi3-bom:3.10.1"))
> implementation("org.jdbi:jdbi3-core")
> implementation("org.jdbi:jdbi3-kotlin")
> implementation("org.jdbi:jdbi3-kotlin-sqlobject")
> implementation("org.jdbi:jdbi3-jackson2")
> }
> {code}
> Instead of this:
> {code:java}
> val jdbiVersion by extra { "2.6.1" }
>
> dependencies {
> implementation("org.jdbi:jdbi3-core:$jdbiVersion")
> implementation("org.jdbi:jdbi3-kotlin:$jdbiVersion")
> implementation("org.jdbi:jdbi3-kotlin-sqlobject:$jdbiVersion")
> implementation("org.jdbi:jdbi3-jackson2:$jdbiVersion")
> }
> {code}
> Notice how you just leave the versions off when you use a BOM. This can help
> reduce the number of dependency compatibility surprises one can encounter,
> especially if a transitive dependency brings in a newer version of one of the
> components (it'll be reduced to the BOM's version). Note also that you still
> have to list dependencies you want with a BOM, just not the versions.
> Here's a deeper dive into how a BOM works:
> [https://howtodoinjava.com/maven/maven-bom-bill-of-materials-dependency/]
> The Maven help site also has a section on it (Ctrl+F for "BOM"):
> [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]
> I think BOMs would be a great for the users of the Flink project because
> there are lots of Flink libraries (core, connectors, etc) that require the
> same version as other Flink dependencies to work correctly. BOMs were
> designed for exactly this use case :)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
