| To clarify, Quarkus cannot claim compatibility because we choose to deliberately not support MP Metrics. All the other specs are supported, pass the TCK, and their implementations evolved way beyond the MP APIs.
The option to not support MP Metrics was well explained in some of our announcements:
(I also wanted to link a google group thread, but that seems to be gone - for some reason, we are missing threads from the group archive)
MP Metrics is not part of the platform, so the intention is to apply for a CCR with Quarkus. In fact, the plan is to use Quarkus for the MP 7.1 release.
Cheers, Roberto On 25 Feb 2025, at 15:41, Arjan Tijms via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
Hi Lenny,
That's not a bad point. Interesting though is that Quarkus was not even officially MP compatible and trailing behind Open Liberty. If it was just about MP, you would think Helidon (which is a very nice implementation too), would be much, much more adopted.
In my biased view, the quarkus installations I saw added a lot of the Jakarta APIs from the Quarkiverse like Faces (MyFaces) and Servlet (Undertow).
So I agree with your point regarding Quarkus, though I don't see the microprofile aspect across the board. Maybe it's the case that the marketing for Quarkus as new and super fast and built for speed, and made for performance, and reactive and native is what's driving most of its adoption? At least from my (admittedly limited) point of view that's what I hear from engineers.
Kind regards, Arjan Tijms
Does “uptake of MP” include the uptake of Quarkus in your view? Of course in my view, the adoption of Quarkus represents both Jakarta EE And MicroProfile, but in “marketing” I think that Quarkus is “mostly MP” as viewed by management / marketing people.
If that is indeed the case, MP adoption is way higher than the survey would suggest, as the survey is about the MP APIs specifically, but not he “MP-only marketed Products” such as Quarkus, Micronaut and Helidon.
Hi
Of course Spring Boot also uses much of Jakarta EE, but not MP which mostly competes with its own libraries.
Which made me think.
I sometimes get the feeling, and it's not really been stated anywhere by anyone so it's just my feeling, that people want to pursue MicroProfile and ignore Jakarta EE, just because of the idea that our competitors have been too successful in the past with their marketing campaigns of blackening the name of Jakarta EE (Java EE).
In that sense, MicroProfile is a new start. It's basically still Jakarta EE, but because it pretends very hard not to be, the market could have fallen for it. I understand that sentiment, IFF it was to be true. We all know that the terms "EJB" and "JSF" have been very successfully attacked in the past and are considered tainted as well. Some of that was deservedly (both techs had real and serious problems), some of that was undeserved (most problems were fixed later, which our competitors conveniently ignored to acknowledge).
The problem however is twofold;
1. Even if it worked, what is to say our competitors would not again launch campaign after campaign blackening the name of MicroProfile in the same way?
2. IMHO, it didn't really work. The uptake of MicroProfile is lower than Jakarta EE without any clear trends of that increasing massively. The net effect, IMHO again, is only that we are weakening ourselves as stated before.
I acknowledge the fact there's a lot of feelings and speculations in the above, but still. Some food for thought maybe.
Kind regards, Arjan Tijms
Kind Regards,
Werner
Yep, these are some of the brand dilution and confusion issues I intend to bring up in the Steering Committee.
On 2/24/2025 2:51 PM, Arjan Tijms via jakartaee-platform-dev wrote:
Hi,
While we have the same debates the market does not care and moves on.
Of all the things said here, this is perhaps the most important one.
Instead of presenting to the market one strong and coherent set of APIs, we create confusion by presenting a fragmented set. We also needlessly fragment our marketing efforts by promoting two brands, further confusing the end user.
We're already in a somewhat more difficult position than say Spring Boot, where we have to explain that end user what the difference is between Jakarta EE as-in the APIs, and Jakarta EE as-in the implementations like GlassFish, Open Liberty, Payara, WildFly,
TomEE, etc.
Now we also have to explain that there's also MicroProfile, which simultaneously acts as a set of extra APIs for Jakarta EE, and as a platform itself without a direct relation to Jakarta EE (except then, of course, that it uses the Jakarta Core Profile,
and all MicroProfile implementations bundle extra Jakarta EE APIs like Validation and Persistence).
Sorry, but clearly the market does not seem to react kindly to that.
During conferences and consultancy I often try to explain to people what Jakarta EE is. People ask if Jakarta EE has support for e.g. circuit breakers. I can then either just bluntly say : yes, it has! And people are generally okay with that. Or, I go
a bit more into the details and explain how that comes from MicroProfile, and how that aligns with Jakarta. And that we have implementations that are "mainly microprofile but also Jakarta" and other implementations that are fully Jakarta and fully Microprofile.
One nice guy I recently met at a conference basically said it best: "Oh, but luckily I'm using Spring Boot. In Spring Boot we don't have those kinds of problems".
Kind regards,
Arjan Tijms
I strongly disagree with forking MP Config to Jakarta with namespace changes. This introduces unnecessary headaches and namespace clashes in the IDEs. Why cannot Jakarta EE adopt MicroProfile Config as it is and job done? No more hassle.
The namespace update is purely artificial and causes too many headaches and version matching. In order to continue the forking and namespace changes, can anyone show me the rule of Jakarta not allowing the use of MicroProfile specs first?
Emily
Kito/all,
Thanks for forwarding this, although the quote of quotes of quotes makes it very hard to read.
I fully agree with Otavio's message that both are developed under the Eclipse Foundation, and users of a product don't really care, if it was developed in repository A or B.
However, what Roberto outlined earlier about continuous copying between MP Config and Jakarta Config makes absolutely no sense.
RC> After the initial copy/paste, how would things evolve?
My intention is that technical evolution would take place in the
MicroProfile Config project. In the event of Jakarta specific
accommodations, we would
1. Cross that bridge when we come to it.
2. Try to come up with solutions that are palatable to both communities, Jakarta
EE and MicroProfile.
3. If absolutely necessary, we would define content in MP Config that
would have the proviso such as "this only takes effect in Jakarta
EE environments". There is ample precedent for such approaches. See
what we did with Faces when Validation was present (in EE) vs. not
present (such as in Tomcat).
RC> Would Jakarta keep the APIs in-sync?
Yes. Every time Jakarta needed a new version, they would pick up a
chosen release of MP config to give the copy/paste treatment to.
MicroProfile consumes Jakarta EE, so there is no MP application or platform without a Jakarta EE platform, at the very least the Core Profile. So Jakarta Config is expected to be available in every profile. If the MP Config API was to co-exist with Jakarta
Config forever, then applications would have to exclude one of them from their build system, otherwise they risk confusion or even mixing them in the same project with unforseen and unpredictable consequences. Especially if a Jakarta EE application using Jakarta
Config API also wanted to use certain MP features like OpenTelemetry, Health, etc. internally configured via MP Config, but potentially even a different version of the API, if e.g. MP 8.1 used a new version of MP Config while Jakarta EE was still on 12 or
13 based on an older MP Config API.
If the API is a drop-in-replacement then nothing keeps the MP projects from using the Jakarta one after the next release. And it does not really matter, if it was maintained in
https://github.com/jakartaee/config or
Otherwise everyone, most importantly developers and users of both MP and Jakarta EE would face a "config hell".
Regards,
Werner
I think that, in the case of config, other specifications can just specify the accepted config properties, regardless of how these properties are provided. The TCK could use system properties as a common config source.
Then Microprofile umbrella can state that these properties are supplied by MP Config, Jakarta EE Platform would state they are supplied by Jakarta Config. Jakarta Core profile wouldn't need to include Jakarta Config. Or it could, but then MicroProfile
would state that Jakarta Config is not required. I'm sure there's a way to define all this in a simple way so that everybody is happy.
I think that makes a lot of sense. Each spec just says what it needs from a "Configuration Provider" and that provider would be either MP Config or Jakarta Config.
With all that, I share the same sentiment with Reza. I always hoped that MP would tend to donate APIs to Jakarta after they become stable, and then completely rely on the Jakarta version of the API.
I agree with this sentiment as well...
We need to also keep in mind the perspective of the end users... they want a "normal" configuration setup that "just works" with all of the different parts of the app. And it would be confusing to have two different namespaces with the same classes. It's
also confusing for the end user to have two different Config specifications, even if they're roughly the same.
I think that, in the case of config, other specifications can just specify the accepted config properties, regardless of how these properties are provided. The TCK could use system properties as a common config source.
Then Microprofile umbrella can state that these properties are supplied by MP Config, Jakarta EE Platform would state they are supplied by Jakarta Config. Jakarta Core profile wouldn't need to include Jakarta Config. Or it could, but then MicroProfile
would state that Jakarta Config is not required. I'm sure there's a way to define all this in a simple way so that everybody is happy.
With all that, I share the same sentiment with Reza. I always hoped that MP would tend to donate APIs to Jakarta after they become stable, and then completely rely on the Jakarta version of the API. But that's not necessary, and I think anything is better
than the current state, when many implementations rely on MP config even for their Jakarta EE functionality, or even worse, MP parts support MP Config while Jakarta EE parts don't.
All the best,
Ondro
I am sure Ed and/or Jared will respond with their own thoughts - in the meantime let me share my two cents, including on some of the broader technical intricacies.
First a purely personal opinion independent of Microsoft. These are some of the intricacies of managing two platforms run by two separate working groups that in practice need to co-exist closely. It's the reason some of us espoused the hope that common
dependencies and possible sources of colliding resources to manage would only be in one direction with the Jakarta EE Core Profile being keenly mindful of the needs of both MicroProfile as well as the other Jakarta EE Profiles (and hopefully in some distant
future other non-Eclipse Foundation platforms that also depend on a stable/high-quality/minimal Core Profile). The hope would have been that platforms such as MicroProfile would deprecate APIs that are effectively standardized onto the shared space of the
Core Profile.
Setting aside the above purely personal opinion, if MicroProfile is very averse to supporting both Jakarta Config and MicroProfile Config, I don't think it's too hard to just keep Config out of the Core Profile including the small handful of Jakarta EE
APIs there (via spec profiles if needed). The major customer pain point is needing to configure the data/external infrastructure related Jakarta EE technologies using old style embedded XML or Java, which are mostly not in the Core Profile anyway.
On 2/17/2025 11:17 AM, Roberto Cortez via config-dev wrote:
If we have separate namespaces and APIs are synced manually / selectively (and evolve independently), I’m guessing that any Jakarta specification would use its own Jakarta Config, and MicroProfile specifications would use MP Config?
In practice, even if Jakarta Config is not part of the Core, if any Core specification adopts it, it would force Jakarta Config with its own API to the MP platform. Is this correct?
Cheers,
I plan to bring this up in the Jakarta EE Steering Committee. The technical debate aside, I think there are also process and branding/IP considerations here. For one, it's important to track down what the existing consensus had been in Jakarta EE WG/Jakarta
Config with regards to namespace. A sanity check from the perspective of branding/IP is also in order as these are in reality two different working groups.
I agree that the most prudent approach is avoiding needlessly introducing mutual inter-dependencies. Both MicroProfile and Jakarta EE should be able to independently evolve their configuration approaches when needed. Separate namespaces with APIs synced
manually/selectively when needed does that well.
On 2/11/2025 11:00 AM, Ed Burns via config-dev wrote:
Even with approaches that allow for mitigating the circular dependencies, I am strongly predisposed to prefer the repackaging approach that allows the content of MicroProfile config to
be accessed by Jakarta specifications using an entirely Jakarta namespace.
Ed
My responses are inline. We will discuss this issue in more detail at this Tuesday's MP Technical call. Please join if you are interested. The joining details can be found
here.
Hi Ed,
Thank you for the response.
1. A technical problem regarding introducing circular dependencies.
Yes, the issue is that MP Config is dependent on CDI. This has been discussed many times, and I believe MP is open to make the necessary adjustme=
_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
