Please ship a bill of materials dependency

[sixcorners]

A bill of materials or bom dependency is one that can be used to keep the versions of dependencies in sync. Instead of adding a bunch of dependencies and setting them all to version 3.2.2 or using properties you could instead add a bom with version 3.2.2 and omit the versions on the dependencies managed by the bom. It's a good way to not having to repeat yourself if there are a bunch of versions that all need to be set to the same thing. It also makes sure you are using a set of versions that have all been tested to work together. It would be nice if lwjgl provided a lwjgl-bom dependency I could import.

Here are a few examples of them:
https://github.com/apache/logging-log4j2/blob/log4j-2.12.0/log4j-bom/pom.xml
https://github.com/FasterXML/jackson-bom/blob/jackson-bom-2.9.9/pom.xml
https://github.com/quarkusio/quarkus/blob/0.18.0/bom/pom.xml
https://github.com/spring-projects/spring-data-build/blob/2.1.9.RELEASE/bom/pom.xml
https://github.com/spring-projects/spring-boot/blob/v2.1.6.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml

Here is how I would use one in maven: https://logging.apache.org/log4j/2.x/maven-artifacts.html#Bill_of_Material
Here is how to do it in gradle: https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:bom_import

[XenoAmess]

The reason not to do so I guess is people usually not use all of those packages.

[TheMrMilchmann]

You don not need to use all of the packages with a BOM. Instead, when you include the BOM, you still need to declare all of the dependencies but not their versions. So, what this does is effectively allowing you to skip declaring the LWJGL version {numberOfLWJGLDependencies} times by declaring one additional dependency.

Instead of:

dependencies {
    // define dependencies with versions
    implementation("org.lwjgl", "lwjgl", lwjglVersion)
    implementation("org.lwjgl", "lwjgl-glfw", lwjglVersion)
    implementation("org.lwjgl", "lwjgl-opengl", lwjglVersion)
    implementation("org.lwjgl", "lwjgl-stb", lwjglVersion)
    runtimeOnly("org.lwjgl", "lwjgl", lwjglVersion, classifier = lwjglNatives)
    runtimeOnly("org.lwjgl", "lwjgl-glfw", lwjglVersion, classifier = lwjglNatives)
    runtimeOnly("org.lwjgl", "lwjgl-opengl", classifier = lwjglNatives)
    runtimeOnly("org.lwjgl", "lwjgl-stb", lwjglVersion, classifier = lwjglNatives)
}

You could write:

dependencies {
    // import a BOM
    implementation(platform("{BOM_ARTIFACT_COORDINATES}:lwjglVersion"))

    // define dependencies without versions
    implementation("org.lwjgl", "lwjgl")
    implementation("org.lwjgl", "lwjgl-glfw")
    implementation("org.lwjgl", "lwjgl-opengl")
    implementation("org.lwjgl", "lwjgl-stb")
    runtimeOnly("org.lwjgl", "lwjgl", classifier = lwjglNatives)
    runtimeOnly("org.lwjgl", "lwjgl-glfw", classifier = lwjglNatives)
    runtimeOnly("org.lwjgl", "lwjgl-opengl", classifier = lwjglNatives)
    runtimeOnly("org.lwjgl", "lwjgl-stb", classifier = lwjglNatives)
}

[Spasi]

@TheMrMilchmann Would it be a bad idea to change the native artifact scope to runtime? Why is it compile now, did we have any trouble with the Java module system?

[TheMrMilchmann]

I do not recall any particular issue leading to this decision (though there were some inconsistencies between Maven and Gradle that we have to watch out for when changing this). However, after some testing, it seems like the current approach is the way to go. Specifying <scope>runtime</scope> in the BOM seems to be implicitly overwritten when omitting the scope in the consuming POM.

When using

<dependency>
    <groupId>org.lwjgl</groupId>
    <artifactId>lwjgl</artifactId>
    <classifier>natives-${platform}</classifier>
</dependency>

+- org.lwjgl:lwjgl:jar:natives-windows:3.2.4-SNAPSHOT:compile is printed by mvn dependency:tree. However, using an unmodified BOM and overwriting the scope (by declaring <scope>runtime</scope> in the consuming POM) reports +- org.lwjgl:lwjgl:jar:natives-windows:3.2.4-SNAPSHOT:runtime as expected.
Thus, I'm not even sure now if the scope defined in the BOM contributes to dependency resolution and we should probably remove it. (The JBoss BOM does not define any scopes.)

May I ask why you would want to change it? If there is a particular issue you are facing, I'll have another look at it.

[Spasi]

Thus, I'm not even sure now if the scope defined in the BOM contributes to dependency resolution and we should probably remove it.

Sounds good.

May I ask why you would want to change it? If there is a particular issue you are facing, I'll have another look at it.

Nothing in particular. I was just going over how we handle things wrt Maven to reply to http://forum.lwjgl.org/index.php?topic=7062.0 and found it odd that the native artifacts were declared with the compile scope.