ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: [PATCH] [FIX] RE: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdefs/optional/net
Date Tue, 26 Mar 2002 20:38:29 GMT

----- Original Message -----
From: "Nigel Magnay" <>
To: "'Ant Developers List'" <>
Sent: Tuesday, March 26, 2002 1:16 AM
Subject: RE: [PATCH] [FIX] RE: cvs commit:

> >
> > the generic test would be to telnet to port 80 on
> >, do
> >
> > file="ant/"
> > response="200 OK"  //is that right?
> >
> > then in telnet
> > <write>GET ${file} HTTP/1.0</write>
> > <write>
> > <read>${response}</read>
> >
> Good idea.
> I've attached a build.xml file which does exactly that -
> and checks that if you don't set the translateProperties
> flag that it defaults to the old behaviour.

Nice tests.

There is an interesting issue here regarding the property translation

1. the old behaviour is a bug, pure and simple, right?
2. if we fix it, then all new code will be written expecting translation;
escaping dollar signs &c
3. if we dont make the fix a default, then we ar just going to cause grief
for people down the line
4. but if we do fix it, we cant guarantee that you can write a build file
which works on both 1.5. and earlier versions. Actually you can, you just
dont nest the text, you use <read string=>; if you know what you are doing
you can do a cross-version <telnet> that works

I want to patch how we expand properties overally, so that $$ -> $ and $ ->
$. with this patch in, we eliminate the 'doesnt exclude class$subclass'
bugreps, and any <telnet> use where you do something like
 <read>ready$</read> will still works. So all that we would break would be
the ${PATH} use case.

But here is the best bit, what will the result of  <read>${PATH}</read> be
if PATH is undefined? That's right: it'll be ${PATH}

So we will only have a problem if the user is using ${something} and <isset
property="something"> holds. Which is kind of insidious; that could
introduce intermittent failures in obscure cases.

So, I am fairly tempted to move to a model where we always expand properties
in the telnet task, we doc it as a 'this may break stuff' flag and move on.
If we are going to have a switch, make it in the task nto the read and write
datatypes, and then add a way to set it from a property
ant.telnet.brokenMode so that you can turn it on without changing the build

How about we move the translate properties to the <telnet> task itself? I
cant see anyone adding it on a case by case c

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message