scottkurz
commented
4 years ago This item relates to a specific, earlier, proposed release plan. It doesn't make sense to carry forward in this way.
In general, as we make release plans, we will have to consider when to update the job version in XSD.
Originally opened as bug 7282 by ScottKurz
--------------Original Comment History---------------------------- Comment from = ScottKurz on 2015-09-03 15:23:23 +0000
Opening this as a separate item.
My thought is, if it seems there are enough interesting changes to require or suggest an XSD update, we do one. OTOH, if there maybe are not, maybe we don't and just stay with the 1.0 XSD.
E.g. in https://java.net/bugzilla/show_bug.cgi?id=5403 the idea is suggested to loosen the schema. I don't think I'd want a new version JUST for this, but if there are enough, will use this item to track the schema update.
Comment from = m_edgar on 2015-09-22 15:04:06 +0000
This may merit a separate bug entry, but it's related to your comments.
Unlike many other JEE XML formats, the JSL approach is somewhat procedural, but without any code reuse mechanism. One feature that I would like to see in JSL is the ability to include fragments of reusable JSL. I haven't fully thought it out, but it seems reasonable for a JSL fragment to allow any complex type from JSL as its root. The result of the include would be the same as specifying the fragment directly in the parent XML, with any parameters resolved.
For example, if I find myself defining the same listeners on every step in every job, having the ability to include another file (with parameter passing) allows me to get some code reuse (see below).
*** myjob.xml
*** common-listener-set.xml
Comment from = ScottKurz on 2015-09-22 15:21:51 +0000
Yes this is a separate topic (please open a new issue).
We had originally targeted this function for 1.0, calling it "JSL inheritance".
As we got close to our deadline, we pulled it out, realizing that the rule set for resolving property substitution in inheritance cases had quite a few details left to completely specify.
Since the 1.0 EG had this is plan originally, I think it's a fair topic to consider again for 1.1.
That said, I think I'll need help to resolve those issues, in order to actually get this in 1.1. We know SpringBatch has support for this and it looks like JBeret does as well. Not too familiar but I'm sure they'd be good starting points.