Re: [jakarta.ee-community] About Profiles

[Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>]

Wow, this thread is great!  So many awesome ideas from good people. Let me address your points below ...

On Mon, May 7, 2018 at 12:34 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

On Mon, May 7, 2018 at 7:14 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:

So then the first question is perhaps; who wants profiles and benefits from it? Is a profile intended for vendors or for users?

Both.  You want the users to have options but still have a standardized platform.  You want vendors to be able to enter into the market and provide users with options.

I understand what you mean, but I see things somewhat differently.

Users can have all the options they want starting from a full or web profile server, using the aforementioned pruning tool. That way they also start out with a fully standard platform, and then tailor it to their specific needs.

Vendors can already enter the market with the current profiles. What does a new profile allow them that they can't do today?

So, I’m thinking ahead to a time when new kinds of solutions come into existence that would need some of Jakarta EE but not all of it, but also don’t fit into the current Web Profile.  The creation of a profile system supports this.  For example, its possible that Internet of Things (IoT) might become the biggest concern in the future. At that point people will be looking for IoT middleware and microservices but the protocols and types of APIs needed may be very different than what is currently defined in the Web Profile.  In that case, a new profile IoT Profile could be defined.  So while the Full Profile and Web Profile may address what is needed right now (although I don’t think that is totally true) more profiles will be needed to meet future needs.  Havaing a well defined profile process in standardization accomidate that future need.

Say we have a new profile consisting of CDI, JPA, and JTA. Call it the "persistence profile". 

If a small vendor wants to enter this market, will they implement CDI, JPA and JTA themselves? Given the maturity and complexity of these specs I think it's much more likely that they will just bundle Weld or OWB, Hibernate or EclipseLink, and Narayana or JoTM.

If a vendor only wants to implement a single component/API, e.g. CDI, they can do so today, can't they? And then just certify for CDI only.

 

I believe that Glassfish and IBM fully implement Java EE 8 but no one would be required to implement the full profile.

They provide the full platform, but don't implement it fully themselves.

GlassFish for instance bundles Weld (CDI), and Hibernate Validator (Bean Validation).

IBM bundles MyFaces (JSF), OWB (Weld), EclipseLink (JPA), BVal (Bean Validation), etc.

I may be missing your point here, but it seems to me irrelevant as where a vendor (proprietary or OSS) gets their components that make up a compliant Jakarta EE implemenation as long as all those pieces together fullfill Jakarta EE compliance for a specific profile.  Just slapping together MyFaces, Weld, and EclipseLink doesn’t make for a compliant profile. The profile has to clearly state how those pieces work together.  Tomee is an example of that taking a different open source components, packaging them together, and declaring it compliant with the Java EE Web Profile. 

 

That’s the whole point of having sub-profiles. 

That's more the definition of a sub-profile, not necessarily the point of it ;) 

Sub-profile is not a real term. I’m just using that to make it clear that a profile is a subset of the Full platform.

 

I'm not sure if a bloated product line-up with a dozen profiles really makes things easier for users.

It’s not boated, it simple the largest profile from which the sub-profiles are derived.

Just to be sure, I didn't mean the full profile is bloated, but that having a plethora of different profiles makes for a bloated product line-up.

This is a concern, but I suspect, over time, profiles will be updated to meet new needs and some may eventually be retired.  Some have suggested that the correct number of profiles to standardize be 3 or 6 or 12.  I think we should minimize the number but it should be driven by the need not some arbitrary number that sounds good.

I was just remembered today about the many models that Apple had in its line-up before Steve Jobs returned. One of the first things Steve Jobs did was to slash all those barely different models (essentially, "profiles" of a base Mac model), and simplify things by having a small product line-up.

I don’t think this analogy translates very well, but I do get your point. At the same time I’m not arguing for 25 different profiles. We would only create a new profile if the problem space it addresses is a) common and b) important to differentiate. 

Kind regards,

Arjan

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community

--

Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io