[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
|
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
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
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.
I believe that there is value in public discussion and tracing.
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 --------
Date: 1/19/21 9:47 AM (GMT-05:00)
Subject: Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Hi,
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@xxxxxxxxxxxTo 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
