| [jakartabatch-dev] job xml XSD 'version' update (to 2.0) proposed |
Let me run this by the list here.
Though I'd mentioned the change of our job XML's schema targetNamespace (back in https://www.eclipse.org/lists/jakartabatch-dev/msg00080.html), it hadn't crossed my mind to update the "version" attribute on the <job> root element.
As it turns out, the other Jakarta EE 9 specs are incrementing these version numbers to match the spec version: https://jakarta.ee/xml/ns/jakartaee/#9
So to follow this pattern, we should also make a change like: https://github.com/jakartaee/jakarta.ee/pull/812/files to bump up our version to "2.0".
So the net change for a typical job XML would be something like:
-<job id="job_batchlet_1step" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
+<job id="job_batchlet_1step" xmlns="https://jakarta.ee/xml/ns/jakartaee" version="2.0">
I'd be surprised if anyone thinks we should go in a different direction than the platform, but please speak now if there are any concerns.
-----
A couple other notes:
1. Note I included the common jakartaee_9.xsd file to use the common platform 'dewey-versionType'
2. I'm also planning to remove the XSDs from the API JAR (to avoid duplication in terms of which jakarta spec project "owns" the source of the .xsd... though they are effectively still duplicated in the spec). I'd suggest that impls that want them packaged can package them in the impl, rather than relying on them packaged in the API.
3. If you're familiar with the Eclipse Transformer project, you'll know its intention is to help migrate from Jakarta EE 8 -> Jakarta EE 9, e.g. helping with the javax.* => jakarta.* package conversion.
I opened up an issue here https://github.com/eclipse/transformer/issues/73 to address the batch job XML (and batch.xml) migration use cases.
Now we just need someone to implement that ;)
----
Finally.. just a quick note... the spec does say job XML has to be schema-valid (in case anyone was wondering) ...(not sure if the TCK enforces though).
The batch runtime must perform schema validation during JobOperator start processing before the start method returns to the caller.
Thanks,
------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------