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
Hello Everyone!

I like the idea of not using the MP namespase on JakartaEE, I mean JakartaEE should not have a dependency on MP in any way

Moving the MP API's to JakartaEE sounds good in paper, but that's a lot of work and discussions for every API and that's what led us to this.
Getting those API's back to MP for further development sounds complicated, so if some API is moved to JakartaEE I think that the best is to continue on JakartaEE 

I see MP as an optional complement to JakartaEE that extends the current API's, so What about having something like a LTS version of the MP API's ?

So for example MP Wombat 2.0 is a LTS version that all vendors should support, but MP Wombat 3,4,5 are Experimental and MP Wombat 6 is another LTS Release (this can be at API level or at MP umbrella level )
The only thing about this approach is how the vendors can support both versions, the LTS and the experimental... but maybe we can figure out something for that.

In this way, the vendors can choose between supporting only the LTS versions of the API or keep working on the experimental versions too.

The LTS version can be useful for those who write libraries / frameworks, because they will have a stable dependency on MP that all of the compatible vendors support for the next X years without the need of updating the dependency every time an MP API's have breaking changes.


Jorge Cajas
+502 54754892


On Thu, Jan 14, 2021 at 5:54 AM hantsy bai <hantsy@xxxxxxxxx> wrote:
I really like these suggestions, it is better there is a sandbox or experimental group which is responsible for incubating new specs, quickly forward and allows change more frequently,  and accept incompatibility in the incubating stage, when it is involved and becomes mature, adopt it or some features of it into the Jakarta EE.

In one word, a side project under ee4j for theses, but I am not sure if it should be the responsibility of MP.

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach

GitHub: https://github.com/hantsy

Twitter: https://twitter.com/@hantsy

Medium: https://medium.com/@hantsy


On Thu, Jan 14, 2021 at 6:04 PM 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

Back to the top