Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: : Additional profiles

I will kick off a Google Doc somewhere on one of the Eclipse drives to collaborate on fleshing out the proposal.

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Reza Rahman
Sent: 31 March 2021 13:52
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [External] : Re: : Additional profiles

 

Who can sponsor? If it materializes, the Jakarta EE Ambassadors would certainly like to help with option 2. This is currently our official joint position though we are waiting for survey input to understand what end users truly want.

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 31, 2021, at 7:39 AM, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:

 I am ready to sponsor option 2. Can do it in collaboration with Steve and/or other volunteers.

 

-- Dmitry



On 31. 3. 2021, at 12:59, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

 

In the initial CN4J alliance discussions it was suggested that to propose something at the alliance level a proposal needed a sponsor from both working groups. Hence the discussion below.

 

I assume the volunteers will suggest a way forward for how to incorporate MicroProfile Config or something related into Jakarta EE and that will be discussed at CN4J and then voted on at each working group?

 

There seems to be two proposals on the table that need development and submitting to the alliance discussions (I paraphrase).

 

1.      Move MP Config as is to Jakarta and retain the microprofile namespace

2.      Move MP Config to Jakarta changing to Jakarta namespace and doing more standardisation work.

 

Steve

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Dmitry Kornilov
Sent: 31 March 2021 11:49
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [External] : Re: : Additional profiles

 

I don’t completely understand what we are talking about. What volunteered persons will do exactly? I would like to participate on the proposal work too. I see it as all ideas are welcome and we should not limit a number of participants. 

 

-- Dmitry




On 31. 3. 2021, at 12:43, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

 

Steve, 

In my previous email, I volunteered myself from the MP side and Scott from the Jakarta side. I think you are in Jakarta WG not MP WG. You might also represent Jakarta WG. Anyway, we can work together to get this proposal under CN4J.

 

See below:




 

 

 

On Wed, Mar 31, 2021 at 9:45 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

I am happy to be the MP sponsor for the alternative of further standardisation and moving to the Jakarta namespace. I will seek a co-sponsor on the Jakarta side.

 

Steve

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Scott Stark
Sent: 30 March 2021 20:44
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [External] : Re: : Additional profiles

 

Yes, so that would be the options to move config without a package namespace change.

 

Two others (or more) need to propose the alternative.

 

On Tue, Mar 30, 2021 at 1:11 PM Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

I would like to volunteer to take this to CN4J from MicroProfile. Scott, would you want to be the co-advocate from Jakarta? We can then start a conversation in next week's CN4J call.

 

Thanks

Emily

 

On Tue, Mar 30, 2021 at 5:02 PM Scott Stark <starksm64@xxxxxxxxx> wrote:

One of the things that has been discussed in CN4J is the criteria for creating an item for a vote when it affects both working groups. I thought that it required that there be an advocate from each working group to present the proposal. That is something that should be started. It seems there should be at least two competing proposals.

 

On Tue, Mar 30, 2021 at 4:14 AM Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:

I am not sure that we are in agreement. There is still option to have a minimal Jakarta EE Config spec and extend it in MP Config. We need to discuss all available options, select one which suits us the best and vote. I don’t know which meeting should we use for it. It will be a technical discussion, it’s not for the steering committee. We will bring it there when we have some solid offer. It can be a platform meeting if we need a public discussion or spec committee if we want to limit a number of participants to spec committee members only. Both options are fine with me.  

 

-- Dmitry

 

On 29. 3. 2021, at 23:17, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

 

I think this matter needs to be discussed under CN4J. Hopefully, we discuss this in more details as the next agenda item.

Personally, I think the most important matter is not having two config. I think we are in agreement.

 

If MP Config is directly moved to Jakarta EE without changing namespace, this will involve less work and will pose no impacts to end users but demonstrating strong collaboration between two WGs.

 

This approach might be easier to be accepted by MP as it has not got much impact (just removing MP config from platform release but got it from Jakarta). Most MP specs depend on MP Config and they do not need to change much either. 

 

My 2cents.

Emily

 

On Fri, Mar 26, 2021 at 12:33 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

Hi Emily,

 

I agree with you except I believe there should be a namespace change and maybe some additional standardisation work. I believe the MicroProfile WG could adopt the new version in the new namespace when MP moves to the Jakarta namespace, however that is a decision for that working group.

 

Steve

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Emily Jiang via jakartaee-platform-dev
Sent: 26 March 2021 12:06
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] : Additional profiles

 

Since I was involved in most of the Config revolution, here is what happened and what I would like to see to happen in the future.

 

Ondro was right that we did try to evolve Config under JCP for some time - Mark Struberg and I were the spec leads. Before we had a chance to do a release, I personally observed multiple issues with that, e.g. it was very difficult to maintain both MP Config and JSR Configuration and keep them in sync. It will be very bad to have two versions of Config laying around and go out of sync and then confuse end users- which features exist in MP Config, which features exist in JSR Config. Therefore, I am strongly -1 to split config to pieces and make one part live under Jakarta EE and the rest on MP. MP Config is not big to start with.

 

After Java EE moved to Eclipse Foundation, JSR Config lost its foundation. It did not make sense to keep JSR Config under JCP any more. After getting approval from Config EG, I withdrew Jakarta Config from JCP with the intention to bring Config under Jakarta EE. I think the destination of Config should be under Jakarta EE so that other specs can benefit from it. I see Config and CDI as the core technologies for other specs to rely on.

 

I think moving MP Config to Jakarta EE should be discussed under CN4J, followed by a vote by both WGs. I also prefer to keep the microprofile namespace to simplify the move (MP and Jakarta EE live under one roof) and it is easier for end users as well without any migration need. What do others think?

 

Emily

 

On Fri, Mar 26, 2021 at 11:30 AM Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:

In my opinion, a huge portion of Jakarta EE users would welcome just moving MP Config as it is to Jakarta EE and let MicroProfile to depend on it. From the perspective of the MicroProfile project, the situation a year or so ago, as discussed for example here on the ee-community ML. Back then, MicroProfile wanted to be able to evolve Config faster than expected within Jakarta EE. I think that one year later, there's not much need to evolve Config that fast and it's best if it's moved to Jakarta EE.

 

Alternatively, a reasonable part of MP Config can be moved to EE, with enough extension points to refactor the existing MP Config on top of it as an extension. Personally, I believe that all Jakarta EE APIs should provide enough extensions to allow building innovative solutions and APIs on top of it, which could be later transferred to the Jakarta EE spec.

 

Ondro

 

št 25. 3. 2021 o 16:54 Reza Rahman <reza_rahman@xxxxxxxxx> napísal(a):

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

  

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

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev



-- 

Thanks
Emily



-- 

Thanks
Emily

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev



-- 

Thanks
Emily

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev



-- 

Thanks
Emily

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!GqivPVa7Brio!IFnMEjK0RJ3Mlag14GPGyl-vA1OrqCmgeuGUEoNFb3j3w8_p7Zfl6I-FInQW0ZJuvF1M$

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


Back to the top