| Re: [jakartabatch-dev] post-EE 9 plans for batch's compatible implementation ? |
_______________________________________________So things have been looking up in the Jakarta Batch world:
* In the past couple weeks we've taken small but concrete steps closer to finishing up the EE 9 work every couple days, and added several new contributors and volunteers
* From Ondro and Romain we have some interesting ideas out there for how to advance the TCK.
Let me launch what I think is the last key conversation in preparation for adding new function post-EE 9 about the future of the jbatch implementation: https://github.com/WASdev/standards.jsr352.jbatch
First some Eclipse Foundation Specification Process education (this is my take, feel free to correct me if needed):
The jbatch impl was originally, of course, the JSR 352 Reference Implementation. This project now (in Jakarta EE 8 / 9 ) plays the important role of providing the "at least one" Compatible Implementation that each specification update requires, at the time the specification is finalized.
Like a Reference Implementation, this first Compatible Implementation delivered concurrent with the spec proves that a spec's ideas can be implemented and that a TCK suite can be executed and passed. Unlike the Reference Implementation, however, it retains no special status once other Compatible Implementations become available. The "jbatch" implementation provides this initial Compatible Implementation for both the Jakarta Batch spec itself, as well as for the platform, through its inclusion within Eclipse Glassfish.
---
So, this all builds up to my announcement that, after the EE 9 release is all finished, IBM is planning to shut down the jbatch project.
Since Jakarta Batch needs to maintain a compatible implementation, we would be responsible, as a community, for coming up with one, in order to progress post-EE 9. This is needed both directly to advance the Jakarta Batch spec and also to provide the Eclipse Glassfish platform implementation a batch component.
A simple solution here would simply be to donate/fork the jbatch repo into a new eclipse-ee4j repo ("batch-impl " / "jbatch") and do a package rename (com.ibm.* => org.glassfish.*). The impl-specific SPIs used to manage jbatch as a component within Glassfish would basically be unchanged (as would the DB persistence), and jbatch defines no application APIs external to the spec.
If this all seems like a whole lot of nothing... moving the same codebase from one repo to another, well, good, that is a virtue of this plan indeed. We'd have essentially the same implementation but in a community repo rather than in the less-suitable "WASDev" organization.
Let me stop now and see what others on this list think.
Thank you,
-------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev