I definitely think such an analysis and blog entry would be useful. It would help end users and demonstrate a good faith effort on part of decision makers. The write-up could end with a SurveyMonkey poll so that people could easily express what tradeoff they really prefer.
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: Edwin Derks <ederks85@xxxxxxxxx> Date: 1/19/21 3:59 AM (GMT-05:00) 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
Would it make sense to start writing down the possibilities/scenario's that we can think of? With the aim of steering this good discussion into concrete and understandable actions?
1. Jakarta EE has a specification that MP wants to adopt. This is the current situation for MP with the Jakarta EE base, will it stay that way? 2. MP has a specification that Jakarta EE wants to adopt, e.g. Config. What happens? Fork? Namespace? Other...? This is under discussion now. 3. Both Jakarta EE and MP share the same specification, but one of the platforms is in need of a change. There is only one specification project. Fork? No fork, but adopt change in both platforms after achieving consensus between WG's? 4... 5...
Are we in need of a Specification Adoption process? :)
Edwin
Isn't it the case that what was included was actually Java bindings for non-Java specifications (that had no circular dependency on Java SE/EE at all)? Given that these were from organizations different from the JCP, was there any other ways of including them (so forming an alliance like this one would not have been practical)? Also, I believe these were all pretty stable specifications that never changed once included, not to mention they all had backwards compatibility guarantees. I don't think the MicroProfile case is really the same and there are more possibilities that should be considered.
That said, I don't think this is a black/white issue. Nonetheless it is a very important matter that should be decided carefully and with strong consensus. In such cases, my view is that it is best to gather very broad input such as through an open poll/survey to understand what users really prefer. Each time I have done so informally myself, the outcome has been that the most amount of people expect MicroProfile APIs to be rolled into Jakarta EE including the namespace. I suspect this has much to do with how users that I am able to reach still perceive the relationship between Jakarta EE and MicroProfile, which I don't think puts either effort in an altogether unfavorable position.
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 -------- Date: 1/18/21 7:11 PM (GMT-05:00) Subject: Re: [cn4j-alliance] MP apis and "graduation" to Jakarta EE
Yes, we will most certainly disagree that Jakarta could not consume an MP specification under the terms discussed for the config example, which included moving its maintenance to Jakarta with no further work under that namespace. Jakarta cannot be some special gating WG or there is no point to having an alliance of working groups. A consistent platform does not require a single package namespace. W3C, OMG, etc. are simple examples of external namespaces that have been imported previously. On Mon, Jan 18, 2021 at 12:22 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
We’ll likely have to agree to disagree on this then
😊 as one of my key goals for Jakarta EE is to deliver a consistent platform to the developer.
Some consequences if you retained the io.microprofile namespace when moving a spec to the Jakarta WG.
First MP WG would have to agree to not further develop the api.
Second it bakes api history into Jakarta EE. For example a new developer coming to Jakarta EE who knows or cares nothing for the history of MP Config needs to understand why the api isn’t in the
jakarta namespace. I feel Jakarta EE has enough of these baked in history issues e.g. why JAX-RS annotations aren’t bean defining etc. etc. without adding more. Will that future developer thank you for not doing the extra work?
Steve
Agreed, no reason to introduce extra work. The point of an alliance should be to allow for cross pollination without burdensome exercises like the javax to jakarta effort.
I think namespace updates lead to migration issues. When moving MP Config to Jakarta, the api jar maven coordinates would be updated. In this case, there is no necessary source code change required. In my opinion,
any migration would potentially reduce productivity and we should minimize it. Surely we could do better than Java EE to Jakarta EE migration.
I would still prefer a namespace change in moving to jakarta.
First and mainly for branding. I think developers should know from the namespace whether they are using a MicroProfile spec or a Jakarta spec.
Second for governance. I think each group in the alliance should have full control of specifications in their namespace.
Steve
A variation of what you propose Emily might be this; say we have a stable spec like config that we want Jakarta to start using. This spec is already in widespread use in both MP and EE containers. The current spec could transition to Jakarta without a fork
to preserve the existing namespace.
If at some point in the future, a new incompatible config is needed, that could be started in MP and evolved under a new namespace.
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.
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.
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
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.
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.
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
--
_______________________________________________
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
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
|
