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
Just getting back from a long weekend and jumping in mid thread.  If there are ~4 MP APIs that we think could be adopted by Jakarta then I think the one good option would be:

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.
2) If and when MP decides it needs to make a breaking change to the API then they create a new package for the API to live where they can make breaking changes going forward.  Other very successful projects use this approach when they introduce breaking changes (e.g. junit).
 
My thinking is that the MP APIs Jakarta wants are likely already to a stable point?  If that is completely off then perhaps this is not a great option.  Why break with the MP namespace before we even have a problem with compatibility?  There are likely other ways to overcome the compatibility issue.

Tom
 
 
 
----- Original message -----
From: Scott Stark <starksm64@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: Mon, Jan 18, 2021 9:55 AM
 
The spec has to live in a WG. CN4J is not a WG. Essentially you are arguing against the pull model and wanting to freeze the MP specification. At that point it might as well fork into Jakarta so the future maintenance occurs there. If at some point a new incompatible MP version is needed, it would need a new namespace.
 
On Mon, Jan 18, 2021 at 9:11 AM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
I think we will run into headaches with forking very soon. When two similar technologies evolve at a different speed independently, we are creating new problems and confusions for our end users.
 
Here is what I thought that could work.
 
Since we have established CN4J, we can lift MP Config and a subset of its essential APIs and have them hosted by CN4J. No breaking changes are allowed in these APIs. In this case, Jakarta EE can rely on these APIs. MP also consumes these APIs and deprecates its own identical copy. There will be no circular dependencies either.
 
I think we should be cautious with what specs are moved there. We should only move the specs that are absolutely needed by Jakarta EE, such as Config.
Thanks
Emily
 
On Mon, Jan 18, 2021 at 3:06 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

Yes this is why moving a spec to the Jakarta namespace when adopted by Jakarta EE I believe is a necessity.

 

There doesn’t need to be a huge increase in effort if the alliance can agree that the specification is mature and future evolution should take place in Jakarta EE. The MP platform can then switch namespace for the specification at a future major.

 

I actually don’t think this will arise too often. I only see maybe 4 core MP specs that could move to Jakarta EE in the medium term.

 

Steve

 

From: cn4j-alliance <cn4j-alliance-bounces@xxxxxxxxxxx> On Behalf Of Scott Stark
Sent: 18 January 2021 14:31
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

 

Thinking about it more, this would set up the same situation we just when through with javax. When the compatibility of the MP spec is changed and the package is updated to jakarta, the next Jakarta release would have a change in namespace. 

 

On Mon, Jan 18, 2021 at 7:53 AM Scott Stark <starksm64@xxxxxxxxx> wrote:

By immediately forking any MP specification into Jakarta when there is a desire to use it in Jakarta, we are increasing the effort without a demonstrated need. Until the compatibility requirements of Jakarta are broken, the MP specification should be used as is in order to minimize the effort. Even in the case of consistency across Jakarta specifications where additional requirements should be added, that could be done as an extension to the MP specification by describing the additional integration requirements around the Jakarta Security support for example. Only when that cannot be done without changes in the MP specification should that cause a need to fork.

 

 

 

On Thu, Jan 14, 2021 at 4:04 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

I’ve thought a lot over the last year about the relationship of MP and Jakarta and how apis should be consumed for each. I just thought I’d put this down as a conversation starter from my vendor perspective.

 

So some overall statements.

 

1.      Jakarta EE should not use the MicroProfile namespace

2.      Jakarta EE should adopt MP apis by moving them into the Jakarta namespace when they are mature

3.      MP can choose to add the adopted api back into their platform just like Jakarta REST today or can continue to evolve the api in its own namespace.

 

Why do I think this?

 

Jakarta EE has a focus on backwards compatibility while MicroProfile has the goal of experiment and innovate without backwards compatibility. Moving a Jakarta adopted api into the Jakarta namespace means the Jakarta team can ensure backwards compatibility.

 

Prevents developer confusion. Developers can know that when they import an api in the Jakarta namespace they get stability and backwards compatibility and when they import an api in the microprofile namespace that it may change between major releases.

 

Vendors like Payara can more easily support both platforms. Take for example the case of where Jakarta EE wants to adopt MicroProfile Wombat 2.0 but MicroProfile WG wants to keep evolving MicroProfile Wombat 3.0 to a completely new api. By moving namespace and creating Jakarta EE Wombat 2.0 Payara can support both the latest MicroProfile Wombat 3.0 AND Jakarta EE Wombat 2.0 delivering the needs of the different developer communities.

 

Platform consistency – when moving an api into Jakarta EE it may need to be evolved to ensure it is consistent with the rest of the Jakarta EE platform e.g. supporting Jakarta Security etc. This is likely not possible in MP.

 

Easier demarcation between independent groups. The groups are independent of each other and this enables each group to be in control of its own platform without the need to maintain an LTS or Profile on one side just for the benefit of the other.

 

The alliance is then more about minimising duplication of effort when creating and evolving specification and deciding where the creation and maintenance of a specification should live.

 

Thanks

 

 

Steve

 

 

_______________________________________________
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


--
Thanks
Emily
 
_______________________________________________
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