Why does the Narayana BOM feature third-party dependencies?

[Laird Nelson]

I was curious why the Narayana BOM features third-party dependencies, instead of the more common practice of including only what you publish.

Best,

Laird

[Manuel Finelli]

Hi Laird, The goal of JBTM-3735 was to simplify the version management of Maven dependencies across Narayana.

Best,

Manuel

--
You received this message because you are subscribed to the Google Groups "narayana-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to narayana-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/CAHNdxu%3DEHfiSjJ46cOhhnXw%2BHU7H_TAUc6PoriN3SPnHe_Y5PA%40mail.gmail.com.

[Laird Nelson]

I see; thank you. It's just that: most BOMs include only what a project publishes so that other projects using those BOMs can continue to use their transitive dependency convergence strategies. The Narayana BOM, as currently constituted, prevents that.

Some arbitrarily selected examples:

Jackson BOM: https://github.com/FasterXML/jackson-bom/blob/jackson-bom-2.15.2/pom.xml

Helidon BOM: https://github.com/helidon-io/helidon/blob/3.2.2/bom/pom.xml

Jersey BOM: https://github.com/eclipse-ee4j/jersey/blob/3.1.3/bom/pom.xml

AWS BOM: https://github.com/aws/aws-sdk-java/blob/1.12.556/aws-java-sdk-bom/pom.xml

OCI BOM: https://github.com/oracle/oci-java-sdk/blob/v3.25.1/bmc-bom/pom.xml

…and so on.

Thanks again for the rationale.

[Michael Musgrove]

We need to harmonise dependency versions across the various Narayana modules.

If we did it the same way as WildFly does it would that work for you, for example the standard ee bom contains:

```
    <dependencyManagement>
        <dependencies>
            <!-- Inherit the common deps -->
            <dependency>
                <groupId>${ee.maven.groupId}</groupId>
                <artifactId>wildfly-common-ee-dependency-management</artifactId>
                <version>${ee.maven.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
```

and the wildfly-common-ee-dependency-management pom is similar to our bom in the sense that it includes third-party dependencies, i.e. the resulting "effective-pom" for the WildFly bom will be similar to the narayana bom.

[Marco Sappe Griot]

Thanks Laird for your question,

we decided to add extra description and comments in Narayana BOMs in order to clarify their function.

You can see the merged PR.

Marco

To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/fdfccac8-1754-4fb0-ada8-2af247a98d75n%40googlegroups.com.

[Laird Nelson]

No, but that's OK, we just won't use it.

Normally BOMs are exactly that: a bill of materials of the stuff the project makes, not stuff it uses.  (This thing, whatever it is, is a convenience collection of managed versions for a particular set of use cases, and it probably satisfies those use cases, whatever they are, just fine.)

[Michael Musgrove]

So, since the WildFly BOMs inherit common third party dependencies in the dependencyManagement section (I provided links in my previous message), I think we should follow their lead.

To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/b5d3d67b-4f04-4c1c-9b35-95d1cb65dc2cn%40googlegroups.com.

[Marco Sappe Griot]

I agree with Mike, 

Laird, would that be convenient for your use-case?

Thanks,

Marco

To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/CAKJ8-j6Xhbq-8mx1-32mHdFKjZ28aUW0Xs2YKrkLNxP_iYy0Qw%40mail.gmail.com.

[Laird Nelson]

I'm honestly not sure. All of the other BOMs we use don't have third party dependencies in them, so we probably won't start here. Thanks for the conversation!