Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Specification Project and Document progress tracking

Wayne,

I added DSOL to the bottom of the Raw tab, in your spreadsheet. I just put in  my best effort for the new name. I also went ahead and dropped it (for the purposes of the tracking spreadsheet) into the JSP project. If nothing else, it needs a Scope Statement. I wasn't sure what to do with Column J. Maybe you can fill that in?  I didn't look to see if I needed to make changes to any of the other tabs. If there is additional work you'd like me to do, for this sheet, please let me know directly.

The DSOL Spec. generates no API. The TCK test just verifies that the correct actions are taken in a JSP, with the proper input. For the purposes of Jakarta EE 8, the ballot will consist of the Specification Document and a TCK. There will not be a revised API JAR, and I don't think there will be any JavaDoc changes (specific to an API). This isn't an evolving spec and I suspect no one has much of an opinion on any of these contents. However, it is needed for Jakarta EE 8.

Just as a reminder: Jakarta XML Binding, Jakarta Enterprise Web Services, Jakarta Activation, Jakarta SOAP Attachments are not requirements of the Jakarta EE 8 specification. We can accept them into the fold of Jakarta EE and run them through a ballot, but they will not become requirements until Jakarta EE Platform moves to newer versions of Java SE. Lack of attention or acceptance of these four APIs should not block completion of Jakarta EE 8.

-- Ed

On 6/27/2019 3:23 PM, Bill Shannon wrote:
A few issues that Ed pointed out to me, and some questions about this spreadsheet...

The Debugging Support for Other Languages spec is missing.  I think it should be part of the JSP project.

The CDI, BV, DI, and Batch specs should be added to Specs by Project.

The discussion in email about Enterprise Web Services didn't seem to come to a definite conclusion.  I believe the implementation is part of the JAX-WS/Metro implementation.  Are we all ok with the spec and TCK being part of the Stable APIs project?

Some of the specs in this spreadsheet are not part of Jakarta EE 8.  Can we add a column to mark that?

While we're no longer required to change any of the acronyms, that doesn't apply to the trademarks, so we're going to need to change the name "javamail" everywhere it appears.  I assume we'll change it to "jakartamail", synonymously with "Jakartabatch"?  Or should those be "mail" and "batch" since almost none of the others use "jakarta" in the short name / id?

There's a comment on ee4j.batch about not transitioning the project.  What does that mean?


Wayne Beaton wrote on 6/18/19 9:26 PM:
I've created a new spreadsheet to keep track of the specification documents.

The sheet is based on the specifications documents that Bill provided. You'll notice two columns on the "Raw Data" tab labeled "Directory" and "File" that reference the contents of the ZIP file that I can't currently share with the group.

With the first pass, I've made what I believe are very good guesses at the names of the specifications. I'll adjust these as I go through the restructuring reviews. I'll likely also copy over the specification scope statements so that we have them all in one place (this feels like something that might be useful). Feel free to fix anything that I've missed.

I've added some columns to track that I've turned projects into specification projects, that we've gotten the necessary approvals to contribute the documents, and that we've contributed the documents. I'll update these columns as I work through these events.

I've started creating some pivot tables to show the data in different format. There's a pie chart on the "Spec Rights Acquired" tab that shows progress in our JCP Copyright License exercise. I'l likely tweak this chart's presentation a little; the number will increase over the next couple of days as we sort through the first batch of specification documents that we believe that we've acquired the necessary rights for.

The "Specs by Project" tab has a pivot table that shows the relationship between projects and specifications. I believe that what's there reflects reality. I used the Relationships chart as a guide in a few cases. Let me know if you notice anything that looks out of place.

I noticed in particular, that there are five specifications associated with the Jakarta EE Stable APIs project (the PMC decided today that there were only four). Note that I have an actual document for every entry in the "Raw Data" page, so everything there is real.

Comments welcome.

Wayne
--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.


_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee



_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

Back to the top