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.
----- 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,
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