[
https://issues.apache.org/jira/browse/LUCENE-10386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Portnov updated LUCENE-10386:
----------------------------------
Description:
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.
was:
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 props:
* 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.
> 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
>
> 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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
