Matt Benson wrote:
> One (slightly messy) solution might be to decouple the
> parsing and substitution... thinking out loud here so
> forgive any glaring omissions or errors...
What I haven't figured out yet is why you bother to parse in the complicated
fashion you do in PropertyHelper.parsePrope
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
[SNIP]
> I don't see any easy way to defer the actual string
> tokenization to
> the individual PropertyHelpers of the chain, so we
> may be better
> served by defining a more useful algorithm at the
> top.
One (slightly messy) solution might be to dec
On Thu, 3 Jun 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> On Thu, 3 Jun 2004, Jose Alberto Fernandez
>> <[EMAIL PROTECTED]>
>> wrote:
> [SNIP]
>> > Agree in principle. As a matter of fact, we
>> already have the
>> > PropertyHelper chain framework
What I was worried about were setPropertyHook() and
getPropertyHook()...
Maybe the java.text.Format comparison only applies to
the parsePropertyString() implementation of a given
PropertyHelper. So one PropertyHelper might use
something like it, but another--such as the default
one--would not. B
> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
>
> I think you're basically right. And I remember having
> wondered why java.text.Format was implemented that
> way; now I know...
>
> > Such strategy would allow writing property
> > evaluators that contain real
> > complex expressions insi
--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
[SNIP]
> I guess, the way to do it properly is to use
> something like the way
> java.text.Format
> works. You find the beginning of a property
> reference and the
> PropertyHelper chain is the one that tells you where
> is the end pf the
> prop
Jose Alberto Fernandez wrote:
> > From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
> >
>
> Well, it seem to me the problem is deeper.
You're correct ... I've got recursive expansion kinda working already, just
fixing a bug now but have to put it aside to do some real work :-)
> So what needs to be
> From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
>
> Matt Benson wrote:
>
> > We could create a new property
> > ant.PropertyHelper.classname or some such, to allow
> > users a comfortable way to avoid the situation above,
> > but AFAICT the issue still exists.
>
> Well, some of what you are tal
Matt Benson wrote:
> We could create a new property
> ant.PropertyHelper.classname or some such, to allow
> users a comfortable way to avoid the situation above,
> but AFAICT the issue still exists.
Well, some of what you are talking about is a little deeper in Ant-fu than I
care to go for this p
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Jun 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]>
> wrote:
[SNIP]
> > Agree in principle. As a matter of fact, we
> already have the
> > PropertyHelper chain framework.
>
> That's what I've been talking about, yes 8-)
>
Nice... howev
Stefan Bodewig wrote:
On Thu, 03 Jun 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
I do not think that this is a bug.
I'm not convinced either. I'd only want to reinstate 1.6.x's behavior
if it really had changed in CVS HEAD (which I doubt, BTW).
Ah, I see.
Just tested with ant 1.5.4 and t
On Thu, 03 Jun 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> I do not think that this is a bug.
I'm not convinced either. I'd only want to reinstate 1.6.x's behavior
if it really had changed in CVS HEAD (which I doubt, BTW). It
probably has always (since 1.4 or so) worked the way it does now
On Thu, 3 Jun 2004, Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
>> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>>
>> > Okay. I'm going to add one class
>> > ..ant.util.RecursivePropertyParser and call it from
>> > ..ant.PropertyHelper.replacePropertiesRecursively()
>>
>> I'd rather make
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> > Okay. I'm going to add one class ..ant.util.RecursivePropertyParser
> > and call it from ..ant.PropertyHelper.replacePropertiesRecursively()
>
> I'd rather make that a completely new PropertyHelper that can
> be selected on the command line
On Wed, 02 Jun 2004, Jack J. Woehr <[EMAIL PROTECTED]> wrote:
> Ant should behave analagously to m4: recursively expand until
> it either hits ground or an uninstantiated ${decorated} name.
And potentially break existing build files.
You can always write a PropertyHelper implementation
Stefan Bodewig wrote:
On Wed, 02 Jun 2004, Antoine Lévy-Lambert <[EMAIL PROTECTED]>
wrote:
In my opinion, the problem reported is a bug, even if for instance
JDK 1.4 regexp has a similar bug. I would go for fixing the bug
without BC, in order not to make the code too complicated.
Where "fi
On Wed, 02 Jun 2004, Jack J. Woehr <[EMAIL PROTECTED]> wrote:
> Okay. I'm going to add one class ..ant.util.RecursivePropertyParser
> and call it from ..ant.PropertyHelper.replacePropertiesRecursively()
I'd rather make that a completely new PropertyHelper that can be
selected on the command line
On Wed, 02 Jun 2004, Antoine Lévy-Lambert <[EMAIL PROTECTED]>
wrote:
> In my opinion, the problem reported is a bug, even if for instance
> JDK 1.4 regexp has a similar bug. I would go for fixing the bug
> without BC, in order not to make the code too complicated.
Where "fixing the" bug would ex
Dominique Devienne wrote:
> It does to me. Just throw in a test case too. --DD
Okay. Thanks.
--
Jack J. Woehr # We have gone from the horse and buggy
Senior Consultant # to the moon rocket in one lifetime, but
Purematrix, Inc. # there has not been a corresponding moral
www.purematrix.com
> From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
> Dominique Devienne wrote:
> > Code has momentum. Design talk does not. Plat at will. --DD
>
> Okay. I'm going to add one class ..ant.util.RecursivePropertyParser and
> call it from ..ant.PropertyHelper.replacePropertiesRecursively()
> and add some
Dominique Devienne wrote:
> Code has momentum. Design talk does not. Plat at will. --DD
Okay. I'm going to add one class ..ant.util.RecursivePropertyParser and call it
from ..ant.PropertyHelper.replacePropertiesRecursively()
and add some switch between that method and
.ant.PropertyHelper.replac
> From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
> > Cool. Then people wouldn't need and/or the
> > trick, or the propertyfile trick. Lets see what other committers think.
>
> Should this lowly non-committer play with code or await some kind of
> consensus on design?
I don't know what that last
Dominique Devienne wrote:
> Cool. Then people wouldn't need and/or the
> trick, or the propertyfile trick. Lets see what other committers think.
Should this lowly non-committer play with code or await some kind of consensus
on design?
--
Jack J. Woehr # We have gone from the horse and bu
> From: Antoine Lévy-Lambert [mailto:[EMAIL PROTECTED]
>
> In my opinion, the problem reported is a bug, even if for instance JDK
> 1.4 regexp has a similar bug.
The JDK regex stuff is a tangent. It's just my own code to do Ant-like
property substitution (or Shell like, or DOS like, as it's flexi
In my opinion, the problem reported is a bug, even if for instance JDK
1.4 regexp has a similar bug.
I would go for fixing the bug without BC, in order not to make the code
too complicated.
This is just me though.
Cheers,
Antoine
Jack J. Woehr wrote:
Dominique Devienne wrote:
There's no such
Dominique Devienne wrote:
> There's no such property, and any new 'magic' property will be a struggle to
> get past IMHO. Committers would have to chime in at this point... --DD
It can be a command-line option or a property option. Looks like I can just
implement PropertyHelper.replaceProperties
> From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
>
> Okay, Alexey wrote:
>
> Just add something like "if (project.getProperty("ant.bc")!=null)
> ..."
> to make them happier.
>
> Was he speaking abstractly or is there an "ant.bc" property really?
Can't know for sure, but Alexey might ha
Dominique Devienne wrote:
> > From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
> > > But you side stepped the BC issue.
> >
> > ?? Not sure I get you. "BC issue"?
>
> Backward-compatibility issue. --DD
Okay, Alexey wrote:
Just add something like "if (project.getProperty("ant.bc")!=null) ..."
> From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
> > But you side stepped the BC issue.
>
> ?? Not sure I get you. "BC issue"?
Backward-compatibility issue. --DD
> > You can always implement (and test) the
> > algorithm above, and see if you can get the committers to put it in. --
> DD
>
> Sure,
Just add something like "if (project.getProperty("ant.bc")!=null) ..."
to make them happier.
- Alexey.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Dominique Devienne wrote:
> > From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
> > > Ant should behave analagously to m4: recursively expand until it
> > > either hits ground or an uninstantiated ${decorated} name.
> >
> > Oh, and the algorithm should be something like:
> >
> >1. Wh
> From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
> > Ant should behave analagously to m4: recursively expand until it
> > either hits ground or an uninstantiated ${decorated} name.
>
> Oh, and the algorithm should be something like:
>
>1. While argument X contains any "${}" expr
"Jack J. Woehr" wrote:
> Ant should behave analagously to m4: recursively expand until it either
> hits
> ground or an uninstantiated ${decorated} name.
Oh, and the algorithm should be something like:
1. While argument X contains any "${}" expressions {
2. Y : = Expansi
> From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
> > Second, what's one to do? Ant by contract does not support nested
> > properties, so what's Ant to do when it sees on opening ${?
>
> Glad you ask.
>
> Ant should behave analagously to m4: recursively expand until it
> either hits grou
Dominique Devienne wrote:
> > From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
> >
> > Dominique Devienne wrote:
> >
> > > I believe that ${${a}.${b}} is parsed as:
> > >
> > > getProperty("${a") + "." + getProperty("b") + "}", thus the result. --DD
> >
> > Well, it sure looks like it is :-)
> >
> >
> From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
>
> Dominique Devienne wrote:
>
> > I believe that ${${a}.${b}} is parsed as:
> >
> > getProperty("${a") + "." + getProperty("b") + "}", thus the result. --DD
>
> Well, it sure looks like it is :-)
>
> But is that result reasonable? It looks more
Dominique Devienne wrote:
> I believe that ${${a}.${b}} is parsed as:
>
> getProperty("${a") + "." + getProperty("b") + "}", thus the result. --DD
Well, it sure looks like it is :-)
But is that result reasonable? It looks more to me like an artifact of a coding
strategy
being elevated to a prin
> From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
> I wrote a quick counter-example which shows how expansions of properties
> in Ant is not recursive:
>
>
>
>
>
>
>
>
>
>
>
> but when I ran it, in Ant ve
38 matches
Mail list logo
