| Here is my reply to Ed’s vote on the straw poll thread
—
On May 12, 2025, at 4:21 PM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
I'm a bit unclear how to cast a vote for this. First, I will make an assumption that you are asking the members who would be voting for a working group resolution -- which I think would be the Steering Committee member representatives -- of which I (as a representative for Oracle) am a member. It might also be that this vote is for committer members, a group for which, I am not a member (though I do seem to be listed as a 'contributing' member for whatever that is worth).
Correct.As part of my consideration, I want to remind my fellow members that in a steering committee resolution ballot, Abstain implies does not simply no preference. Importantly, Abstain removes that members vote from any threshold considerations. Therefore, I do not interpret Abstain as merely "no opinion.”
Agreed As I have previously stated in live meetings, regardless how Oracle might consider any one of the proposed name-space alternatives that have been discussed, it is our top preference that the two working groups merge and work cooperatively toward a common goal. It is also my recollection that Eclipse representatives have previously asserted that one working group cannot force decisions on another working group. Therefore, any consideration of an acceptance requirement on Jakarta EE may or may not actually be enforceable.
Yup. Specifically, in regard to the technologies, as was discussed in live meetings, there may be cases where this could well make sense (I think an example someone raised was MicroProfile REST Client and the potential to refactor it with the Jakarta REST specification and logically combine the classes as made sense to that revised specification), while in other cases, perhaps this would be too disruptive.
Understood Oracle is strongly in favor of combining the two working groups. We believe it is best to follow the same path previously followed: Contribute what we have to Jakarta EE, then trust that the combined committer teams will "do the right thing" just as we have always done.
Gotcha. Therefore, Oracle is -1 (against) a resolution clause prohibiting (or implying a prohibition on) the Jakarta EE working group from making a namespace change to any technology contributed from the MicroProfile working group, currently under org.eclipse.microprofile.
Thanks Ed. What I’m trying to get to is out-of-band ahead-of-time agreements. While one WG cannot force another WG to do something, I’m hoping we can agree ahead of time what the namespace decision will be.
Trying to figure this out in one straw poll is understandably difficult, but it’s an attmempt to move the discussion forward. It does sound like the project committers have a strong say in the namespace. I don’t know if there is a policy written down within Jakarta EE Working Group that the namespace must be Jakarta.*. Also, if the project agrees on a non-“Jakartaee.*” namespace, can this be overridden by the spec committee or steering committee? N.B. This does not imply that Oracle will vote one way or another on whatever resolution might be ultimately be put forward for consideration by representatives of the MicroProfile Steering Committee.
Thank you,
-- Ed PS if I was incorrect and you are asking for committers to vote, please let me know.
On May 2, 2025, at 12:13 PM, John Clingan <jclingan@xxxxxxxxxx> wrote:
At this week's Live Hangout, we continued to discuss the MicroProfile->Jakarta EE Proposal. To keep the eventual resolution "simple", the idea is to come to agreement "out of band" and "ahead of time", where possible. That way, we have a better idea of what the resolution encapsulates. We are going to discuss these items on the microprofile-wg email alias, followed by non-binding straw polls. These are areas where we currently do not have agreement. Many of the MicroProfile Working Group members are also Jakarta EE Working Group members. Not all Jakarta EE Working Group members are MicroProfile Working Group Members, but I'd like to encourage them to participate in this discussion. The first topic is the MicroProfile namespace for existing MicroProfile specifications, which is currently org.eclipse.microprofile. This is arguably the most impactful discussion because it could result in a breaking change for developers and our customers. The question is whether or not this namespace remains if the MicroProfile->Jakarta EE resolution passes. I have seen a few options discussed so far:
1) Keep org.eclipse.microprofile
2) Change the namespace to jakarta.*
3) Change the namespace to jakarta.microprofile.*
I'd like to give a couple days of open discussion before opening up a separate straw poll email thread. Please respond to this thread discussing benefits and concerns. Thanks!
|
