--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
[SNIP]
But are there enough usages
> as to grant the
> definition of a full framework for this pattern.
That's backwards... the original idea was not a full
framework to support this pattern... this pattern is
only one possible way to exploit
Your example has this assumption, quite thin for the general case
that no matter what accion, the set of other attributes and
elements must be exactly the same.
I really do not see to much of the usability gain in something like
that.
Usually you expect different input for different actions. And w
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
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> This actually ties back to what Magesh proposed (the
> dispatch task).
>
> One of the useful bit his proposal allowed was to
> conditionally
> execute one mode or the other thanks to
> mode="${mode}", where
> mode can be configured/computed befor
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> On Fri, 4 Jun 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
> > If there is any reason why we couldn't/shouldn't have
> > a generic DynamicConfigurator that could
> > execute an arbitrary task by classname, and a generic
> > or , probably also a
>
On Fri, 4 Jun 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
> If there is any reason why we couldn't/shouldn't have
> a generic DynamicConfigurator that could
> execute an arbitrary task by classname, and a generic
> or , probably also a
> DynamicConfigurator, to instantiate (and optionally
> con
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Jun 2004, Matt Benson
>
> Sorry, what is your question?
>
If there is any reason why we couldn't/shouldn't have
a generic DynamicConfigurator that could
execute an arbitrary task by classname, and a generic
or , probably also a
DynamicC
On Thu, 3 Jun 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Matt Benson <[EMAIL PROTECTED]> wrote:
>> > />
>>
>
> The above reminds me of something... for one thing,
> that should have been a in that context, but
> anyway...
>
> what would be the ramifications of having
>
>
> ...
>
>
>
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
--- Matt Benson <[EMAIL PROTECTED]> wrote:
> />
>
The above reminds me of something... for one thing,
that should have been a in that context, but
anyway...
what would be the ramifications of having
...
and
Et cetera?
-Matt
__
--- 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
I was just adding to the Ant Wiki AntOddities page the following macrodef :
I wrote a quick counter-example which shows how expansions of properties in Ant
is not recursive:
47 matches
Mail list logo
