Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cn4j-alliance] [External] : Perspectives on technical relationship

Speaking from a personal viewpoint, not IBM's...

I think Dmitry's proposal has some merit and should be considered.  As our CN4J messaging presentation outlined, there are far more similarities between our two efforts than differences.  As more MP specs are considering the move to Jakarta (Config, Context Propagation (Concurrency), and REST Client), there have been some concerns vocalized along the lines of "what's left in MP?"  So, maybe it's time to start thinking about bringing these two communities together similar to what Dmitry has outlined.

I also have to say that it bothers me (and I know I'm paraphrasing) that Jakarta EE is for "stable projects" and MP is for "innovative projects".  I fought against that when we were preparing the CN4J presentation and it continues to bother me when I hear that type of connotation in our descriptions of the projects.  Jakarta EE is evolving from the old Java EE.  It has to in order to survive and thrive.  Look at Jakarta EE 10 -- we have 11 component Specifications with a Major version update (most of them are doing this due to breaking API changes)!  That doesn't sound like "stable, consistent for 10 years".  Maybe Java EE was the stodgy old programming model, but that doesn't mean that Jakarta EE has to follow suit.

Maybe we're not quite at the stage of following Dmitry's proposal.  But, we should start this effort with Config, Context Propagation, and REST Client and then re-evaluate whether it still makes sense to keep MicroProfile separate.

-- Kevin

On Wed, Aug 11, 2021 at 6:18 AM Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:
Below is my personal opinion.

It's hard to separate two standardization efforts in the same area. This separation is artificial, doesn't bring advantages to any of the parties and doesn't make sense in general. Instead of separation we should join these two efforts together. It will save us a lot of time which we can use more productively.

- Move MicroProfile project under Jakarta keeping all committers. Use it as an incubator for new and fast evolving specifications.

- Use Jakarta specification process. It's well established and proven to work.

- Move all MicroProfile specs to jakarta namespace. It's the most painful step. But MP 5.0 is going to adopt jakartified versions of Jakarta EE specifications anyway. If this change is done at the same time the pain will be significantly reduced.

- Keep MicroProfile brand.

- Keep MicroProfile platform.

Thanks,
Dmitry

-----Original Message-----
From: cn4j-alliance <cn4j-alliance-bounces@xxxxxxxxxxx> On Behalf Of David Blevins
Sent: Wednesday, August 11, 2021 12:43 AM
To: cn4j-alliance@xxxxxxxxxxx
Subject: [External] : [cn4j-alliance] Perspectives on technical relationship

I thought it might be useful for each of us to write our perspective on how we see the two projects align technically in principle.

The high-level Tomitribe perspective is basically:

 - We see Jakarta EE as the brand behind which we can offer more stability to customers.  We see MicroProfile as the brand behind which we can address parts of the market that are volatile.

 - We've deliberately not created anything in MicroProfile that would compete with Java EE (now Jakarta EE).  All specs are complimentary.  We'd like to see this "no duplication" and "no competing" principle last and be bi-directional.

 - We are happy to see specifications move from MicroProfile to Jakarta as needed.  The Jakarta version of the spec would be under `jakarta`.  The MicroProfile version would cease to be developed, but could still be shipped as frozen for a period of time.

None of the above should be confused with innovation.  We don't see that innovation stops on a spec, regardless of where it is in its lifecycle.

It's really more about volatility of emerging sections of our industry where things are created and obsoleted quickly.  By definition you can't create a stable spec on something that is itself unstable.  In the past we did all of this under one brand and that has its own set of disadvantages and risks.


--
David Blevins
https://urldefense.com/v3/__http://twitter.com/dblevins__;!!ACWV5N9M2RV99hQ!dayf82s4XlHJVRZp60Mom9XUFS9G7UwRVYyLdgKnGEoQlKUP8TNGmaDQjBSoZthnUNtQ$
https://urldefense.com/v3/__http://www.tomitribe.com__;!!ACWV5N9M2RV99hQ!dayf82s4XlHJVRZp60Mom9XUFS9G7UwRVYyLdgKnGEoQlKUP8TNGmaDQjBSoZtTms9Sn$
_______________________________________________
cn4j-alliance mailing list
cn4j-alliance@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://urldefense.com/v3/__https://dev.eclipse.org/mailman/listinfo/cn4j-alliance__;!!ACWV5N9M2RV99hQ!dayf82s4XlHJVRZp60Mom9XUFS9G7UwRVYyLdgKnGEoQlKUP8TNGmaDQjBSoZsm3WyWw$
_______________________________________________
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