The culprint *may* be xmvn, as there is (at least) one pkg in rhel8 which is jdk11 based but is build by Makefile, and do not suffer the issue.
More details about the java provides.

Each rhel, have system jdk. In rhel8 it is, and will remain jdk8. Such "system jdk", is th eonly jdks which provide version-less provides, lije java, java-headless, java-devel and so on (+ version-full alternatives like java-1.8.0-devel etc...). Every jdk, compatible with system jdk can keep the version-less provides.
Every other jdk (eg java-11-openjdk, or java-17-openjdk, or java-1.7.0-openjdk) have onny version-full provides like java-11-headless, java-17-devel and so on.

This is here so the system JDK may be changed smoothly. If jdk11 will become system JDK, ti will start to provide version-less provides, and jdk8 will stop provide them. 


Thus the version-less provide, accompanied by version is simply bug, as it can not be satisfied and actually breaking the smooth system-jdk change (which is unlikely to happen in rhel8, but may happen in rhel9 by jdk11->jdk17)

Adding relevant information:

Contents of the .spec file:
BuildRequires:  maven-local
BuildRequires:  mvn(com.beust:jcommander)
BuildRequires:  java-11-openjdk-devel

Requires:       java-11-headless
Requires:       beust-jcommander
Requires:       javapackages-tools

The built .rpm file Requires:
/bin/bash
beust-jcommander
java-11-headless
java-headless >= 1:11
javapackages-filesystem
javapackages-tools
mvn(com.beust:jcommander)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

> java-headless >= 1:11

Is the bad one

Thank you for taking the time to report this issue to us. We appreciate the feedback and use reports such as this one to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution.

If this issue is critical or in any way time sensitive, please raise a ticket through the regular Red Hat support channels to ensure it receives the proper attention and prioritization to assure a timely resolution.

For information on how to contact the Red Hat production support team, please visit:
    https://access.redhat.com/support

(In reply to Mikolaj Izdebski from comment #4)
> Thank you for taking the time to report this issue to us. We appreciate the
> feedback and use reports such as this one to guide our efforts at improving
> our products. That being said, this bug tracking system is not a mechanism
> for requesting support, and we are not able to guarantee the timeliness or
> suitability of a resolution.
> 
> If this issue is critical or in any way time sensitive, please raise a
> ticket through the regular Red Hat support channels to ensure it receives
> the proper attention and prioritization to assure a timely resolution.
> 
> For information on how to contact the Red Hat production support team,
> please visit:
>     https://access.redhat.com/support

Hi, This is severe issue reprted by employees. Do you already have some opinions?

The root cause is that "java-headless" provide means "default system JRE" and that there is no provide with meaning "any JRE".
Therefore it's not possible to require "any JRE", except by enumerating all of them, eg. "Requires: (java-headless or java-11-headless or java-17-headless)".
A proper long-term fix would mean redesigning how provides and auto-requires are supposed to work. There are several possibilities.
One is redefining java-headless to mean "any JRE" and adding generic provides to all JDKs - I still don't see any good reason why newer JDKs can't provide java-headless and such.
Another possibility is removing auto-requires on java-headless altogether - they add little value and cause much trouble.
There is no obvious best solution, so this needs discussion. The change should first happen in Fedora.

This is how I worked around this issue when using xmvn:

...
%install
%mvn_install
sed -i '/requiresJava/d' %{buildroot}/usr/share/maven-metadata/<name>.xml
...

Now only the line without the version requirement is generated:
Requires: java-headless

You can then manually add the right java-11-headless requirement.

Certainly this will also require the system default and this is only a workaround.

Well, the current workaround is this:
https://src.fedoraproject.org/rpms/classpathless-compiler/c/9e1c30d96a5a24d9fc60a673b29531eaca848006?branch=epel8

Comment #8 explains the problem. This is not something that can be fixed within javapackages-tools. The cause is a design decision of the Fedora OpenJDK maintainers.