Eclipse Foundation

Processes…

It has been a lot of talk about processes in the Jakarta and MicroProfile community lately, so I just want to remind us all about this item from the Agile Manifesto.

Individuals and interactions over processes and tools.

https://agilemanifesto.org/


That said, some process is needed. Especially for work with specifications. In this post, I explain the Jakarta EE Specification Process and also think aloud about how the same principles could be applied to Eclipse MicroProfile.

The Jakarta EE Specification Process (JESP) is derived from the Foundation Specification Process (EFSP). The short version is that it specifies how long the voting periods (ballots) are for the various reviews:

  • Creation Review: 7 days
  • Plan Review: 7 days
  • Progress Review: 14 days
  • Release Review: 14 days
  • Service Release Review: 14 days

The entire process is visualized in the figure below.

Eclipse Foundation Specification Process (EFSP)

So, how fast can you develop a specification using the JESP?
Well, you will need to come up with a specification project proposal and submit it for review. This review may take up to 7 days to be finalized.

The next step is to present the release plan for the Jakarta EE Specification Committee for a Plan Review. This step is optional and meant as a means for the project to secure that you are on the right track. Let’s say we opt-in for this review which means another 7 days, i.e. 14 in total so far.

When your specification is ready to be released, you will submit it for a release review. This will take 14 days to complete and may run in parallel with the ratification by the Jakarta EE Specification Committee. The total amount of days in review for your specification will then be 28 days.

Without the plan review, we are looking at 21 days which is exactly the same as for any project following the Eclipse Development Process (EDP). Which applies to the e.g. the Eclipse MicroProfile project.

The difference between the governance model of Jakarta EE and Eclipse MicroProfile is that Jakarta EE is a working group and has a specification process in place for capturing the intellectual property before a specification is released. Whereas Eclipse MicroProfile is a standard Eclipse Foundation project with an ad-hoc specification process. As an Eclipse Foundation project, the project name has to be prefixed with Eclipse. As a working group, this restriction does not apply.

In the table below, I have summarized some of the similarities and differences and even taken the liberty to draw up how it could look like if a MicroProfile working group with its own specification process was established.

Jakarta EEEclipse MicroProfile
(as a project)		MicroProfile
(as a working group)
Specification ProcessJESPnoMSP (*)
Development ProcessEDPEDPEDP
Release Review14 days14 days14 days
Ratificationyesnoyes
Working Groupyesnoyes
Project NamesJakarta [spec]Eclipse MicroProfile [spec]MicroProfile [spec]
Specs Consumable by Jakarta EEyesnoyes
Specs Consumable by Eclipse MicroProfileyesyesyes

(*) Thinking aloud: MicroProfile Specification Process (MSP)

The MicroProfile Specification Process could be as simple as this: Adopt the EFSP with the following voting periods (ballots):
(…still thinking aloud…)

  • Creation Review: 7 days (as today according to the EDP)
  • Plan Review: 7 days (or optional as today)
  • Progress Review: 7 days
  • Release Review: 14 days
  • Service Release Review: 14 days

To sum up, I think the JESP has captured the essence of “Individuals and interactions over processes and tools” by being as lightweight as possible while still protecting everyone involved.

Signing in…

It’s been a week since I started as the Jakarta EE Developer Advocate at the Eclipse Foundation!

As you may have noticed, I am involved in almost any committee around Jakarta EE and enterprise Java in general and my new role has some implications for these engagements. I have listed them below and tried to give a reasonable explanation for each of them.

EE4J PMC

I have been a member of the EE4J PMC since its inception back in 2017, and for practical reasons served as the PMC Lead the entire time. According to the charter, we are supposed to rotate the leadership among the non-foundation staff members of the PMC. In order to minimize overhead, the PMC decided to stick with me as the lead until otherwise decided.

If the PMC wants me to continue in the PMC Lead position, the “non-Foundation staff” phrase will have to be removed from the charter. This has been put on the agenda for the PMC meeting on November 5th, so then we will know…

Jakarta EE Working Group Steering Committee

I have withdrawn from my elected Committer Representative seat in the Steering Group as this seat should not be held by anyone from the Eclipse Foundation. This position is currently up for election (hint hint: if you want to be involved, nominate yourself…).

Jakarta EE Working Group Specification Committee

The position I have in the Specification Committee is the PMC Representative. It is up to the PMC whether I should continue or withdraw. This will also be handled at the next PMC meeting on November 5th.

Java Community Process (JCP) Executive Committee

I have withdrawn from my Associate Seat at the JCP since the Eclipse Foundation is already on the committee. However, I will still be lurking around here as I will be the alternate representative for the Eclipse Foundation. 

The JCP Elections have started. Remember to cast your vote!