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?
