You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Petr Portnov (Jira)" <ji...@apache.org> on 2022/04/22 13:20:00 UTC

[jira] [Updated] (LUCENE-10386) Add BOM module for ease of dependency management in dependent projects

     [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org