• Batch and CDI Integration

• Proposals for Spec Updates

• TCK Coverage Needed

• Other TCK Enhancements

• Specification Document Format

• To open your own new issue

In bugzilla, the SPEC component will be used to hold all spec issues:

• clarifications

• corrections

• brand new ideas

• elaborations

You get the picture.

Use this Bugzilla query to see the unresolved items.

A goal is to get the TCK documentation (in the form of contributor’s guides, etc.) to the point where people could reasonably be asked to contribute a TCK test along with a new spec issue (or at the least some portion of the test).

To open your own new issue, click here.

In bugzilla, the TCK component will hold spec issues that still need enforcement added in TCK.

After a spec issue is agreed upon and documented its component field will be changed to TCK reflecting the need to still add a test in the TCK.

The RI may still need updating as well. We won’t try to track RI compliance in bugzilla, we’ll use the RI issues if needed but otherwise assume the RI is always passing the latest TCK.

Here is a query for unresolved issues in the TCK component (i.e. resolved spec issues requiring TCK updates).

Note: This probably isn’t the ideal workflow for a spec issue, but since we have this coverage gap, it’s worth noting along with the spec issues that are being tracked.

See the TCK project on GitHub. These will eventually be described in more detail on the Wiki at the GitHub project. The issues page should also be one starting point.

The effort to rewrite the spec in AsciiDoc is captured in this standards.jsr352.batch-spec repo at the specification subdirectory off of the root level.

Some issues are listed there.

A review is greatly needed/appreciated.