[
https://issues.apache.org/jira/browse/LUCENE-10386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528596#comment-17528596
]
Dawid Weiss commented on LUCENE-10386:
--------------------------------------
Hi Petr.
So, I did have a look. TL;DR; version is that I honestly think this kind of
thing should be moved to downstream projects to handle in whatever way they
fancy. It introduces an additional level of overhead to Lucene maintenance and
a potential for problems that I don't think justifies the gains (see below for
specific examples). BOMs are not the only way to avoid adding consistent
version numbers to projects (Lucene uses Palantir's version consistency plugin,
for example) and the diversity here means it'll be hard to please everyone. If
you need a BOM - you can create a subproject in your own project (with all the
dependencies needed) and treat it as a platform... So it's not that difficult.
Here is what I noticed when I applied your patch (and it motivates my above
opinion):
1) the diff of poms in the release (gradlew -p lucene/distribution
assembleRelease) shows the description and name have changed:
{code}
<name>Apache Lucene (module: lucene-root)</name>
<description>Grandparent project for Apache Lucene Core</description>
{code}
The refactoring you made to extract configurePublicationMetadata has a side
effect in that the lazy provider resolves project reference to the root instead
of the context properly.
2) the code for constraints in the BOM submodule includes all the exported
Lucene subprojects. But in reality many people will be using just a subset of
those - the constraints imposed by the BOM (including transitive dependencies?)
will have to be downloaded and will be effective for those dependencies the
bom-importing project is not touching at all. I see this as a problem than a
benefit, actually.
> Add BOM module for ease of dependency management in dependent projects
> ----------------------------------------------------------------------
>
> Key: LUCENE-10386
> URL: https://issues.apache.org/jira/browse/LUCENE-10386
> Project: Lucene - Core
> Issue Type: Wish
> Components: general/build
> Affects Versions: 9.0, 8.4, 8.11.1
> Reporter: Petr Portnov
> Priority: Trivial
> Labels: BOM, Dependencies
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h1. Short description
> Add a Bill-of-Materials (BOM) module to Lucene to allow foreign projects to
> use it for dependency management.
> h1. Reasoning
> [A lot of|https://mvnrepository.com/search?q=bom] multi-module projects are
> providing BOMs in order to simplify dependency management. This allows
> dependant projects to only specify the version of the BOM module while
> declaring the dependencies without them (as the will be provided by BOM).
> For example:
> {code:groovy}
> dependencies {
> // Only specify the version of the BOM
> implementation platform('com.fasterxml.jackson:jackson-bom:2.13.1')
> // Don't specify dependency versions as they are provided by the BOM
> implementation "com.fasterxml.jackson.core:jackson-annotations"
> implementation "com.fasterxml.jackson.core:jackson-core"
> implementation "com.fasterxml.jackson.core:jackson-databind"
> implementation "com.fasterxml.jackson.dataformat:jackson-dataformat-yaml"
> implementation "com.fasterxml.jackson.datatype:jackson-datatype-guava"
> implementation "com.fasterxml.jackson.datatype:jackson-datatype-jdk8"
> implementation "com.fasterxml.jackson.datatype:jackson-datatype-jsr310"
> implementation
> "com.fasterxml.jackson.module:jackson-module-parameter-names"
> }{code}
>
> Not only is this approach "popular" but it also has the following pros:
> * there is no need to declare a variable (via Maven properties or Gradle
> ext) to hold the version
> * this is more automation-friendly because tools like Dependabot only have
> to update the single version per dependency group
> h1. Other suggestions
> It may be reasonable to also publish BOMs for old versions so that the
> projects which currently rely on older Lucene versions (such as 8.4) can
> migrate to the BOM approach without migrating to Lucene 9.0.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
