I can attest you are not alone. A large part of the end user community has trouble understanding why moving things to the JCP/Java EE was deemed OK but moving things to Jakarta EE is somehow more problematic. It is indeed cause for some cognitive dissonance.
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. On Mar 25, 2021, at 10:39 AM, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
I agree that the issue is not whether
the spec comes from another source whether that is an Eclipse
Foundation working group or the W3C.
The issue is that MicroProfile
explicitly states that breaking changes are permitted while
Jakarta explicitly states they are not. The impedance mismatch is
caused by explicitly differing intentions.
Separately, I would add that I
personally suffer some degree of cognitive dissonance because it
was once thought reasonable to move Config to the JCP but
apparently it is unreasonable to move it to Jakarta EE. But maybe
that's just me.
On 2021-03-25 9:39 a.m., BJ Hargrave
wrote:
Um, Jakarta EE relies on 3rd party specs all the
time. JSON, XML, HTTP, SQL, REST, LDAP, SOAP, Java SE
Platform, ... Declining to rely on a 3rd party spec just
because it comes from another Eclipse Working Group seems
quite wrong and is not a valid reason.
Points about the stability of the 3rd party spec
are valid. This can of course be negotiated with the spec
author.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and OSGi Specification Project lead // mobile: +1
386 848 3788
hargrave@xxxxxxxxxx
-----
Original message -----
From: Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>
Sent by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
Cc: jakartaee-platform developer discussions
<jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [External] : Additional
profiles
Date: Wed, Mar 24, 2021 18:38
It was never a good practice to rely on a spec created by
another working group. It’s out of control. It can be
evolved a not desired way or abandoned. Look what’s happened
with MP Tracing when OpenTracing turned into OpenTelemetry.
Moving MP Config to Jakarta is definitely one of the
options. It has its own pros and cons. As it was created by
another WG, moving will require some approval process. I
cannot guarantee that it will be accepted as it is without
modifications. Or maybe it can be accepted assuming that it
will be modified in next releases. If we agree that this
option is a way to go, it’s definitely a CN4J responsibility
to define how to do it. It will require some time,
significant time, considering the fact of how it goes now.
The solution with simplified Jakarta Config spec looks
easier to me.
I think that Core profile must have Config. Even
more, I think that other specs in Core must use it.
-- Dmitry
Well, my suggestion is to move MP Config to
Jakarta and put it under core profile and then
MP can directly get it back. I am also fine not
to put config in the core but not having two
configs. Anyway, I think this discussion needs
to happen under CN4J.
Emily
What is
your idea? How shall we deal with Config in
Jakarta EE?
-- Dmitry
I disagree with creating a
Jakarta Config, which creates a
competing message with
MicroProfile Config. When MP
consumes this core profile, it
will have two configs to deal
with.
MP Config is not huge and I
don't see the value to further
split it.
Emily
I agree that Config must be
in Core profile, but I disagree
that it should be MP Config.
IMO, it must be Jakarta EE spec.
Depending on a spec from another
project brings many
disadvantages and Jakarta is all
about stability and backwards
compatibility.
I think it should be a new
spec which MP Config should
possibly extend. It can be
very minimalistic like one
@ConfigValue annotation. So,
there is a similar
relationship as between
@Inject spec and CDI. Or it
can contain the most stable
features of MP Config.
-- Dmitry
Hi,
MP Config of
course only given a
sufficient stable
and guaranteed
release plan for
Jakarta.
I'd almost say
this Core profile
should be governed
by its own
working group, who
take into account
the interests of
both EE and MP,
being a core profile
for them both.
Now I know we
can't have yet
another actual
working group, but
such Core
profile (should it
come to fruition in
this form) probably
benefits from such
shared interest
governance.
Kind regards,
Arjan Tijms
-1 for
MP Config.
Unless
the MP Folks
can commit on
„mature
Features“ (a
bi like the
maturity Level
of CNCF) that
won’t suddenly
receive
breaking
changes and
they also
guarantee to
provide a
Jakarta first
Roadmap where
e.g. MP Config
is migrated to
the „jakarta“
Namespace and
newest Jakarta
release ASAP
before any
other MP specs
it is not
ready to be
included in
any Jakarta EE
profile I’m
afraid.
Implementations
may use it at
their own risk
but we already
see how badly
that affects
and slows down
Jakarta NoSQL
and its
implementations.
Werner
Gesendet
von Mail für
Windows 10
Hi,
Just
thinking about
Core from
another
perspective,
is having it
contain
exactly what
EE and MP have
in common.
So that
could be, for
now:
Following this
Core profile,
both the rest
of EE and the
rest of MP
could depend
on it.
I agree
persistence is
too much for
Core. While
the issue is
that most
microservices
do persist
data, the
sources are
often varied
including
simply
messaging and
some
microservices
merely perform
orchestration
of one kind or
the other.
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.
> On Mar
23, 2021, at
7:27 AM, Lukas
Jungmann <lukas.jungmann@xxxxxxxxxx>
wrote:
>
> On
3/18/21, 6:07
PM,
"jakartaee-platform-dev
on behalf of
Emily Jiang
via
jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx on
behalf of jakartaee-platform-dev@xxxxxxxxxxx>
wrote:
>
> Do we
need to put
Data Access on
the list?
Microservices
normally need
to access a
database. Do
we want to add
JPA or JNoSQL
or something
else?
>
> This is
good question.
Both might be
too big for
the "core".
OTOH, when I
look the
JNoSQL stuff
and compare
that with
current
Persistence, I
think, it
would probably
make sense to
define sth
like
"persistence-core"
containing
annotations
common to both
of them + some
lightweight
EntityManager/EntityManagerFactory
like
interface(s)
offering just
basic CRUD
operations
with some
unwrap method
eventually and
nothing more.
A Map.Entry or
an item in the
List could
then be seen
as trivial
implementation
of the
"Entity" from
the
"persistence-core".
It could be
even part of
existing
common-annotations
API. Seeing
jakarta.persistence.Entity
and
jakarta.nosql.mapping.Entity
together
reminded me
times figuring
out what type
of Node is the
code I have to
work with
using - is it
org.w3c.dom.Node or javax/jakarta.xml.soap.Node? - and that can be
confusing for
users in some
cases in the
future.
>
> thanks,
> --lukas
>
>
> Thanks
> Emily
>
>
>
> On
Thu, Mar 18,
2021 at 2:59
PM Reza Rahman
<reza_rahman@xxxxxxxxx>
wrote:
>
>
> With
regards to
deployment
models, I
think it is
best to leave
it completely
open. The
problem is
that the dust
hasn’t quite
settled yet
and there are
several
options that
make sense to
one extent or
the other:
thin wars,
fat/uber jars
and hollow
jars. I bet it
would be hard
to get
complete
consensus on
which
deployment
models should
be required.
> With
regards to
Configuration,
one can live
with XML but
it is far from
ideal. I think
it is best to
aim for
property files
via a
Configuration
specification.
In addition, a
fully
Java/annotation
way of
configuration
could also be
explored but I
think it is a
lower
priority. If
you look at
Spring Boot
specifically,
the properties
based
configuration
mechanism
seems to have
won out for
the most part.
In order to
get the Core
Profile out in
time for
Quarkus
perhaps it is
best to leave
configuration
unspecified at
least
initially.
>
> Most
folks here are
probably aware
of this
analysis of
the various
ways of
bringing
Configuration
into Jakarta
EE: https://reza-rahman.me/2021/02/09/your-input-needed-to-determine-path-for-jakarta-ee-microprofile-alignment/ <https://reza-rahman.me/2021/02/09/your-input-needed-to-determine-path-for-jakarta-ee-microprofile-alignment/>.
I think it
should help
make the
discussion a
bit easier.
All options
are workable,
but this would
be the order
for me: A2,
A1, B, C. B I
think carries
too many
unnecessary
risks and
complexities.
C I think
really sends a
poor message
to the
community as
to the
relationship
between
Jakarta EE and
MicroProfile.
I think
effectively
what you are
proposing is
C.
>
> Reza
RahmanJakarta
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.
>
>
>
> On Mar
18, 2021, at
6:41 AM,
Dmitry
Kornilov <dmitry.kornilov@xxxxxxxxxx>
wrote:
>
>
>
>
> We
talked a lot
about which
specs should
or should not
be included in
the core
profile. I
would like to
go a little
beyond this
topic and talk
about two
things which
are not clear
to me. The
first is what
kind of
deployment
model should
we use?
>
>
Logically it
should support
the standard
Jakarta EE
deployment
model assuming
using war/ear
archives and
supporting
multiple
deployments.
It will
provide
maximum
portability
between
Jakarta
profiles. On
the other hand
it’s an
overhead for
the smallest
profile. In
the most cases
microservice
is one
application,
so multiple
applications
support maybe
not needed.
XML-based
deployment
descriptors
are something
from the last
century. We
actually don’t
want to
include any
XML processing
specs to the
core profile
and even made
them optional
in the main
Jakarta
profile. I am
trying to say
that maybe
deployment
specification
needs a rework
to support
more modern
approach like
yaml or json
files or even
be based on
configuration
spec. It’s one
of the
options.
Another option
would be using
executable jar
files the same
way as in
Spring Boot,
Helidon,
Quarkus, etc.
This approach
has many
advantages
such as
unnecessary
class loading
madness,
potential
GraalVM
native-image
support, etc.
>
>
Another topic
is
configuration.
There is no
doubt that
configuration
specification
is needed in
Jakarta.
Potentially we
can use
MicroProfile
Config, but we
immediately
have namespace
problems. IMO,
Jakarta
profile must
use/depend on
Jakarta
specifications
only. Recently
I talked with
Tomas Langer
(Helidon
architect) and
he had an idea
of creating a
minimalistic
config
specification
in Jakarta
which contains
one annotation
-
@ConfigValue.
More
functionality
can be added
later.
MicroProfile
Config can
depend on
Jakarta
Config. It
will make
possible using
MP Config
implementations
in Core
Profile
implementations.
It makes sense
to me.
>
> I
would like to
hear your
opinions.
>
> --
Dmitry
>
>
> On 18.
3. 2021, at
10:51, Dmitry
Kornilov <dmitry.kornilov@xxxxxxxxxx>
wrote:
>
>
>
>
> On 17.
3. 2021, at
23:44, Emily
Jiang via
jakartaee-platform-dev
<jakartaee-platform-dev@xxxxxxxxxxx>
wrote:
>
> I
think the
Cloud Profile
from Ivar's
doc https://docs.google.com/presentation/d/1THhvjZazSFpDE95rqtcdQXgBQxa-B3aMFksq8xKJo08/edit#slide=id.g786c259e4b_0_101 <https://docs.google.com/presentation/d/1THhvjZazSFpDE95rqtcdQXgBQxa-B3aMFksq8xKJo08/edit#slide=id.g786c259e4b_0_101>should
be renamed to
the core
profile and
the list is a
good start. By
the way, I
don't want to
see EJB on the
Core profile
list. CDI is
the
replacement
for EJB.
>
>
> I
think this
list can be
further
shortened to:
>
> JAX-RS
> JSON-B
>
Annotation
> Bean
Validation
> CDI
> Config
>
Security
>
> CDI
contains
Injection, no
need to
mention
Injection I
think.
>
> Since
we have
JSON-B, do we
still need
JSON-P?
>
>
>
>
>
> We
need both
JSONP and
JSONB.
>
>
> --
Dmitry
>
>
>
>
> Thanks
> Emily
>
>
>
> On
Wed, Mar 17,
2021 at 3:14
PM arjan tijms
<arjan.tijms@xxxxxxxxx>
wrote:
>
>
> Hi,
>
>
> On
Wed, Mar 17,
2021 at 3:33
PM Reza Rahman
<reza_rahman@xxxxxxxxx>
wrote:
>
>
> I
think either
it is best to
leave Web
Profile mostly
alone (and
maybe prune
it) or use it
as a more
effective
replacement to
Full Profile
(and basically
treat the Full
Profile as
mostly
legacy).
>
>
> I
would like to
see the latter
option.
Speaking with
my Piranha
Cloud hat on;
we're not
looking
forward to
implementing
things like
the
Application
Client
Container, EAR
support, and
some of the
more obscure
aspects of
Corba and EJB2
and whatever
else still
lingers in
EJB-full.
>
> Moving
at least
Concurrency
and
Authorization
to Web Profile
(for
Authorization,
perhaps for
simplicity
make it a
sub-spec of
Security), and
perhaps a
Messaging lite
(Messaging
with only the
newer,
simplified
API) and Mail,
would make the
Web Profile
essentially
the Legacy
Free Profile
that has been
talked about
before.
>
> When
Concurrency
absorbs most
of the still
useful
EJB-based
services in an
CDI version,
EJB-lite can
be safely
pruned from
the Web
Profile, IMHO.
_______________________________________________jakartaee-platform-dev mailing listjakartaee-platform-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|