I don’t think additional Jakarta EE profiles adds a lot for developers. Although it makes it easier for a product creator to gain Jakarta EE compatibility on a subset of specifications. Just looking
at our download stats Full profile is download 20x more than Web Profile. Also we get more demands to add additional apis to Payara Micro which is Web Profile+ than anything else.
Given we have MicroProfile I don’t see the need to have an equivalent profile in Jakarta EE. Can’t MicroProfile just create a platform TCK that takes a subset of the Jakarta EE TCK for the specs
that form that profile.
From: cn4j-alliance <cn4j-alliance-bounces@xxxxxxxxxxx>
On Behalf Of Edwin Derks
Sent: 14 January 2021 07:43
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Subject: Re: [cn4j-alliance] Thoughts on the CN4J purpose
I'm not sure if too "many" profiles are going to be confusing. It's how we make them available. But having vendors implement a profile and add a few other specifications, effectively creating their own vendor-specific
profiles might not be the desired way to go either.
On agreeing whether or not to evolve Jakarta EE specifications "too much": I don't think we have any choice but to evolve them in order to keep them valuable for developers. If they aren't, we run the risk that
vendors are going to create their own versions of these specifications because their end-users aren't going to use the original specifications, effectively rendering them obsolete. If that happens, the whole reason that we have standards in specification falls
apart and loses its value.
I added my comments on the Google Doc.
·
Slide 4:
o
Too many profiles. This will cause confusion. Now you need criteria to figure out which one to use and then worry about how to move between profiles. I like " à la carte” or everything but that’s my personal
opinion.
·
Slide 6:
o
Why would winning new developers happen specifically with MicroProfile and LiteProfile? I can see some vendors wanting to push one or the other due to business reasons but I don’t think this should be
a goal for CN4J.
o
I don’t agree with trying NOT to evolve the Jakarta EE specs “too much”. Why don’t wouldn’t we want to evolve the specs? It it isn’t evolving then people will think it is dead.
Here are some initial thoughts on what CN4J needs to address and how that might happen. These are largely Red Hat's current views. The document is open to anyone with the link. Feel free
to comment here or in the document.
This will be a lengthy discussion that we expect to involve members of both Jakarta and MicroProfile communities as well as their respective committees.
_______________________________________________
cn4j-alliance mailing list
cn4j-alliance@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cn4j-alliance
_______________________________________________
cn4j-alliance mailing list
cn4j-alliance@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cn4j-alliance
|
