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

I agree with Scott's points too. Especially those that talk about process and legal issues. Because there are different goals and history behind MicroProfile and Jakarta EE, it's good to keep the processes separate to avoid eternal disputes and losing time on with things we'll never agree on.

I think that it's important to establish CN4J as a common forum for both MicroProfile and Jakarta EE as Steve says, where we informally and asynchronously coordinate evolution of MicroProfile and Jakarta EE so that there's as little confusion among the users (developers that consume one of them or both) as possible. We should struggle to make it simple for developers and easy to use, no matter if they want to use Jakarta EE, MicroProfile or both of them, or they simply don't care and want to write apps with a good API (in the latter case, we risk they will start using something else, e.g. Spring, or vendor-specific solutions, and we all lose).

In my opinion:
  1. The governance of MicroProfile and Jakarta EE should stay separate
  2. We should have a process for moving specifications from MicroProfile to Jakarta EE. Or vice versa, although it makes much less sense. Maybe for standalone Jakarta specifications like MVC or NoSQL that haven't made it yet to any Jakarta EE profile
  3. We should have a vision how the specification moved from MP to EE (or vice versa) should continue to be consumed by the original umbrella so that the "donating" project is happy with it and knows what to expect, and their community of users knows what to expect
My ideas how to approach point 2 and 3

For point 2, I saw that recently there was a consensus to change the package names  to match the schema of the target project (e.g. org.eclipse.microprofile.* changes to jakarta.*). There also were several surveys that show that a lot of users would expect that. Jakarta Config spec already works with this and plans to adopt MP Config with the changed namespace. I think we should build the "donation" process around that.

For point 3. changing the namespace is also a way to allow users using the old namespace and the original project to continue supporting both namespaces. E.g. MP can adopt Jakarta Config while also include the latest version of MP Config. It's not wise to continue development in both namespaces but it's at least possible to release patch versions of the original namespace for users that can't afford to refactor their source code for the changed package name but need some small enhancements or fixes here and there. On the other hand, it should also be possible to use Eclipse transformer or similar technology to transform the namespace used by the app at build time or on the fly. An implementation can choose which of the options to offer. The important thing is that vendors have more options to choose from and all of them are pretty good for users.

Ondro

ut 24. 8. 2021 o 16:42 John Clingan <jclingan@xxxxxxxxxx> napísal(a):
I have to agree with these points as well. I’d like to generally emphasize that the  organizational and process differences. The discussions tend to highlight the technical aspect.

It is also unclear to me what the criteria are for moving a spec from MicroProfile to Jakarta. Concurrecy I get. The others are not so clear to me. Moving a spec means that the non-technical aspects of a project will be changed as well. Also, are there specifications that would benefit from being moved from Jakarta to MicroProfile based on what Scott outlined below?

On Aug 12, 2021, at 2:23 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

This is all incredibly well said, Scott.  Huge +1 to all 8 points.


On Aug 11, 2021, at 8:09 PM, Scott Stark <starksm64@xxxxxxxxx> wrote:

Tl/Dr; Red Hat is opposed to this suggestion for several reasons, not the least of which is that it contradicts one of the fundamental ideas agreed to in the CN4J messaging statement.


Reasons for opposing this approach:

  1. There are fundamental organizational, operational and funding differences between the working groups
    1. MicroProfile has a flattened governance structure to help it deliver more quickly 
    2. It is our belief that MicroProfile is more transparent, with all meetings recorded and publicly available
    3. There is a fundamental difference in the fee structures and forcing MP into Jakarta would entail a huge jump in cost to achieve the same level of participation
    4. Red Hat’s intent is to help minimize the overhead introduced by the EFSP/working group to behave as much as possible like the former open source project
  2. There is a fundamental difference on the patent license type, and the recent vote indicated there is no clear majority opinion on this in the Jakarta working group.
  3. It does not introduce any time savings as you are simply replacing the MicroProfile state with an incubation state. You still have to argue over when a specification is ready to migrate and you have to exclude non-incubation specifications from introducing dependencies on incubation specifications. There is a benefit to having separate namespaces for APIs in different states of development.
  4. Jakarta EE is yet to prove itself as a vehicle which can deliver stable technologies, let alone be a safe home for fast moving innovation. To date all that has been delivered are repackaging of Java EE 8. Six to 7 years of no functional Java EE progress means Jakarta will have difficulty reinventing itself as a lightweight cloud native platform versus more mature and adopted cloud-native runtimes like Spring and Node.js.
  5. There seems to be a more restrictive view towards compatibility requirements in Jakarta than MP. Recent internal steering committee discussions would seem to indicate that some Jakarta members would like to go so far as preventing non fully compatible implementations.
  6. MP formed as a community with no barriers to entry that leveraged key annotation oriented specifications from EE to build micro service/cloud native focused specifications. While perhaps contested, our view has always been that MP supports 'based on' implementations of its specifications as well as 'based on' Jakarta dependencies as there should be no requirement for transitive compatibility requirements. There are members in MP that would be alienated with a fold of MP into Jakarta without a new sub-working group structure, the introduction of which brings us back to a Jakarta/MP structure.
  7. Whilst MP utilises some Jakarta EE specifications, there are MP implementations that don't require Jakarta EE compatible implementations under the covers, so that's another change we'd be pushing on them with a merge. Further, there are MP based implementations that have no ability to reasonably implement full specifications because it breaks their usecase; bridges into cloud serverless environments is one example.
  8. This continued rehashing of an agreed on working groups structure will ultimately lead to a fracture of Jakarta/MP into two disconnected groups with duplicated APIs ala the Hudson/Jenkins debacle.

On Aug 11, 2021 at 6:17:50 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
_______________________________________________
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

_______________________________________________
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