Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] About Profiles
@Mrinal
The profile doesn't *handle* anything. It's just a spec/cert that you check for. 

If you are a vendor implementing your own jakarta server, then you'll make sure all your fiddly bits integrate correctly (or, at least, good enough to pass the TCKs needed to tack that "JakartaEE Profile X Certified" badge on the tin). If you ever change any of your libraries/modules (be it home grown or a third party), you'll have to re-check for that cert, so that's still on the vendor.

If you are a vendor of any solution that will run on a server, and you have a hard dependency on a specific JakartaEE API, then you will explicitly document your unmet dependencies, or provide your own (and then hardcoding over it). That way, your users know what they need to look for in their servers/providers.

On the same page, if you are a JakartaEE user of any kind, you'll need to make sure you are running the app on a stack with the correct APIs available, be it by using a server with a certification for a complete enough profile, or by (once again) providing your own.

The only relevance profiles have on this is as lists of available APIs on your current environment, for you to provide any missing deps you might need.


Following your example:

1) If you have a caching solution, with your own JPA certifiable implementation of persistence, why would you care if the environment has JPA? You're still going to use your home-grown solution.

2) If you will work directly over the JPA API, then you wouldn't care about shipping your own implementation of that. You'd tell everybody they need JPA in their environment for your solution to work. Then, it'll be irrelevant what profile or environment the user is on, as long as they make sure to have a JPA implementation available.

3) If you want to distribute your home-grown solution as another JPA implementation, you're free to do so, separately from your Cache solution. Then, it follows the same logic as (2)

4) If you want to have both general JPA use, and your homegrown solution embedded into your caching solution, then you also build in some logic for the user to configure which one they want to use (or, if you're daring enough, for your solution to find out which option to switch to based on the current environment), and then switch between straight calls to the JPA API, and calls to your embedded solution accordingly.


None of this is changing, since this is how Java works (add implementations to the classpath/modpath, then call their APIs from your code), irrelevant of what we want to do with JakartaEE.
The point of profiles is to not just know an implementation of an API works on spec, but that your environment won't implode because of weird interactions *between* those implementations.
You still need to know the list of deps you need for anything to run correctly. Profiles just reduce your list from a hundred versioned deps, to a single (or more, depending on the solution we end up mostly agreeing on) versioned profile cert, plus a few dozen non-spec versioned deps.


Mariano Amar

Senior Consultant

email/hangouts: mariano.amar@xxxxxxxxxx
skype: marianoamar

AVISO DE CONFIDENCIALIDAD DE CORREO ELECTRÓNICO

Esta comunicación contiene información que es confidencial y también puede contener información privilegiada. Es para uso exclusivo del destinatario. Si usted no es el destinatario tenga en cuenta que cualquier distribución, copia o uso de esta comunicación o la información que contiene está estrictamente prohibida. Si usted ha recibido esta comunicación por error por favor notifíquelo por correo electrónico(info@xxxxxxxxxx) o por teléfono (+54 11 3249 7503)

This communication contains information that is confidential and may also be privileged. It is for the exclusive use of the recipient. If you are not the intended note that any distribution, copying or use of this communication or the information it contains is strictly prohibited. If you have received this communication in error please notify us by email(info@xxxxxxxxxx) or phone (+54 11 3249 7503)


On Wed, May 9, 2018 at 4:52 PM, Mrinal Kanti <design@xxxxxxxxxxx> wrote:
What about service providers (say, caching)?

How about the scenario when the spec implementation refers to other specs which are not referred in the spec itself. For example, if a Jcache implementation uses JPA to persist cached objects (for distributed access or failover) then how would the profile handle this (assuming Jcache spec has no association with the JPA spec)?

Should the Jcache implementation ship it own version of JPA (and its implementation)? If so, then what happens when the user upgrades their application from one profile (which does not have JPA) to another (that has JPA)?

-Mrinal

On Wed, May 9, 2018 at 10:44 PM, Scott Stark <sstark@xxxxxxxxxx> wrote:
A given distribution incorporating implementations from different vendors is just a detail. What matters is that the distribution has gone through the trouble of certifying the behavior of a test suite/TCK for a profile that provides some level of confidence that a user can write applications that combine a the apis from a profile and have the app run on different distributions.

This is also the point of profile specification in my view. A given spec should not be making references to every other possible spec they can be combined with. Rather, a profile specification should define the integration requirements and have corresponding TCK tests for validation of those requirements.

On Mon, May 7, 2018 at 10:34 AM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

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

 
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.

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

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

 
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.

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.

Kind regards,
Arjan




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



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



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


Back to the top