Make Full / Web profile play nice with MicroProfile maven dependencies

[lprimak]

Problem: Jakarta EE API dependencies do not play well with MicroProfile dependencies, even after the empty platform JARs are implemented

Let's assume that Jakarta EE 10.0.1 is a new API version of Jakarta EE 10 with #137 merged in (empty platform JARs),
and some other minor API improvements, just to set up a realistic scenario.

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>10.0.1</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>org.eclipse.microprofile</groupId>
    <artifactId>microprofile</artifactId>
    <version>6.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>

This will yield the following dependency tree:

# mvn dependency:tree
[INFO] +- jakarta.platform:jakarta.jakartaee-api:jar:10.0.1:provided
[INFO] |  +- jakarta.platform:jakarta.jakartaee-web-api:jar:10.0.1:provided
[INFO] |  |  +- jakarta.servlet:jakarta.servlet-api:jar:6.0.0:provided
[INFO] |  |  \- jakarta.security.enterprise:jakarta.security.enterprise-api:jar:3.0.0:provided
[INFO] |  +- jakarta.jms:jakarta.jms-api:jar:3.1.0:provided
[INFO] |  +- jakarta.activation:jakarta.activation-api:jar:2.1.0:provided
[INFO] |  +- jakarta.mail:jakarta.mail-api:jar:2.1.0:provided
...
[INFO] +- org.eclipse.microprofile:microprofile:pom:6.0:provided
[INFO] |  +- jakarta.platform:jakarta.jakartaee-core-api:jar:10.0.0:provided
[INFO] |  +- org.eclipse.microprofile.config:microprofile-config-api:jar:3.0.2:provided
...

As you can see above, even though the Jakarta EE API version is 10.0.1, the core profile is still 10.0.0, which may lead to subtle errors that are not readily apparent.

Proposed Solution:
As follow-up to #133, I think we can make web profile depend on core profile, thus normalizing APis.
Currently, there is a whole bunch of copy-and-paste dependencies between core profile and web profile.

With the above solution, the Core Profile dependency that's expected by the Maven resolution rules (10.0.1) would be pulled in.
Even better, if a future version of MicroProfile provides a later version of Core Profile (and it's APIs), that would also work as expected, if the MicroProfile dependency would be put first in the pom.xml. This is also consistent with maven resolution rules, and thus would be exactly what developers would expect.

AB#91

[starksm64]

This is a relationship Red Hat has argued against as the core profile should be able to evolve in the direction that makes sense for cloud native without worrying about impacts on other profiles or the platform.

[lprimak]

Thanks for looking at this Scott(s),
Can you please point me to any written discussions about this, perhaps there may be another way to fix the immediate problem of Jakarta EE dependencies not playing nice with MicroProfile dependencies that still makes sense for Quarkus.

[lprimak]

Do you have any suggestions that would work better?

[lprimak]

Hi guys,

I updated the description with a specific example where the current status quo fails to deliver consistent results for developers.

Also, @starksm64 are you sure that the issue outlined here:

This is a relationship Red Hat has argued against as the core profile should be able to evolve in the direction that makes sense for cloud native

would still be relevant with the empty JAR for the core profile?
Wouldn't it be the case that Quarkus bom can update / exclude whatever dependencies it wants from the core profile, without worrying about the other effects, since core profile is now just a pom with a list of transitive dependencies?

As far as I can see, currently core profile is basically MicroProfile, i.e. jax-rs and CDI.
Let's say Core wants to add micrometer to it's APIs. But Web and Full do not want to do this.
In that case, core can include it as optional, and quarkus bom can 'promote' to required, or web and full can exclude them easily from their list of transitive dependencies.
Wouldn't either option would be better than the status quo we have now?
What do you think?

[lprimak]

As per discussion in the Platform Call on May 30th,
the comment #138 (comment) is not applicable to this issue.

Please let me know if I am not understanding the above correctly @starksm64

Thanks!