Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cn4j-alliance] CN4J and Jakarta EE Profiles
The names of the profiles should be ultimately refined for maximum marketing value. I had added core as one alternative name. Kernel could be another.

The problem with the web profile as I see it was due to how the TCK licensing was done. It simply was not cost effective for a non-commerical or small commercial web container to pursue certification. That has been eliminated with the current Jakarta compatibility requirements.

The notion of the enterprise/xyz profile is solely on standardizing portability of legacy EE8 apps into an EE9+ runtime. I don't know if this is something vendors are interested in doing. We were not for EE9, but that seemed to be more about reducing scope creep and the lack of experience in the transformation tooling.

On Sat, Jan 16, 2021 at 4:40 PM reza_rahman <reza_rahman@xxxxxxxxx> wrote:
The profile ideas proposed in the deck are useful, but I think need refinement.

Given that Jakarta EE and MicroProfile in practicality will remain two separate efforts with different goals, I think the proposed "Lite" profile is important in making alignment and certification more formal. Pretty much anything MicroProfile platform compatible will transitively become Jakarta EE compatible. The contents of the profile seems right as well.

I do think though that a better name than "Lite" profile is needed. While I understand that some vendors are focused more on this profile and MicroProfile as a technology set, a majority of implementations still fully support both Jakarta EE and MicroProfile technologies. It is also easy enough to make the case that there are many Jakarta EE technologies that are very relevant to developers aside from the four mentioned in the profile. For these reasons and the history behind us, it is important to avoid any implication that technologies aside from those four are somehow "heavy" or "not light". I think a much more neutral but still effective name would be much more valuable such as: "Base Profile", "Core Profile" or "Microservices Profile".

I do believe that the Web Profile was a good idea at the time but in reality has not enjoyed much adoption. I think it is time to simplify things and prune that profile. Similarly I think things like JSF, JSP and JSTL can be safely pruned from the platform for the foreseeable future.

Lastly, I really did not understand the purpose of the proposed Enterprise Profile. The only distinction appears to be making backwards compatibility with Jakarta EE 8 and the Eclipse Transformer a requirement. Wasn't it already decided not to worry about these things as of Jakarta EE 9 and think of Jakarta EE as more or less a reset point? Why can't these concerns continue to be handled in a vendor specific way for users absolutely unwilling to move forward and make a one-time backwards incompatible change once in almost two decades so that the platform can evolve more freely under open governance?

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Date: 1/14/21 4:45 AM (GMT-05:00)
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 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.

 

Edwin

 

On Thu, 14 Jan 2021 at 03:19, Ryan Cuprak <rcuprak@xxxxxxxxx> wrote:

Hello,

 I added my comments on the Google Doc. 

 

 Two things:

· 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. 

 

 -Ryan Cuprak

 

 

On Thu, 7 Jan 2021 at 17:43, Scott Stark <starksm64@xxxxxxxxx> wrote:

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

_______________________________________________
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

Back to the top