Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Here is where I would like to see the discussion from the MP side before entertaining that a fork is absolutely necessary.  The MP working group is not at all open to discussing the possibility of identifying a small subset of MP that can be considered for maintaining in a backwards compatible way moving forward?
 
It seems like a natural progression for any API is that it gradually becomes stable and hopefully is able to be evolved in backward compatible ways.  Can we discuss this possibility for some small subset of MP such that it is appealing for Jakarta to consume as-is from one release to the next?

Tom
 
 
 
----- Original message -----
From: Rudy De Busscher <rdebusscher@xxxxxxxxx>
Sent by: "cn4j-alliance" <cn4j-alliance-bounces@xxxxxxxxxxx>
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Date: Tue, Jan 19, 2021 12:34 PM
 
I do not see any solution other than a fork with a name change (how unfortunately it might be) possible. MicroProfile has decided that it will not maintain an LTS or other specific version for Jakarta or any other group.

A fork of, for example, MicroProfile Config to Jakarta Config, is the ONLY available option left in this case. And for those who do not want to change the package name, they still can use the MicroProfile Config names (and address potential breaking changes in the next release). Those who change to package names to the new Jakarta Config will have the long term stability of the API and spec.

Rudy
 
On Tue, 19 Jan 2021 at 19:27, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
An unintended cord has been struck.  I hoped that this alliance concept was not going to disrupt the governance of the independent working groups.  I am glad to hear we are in agreement.  I did not realize I indicated otherwise.  I assume any movement or inclusion of technologies between the two working groups, if required, would be voted on and agreed to independently by the two working groups.
 
Given that, what restrictions do we have for the possible solutions when discussing how future Jakarta specification APIs can be included in future MP releases or vise versa?

Tom
 
 
 
----- Original message -----
From: Mark Little <markclittle@xxxxxxxxx>
Sent by: "cn4j-alliance" <cn4j-alliance-bounces@xxxxxxxxxxx>
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Date: Tue, Jan 19, 2021 12:06 PM
 
+1
 
On 19 Jan 2021, at 17:32, Amelia Eiras <aeiras@xxxxxxxxxxxxx> wrote:
 
I have seen initiatives such as the potential CN4J alliance solely as a communication alliance. 
Communicating synergies efficiently is the hardest thing in any software collaboration.   
 
To do so, the "wishful" initiative's core must be written to not to disrupt the governance of the independent Working Groups & the external technologies (outside the EF foundation) that might consider evaluating if there is a value through to allow for investment and reputation as belonging states the project & ecosystem supports the outcome. 
 
As stated in the MP Community call on Dec 15th, the 18 minutes dedicated to creating the cn4j mailing list [MPWG Update] CN4J Alliance Co-Create CN4J mailing list, nothing might come from an alliance btw the current 2 groups. 
 
I believe that there is value in public discussion and tracing. 
 
 
On Tue, Jan 19, 2021 at 8:17 AM Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
It is unfortunate, in my opinion, that we are talking about changing the WG responsible for the evolution of an API to address a build issue.  If the CN4J alliance agrees this is a problem that is best solved by moving the evolution of the API to Jakarta then that is how we may have to proceed.  I still don't see why that decision has to result in a namespace change to jakarta.  I only see a namespace change as unnecessary and disruptive for no gain.
 
Tom
 
 
 
----- Original message -----
From: reza_rahman <reza_rahman@xxxxxxxxx>
Sent by: "cn4j-alliance" <cn4j-alliance-bounces@xxxxxxxxxxx>
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Date: Tue, Jan 19, 2021 9:26 AM
 
I think there are also other practical problems that arise from trying to include a MicroProfile specification as-is without making them essentially a Jakarta EE specification - such as Jakarta EE specific, likely bi-directional changes and integrations. A couple of examples would be using Configuration in EL as well as Jakarta XML deployment descriptors as well as getting JWT to work with Jakarta Servlet/Jakarta Security. This of course in addition to the issues of release cadence matching and circular dependencies. The backwards compatibility issues pose problems as well. If Jakarta EE wants to further evolve a feature after MicroProfile breaks backwards compatibility, there is no choice but to effectively need a fork anyway and move that forward.
 
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.
 
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
 
 
-------- Original message --------
From: arjan tijms <arjan.tijms@xxxxxxxxx>
Date: 1/19/21 9:47 AM (GMT-05:00)
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Subject: Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
 
Hi,
 
On Tue, Jan 19, 2021 at 3:31 PM Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
1) Keep the namespace as-is in MP and keep the API evolving in MP in backward compatible way moving forward.  Jakarta can then pick up new versions as it see fit.
 
 
How would this work for products that support both EE and MP? Especially when we know that this is the majority of the products out there?
 
Having config files picked up by two different MP versions that both live in the same runtime, potentially even the same implementation (so the same implementation packages), I'm not really looking forward to code and maintain such a setup.
 
Kind regards,
Arjan
 
 
_______________________________________________
cn4j-alliance mailing list
cn4j-alliance@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cn4j-alliance
 

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

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

Back to the top