+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
|
