Trying to match release cadence is an inevitable challenge when you have two efforts that are so closely related. That's why there is a concern with compounding the problem with introducing circular dependencies.
The reason the one way dependency we have right now is not an issue is largely because the Jakarta EE APIs are in relatively stable/mature state. I think we would want to make sure that is true of any MicroProfile technologies that are included in Jakarta EE. It is also the case there is an ability for specifications to have independent releases. I believe one of the objectives post Jakarta EE 9 is to have more of those anyway.
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: Thomas Watson <tjwatson@xxxxxxxxxx> Date: 1/20/21 9:12 AM (GMT-05:00) To: cn4j-alliance@xxxxxxxxxxx Subject: Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Just to clarify. You are stating that a future release of MicroProfile has no need to depend on a future version of MP Config? I assume the answer is yes, future MicroProfile releases will have some need to use new features coming in a future MP Config spec. Moving MP Config to Jakarta now puts a blocker in front of MicroProfile releases while they wait for a Jakarta release that includes the new MP Config. I would be surprised if that is acceptable.
Now Jakarta could decide to modularize and release an updated MP Config spec ahead of the full Jakarta release that includes it, unblocking the MicroProfile release. But if that is possible then surely MicroProfile could do the same such that the future Jakarta release can depend on the new MP Config.
Tom
----- Original message -----
From: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
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 5:09 PM
Moving MP Config to Jakarta will not create circular dependencies as Jakarta does not depend on MP releases. MP releases depend on Jakarta releases. When moving a MP Spec to Jakarta, this MP spec will no longer be part of MP releases.
Thanks
Emily
I agree with everything you state except need to move the MP config itself to Jakarta. So far I don't understand why we have to move working groups to do this. I read that there may be some circularity issue that would pose an issue for building the specifications? Would not moving MP config to Jakarta also introduce a circularity issue for future MP releases that now need to consume the latest from Jakarta?
Tom
----- Original message -----
From: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
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 2:49 PM
I meant that they were originally planned to be done for Java EE 8, via the JCP. So there was nothing to transition ;)
It's a past statement. I don't think there is much value to discuss what might have been included in Java EE 8.
I disagree with forking and changing namespaces. It is unnecessary and causes unnecessary migration.
I also disagree with two configs existing in both Jakarta and MicroProfile. It is a recipe for confusion and disaster.
I think moving MP Config to Jakarta while retaining the same namespace is a better option.
Thanks
Emily
Hi
Yes, many and APIs were not intended to ever transition to the JCP.
I meant that they were originally planned to be done for Java EE 8, via the JCP. So there was nothing to transition ;)
Kind regards,
Arjan Tijms
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
--
|
