Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Bootstrapping the JESP operations
Scott Stark wrote on 3/19/19 7:51 PM:

A number of our spec leads/previous Java EE EG members have been asking about how the specs would resume work once the JESP was completed. Their questions bring up some questions regarding how the new Jakarta EE spec projects become fully functional.

An example of one question was whether the current Java EE specification projects are going to have any of the post EE 8 open issues migrated over to their Jakarta EE counterpart? One example is:

where there are references to previous Java EE specification text, and design discussions are happening. Given that such issues have not simply been moved over to the https://github.com/eclipse-ee4j/jta-api/issues Jakarta EE project, the question was what restrictions if any would there be for interested parties to reconstitute such issues in the new Jakarta EE project?
We haven't migrated them because we've had no place to migrate them to.

I assume we'll create new specification repositories under existing projects, to contain the specification documents and the issues.  We can then migrate these issues to these repositories.


There was a PMC statement about initial EE4J project contributions:

That outlines a number of project process level details that are not captured in the current JESP operations document. The questions that were raised by a previous JAX-RS EG member was in regard to a PR:

That was proposing a change to a public API that while made sense, would basically change the behavior for some edge cases.

The PMC statement suggests that only critical bugs should be fixed and incorporated into the EE4J_8 branch that is the basis for the Jakarta EE 8 platform release.

Our EG member was questioning what process was being used to mange the changes going into the EE4J_8 branch as there have been javadoc modifications mentioning a specific behavior which was vague before, and there was validation by a TCK. They were looking for a detailed guideline on what is allowed and what is not, which could be circulated to the project committers.
Yes, more guidance would be good.  Do you want to try to draft a first version?

I think we were trying to limit "general bug fixing" just to reduce the risk for this first Jakarta EE release.  I don't think bug fixes to the implementations otherwise conflict with our goals for Jakarta EE 8.

Changes to the javadocs to clarify the specs would fall under the JCP MR errata process, or the JESP Service Release process.  I agree we should decide explicitly whether we want to allow that level of change between Java EE 8 and Jakarta EE 8.  Perhaps it would be sufficient to clearly document all such changes as part of the first release review for the Jakarta EE 8 specs?  The Specification Committee could decide on a case by case basis whether such a clarification to the spec is acceptable.

It seems like we need a bootstrapping section in the operations guide that deals with these types of questions as well as others I have gotten regarding specification text, unavailable TCKs like JAXB, etc.
The JAXB TCK will be available.  But I don't expect the contributed JAXB TCK to be relevant for Jakarta EE 8 since I expect Jakarta EE 8 to require Java SE 8, which includes JAXB.

Beyond that, why don't you suggest wording you would like to see added to the operations document to address your issues?

Unless the initially approved JESP and related content is able to address existing issues, we don't see we are ready to approve a JESP.
So you want to see a finalized and complete operations document before approving the JESP?  Do you fear that there are issues not yet known that will come up while finishing the operations document, but that will require updates to the JESP?

Back to the top