On 6/15/07, Endre Stølsvik <[EMAIL PROTECTED]> wrote:
>> > 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?
But I thought you argued previously in this thread that you never
wanted to change, silently, the 4.1 schema for 4.1.2 at runtime?
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)
If there was ever an issue with 4.1.1 and the user wanted to go back
to 4.1 XSD, they couldn't using this approach.
I think I'd prefer an alias to 'the latest spec' instead.
say 4.x would resolve to the latest/greatest spec etc.
(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! :)
Fancy submitting a match? :)
META-INF/MANIFEST.MF could also do with a shine (I've commented on
that before),
Ditto :)
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?)
Its certainly possible; though I do worry about huge jars with every
release adding a big XSD inside it.
So far am leaning towards the 4.x idea and just including the latest schema
--
James
-------
http://macstrac.blogspot.com/
