Rahul Akolkar wrote:
On 8/12/06, Oliver Heger <[EMAIL PROTECTED]> wrote:
>> Rahul Akolkar wrote:
>>
>> The method in question apparently has existed ever since xalan2 came
>> about (my guess would have been there is some version xalan1 in
>> lib/ext, but you've tried all that).
>>
>> As a side note, xalan 2.6.0 -> 2.7.0 is generally considered a bigger
>> leap, so I've left [scxml] at 2.6.0 (its closer to what JDK 1.4 had
>> built in, so the 1.4 user has less reason to need the endorsed
>> standards override mechanism, and cause any errors therein) -- but
>> since [configuration] has had atleast one prior release with a xalan
>> 2.7.0 dep (are we using any 2.7.0 specific stuff?), maybe the xerces
>> version also should be upgraded? (2.7.0 has been tested with xerces
>> 2.7.1).
>>
<snip/>
Rahul,
you are right: when downgrading to xalan 2.6.0 the error does not happen.
I wonder if I can change the version because [configuration] 1.2 was
released with the dependency to xalan 2.7.0. But because xalan is needed
only for JDK 1.3 support I think it is not that problematic.
<snap/>
Yup, jar hell, a downgrade probably doesn't happen often. The tricky
scenario is where folks have begun to rely on 2.7.0 bits in their apps
because of the fact that it was available when using [configuration]
1.2, but then again for them the particular bits affected by these
tests may fail by staying at 2.7.0. I'd say its your call, but
probably worth a mention someplace.
-Rahul
I think, I leave the 2.7.0 dependency. With the additional try-blocks
the two affected unit tests don't cause problems. But I will add a note
to our dependencies page.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
