[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] : Additional profiles
|
> 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.I don't think
it's unreasonable to move MP Config to Jakarta. I agree with Emily's
earlier comments -- I don't want to see a fork of MP Config in Jakarta.
But, if it makes sense to move MP Config to Jakarta in order to provide
a more controlled, more stable development process, I would be okay with
that direction.
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)From:
Mike
Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>To:
jakartaee-platform-dev@xxxxxxxxxxxDate:
03/25/2021
09:39Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] : Additional profilesSent
by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx>
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 On 24. 3. 2021, at
23:08, Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
wrote: 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 On Wed, Mar 24, 2021
at 11:40 AM Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>
wrote:What is your idea?
How shall we deal with Config in Jakarta EE? -- Dmitry On 23. 3. 2021, at
23:49, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
wrote: 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 On Tue, Mar 23, 2021
at 5:11 PM Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>
wrote: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 On 23. 3. 2021, at
15:32, arjan tijms <arjan.tijms@xxxxxxxxx>
wrote: 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 On Tue, Mar 23,
2021 at 2:59 PM Werner Keil <werner.keil@xxxxxxx>
wrote:-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
Von: arjan
tijms
Gesendet: Dienstag, 23. März 2021 14:52
An: jakartaee-platform
developer discussions
Betreff: Re: [jakartaee-platform-dev] [External] : Additional
profiles
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:
Jakarta
REST
Jakarta
JSON-P/B
Jakarta
CDI
Jakarta
Security
MP
Config
Following this
Core profile, both the rest of EE and the rest of MP could depend
on it.
Thoughts?
Kind
regards,
Arjan
Tijms
On
Tue, Mar 23, 2021 at 2:48 PM Reza Rahman <reza_rahman@xxxxxxxxx>
wrote:
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 list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev