Return-Path: 
 <commons-dev-return-92707-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 4940 invoked from network); 15 Aug 2006 20:04:22 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 15 Aug 2006 20:04:22 -0000
Received: (qmail 19754 invoked by uid 500); 15 Aug 2006 20:04:19 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 19686 invoked by uid 500); 15 Aug 2006 20:04:19 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 19666 invoked by uid 99); 15 Aug 2006 20:04:19 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Aug 2006 13:04:18 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [212.227.126.188] (HELO moutng.kundenserver.de)
 (212.227.126.188)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Aug 2006 13:04:17 -0700
Received: from [217.81.252.42] (helo=[192.168.178.21])
	by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis),
	id 0MKxQS-1GD58l1LyH-0002zP; Tue, 15 Aug 2006 22:03:55 +0200
Message-ID: <44E228A7.7040903@oliver-heger.de>
Date: Tue, 15 Aug 2006 22:03:51 +0200
From: Oliver Heger <oliver.heger@oliver-heger.de>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: svn commit: r426813 - in
 /jakarta/commons/proper/configuration/trunk/src:
 java/org/apache/commons/configuration/ test/org/apache/commons/configuration/
References: <20060729145232.E8AA31A981A@eris.apache.org>
	 <ce1f2ea80607292109te86eafcube52d436fff15037@mail.gmail.com>
	 <44CCE3DC.2050602@oliver-heger.de>
	 <ce1f2ea80607311149i1e41cabfu938c2f460eb3adbd@mail.gmail.com>
	 <44CE6159.70403@oliver-heger.de> <44DDF827.7030803@oliver-heger.de>
 <ce1f2ea80608141525i46e5623fxd98251362ad2bad2@mail.gmail.com>
In-Reply-To: <ce1f2ea80608141525i46e5623fxd98251362ad2bad2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: kundenserver.de abuse@kundenserver.de
 login:060b6f3a5b4852d7db894881f1c69c62
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Rahul Akolkar wrote:
> On 8/12/06, Oliver Heger <oliver.heger@oliver-heger.de> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org