Add a range of JRE versions as external dependency

[ppkarwasz]

It would be useful to document in each JAR, what is the minimal JRE version required by the library. This information is hard to come by, since it is not present in neither the POM nor the manifest.

[ppkarwasz]

There are a couple of questions that need to be decided for this issue:

• What PURL can we use for a generic JVM implementation?
• Do we need separate entries for the JVM and the Java Class Library?

[hboutemy]

• if it's not present in the POM, I don't get how you hope it will come to a SBOM generated during build (when done with Maven)

• is what you have in mind the maven.compiler.release / source / target used when compiling with javac? or something else?

• I'm not convinced SBOM is the solution to every tech problem that is not a question of Bill Of Materials: for Maven, I'd go more the MANIFEST way https://maven.apache.org/shared/maven-archiver/#manifest: not only storing Build-Jdk-Spec but also Target-Jdk-Spec (name to be defined)

[ppkarwasz]

• if it's not present in the POM, I don't get how you hope it will come to a SBOM generated during build (when done with Maven)
• is what you have in mind the maven.compiler.release / source / target used when compiling with javac? or something else?

Yes, I mean we could store the -target or --release arguments passed to the javac compiler.

• I'm not convinced SBOM is the solution to every tech problem that is not a question of Bill Of Materials: for Maven, I'd go more the MANIFEST way https://maven.apache.org/shared/maven-archiver/#manifest: not only storing Build-Jdk-Spec but also Target-Jdk-Spec (name to be defined)

You are right: checking that all libraries have the same Java version requirement should be done without SBOMs. However, it does make sense to add information about the runtime environment to the SBOM, since this is also a (hidden) dependency of Java applications.

[hboutemy]

However, it does make sense to add information about the runtime environment to the SBOM, since this is also a (hidden) dependency of Java applications.

I disagree: SBOMs are not about managing any aspect of what people can call "dependencies", with build tool experts thinking at adding more and more

SBOMs are a way for non expert to have uniform way to deal with BOM topics, whatever the ecosystem or build tool: currently we add more and more question to the Maven plugin implementation before the basics are well understood and managed

trying to add more will bring more complexity, then less usage (and no time to work on features)
do you remember https://fosdem.org/2025/schedule/event/fosdem-2025-6483-where-in-the-oss-supply-chain-do-sbom-attributes-come-from-/ ?

[hboutemy]

Jira issue created https://issues.apache.org/jira/browse/MSHARED-1466
every Maven packaging plugin will have to upgrade to benefit...

from a user perspective, we display the info in the generated documentation https://maven.apache.org/shared/maven-archiver/summary.html
perhaps we should do the same type of history as what we did for plugins https://maven.apache.org/plugins/maven-compiler-plugin/plugin-info.html#system-requirements-history => https://issues.apache.org/jira/browse/MPIR-480 created too

(notice: Maven discussion, not really SBOM discussion: we're far from going from Maven to more generic SBOM, JVM or even cross-ecosystem)