|
Hi Scott,
The version stuff all makes senes to me. I do have one question though, what is the motivation for removing the XSDs from the API JAR? Given the requirement to validate the XML on startup, any implementation would be required to ship those XSDs so it feels
like an unnecessary duplication across all the implementations. It also introduces the risk that the XSD could evolve from what the spec requires. I'd vote to leave it in.
Thanks,
Michael
From: jakartabatch-dev-bounces@xxxxxxxxxxx <jakartabatch-dev-bounces@xxxxxxxxxxx> on behalf of Scott Kurz <skurz@xxxxxxxxxx>
Sent: Monday, June 22, 2020 1:34 PM
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Subject: [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
--------------------------------------------------------
|
