> If users stuck on (say) 4.1 of the XSD and we
> released 4.1.2; then the entity resolver would not be able to resolve
> the 4.1.2 schema; so your application could break if you upgrade to a
> newer version of ActiveMQ.
Why is that?
The release only includes the current generated XSD in the jar. So we
can't easily ship 'every possible old version of the XSD' inside the
jar as well. So version 4.1.2 will just include 4.1.2 of the XSD and
so just work with
http://activemq.apache.org/schema/core/activemq-core-4.1.2.xsd.
If you're config file is using 4.1 or 4.1.1; then ActiveMQ will be
using the internet to resolve the XSD
Not necessarily: IF you only have changed doc, OR only _added_ stuff,
then you could use the multi-line possibilities in spring.schemas to
"redirect" the older ones to the new included one - didn't you also
point this out, by suggesting that both the versioned file, and the
unversioned file, should have its own line in spring.schemas? Why not
just also add in the older lines, e.g. 4.1.0, 4.1.1 and so on, in there?
This because any older XML files (the config files) would then
"compile against" the new XSD, without errors - and everyone would be
happy. If however anything came up, everyone would know just which exact
version of AMQ this file originally was written against (although, since
you won't distribute the older xsd's, you can now add new stuff to an
old config file, and it will still run - which I guess it shouldn't have
if you wanted to be totally correct)
(I still, though, think the included (the one inside the jar) could
benefit from having the version number attached (and also have it inside
the actual schema, as a comment??). I don't know if I've gotten through
on that point - but i _love_ explicitness! :)
META-INF/MANIFEST.MF could also do with a shine (I've commented on
that before), and all files all over should have the version number
tagged on. The point is that if you see ANY such artifacts outside their
container, or "outside their scope", it is very nice to be able to
"backtrack" to what it belongs to and where it came from. It usually
doesn't take that much labor to include it, but gives many small
benefits ever after.).
(And when it comes to including the older XSDs in new releases -
wouldn't that just be to suck in all the XSDs that are laying around on
the dist-site when cutting a new release?)
Kind regards,
Endre.
