Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <user@ant.apache.org>
Message-ID: <40DC8266.9010402@magmic.com>
Date: Fri, 25 Jun 2004 15:52:06 -0400
From: Jeffrey Bacon <jbacon@magmic.com>
Organization: Magmic Inc.
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
MIME-Version: 1.0
To: Ant Users List <user@ant.apache.org>
Subject: Re: recursive expansion of property names
References: <20040623222044.93834.qmail@web20423.mail.yahoo.com>
 <40DB159A.3E9088F3@purematrix.com> <40DB2C9C.80206@magmic.com>
 <6.1.1.1.2.20040624172105.02845e28@pop1.mail.com> <40DB50D5.50206@magmic.com>
 <6.1.1.1.2.20040624181124.0288f1a8@pop1.mail.com>
 <40DB56E2.9050604@magmic.com>
 <6.1.1.1.2.20040624191659.0289ccf0@pop1.mail.com>
 <40DB648D.3080405@magmic.com>
 <6.1.1.1.2.20040625095350.02835558@pop1.mail.com>
 <40DC33AD.6080405@magmic.com> <40DC36C1.4060606@magmic.com>
 <6.1.1.1.2.20040625105123.028cbb68@pop1.mail.com>
 <40DC6834.6000103@magmic.com>
 <6.1.1.1.2.20040625152757.028c9798@pop1.mail.com>
In-Reply-To: <6.1.1.1.2.20040625152757.028c9798@pop1.mail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

good call.  I'll bet that's exactly what's happening.  Maybe what it 
should do is create a tree out of the string and then walk the tree in a 
depth-first manner to do a replacement on each node where each node is 
composed of the combination of it's child nodes.
--
Jeffrey Bacon
jbacon@magmic.com
Creative Developer
http://www.magmic.com

Wascally Wabbit wrote:
> At 02:00 PM 6/25/2004, you wrote:
>  >can you copy-n-paste your resolvePropertiesRecursively method here?  I am
>  >getting a wierd error.  I'll trace it through below.  It's wired that it
>  >suddenly craps out not finding the 3rd '${' instance (or the 4th instance
>  >for that matter).
> 
> I think there are problems with the resolvePropertiesRecursivlly method. In
> particular
> these two lines look funny to me (haven't debugged thoroughly):
> 
> ?? sb.replace(nextOpenerIndex, balancingCloserIndex +
> RecursivePropertyParser.CLOSER_LENGTH, fragment);
> ?? nextOpenerIndex = RecursivePropertyParser.nextOpener(sb.toString(),
> balancingCloserIndex + 1);
> 
> The first calc of 'balancingCloserIndex' (not shown) is determined based
> on the original string, but the increment code is based on the
> string-under-construction. There's no guarantee that the
> 'balancingCloserIndex' index is even remotely correct for the partially
> constructed string. The closer index value should be adjusted
> for the difference between the property's name length and the replacing
> property value's length. It's not.
> 
> Example: if the original string is "${foo}/${${bar}.src}" and "foo" is 
> defined
> as "fu" then 'balancingCloserIndex' would be initially set for the 5th
> index which would be *WRONG* for the partially constructed buffer of
> "fu/${${bar}.src}" as passed to the nextOpener method...the next call to
> nextOpener would completely miss the next two $ openers.
> 
> 
> The Wabbit
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org