[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-community] About Profiles
|
As requested, responses in-line. Extra text removed for brevity.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: Dimitris Andreadis <dandread@xxxxxxxxxx>
Date: 5/18/18 2:07 AM (GMT+01:00)
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>, Kevin Sutter <sutter@xxxxxxxxxx>, Mark Little <mlittle@xxxxxxxxxx>
Subject: Re: [jakarta.ee-community] About Profiles
- We need to define "some" profiles for certification and
portability purposes
RR: +1
- A vendor may claim compliance to one or more profiles
RR: +1
- Specs should have stand alone TCKs so they can be tested
separately and profiles could have additional tests that test
profiles as collections of APIs (profile platform tests).
RR: +1
- Profiles don't necessarily need to inherit from each other,
but they could.
RR: I believe every profile should inherit from a core profile. Other than that +1.
- Within a profile a vendor may package a newer version of a
prescribed spec, if it's compatible.
RR: +1
- Within a profile a vendor may provide additional APIs. This
doesn't change the profile itself.
RR: +1
- Within a profile a vendor may let the user add support for
additional APIs.
RR: +1
- A vendor should have the freedom to offer the user the option
of reducing/optimizing the runtime that implements a particular
profile (which may be also enhanced by the vendor or the user
with additional APIs), for example, by removing API
implementations not in use by a particular app, or creating a
runtime specific for a particular app and link externally to the
deployment or bundle everything together in a fat jar, or
perform any packaging optimization that can improve consumption
in a containerized/cloud environment (e.g. bundle the app, the
runtime and a customized version of the jvm to form an
executable).
RR: +1
- A vendor could offer the user the ability to create their own
custom profiles by starting from scratch, in which case the
resulting configuration is not considered "certified".
RR: +1
As to what the exact profiles should be,...we should provide the
existing.
RR: +1
Then for new apps we should be probably looking at new/modern:
- Jakarta EE All profile, with non needed legacy APIs removed
and new ones (possibly) added
RR: I don't think we should do this. It sends a strange message that we are not too good about judging what needs to be pruned in time and need to keep things around in a profile that basically no one would use. Let's just have a full profile and deprecate what clearly makes sense.
- Jakarta EE Micro profile, geared towards microservices
RR: +1. In addition, we should have a Servlet only core profile that the maximum amount of people in the industry can say is the baseline of what Java EE is.
