Bootstrapping Proposals for Technical Alignment discussion #79
Conversation
|
|
||
| - API classes remain in `org.eclipse.microprofile` | ||
| - Once a specification is stable or "standard" it cannot be changed in a backwards-incompatible way | ||
| - some clear label or marker would need to be created to distinquish "standard" specifications |
There was a problem hiding this comment.
Alternative: MP Specification can be moved to Jakarta, keeping the original package name. That way it is clear when it becomes a "standard" specification.
MP umbrella still can combine spec from Jakarta and MP as it is now (with JAX-RS, CDI, ... coming from Jakarta )
There was a problem hiding this comment.
All MP specifications we have today, are useful in todays 'enterprise' development, so not only for micro-services. This is also clear by the fact that all vendors included MicroProfile in their 'classic' Java EE product.
There was a problem hiding this comment.
Moving home is not trivial. I prefer the graduation in MP and mark it as standard.
|
|
||
| # Long-term Effects | ||
|
|
||
| Under this proposal MicroProfile will become a predominately stable community. |
There was a problem hiding this comment.
MicroProfile will still be the place where innovations happen.
The MicroProfile umbrella can be seen as some kind of 'profile' (although not defined by Jakarta) so the pure MP implementation (like Helidon) can still have their place.
|
|
||
| # Open Questions | ||
|
|
||
| * If a stable specification depends on a non-stable spec, how does that work? |
There was a problem hiding this comment.
We need to differentiate between non-stable and backward incompatible.
| # Open Questions | ||
|
|
||
| * If a stable specification depends on a non-stable spec, how does that work? | ||
| * If MicroProfile needs to make a blanket breaking change (such as the recent pom discussion), how does that work? |
There was a problem hiding this comment.
Is this about the 'standard' MP specifications or the 'innovation' specs? For 'standards' spec, something similar as Jakarta EE 9 can happen, otherwise the standards Semantic versioning rules apply.
|
|
||
| * If a stable specification depends on a non-stable spec, how does that work? | ||
| * If MicroProfile needs to make a blanket breaking change (such as the recent pom discussion), how does that work? | ||
| * With both MicroProfile and Jakarta EE being focused on creating stable standards, the relationship between MicroProfile and Jakarta EE will become less clear. |
There was a problem hiding this comment.
Not when Stable MP Specs are moved to Jakarta EE, then it is still clear (with MP Umbrella as some kind of 'Profile')
| * If a stable specification depends on a non-stable spec, how does that work? | ||
| * If MicroProfile needs to make a blanket breaking change (such as the recent pom discussion), how does that work? | ||
| * With both MicroProfile and Jakarta EE being focused on creating stable standards, the relationship between MicroProfile and Jakarta EE will become less clear. | ||
| ** If you have a new idea where do you submit it? |
There was a problem hiding this comment.
Feature of existing spec -> Jakarta EE
new idea -> MicroProfile
| ** If if all unproven ideas are submitted in MicroProfile and never leave, how does Jakarta grow? | ||
| ** Will the intended synergy between the two become lost and eventually be two brands for the same inseparable thing? | ||
| * Does this create a circular dependency that could be difficult to manage? | ||
| * Could users find it difficult to understand which APIs are stable and when? |
There was a problem hiding this comment.
This will be clear when we move MP stable specs to Jakarta EE.
|
|
||
| Under this proposal specifications ready for standardization are proposed as Jakarta specifications via Creation Review defined by the Jakarta EE Specification Process (JESP). | ||
|
|
||
| - API is repackaged into the `jakarta` namespace as currently defined by the Jakarta EE Specification Committee |
There was a problem hiding this comment.
This will be very disruptive for the end users which are our main target. You simply don't do anything that harms your product.
There was a problem hiding this comment.
I actually think that makes sense. Take Config it is pretty stable I think it should be moved to jakarta and standardised in Jakarta EE 10. Similar for REST Client being part of Jakarta REST, Context Propagation should be part of the evolution of Jakarta Concurrency and Reactive Messaging (or something a bit like it) should become part of Jakarta Messaging.
Yes it is partially disruptive but it fits the model MP break stuff and move fast and Jakarta stable specs.
|
|
||
| # Open Questions | ||
|
|
||
| - When do we cut over to the `jakarta` version of the specification? |
There was a problem hiding this comment.
After it has proven itself that it is useful and no major, disruptive changes will be needed anymore. This will always be a tricky decision.
There was a problem hiding this comment.
Probably pretty obvious based on level of innovation and churn in the API and also Jakarta has to want to accept it
|
|
||
| Under this proposal specifications ready for standardization are proposed as Jakarta specifications via Creation Review defined by the Jakarta EE Specification Process (JESP). | ||
|
|
||
| - API is repackaged into the `jakarta` namespace as currently defined by the Jakarta EE Specification Committee |
There was a problem hiding this comment.
I actually think that makes sense. Take Config it is pretty stable I think it should be moved to jakarta and standardised in Jakarta EE 10. Similar for REST Client being part of Jakarta REST, Context Propagation should be part of the evolution of Jakarta Concurrency and Reactive Messaging (or something a bit like it) should become part of Jakarta Messaging.
Yes it is partially disruptive but it fits the model MP break stuff and move fast and Jakarta stable specs.
|
|
||
| # Open Questions | ||
|
|
||
| - When do we cut over to the `jakarta` version of the specification? |
There was a problem hiding this comment.
Probably pretty obvious based on level of innovation and churn in the API and also Jakarta has to want to accept it
| @@ -0,0 +1,33 @@ | |||
| # MicroProfile Becomes A Standards Initiative | |||
|
|
|||
There was a problem hiding this comment.
I feel Microprofile setting stable standards will naturally lead to competition with Jakarta EE. What if Jakarta EE doesn't want mixed package names do they just fork the MP standard into Jakarta EE and move namespace, now we have 2 "standards"? What if Jakarta EE likes some of the innovation e.g. Approaches taken in Reactive Messaging but not the specifics of the api do we again fork Reactive Messaging into Jakarta EE or try to change it in MP?
| @@ -0,0 +1,26 @@ | |||
| # Innovations Graduate to Jakarta | |||
|
|
|||
There was a problem hiding this comment.
This is my preferred approach. MP is upstream to Jakarta. Jakarta takes MP specs it wants, moves them to the jakarta namespace does any alignment and consistency work necessary to build a coherent jakarta platform and releases as Jakarta specs. I feel anything else will lead to tension. For example what is Jakarta EE needs changes to an MP spec to make it work better with a none MP spec where is the work done? Clear demarcation is the best option.
| Proposals in discussion: | ||
|
|
||
| - link:proposal-microprofile-becomes-standards-initiative.adoc[MicroProfile becomes a standards initiative] | ||
| - link:proposal-specifications-graduation-to-jakarta.adoc[Innovations graduate to Jakarta] |
There was a problem hiding this comment.
A third option is MP ceases to exist (as a package namespace) and Jakarta introduces a sandbox process where new apis can be experimented on and released before graduating to full stable specifications. Similar to how Java SE is handling things. All MP apis are moved to the jakarta namespace and future MP apis use the jakarta namespace from day one.
Created some rough context for us all to discuss technical alignment. After having gone through this myself, I am increasingly confident we do need to clear this away before any talk of a Working Group makes sense or could be positive.
The long-term effect of one vs the other is pretty extreme.
These proposals are not perfect and people should feel welcome to dramatically change them (not just tweak) as well as add others. They are both very rough and incomplete; I would view big changes as positive contribution to getting them in better shape. I was trying to get something together that could be reviewed and merged before Tuesday discussion with the idea others can build from here and suggest other visions forward.