Re: [Ant 1.6beta1] Missing stylesheet?

[Conor MacNeill]

On Tue, 21 Oct 2003 12:14 am, Dominique Devienne wrote:
>
> What I think is important is that it's in the release ;-) Seems like
> somehow checkstyle-frames.xsl is not making it in the release 1.6betaX of
> Ant. --DD
>

Ok - fixed.

Conor


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant build.xml

[conor]

conor   2003/10/20 16:30:42

  Modified:.Tag: ANT_16_BRANCH build.xml
  Log:
  Merge
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.392.2.7 +1 -1  ant/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/ant/build.xml,v
  retrieving revision 1.392.2.6
  retrieving revision 1.392.2.7
  diff -u -w -u -r1.392.2.6 -r1.392.2.7
  --- build.xml 16 Oct 2003 21:13:29 -  1.392.2.6
  +++ build.xml 20 Oct 2003 23:30:42 -  1.392.2.7
  @@ -1000,7 +1000,7 @@
   
   
   
  -
  +
   
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant build.xml

[conor]

conor   2003/10/20 16:27:59

  Modified:.build.xml
  Log:
  Include checkstyle stylesheets
  
  Revision  ChangesPath
  1.399 +1 -1  ant/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/ant/build.xml,v
  retrieving revision 1.398
  retrieving revision 1.399
  diff -u -w -u -r1.398 -r1.399
  --- build.xml 7 Oct 2003 11:44:34 -   1.398
  +++ build.xml 20 Oct 2003 23:27:59 -  1.399
  @@ -1001,7 +1001,7 @@
   
   
   
  -
  +
   
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Macrodef and parallel in a recursive situation

[peter reilly]

I have made a version that inherits local properties
for ant/antcall et al (if inheritall is true).

Will post tomorrow.

Peter

On Monday 20 October 2003 17:44, Jose Alberto Fernandez wrote:
> Peter,
>
> I just made a browse to the changes you posted and I can see
> why you are concern with ant/antcall. I see you did quite large
> additions to core in order to implement this (using ThreadLocals).
>
> I wonder if we can explore a more simpler implementation that is
> less onerous than the one you have. I would think that adding
> that making  pay for the cost of treating the computations
> separately will make things simpler and make more posible to
> do the right thing for ant/antcall.
>
> BTW, we are not talking ONLY about ant/antcall. We are talking
> about them and about ALL the user implemented versions of 
> , etc, etc that are around because we never provide one
> in core. We cannot just break their them.
>
> Do you see any reasonable way in which  could create
> separate copies of its properties for each execution thread?
> I will try to see if I getthe time to propose actual code.
> But I have been kind of burden ere at work.
>
> Jose Alberto
>
> > -Original Message-
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> > Sent: 20 October 2003 16:54
> > To: Ant Developers List
> > Subject: Re: Macrodef and parallel in a recursive situation
> >
> >
> > This is basicly what the local implementation
> > does.
> >
> > The only problem is for ant/antcall, a new project
> > is created and the local properties would need
> > to be copied to this, keeping in mind all the
> > rules about user/normal/inherited and nested param
> > elements.
> >
> > Peter
> >
> > On Monday 20 October 2003 16:16, Matt Benson wrote:
> > > Jose makes a good point about tasks that set
> > > properties.  Without having delved into the
> > > PropertyHelper* classes, could local properties be
> > > handled some other way?  What about a Scope
> > > TaskContainer subclass that would push an element onto
> > > a stack.  Then any property queries would descend into
> > > the stack... then a task that set a property could
> > > have that property restricted by nesting it in a set
> > > of  tags...
> > >
> > > -Matt
> > >
> > >
> > > --- Jose Alberto Fernandez <[EMAIL PROTECTED]>
> > >
> > > wrote:
> > > > > From: Christopher Lenz [mailto:[EMAIL PROTECTED]
> > > > >
> > > > > Hi Peter,
> > > > >
> > > > > this looks really cool, but I'd suggest adding an
> > > >
> > > > attribute like
> > > >
> > > > > scope="local|global" to the  task
> > > >
> > > > instead of adding
> > > >
> > > > > a completely
> > > > > new task.
> > > >
> > > > I disagree here. The issue is not  by
> > > > itself. This local
> > > > properties need to work with every  that may
> > > > set a property:
> > > > , , , ,
> > > > and a million more
> > > > obscure ones. The main use for  is when it is
> > > > called without
> > > > the value attribute, because in that case this other
> > > > tasks will
> > > > set the local property and not the global one.
> > > >
> > > > Jose Alberto
> > > >
> > > > > -chris
> > > > >
> > > > > peter reilly wrote:
> > > > > > I have written the code to support local
> > > >
> > > > properties.
> > > >
> > > > > > While I was doing this, I realized that the
> > > >
> > > > attributes
> > > >
> > > > > > of a macrodef could/should be local properties
> > > >
> > > > as well,
> > > >
> > > > > removing some
> > > > >
> > > > > > of the issues seen last week (use of attribute
> > > >
> > > > in a bsf script and
> > > >
> > > > > > support of parallel/recursive).
> > > > > >
> > > > > > The following shows it in using a new task
> > > >
> > > > called local.
> > > >
> > > > > > 
> > > > > >   
> > > >
> > > > > >   
> > > > > > 
> > > > > > prop1 is "${prop1}"
> > > > > >   
> > > > > >   
> > > > > > prop1 is "${prop1}"
> > > > > >   
> > > > > > 
> > > > > >
> > > > > > This ant test2 generates the following:
> > > > > >
> > > > > > test1:
> > > > > > prop1 is "a local value"
> > > > > >
> > > > > > test2:
> > > > > > prop1 is "a global value"
> > > > > >
> > > > > > Each taskcontainer sets up a new local scope:
> > > > > >
> > > > > >   
> > > > > > 
> > > > > > 
> > > > > >   
> > > >
> > > > > >   prop2 is "${prop2}"
> > > > > > 
> > > > > > prop2 is "${prop2}"
> > > > > >   
> > > > > >
> > > > > > will generate the following:
> > > > > > sequential:
> > > > > > prop2 is "in sequential"
> > > > > > prop2 is "in target"
> > > > > >
> > > > > > The value part of  is optional, and  the
> > > >
> > > > local
> > > >
> > > > > property may be
> > > > >
> > > > > > set by a subsequent ,  will
> > > >
> > > > only set it if the
> > > >
> > > > > > value is not set.
> > > > > >
> > > > > >   
> > > > > > 
> > > > > > prop3 is "${prop3}"
> > > > > > 
> > > > > > 
> > > >
> > > > > > prop3 is "${prop3}"
> > > > > >   
> > > > > >
> > > > > > will generate the following:
> > > > > > no

RE: Macrodef and parallel in a recursive situation

[Jose Alberto Fernandez]

Peter,

I just made a browse to the changes you posted and I can see
why you are concern with ant/antcall. I see you did quite large
additions to core in order to implement this (using ThreadLocals).

I wonder if we can explore a more simpler implementation that is
less onerous than the one you have. I would think that adding
that making  pay for the cost of treating the computations
separately will make things simpler and make more posible to 
do the right thing for ant/antcall.

BTW, we are not talking ONLY about ant/antcall. We are talking
about them and about ALL the user implemented versions of 
, etc, etc that are around because we never provide one
in core. We cannot just break their them.

Do you see any reasonable way in which  could create
separate copies of its properties for each execution thread?
I will try to see if I getthe time to propose actual code.
But I have been kind of burden ere at work.

Jose Alberto

> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED] 
> Sent: 20 October 2003 16:54
> To: Ant Developers List
> Subject: Re: Macrodef and parallel in a recursive situation
> 
> 
> This is basicly what the local implementation
> does.
> 
> The only problem is for ant/antcall, a new project
> is created and the local properties would need
> to be copied to this, keeping in mind all the
> rules about user/normal/inherited and nested param
> elements.
> 
> Peter
> On Monday 20 October 2003 16:16, Matt Benson wrote:
> > Jose makes a good point about tasks that set
> > properties.  Without having delved into the
> > PropertyHelper* classes, could local properties be
> > handled some other way?  What about a Scope
> > TaskContainer subclass that would push an element onto
> > a stack.  Then any property queries would descend into
> > the stack... then a task that set a property could
> > have that property restricted by nesting it in a set
> > of  tags...
> >
> > -Matt
> >
> >
> > --- Jose Alberto Fernandez <[EMAIL PROTECTED]>
> >
> > wrote:
> > > > From: Christopher Lenz [mailto:[EMAIL PROTECTED]
> > > >
> > > > Hi Peter,
> > > >
> > > > this looks really cool, but I'd suggest adding an
> > >
> > > attribute like
> > >
> > > > scope="local|global" to the  task
> > >
> > > instead of adding
> > >
> > > > a completely
> > > > new task.
> > >
> > > I disagree here. The issue is not  by
> > > itself. This local
> > > properties need to work with every  that may
> > > set a property:
> > > , , , ,
> > > and a million more
> > > obscure ones. The main use for  is when it is
> > > called without
> > > the value attribute, because in that case this other
> > > tasks will
> > > set the local property and not the global one.
> > >
> > > Jose Alberto
> > >
> > > > -chris
> > > >
> > > > peter reilly wrote:
> > > > > I have written the code to support local
> > >
> > > properties.
> > >
> > > > > While I was doing this, I realized that the
> > >
> > > attributes
> > >
> > > > > of a macrodef could/should be local properties
> > >
> > > as well,
> > >
> > > > removing some
> > > >
> > > > > of the issues seen last week (use of attribute
> > >
> > > in a bsf script and
> > >
> > > > > support of parallel/recursive).
> > > > >
> > > > > The following shows it in using a new task
> > >
> > > called local.
> > >
> > > > > 
> > > > >   
> > >
> > > > >   
> > > > > 
> > > > > prop1 is "${prop1}"
> > > > >   
> > > > >   
> > > > > prop1 is "${prop1}"
> > > > >   
> > > > > 
> > > > >
> > > > > This ant test2 generates the following:
> > > > >
> > > > > test1:
> > > > > prop1 is "a local value"
> > > > >
> > > > > test2:
> > > > > prop1 is "a global value"
> > > > >
> > > > > Each taskcontainer sets up a new local scope:
> > > > >
> > > > >   
> > > > > 
> > > > > 
> > > > >   
> > >
> > > > >   prop2 is "${prop2}"
> > > > > 
> > > > > prop2 is "${prop2}"
> > > > >   
> > > > >
> > > > > will generate the following:
> > > > > sequential:
> > > > > prop2 is "in sequential"
> > > > > prop2 is "in target"
> > > > >
> > > > > The value part of  is optional, and  the
> > >
> > > local
> > >
> > > > property may be
> > > >
> > > > > set by a subsequent ,  will
> > >
> > > only set it if the
> > >
> > > > > value is not set.
> > > > >
> > > > >   
> > > > > 
> > > > > prop3 is "${prop3}"
> > > > > 
> > > > > 
> > >
> > > > > prop3 is "${prop3}"
> > > > >   
> > > > >
> > > > > will generate the following:
> > > > > notset:
> > > > > prop3 is "${prop3}"
> > > > > prop3 is "is set"
> > > > >
> > > > > prop3 is still a local variable and will not be
> > >
> > > seen outside the
> > >
> > > > > target.
> > > > >
> > > > > The local properties are thread local so the
> > >
> > > following
> > >
> > > > works as expected:
> > > > >   
> > > > > 
> > > > > 
> > > > >   
> > > > > 
> > > > > t1: prop4 is "${prop4}"
> > > > >   
> > > > >   
> > > > > 
> > > > > t2: prop4 is "${prop4}"
> > > > >  

Re: File Delimiter for Concat Task?

[peter reilly]

No.
The tokenfilter by default splits the input
into lines before giving it to the filters.

Also concat concatenates the input files into
one stream before the filterchain sees the characters.

One horrid solution would be to use the new 
task in antcontib with outofdate:
  




  
  
  


  
  

  
  @

  

  

  
Peter
On Monday 20 October 2003 16:41, Matt Benson wrote:
> Hmm... using a replaceregex TokenFilter should have
> worked, but it didn't.  I tried treating each file as
> a single line of input but it still added the @ to the
> end of each line when I used
>
>replace="\1@" flags="s" />
>
> I am using the ORO matcher... is this a bug?
>
> What about echo your @ to a file and use the new
> concatfilter?
>
> -Matt
>
> --- Joe Parks <[EMAIL PROTECTED]> wrote:
> > I would like to add/find the ability to include a
> > delimiter between concatenated text when using the
> >  task.
> >
> > That is, for example, if I concatenate a bunch of
> > SQL scripts into one file, I would like the ability
> > to have an "@" symbol between each script.
> >
> > Does this functionality already exist in the
> >  task (and I'm just missing it)?  Or, where
> > is the best place to add it?
> >
> > Thanks,
> > Joe
>
> -
>
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
>
> __
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Macrodef and parallel in a recursive situation

[Matt Benson]

Gotcha--I missed that the first time around.  If you
want to restrict the scope of a property set by a
task, you essentially reserve that property in the
local context, then invoke the task.  This should work
although I like my way better... ;)

I think it is okay to force the user to explicitly
send local values for ant and antcall, but that's just
me... I wouldn't think it would be too hard to do it
the other way either, but what if you need to send the
global version?

0.02
-Matt

--- peter reilly <[EMAIL PROTECTED]> wrote:
> This is basicly what the local implementation
> does.
> 
> The only problem is for ant/antcall, a new project
> is created and the local properties would need
> to be copied to this, keeping in mind all the
> rules about user/normal/inherited and nested param
> elements.
> 
> Peter
> On Monday 20 October 2003 16:16, Matt Benson wrote:
> > Jose makes a good point about tasks that set
> > properties.  Without having delved into the
> > PropertyHelper* classes, could local properties be
> > handled some other way?  What about a Scope
> > TaskContainer subclass that would push an element
> onto
> > a stack.  Then any property queries would descend
> into
> > the stack... then a task that set a property could
> > have that property restricted by nesting it in a
> set
> > of  tags...
> >
> > -Matt
> >
> >
> > --- Jose Alberto Fernandez
> <[EMAIL PROTECTED]>
> >
> > wrote:
> > > > From: Christopher Lenz [mailto:[EMAIL PROTECTED]
> > > >
> > > > Hi Peter,
> > > >
> > > > this looks really cool, but I'd suggest adding
> an
> > >
> > > attribute like
> > >
> > > > scope="local|global" to the  task
> > >
> > > instead of adding
> > >
> > > > a completely
> > > > new task.
> > >
> > > I disagree here. The issue is not  by
> > > itself. This local
> > > properties need to work with every  that
> may
> > > set a property:
> > > , , ,
> ,
> > > and a million more
> > > obscure ones. The main use for  is when
> it is
> > > called without
> > > the value attribute, because in that case this
> other
> > > tasks will
> > > set the local property and not the global one.
> > >
> > > Jose Alberto
> > >
> > > > -chris
> > > >
> > > > peter reilly wrote:
> > > > > I have written the code to support local
> > >
> > > properties.
> > >
> > > > > While I was doing this, I realized that the
> > >
> > > attributes
> > >
> > > > > of a macrodef could/should be local
> properties
> > >
> > > as well,
> > >
> > > > removing some
> > > >
> > > > > of the issues seen last week (use of
> attribute
> > >
> > > in a bsf script and
> > >
> > > > > support of parallel/recursive).
> > > > >
> > > > > The following shows it in using a new task
> > >
> > > called local.
> > >
> > > > > 
> > > > >   
> > >
> > > > >   
> > > > > 
> > > > > prop1 is "${prop1}"
> > > > >   
> > > > >   
> > > > > prop1 is "${prop1}"
> > > > >   
> > > > > 
> > > > >
> > > > > This ant test2 generates the following:
> > > > >
> > > > > test1:
> > > > > prop1 is "a local value"
> > > > >
> > > > > test2:
> > > > > prop1 is "a global value"
> > > > >
> > > > > Each taskcontainer sets up a new local
> scope:
> > > > >
> > > > >   
> > > > > 
> > > > > 
> > > > >   
> > >
> > > > >   prop2 is "${prop2}"
> > > > > 
> > > > > prop2 is "${prop2}"
> > > > >   
> > > > >
> > > > > will generate the following:
> > > > > sequential:
> > > > > prop2 is "in sequential"
> > > > > prop2 is "in target"
> > > > >
> > > > > The value part of  is optional, and 
> the
> > >
> > > local
> > >
> > > > property may be
> > > >
> > > > > set by a subsequent , 
> will
> > >
> > > only set it if the
> > >
> > > > > value is not set.
> > > > >
> > > > >   
> > > > > 
> > > > > prop3 is "${prop3}"
> > > > > 
> > > > > 
> > >
> > > > > prop3 is "${prop3}"
> > > > >   
> > > > >
> > > > > will generate the following:
> > > > > notset:
> > > > > prop3 is "${prop3}"
> > > > > prop3 is "is set"
> > > > >
> > > > > prop3 is still a local variable and will not
> be
> > >
> > > seen outside the
> > >
> > > > > target.
> > > > >
> > > > > The local properties are thread local so the
> > >
> > > following
> > >
> > > > works as expected:
> > > > >   
> > > > > 
> > > > > 
> > > > >   
> > > > >  value="thread1"/>
> > > > > t1: prop4 is "${prop4}"
> > > > >   
> > > > >   
> > > > >  value="thread2"/>
> > > > > t2: prop4 is "${prop4}"
> > > > >   
> > > > >   
> > > > >  value="thread3"/>
> > > > > t3: prop4 is "${prop4}"
> > > > >   
> > > > > 
> > > > >   
> > > > >
> > > > > parallel:
> 
=== message truncated ===


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Scarab Build (Was: Re: [vote] Ant 1.6 : further release plan)

[Stefan Moebius]

The problem seems to have been in the build file. The current CVS version of
scarab builds fine using  1.6beta2 :-)

> I just tried an out-of-the-box build of scarab 1.0 b17 (scarab.tigris.org)
> with both 1.5.3 and 1.6beta: It works fine with 1.5.3 but fails with
> 1.6beta:
> 

--
Stefan


-- 
=
Stefan Moebius   <[EMAIL PROTECTED]> 
  Wittenberger Str. 71+49 351 8473953
  01309 Dresden   +49 172 8739617


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Macrodef and parallel in a recursive situation

[peter reilly]

This is basicly what the local implementation
does.

The only problem is for ant/antcall, a new project
is created and the local properties would need
to be copied to this, keeping in mind all the
rules about user/normal/inherited and nested param
elements.

Peter
On Monday 20 October 2003 16:16, Matt Benson wrote:
> Jose makes a good point about tasks that set
> properties.  Without having delved into the
> PropertyHelper* classes, could local properties be
> handled some other way?  What about a Scope
> TaskContainer subclass that would push an element onto
> a stack.  Then any property queries would descend into
> the stack... then a task that set a property could
> have that property restricted by nesting it in a set
> of  tags...
>
> -Matt
>
>
> --- Jose Alberto Fernandez <[EMAIL PROTECTED]>
>
> wrote:
> > > From: Christopher Lenz [mailto:[EMAIL PROTECTED]
> > >
> > > Hi Peter,
> > >
> > > this looks really cool, but I'd suggest adding an
> >
> > attribute like
> >
> > > scope="local|global" to the  task
> >
> > instead of adding
> >
> > > a completely
> > > new task.
> >
> > I disagree here. The issue is not  by
> > itself. This local
> > properties need to work with every  that may
> > set a property:
> > , , , ,
> > and a million more
> > obscure ones. The main use for  is when it is
> > called without
> > the value attribute, because in that case this other
> > tasks will
> > set the local property and not the global one.
> >
> > Jose Alberto
> >
> > > -chris
> > >
> > > peter reilly wrote:
> > > > I have written the code to support local
> >
> > properties.
> >
> > > > While I was doing this, I realized that the
> >
> > attributes
> >
> > > > of a macrodef could/should be local properties
> >
> > as well,
> >
> > > removing some
> > >
> > > > of the issues seen last week (use of attribute
> >
> > in a bsf script and
> >
> > > > support of parallel/recursive).
> > > >
> > > > The following shows it in using a new task
> >
> > called local.
> >
> > > > 
> > > >   
> >
> > > >   
> > > > 
> > > > prop1 is "${prop1}"
> > > >   
> > > >   
> > > > prop1 is "${prop1}"
> > > >   
> > > > 
> > > >
> > > > This ant test2 generates the following:
> > > >
> > > > test1:
> > > > prop1 is "a local value"
> > > >
> > > > test2:
> > > > prop1 is "a global value"
> > > >
> > > > Each taskcontainer sets up a new local scope:
> > > >
> > > >   
> > > > 
> > > > 
> > > >   
> >
> > > >   prop2 is "${prop2}"
> > > > 
> > > > prop2 is "${prop2}"
> > > >   
> > > >
> > > > will generate the following:
> > > > sequential:
> > > > prop2 is "in sequential"
> > > > prop2 is "in target"
> > > >
> > > > The value part of  is optional, and  the
> >
> > local
> >
> > > property may be
> > >
> > > > set by a subsequent ,  will
> >
> > only set it if the
> >
> > > > value is not set.
> > > >
> > > >   
> > > > 
> > > > prop3 is "${prop3}"
> > > > 
> > > > 
> >
> > > > prop3 is "${prop3}"
> > > >   
> > > >
> > > > will generate the following:
> > > > notset:
> > > > prop3 is "${prop3}"
> > > > prop3 is "is set"
> > > >
> > > > prop3 is still a local variable and will not be
> >
> > seen outside the
> >
> > > > target.
> > > >
> > > > The local properties are thread local so the
> >
> > following
> >
> > > works as expected:
> > > >   
> > > > 
> > > > 
> > > >   
> > > > 
> > > > t1: prop4 is "${prop4}"
> > > >   
> > > >   
> > > > 
> > > > t2: prop4 is "${prop4}"
> > > >   
> > > >   
> > > > 
> > > > t3: prop4 is "${prop4}"
> > > >   
> > > > 
> > > >   
> > > >
> > > > parallel:
> > > > t2: prop4 is "thread2"
> > > > t1: prop4 is "thread1"
> > > > t3: prop4 is "thread3"
> > > >
> > > > Use with macrodef.
> > > > -
> > > >
> > > > Attributes may now be implemented as local
> >
> > properties, which means
> >
> > > > that they will be seen as normal properties by
> >
> > ant tasks -
> >
> > > including
> > >
> > > > script.
> > > >
> > > >   
> > > > 
> > > >   
> > > >   
> > > > 
> > > >   System.out.println("x is '" +
> > >
> > > project.getProperty("x") + "'");
> > >
> > > > 
> > > >   
> > > > 
> > > >
> > > > 
> > > >   
> > > >
> > > > will generate:
> > > > macro:
> > > > x is 'this is x'
> > > >
> > > > Macrodef does not do the attribute substitutions
> >
> > so the following
> >
> > > >   
> > > > 
> > > >   
> > > >   
> > > > 
> > > >   System.out.println("x is '${x}'");
> > > > 
> > > >   
> > > > 
> > > >
> > > > 
> > > >   
> > > > will generate:
> > > > macro2:
> > > > x is '${x}'
> > > > as  does not do property expansion.
> > > >
> > > > A variation of the recurive macrodef last week
> >
> > may be done by:
> > > >   
> > > > 
> > > >   
> > > >   
> > > >   
> > > > 
> > > >   
> > > >   
> > > > 
> >
> > > >

DO NOT REPLY [Bug 23942] - Addition of a local property

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 15:51 ---
I have posted the patches, one
thing to work on is the possible
inheritances of local properties to
antcall and ant.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23942] - Addition of a local property

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 15:48 ---
Created an attachment (id=8632)
the local task

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23942] - Addition of a local property

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 15:47 ---
Created an attachment (id=8631)
Diff against HEAD for local property

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23942] New: - Addition of a local property

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942

Addition of a local property

   Summary: Addition of a local property
   Product: Ant
   Version: 1.6Beta
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


It would be nice to have a local property
as described in
http://marc.theaimsgroup.com/?l=ant-dev&m=106664032815130&w=2

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: File Delimiter for Concat Task?

[Matt Benson]

Hmm... using a replaceregex TokenFilter should have
worked, but it didn't.  I tried treating each file as
a single line of input but it still added the @ to the
end of each line when I used 



I am using the ORO matcher... is this a bug?

What about echo your @ to a file and use the new
concatfilter?

-Matt

--- Joe Parks <[EMAIL PROTECTED]> wrote:
> I would like to add/find the ability to include a
> delimiter between concatenated text when using the
>  task.
> 
> That is, for example, if I concatenate a bunch of
> SQL scripts into one file, I would like the ability
> to have an "@" symbol between each script.
> 
> Does this functionality already exist in the
>  task (and I'm just missing it)?  Or, where
> is the best place to add it?
> 
> Thanks,
> Joe
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23941] New: - move task deletes source directory

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23941

move task deletes source directory

   Summary: move task deletes source directory
   Product: Ant
   Version: 1.5.4
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


i'm trying to move xml files from one directory to another without deleting the 
source directory:


  

  


but every combination of commands i've tried so far results in deleting the 
source directory after moving the files.

is this a feature or a bug?

i need this function badly...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Macrodef and parallel in a recursive situation

[Matt Benson]

> handled some other way?  What about a Scope
> TaskContainer subclass that would push an element

I meant "implementation."

-Matt



__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

File Delimiter for Concat Task?

[Joe Parks]

I would like to add/find the ability to include a delimiter between 
concatenated text when using the  task.

That is, for example, if I concatenate a bunch of SQL scripts into one file, I 
would like the ability to have an "@" symbol between each script.

Does this functionality already exist in the  task (and I'm just 
missing it)?  Or, where is the best place to add it?

Thanks,
Joe

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Macrodef and parallel in a recursive situation

[Matt Benson]

Jose makes a good point about tasks that set
properties.  Without having delved into the
PropertyHelper* classes, could local properties be
handled some other way?  What about a Scope
TaskContainer subclass that would push an element onto
a stack.  Then any property queries would descend into
the stack... then a task that set a property could
have that property restricted by nesting it in a set
of  tags...

-Matt


--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> > From: Christopher Lenz [mailto:[EMAIL PROTECTED] 
> > 
> > Hi Peter,
> > 
> > this looks really cool, but I'd suggest adding an
> attribute like 
> > scope="local|global" to the  task
> instead of adding 
> > a completely 
> > new task.
> > 
> 
> I disagree here. The issue is not  by
> itself. This local
> properties need to work with every  that may
> set a property:
> , , , ,
> and a million more
> obscure ones. The main use for  is when it is
> called without
> the value attribute, because in that case this other
> tasks will
> set the local property and not the global one.
> 
> Jose Alberto
> 
> > -chris
> > 
> > peter reilly wrote:
> > > I have written the code to support local
> properties.
> > > While I was doing this, I realized that the
> attributes
> > > of a macrodef could/should be local properties
> as well, 
> > removing some 
> > > of the issues seen last week (use of attribute
> in a bsf script and 
> > > support of parallel/recursive).
> > > 
> > > The following shows it in using a new task
> called local.
> > > 
> > > 
> > >   
> > >   
> > > 
> > > prop1 is "${prop1}"
> > >   
> > >   
> > > prop1 is "${prop1}"
> > >   
> > > 
> > > 
> > > This ant test2 generates the following:
> > > 
> > > test1:
> > > prop1 is "a local value"
> > > 
> > > test2:
> > > prop1 is "a global value"
> > > 
> > > Each taskcontainer sets up a new local scope:
> > > 
> > >   
> > > 
> > > 
> > >   
> > >   prop2 is "${prop2}"
> > > 
> > > prop2 is "${prop2}"
> > >   
> > > 
> > > will generate the following:
> > > sequential:
> > > prop2 is "in sequential"
> > > prop2 is "in target"
> > > 
> > > The value part of  is optional, and  the
> local 
> > property may be 
> > > set by a subsequent ,  will
> only set it if the 
> > > value is not set.
> > > 
> > >   
> > > 
> > > prop3 is "${prop3}"
> > > 
> > > 
> > > prop3 is "${prop3}"
> > >   
> > > 
> > > will generate the following:
> > > notset:
> > > prop3 is "${prop3}"
> > > prop3 is "is set"
> > > 
> > > prop3 is still a local variable and will not be
> seen outside the 
> > > target.
> > > 
> > > The local properties are thread local so the
> following 
> > works as expected:
> > >   
> > > 
> > > 
> > >   
> > > 
> > > t1: prop4 is "${prop4}"
> > >   
> > >   
> > > 
> > > t2: prop4 is "${prop4}"
> > >   
> > >   
> > > 
> > > t3: prop4 is "${prop4}"
> > >   
> > > 
> > >   
> > > 
> > > parallel:
> > > t2: prop4 is "thread2"
> > > t1: prop4 is "thread1"
> > > t3: prop4 is "thread3"
> > > 
> > > Use with macrodef.
> > > -
> > > 
> > > Attributes may now be implemented as local
> properties, which means 
> > > that they will be seen as normal properties by
> ant tasks - 
> > including 
> > > script.
> > > 
> > >   
> > > 
> > >   
> > >   
> > > 
> > >   System.out.println("x is '" + 
> > project.getProperty("x") + "'");
> > > 
> > >   
> > > 
> > > 
> > > 
> > >   
> > > 
> > > will generate:
> > > macro:
> > > x is 'this is x'
> > > 
> > > Macrodef does not do the attribute substitutions
> so the following
> > >   
> > > 
> > >   
> > >   
> > > 
> > >   System.out.println("x is '${x}'");
> > > 
> > >   
> > > 
> > > 
> > > 
> > >   
> > > will generate:
> > > macro2:
> > > x is '${x}'
> > > as  does not do property expansion.
> > > 
> > > A variation of the recurive macrodef last week
> may be done by:
> > >   
> > > 
> > >   
> > >   
> > >   
> > > 
> > >   
> > >   
> > > 
> > >   
> > >   
> > >  > >   datatype  = "int"
> > >   operand1  = "${current}"
> > >   operation = "-"
> > >   operand2  = "1"
> > >   result= "current"
> > >   />
> > > 
> 
=== message truncated ===


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Official (reserved?) namespace of Ant itself???

[Dominique Devienne]

> From: peter reilly [mailto:[EMAIL PROTECTED]
> 
> The default ns for ant is "ant:core".
> 
>   xmlns:ant="ant:core"
>  xmlns:ac="antlib:net.sf.antcontrib">

Thanks. Setting the correct namespace works. Note that the error message I
was getting was not very user friendly...

OK, but! Imagine I was to be able to validate from the outside a build file
using several AntLibs, or write a build file editor with context sensitive
completion for attribute names (and values sometimes) and nested elements.
One obvious way to do that would be to read all the top-level AntLib
declarations, which give you an entry point into what types the these AntLib
declares. By having a NS of ant:core, you have to special case the Core.

If the NS was antlib:org.apache.tools.ant OTOH, with the proper antlib.xml
in Ant's own JAR, then it's 'just' another AntLib...

Sure, NSs can be declared not at top-level, or AntLibs not declared in a
namespace at all, or in just a taskdef, etc... I still see value in the
picture above, provided build file are written using the restriction of
having all AntLib's in ant/lib and declared using a top-level antlib:
shortcut. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Problems with XMLCatalog

[Jose Alberto Fernandez]

Hi,

has anyone had a chance to look at the XMLCatalog problem I reported
during the weekend? I saw comments about the script issue I reported
but not about the XMLCatalog.

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Ant1.6 beta1]

[Dominique Devienne]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> On Thu, 16 Oct 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > Could these two dates either be removed,
> 
> done.

Thank!

> > or changed back to plain text (instead of keyword)?
> 
> The problem is/was that nobody bothered to update them.

Yes, which is why I proposed to remove it ;-)
The info's all in CVS after all.

Thanks again, --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/helper AntXMLContext.java ProjectHelper2.java

[peterreilly]

peterreilly2003/10/20 07:18:35

  Modified:src/main/org/apache/tools/ant/helper Tag: ANT_16_BRANCH
AntXMLContext.java ProjectHelper2.java
  Log:
  Merge with head
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.4.2.1   +1 -0  
ant/src/main/org/apache/tools/ant/helper/AntXMLContext.java
  
  Index: AntXMLContext.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/helper/AntXMLContext.java,v
  retrieving revision 1.4
  retrieving revision 1.4.2.1
  diff -u -r1.4 -r1.4.2.1
  --- AntXMLContext.java13 Aug 2003 13:18:54 -  1.4
  +++ AntXMLContext.java20 Oct 2003 14:18:35 -  1.4.2.1
  @@ -135,6 +135,7 @@
*/
   public AntXMLContext(Project project) {
   this.project = project;
  +implicitTarget.setProject(project);
   implicitTarget.setName("");
   targetVector.addElement(implicitTarget);
   }
  
  
  
  1.33.2.1  +2 -0  
ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java
  
  Index: ProjectHelper2.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java,v
  retrieving revision 1.33
  retrieving revision 1.33.2.1
  diff -u -r1.33 -r1.33.2.1
  --- ProjectHelper2.java   17 Sep 2003 14:13:53 -  1.33
  +++ ProjectHelper2.java   20 Oct 2003 14:18:35 -  1.33.2.1
  @@ -157,6 +157,7 @@
   Target currentTarget = context.getCurrentTarget();
   try {
   Target newCurrent = new Target();
  +newCurrent.setProject(project);
   newCurrent.setName("");
   context.setCurrentTarget(newCurrent);
   parse(project, source, new RootHandler(context, 
mainHandler));
  @@ -790,6 +791,7 @@
   
   Project project = context.getProject();
   Target target = new Target();
  +target.setProject(project);
   context.addTarget(target);
   
   for (int i = 0; i < attrs.getLength(); i++) {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Ant 1.6beta1] Missing stylesheet?

[Dominique Devienne]

> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
> 
> On Fri, 17 Oct 2003 01:40 am, Dominique Devienne wrote:
> > I'm putting Ant 1.6beta1 under CVS on top of the Ant 1.5.3 we have, and
> I
> > noticed the new etc/ant-bootstrap.jar (reported in another post), but
> also
> > that checkstyle-frames.xsl seems to have disappeared! Is this normal?
> Where
> > is it now?
> 
> I moved it to src/etc/checkstyle.
> 
> I improved the stylesheet in a few ways and also addeed one to generate a
> text
> report (and a xdoc version but that may be of less interest). Is it
> important
> to keep it in the same location?

What I think is important is that it's in the release ;-) Seems like somehow
checkstyle-frames.xsl is not making it in the release 1.6betaX of Ant. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/helper AntXMLContext.java ProjectHelper2.java

[peterreilly]

peterreilly2003/10/20 07:13:40

  Modified:src/main/org/apache/tools/ant/helper AntXMLContext.java
ProjectHelper2.java
  Log:
  set project for created targets
  
  Revision  ChangesPath
  1.5   +1 -0  
ant/src/main/org/apache/tools/ant/helper/AntXMLContext.java
  
  Index: AntXMLContext.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/helper/AntXMLContext.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- AntXMLContext.java13 Aug 2003 13:18:54 -  1.4
  +++ AntXMLContext.java20 Oct 2003 14:13:40 -  1.5
  @@ -135,6 +135,7 @@
*/
   public AntXMLContext(Project project) {
   this.project = project;
  +implicitTarget.setProject(project);
   implicitTarget.setName("");
   targetVector.addElement(implicitTarget);
   }
  
  
  
  1.34  +2 -0  
ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java
  
  Index: ProjectHelper2.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- ProjectHelper2.java   17 Sep 2003 14:13:53 -  1.33
  +++ ProjectHelper2.java   20 Oct 2003 14:13:40 -  1.34
  @@ -157,6 +157,7 @@
   Target currentTarget = context.getCurrentTarget();
   try {
   Target newCurrent = new Target();
  +newCurrent.setProject(project);
   newCurrent.setName("");
   context.setCurrentTarget(newCurrent);
   parse(project, source, new RootHandler(context, 
mainHandler));
  @@ -790,6 +791,7 @@
   
   Project project = context.getProject();
   Target target = new Target();
  +target.setProject(project);
   context.addTarget(target);
   
   for (int i = 0; i < attrs.getLength(); i++) {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Macrodef and parallel in a recursive situation

[Jose Alberto Fernandez]

> From: peter reilly [mailto:[EMAIL PROTECTED] 
> 
> On Monday 20 October 2003 13:25, Jose Alberto Fernandez wrote:
> >
> > So what do I get on the ant/antcall/subant side of things?
> > Do I get the original global value? Or nothing?
> 
> The original global value.
> 

I think I have misgivings about this. I may understand assumming
the local as undefined in the call (not inherited), but skiping it and
passing
an old value from the stack, sounds to say the least very confusing
if not wrong. 

The worst part is that there is no way for me to know what is the value
being passed. In the following fragment:

  

  

  

  

  

  

There is no way for me to know what would be the value of "a" in the
antcall. There is no
way to know what the  is actually sending, because the variable
is hidden
behind two levels of local. Which means it is more difficult to
encapsulate code.

Jose Alberto

> > If I need to pass this value, does that mean I need to use  
> > explicitly?
> 
> Yes, one would need to use  explicity
> 
> > This would have to be documented very well
> > because it may be confusing otherwise.
> 
> Indeed..
> >
> > I understand your selection in the context of the attributes of 
> >  but I was thinking on the general case. So let 
> at least add
> > a strong usage description in the docs for .
> 
> Another reason is that I wanted the local properties to be 
> staticly scoped. However in the implementation this is not 
> really the case in that tasks have access to the properties - 
> see the script example.
> 
> Yet another reason is that the Ant.java does a *lot* of 
> messing with properties. It is quite possible any 
> modificiation would cause problems to current scripts.
> 
> Peter
> 
> >
> > Jose Alberto
> > PS: BTW I think this is one of the best features we have 
> added to ANT 
> > so I hope it manages to get to 1.6. With this feature alone one can 
> > get rid of all those anoying properties whose only reason for 
> > existance was passing a value between two tasks.
> >
> > > Peter
> > >
> > > > Jose Alberto
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Macrodef and parallel in a recursive situation

[peter reilly]

On Monday 20 October 2003 13:38, Christopher Lenz wrote:
> Hi Peter,
>
> this looks really cool, but I'd suggest adding an attribute like
> scope="local|global" to the  task instead of adding a completely
> new task.

I had thought of that but shyed away for the moment as
the property task allows mass setting of properties with
the file, resource, url and environment attributes.

It is also used as a nested element by a number of
tasks - ant and antcall being examples.

Peter

>
> -chris
>
> peter reilly wrote:
> > I have written the code to support local properties.
> > While I was doing this, I realized that the attributes
> > of a macrodef could/should be local properties as well,
> > removing some of the issues seen last week (use of
> > attribute in a bsf script and support of parallel/recursive).
> >
> > The following shows it in using a new task called local.
> >
> > 
> >   
> >   
> > 
> > prop1 is "${prop1}"
> >   
> >   
> > prop1 is "${prop1}"
> >   
> > 
> >
> > This ant test2 generates the following:
> >
> > test1:
> > prop1 is "a local value"
> >
> > test2:
> > prop1 is "a global value"
> >
> > Each taskcontainer sets up a new local scope:
> >
> >   
> > 
> > 
> >   
> >   prop2 is "${prop2}"
> > 
> > prop2 is "${prop2}"
> >   
> >
> > will generate the following:
> > sequential:
> > prop2 is "in sequential"
> > prop2 is "in target"
> >
> > The value part of  is optional, and  the local
> > property may be set by a subsequent , 
> > will only set it if the value is not set.
> >
> >   
> > 
> > prop3 is "${prop3}"
> > 
> > 
> > prop3 is "${prop3}"
> >   
> >
> > will generate the following:
> > notset:
> > prop3 is "${prop3}"
> > prop3 is "is set"
> >
> > prop3 is still a local variable and will not be seen outside the target.
> >
> > The local properties are thread local so the following works as expected:
> >   
> > 
> > 
> >   
> > 
> > t1: prop4 is "${prop4}"
> >   
> >   
> > 
> > t2: prop4 is "${prop4}"
> >   
> >   
> > 
> > t3: prop4 is "${prop4}"
> >   
> > 
> >   
> >
> > parallel:
> > t2: prop4 is "thread2"
> > t1: prop4 is "thread1"
> > t3: prop4 is "thread3"
> >
> > Use with macrodef.
> > -
> >
> > Attributes may now be implemented as local properties, which means that
> > they will be seen as normal properties by ant tasks - including script.
> >
> >   
> > 
> >   
> >   
> > 
> >   System.out.println("x is '" + project.getProperty("x") + "'");
> > 
> >   
> > 
> >
> > 
> >   
> >
> > will generate:
> > macro:
> > x is 'this is x'
> >
> > Macrodef does not do the attribute substitutions so the following
> >   
> > 
> >   
> >   
> > 
> >   System.out.println("x is '${x}'");
> > 
> >   
> > 
> >
> > 
> >   
> > will generate:
> > macro2:
> > x is '${x}'
> > as  does not do property expansion.
> >
> > A variation of the recurive macrodef last week may be done by:
> >   
> > 
> >   
> >   
> >   
> > 
> >   
> >   
> > 
> >   
> >   
> >  >   datatype  = "int"
> >   operand1  = "${current}"
> >   operation = "-"
> >   operand2  = "1"
> >   result= "current"
> >   />
> > 
> > 
> > 
> >   
> > 
> >   
> > 
> >
> > 
> >   
> >   
> >   
> > 
> >   
> >
> > The output is:
> > recur:
> > T: 3, C: 1
> > T: 1, C: 4
> > T: 2, C: 5
> > T: 3, C: 0
> > T: 1, C: 3
> > T: 2, C: 4
> > Thread: 3 done
> > T: 1, C: 2
> > T: 2, C: 3
> > T: 1, C: 1
> > T: 2, C: 2
> > T: 1, C: 0
> > T: 2, C: 1
> > Thread: 1 done
> > T: 2, C: 0
> > Thread: 2 done
> >
> >
> >
> > I realize that it is late in the day to get this
> > into ant1.6, but I think that it will make macrodef
> > much more usefull and easy to port current antcalls.
> >
> > The changes are quite small (mostly to PropertyHelper).
> >
> > Peter
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Macrodef and parallel in a recursive situation

[Jose Alberto Fernandez]

> From: Christopher Lenz [mailto:[EMAIL PROTECTED] 
> 
> Hi Peter,
> 
> this looks really cool, but I'd suggest adding an attribute like 
> scope="local|global" to the  task instead of adding 
> a completely 
> new task.
> 

I disagree here. The issue is not  by itself. This local
properties need to work with every  that may set a property:
, , , , and a million more
obscure ones. The main use for  is when it is called without
the value attribute, because in that case this other tasks will
set the local property and not the global one.

Jose Alberto

> -chris
> 
> peter reilly wrote:
> > I have written the code to support local properties.
> > While I was doing this, I realized that the attributes
> > of a macrodef could/should be local properties as well, 
> removing some 
> > of the issues seen last week (use of attribute in a bsf script and 
> > support of parallel/recursive).
> > 
> > The following shows it in using a new task called local.
> > 
> > 
> >   
> >   
> > 
> > prop1 is "${prop1}"
> >   
> >   
> > prop1 is "${prop1}"
> >   
> > 
> > 
> > This ant test2 generates the following:
> > 
> > test1:
> > prop1 is "a local value"
> > 
> > test2:
> > prop1 is "a global value"
> > 
> > Each taskcontainer sets up a new local scope:
> > 
> >   
> > 
> > 
> >   
> >   prop2 is "${prop2}"
> > 
> > prop2 is "${prop2}"
> >   
> > 
> > will generate the following:
> > sequential:
> > prop2 is "in sequential"
> > prop2 is "in target"
> > 
> > The value part of  is optional, and  the local 
> property may be 
> > set by a subsequent ,  will only set it if the 
> > value is not set.
> > 
> >   
> > 
> > prop3 is "${prop3}"
> > 
> > 
> > prop3 is "${prop3}"
> >   
> > 
> > will generate the following:
> > notset:
> > prop3 is "${prop3}"
> > prop3 is "is set"
> > 
> > prop3 is still a local variable and will not be seen outside the 
> > target.
> > 
> > The local properties are thread local so the following 
> works as expected:
> >   
> > 
> > 
> >   
> > 
> > t1: prop4 is "${prop4}"
> >   
> >   
> > 
> > t2: prop4 is "${prop4}"
> >   
> >   
> > 
> > t3: prop4 is "${prop4}"
> >   
> > 
> >   
> > 
> > parallel:
> > t2: prop4 is "thread2"
> > t1: prop4 is "thread1"
> > t3: prop4 is "thread3"
> > 
> > Use with macrodef.
> > -
> > 
> > Attributes may now be implemented as local properties, which means 
> > that they will be seen as normal properties by ant tasks - 
> including 
> > script.
> > 
> >   
> > 
> >   
> >   
> > 
> >   System.out.println("x is '" + 
> project.getProperty("x") + "'");
> > 
> >   
> > 
> > 
> > 
> >   
> > 
> > will generate:
> > macro:
> > x is 'this is x'
> > 
> > Macrodef does not do the attribute substitutions so the following
> >   
> > 
> >   
> >   
> > 
> >   System.out.println("x is '${x}'");
> > 
> >   
> > 
> > 
> > 
> >   
> > will generate:
> > macro2:
> > x is '${x}'
> > as  does not do property expansion.
> > 
> > A variation of the recurive macrodef last week may be done by:
> >   
> > 
> >   
> >   
> >   
> > 
> >   
> >   
> > 
> >   
> >   
> >  >   datatype  = "int"
> >   operand1  = "${current}"
> >   operation = "-"
> >   operand2  = "1"
> >   result= "current"
> >   />
> > 
> > 
> > 
> >   
> > 
> >   
> > 
> > 
> > 
> >   
> >   
> >   
> > 
> >   
> > 
> > The output is:
> > recur:
> > T: 3, C: 1
> > T: 1, C: 4
> > T: 2, C: 5
> > T: 3, C: 0
> > T: 1, C: 3
> > T: 2, C: 4
> > Thread: 3 done
> > T: 1, C: 2
> > T: 2, C: 3
> > T: 1, C: 1
> > T: 2, C: 2
> > T: 1, C: 0
> > T: 2, C: 1
> > Thread: 1 done
> > T: 2, C: 0
> > Thread: 2 done
> > 
> > 
> > 
> > I realize that it is late in the day to get this
> > into ant1.6, but I think that it will make macrodef
> > much more usefull and easy to port current antcalls.
> > 
> > The changes are quite small (mostly to PropertyHelper).
> > 
> > Peter
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Macrodef and parallel in a recursive situation

[peter reilly]

On Monday 20 October 2003 13:25, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > On Monday 20 October 2003 11:43, Jose Alberto Fernandez wrote:
> > > Peter,
> > >
> > > sounds great. How does your implementation using threadLocal works
> > > when going across  or ? Just curious.
> >
> > The local properties do not cross to the ant/antcall project.
> >
> > They could but I figured that as they are "local", they do
> > not need to.
>
> So what do I get on the ant/antcall/subant side of things?
> Do I get the original global value? Or nothing?

The original global value.

> If I need to pass this value, does that mean I need to use
>  explicitly?

Yes, one would need to use  explicity

> This would have to be documented very well
> because it may be confusing otherwise.

Indeed..
>
> I understand your selection in the context of the attributes of
> 
> but I was thinking on the general case. So let at least add
> a strong usage description in the docs for .

Another reason is that I wanted the local properties to be
staticly scoped. However in the implementation this is
not really the case in that tasks have access to the properties -
see the script example.

Yet another reason is that the Ant.java does a *lot* of messing
with properties. It is quite possible any modificiation would
cause problems to current scripts.

Peter

>
> Jose Alberto
> PS: BTW I think this is one of the best features we have added to ANT
> so I hope it manages to get to 1.6. With this feature alone
> one can get rid of all those anoying properties whose only reason for
> existance was passing a value between two tasks.
>
> > Peter
> >
> > > Jose Alberto
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23937] New: - applay command for external execution command are failed for nested build.xml files

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23937

applay command for external execution command are failed for nested build.xml 
files

   Summary: applay command for external execution command are failed
for nested build.xml files
   Product: Ant
   Version: 1.5.3
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


i'm creating integration build.
one of subcomponent use bat files for building process.

also this subcomponent use xml build control file.

if i'm start building of subproject, then all is ok.

if i'm invoke integration build, then i catching the next exception 
Execute failed: java.io.IOException: CreateProcess: compile.bat

if i place dummy bat file (with correct name, in my case compile.bat) in 
directory with integration build.xml, then all is ok.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Macrodef and parallel in a recursive situation

[Christopher Lenz]

Hi Peter,
this looks really cool, but I'd suggest adding an attribute like 
scope="local|global" to the  task instead of adding a completely 
new task.

-chris
peter reilly wrote:
I have written the code to support local properties.
While I was doing this, I realized that the attributes
of a macrodef could/should be local properties as well,
removing some of the issues seen last week (use of
attribute in a bsf script and support of parallel/recursive).
The following shows it in using a new task called local.

  
  

prop1 is "${prop1}"
  
  
prop1 is "${prop1}"
  

This ant test2 generates the following:
test1:
prop1 is "a local value"
test2:
prop1 is "a global value"
Each taskcontainer sets up a new local scope:
  


  
  prop2 is "${prop2}"

prop2 is "${prop2}"
  
will generate the following:
sequential:
prop2 is "in sequential"
prop2 is "in target"
The value part of  is optional, and  the local
property may be set by a subsequent , 
will only set it if the value is not set.
  

prop3 is "${prop3}"


prop3 is "${prop3}"
  
will generate the following:
notset:
prop3 is "${prop3}"
prop3 is "is set"
prop3 is still a local variable and will not be seen outside the target.
The local properties are thread local so the following works as expected:
  


  

t1: prop4 is "${prop4}"
  
  

t2: prop4 is "${prop4}"
  
  

t3: prop4 is "${prop4}"
  

  
parallel:
t2: prop4 is "thread2"
t1: prop4 is "thread1"
t3: prop4 is "thread3"
Use with macrodef.
-
Attributes may now be implemented as local properties, which means that
they will be seen as normal properties by ant tasks - including script.
  

  
  

  System.out.println("x is '" + project.getProperty("x") + "'");

  


  
will generate:
macro:
x is 'this is x'
Macrodef does not do the attribute substitutions so the following
  

  
  

  System.out.println("x is '${x}'");

  


  
will generate:
macro2:
x is '${x}'
as  does not do property expansion.
A variation of the recurive macrodef last week may be done by:
  

  
  
  

  
  

  
  

  datatype  = "int"
  operand1  = "${current}"
  operation = "-"
  operand2  = "1"
  result= "current"
  />



  

  



  
  
  

  

The output is:
recur:
T: 3, C: 1
T: 1, C: 4
T: 2, C: 5
T: 3, C: 0
T: 1, C: 3
T: 2, C: 4
Thread: 3 done
T: 1, C: 2
T: 2, C: 3
T: 1, C: 1
T: 2, C: 2
T: 1, C: 0
T: 2, C: 1
Thread: 1 done
T: 2, C: 0
Thread: 2 done

I realize that it is late in the day to get this
into ant1.6, but I think that it will make macrodef
much more usefull and easy to port current antcalls.
The changes are quite small (mostly to PropertyHelper).
Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Macrodef and parallel in a recursive situation

[Jose Alberto Fernandez]

> From: peter reilly [mailto:[EMAIL PROTECTED] 
> 
> On Monday 20 October 2003 11:43, Jose Alberto Fernandez wrote:
> > Peter,
> >
> > sounds great. How does your implementation using threadLocal works 
> > when going across  or ? Just curious.
> 
> The local properties do not cross to the ant/antcall project.
> 
> They could but I figured that as they are "local", they do
> not need to.

So what do I get on the ant/antcall/subant side of things? 
Do I get the original global value? Or nothing?
If I need to pass this value, does that mean I need to use
 explicitly? This would have to be documented very well
because it may be confusing otherwise.

I understand your selection in the context of the attributes of

but I was thinking on the general case. So let at least add
a strong usage description in the docs for .

Jose Alberto
PS: BTW I think this is one of the best features we have added to ANT
so I hope it manages to get to 1.6. With this feature alone
one can get rid of all those anoying properties whose only reason for
existance was passing a value between two tasks.

> Peter
> 
> >
> > Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23935] New: - Timeout on task -> no ant properties in custom resultformatter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23935

Timeout on  task -> no ant properties in custom resultformatter

   Summary: Timeout on  task -> no ant properties in custom
resultformatter
   Product: Ant
   Version: 1.6Beta
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]



  [...]
  
  [...]


-

package org.example;

public class MyResultFormatter implements JUnitResultFormatter {
  [...]
  public void startTestSuite(JUnitTest suite) throws BuildException {
//Get the ant properties
Properties antProperties = suite.getProperties();
String foo = antProperties.getProperty("foo");
[...]
  }
  [...]
}

Results in a NullPointerException.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Macrodef and parallel in a recursive situation

[peter reilly]

On Monday 20 October 2003 11:43, Jose Alberto Fernandez wrote:
> Peter,
>
> sounds great. How does your implementation using threadLocal
> works when going across  or ? Just curious.

The local properties do not cross to the ant/antcall project.

They could but I figured that as they are "local", they do
not need to.
Peter

>
> Jose Alberto
>
> > -Original Message-
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> > Sent: 20 October 2003 09:59
> > To: Ant Developers List
> > Subject: Re: Macrodef and parallel in a recursive situation
> >
> >
> > I have written the code to support local properties.
> > While I was doing this, I realized that the attributes
> > of a macrodef could/should be local properties as well,
> > removing some of the issues seen last week (use of attribute
> > in a bsf script and support of parallel/recursive).
> >
> > The following shows it in using a new task called local.
> >
> > 
> >   
> >   
> > 
> > prop1 is "${prop1}"
> >   
> >   
> > prop1 is "${prop1}"
> >   
> > 
> >
> > This ant test2 generates the following:
> >
> > test1:
> > prop1 is "a local value"
> >
> > test2:
> > prop1 is "a global value"
> >
> > Each taskcontainer sets up a new local scope:
> >
> >   
> > 
> > 
> >   
> >   prop2 is "${prop2}"
> > 
> > prop2 is "${prop2}"
> >   
> >
> > will generate the following:
> > sequential:
> > prop2 is "in sequential"
> > prop2 is "in target"
> >
> > The value part of  is optional, and  the local
> > property may be set by a subsequent , 
> > will only set it if the value is not set.
> >
> >   
> > 
> > prop3 is "${prop3}"
> > 
> > 
> > prop3 is "${prop3}"
> >   
> >
> > will generate the following:
> > notset:
> > prop3 is "${prop3}"
> > prop3 is "is set"
> >
> > prop3 is still a local variable and will not be seen outside
> > the target.
> >
> > The local properties are thread local so the following works
> > as expected:
> >   
> > 
> > 
> >   
> > 
> > t1: prop4 is "${prop4}"
> >   
> >   
> > 
> > t2: prop4 is "${prop4}"
> >   
> >   
> > 
> > t3: prop4 is "${prop4}"
> >   
> > 
> >   
> >
> > parallel:
> > t2: prop4 is "thread2"
> > t1: prop4 is "thread1"
> > t3: prop4 is "thread3"
> >
> > Use with macrodef.
> > -
> >
> > Attributes may now be implemented as local properties, which
> > means that they will be seen as normal properties by ant
> > tasks - including script.
> >
> >   
> > 
> >   
> >   
> > 
> >   System.out.println("x is '" +
> > project.getProperty("x") + "'");
> > 
> >   
> > 
> >
> > 
> >   
> >
> > will generate:
> > macro:
> > x is 'this is x'
> >
> > Macrodef does not do the attribute substitutions so the following
> >   
> > 
> >   
> >   
> > 
> >   System.out.println("x is '${x}'");
> > 
> >   
> > 
> >
> > 
> >   
> > will generate:
> > macro2:
> > x is '${x}'
> > as  does not do property expansion.
> >
> > A variation of the recurive macrodef last week may be done by:
> >   
> > 
> >   
> >   
> >   
> > 
> >   
> >   
> > 
> >   
> >   
> >  >   datatype  = "int"
> >   operand1  = "${current}"
> >   operation = "-"
> >   operand2  = "1"
> >   result= "current"
> >   />
> > 
> > 
> > 
> >   
> > 
> >   
> > 
> >
> > 
> >   
> >   
> >   
> > 
> >   
> >
> > The output is:
> > recur:
> > T: 3, C: 1
> > T: 1, C: 4
> > T: 2, C: 5
> > T: 3, C: 0
> > T: 1, C: 3
> > T: 2, C: 4
> > Thread: 3 done
> > T: 1, C: 2
> > T: 2, C: 3
> > T: 1, C: 1
> > T: 2, C: 2
> > T: 1, C: 0
> > T: 2, C: 1
> > Thread: 1 done
> > T: 2, C: 0
> > Thread: 2 done
> >
> >
> >
> > I realize that it is late in the day to get this
> > into ant1.6, but I think that it will make macrodef
> > much more usefull and easy to port current antcalls.
> >
> > The changes are quite small (mostly to PropertyHelper).
> >
> > Peter
> >
> > On Saturday 18 October 2003 16:22, Jose Alberto Fernandez wrote:
> > > > From: peter reilly [mailto:[EMAIL PROTECTED]
> > > >
> > > > I think that we may need a thread local variable to
> > > > handle parallel.
> > > >
> > > > This would mean some deep messing with the Property handling.
> > >
> > > I do not see how thread locals would help here. I guess the
> >
> > question
> >
> > > is whether tasks in parallel should be able to modify the global
> > > properties in the frame, or should the changes be local to the
> > > parallel branch (and somehow joined at the end of execution).
> > >
> > > That would mean each parallel computation branch is independent. I
> > > guess I am suggesting the second type of implementation
> >
> > proposed for
> >
> > >  to be used inste

DO NOT REPLY [Bug 23919] - [PATCH] nighlty build and ant 1.6 not buildable with jdk 1.2.2

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23919

[PATCH] nighlty build and ant 1.6 not buildable with jdk 1.2.2

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 AssignedTo|[EMAIL PROTECTED]  |[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 11:28 ---
Martin Kruithof says : 
"Because of encoding issues the following files cannot be build using
java version "1.2.2"
Classic VM (build JDK-1.2.2_016, green threads, nojit)
at least on linux. ..."

I am OK to checkin the patches of Martijn in both the ant1.6 and the main
branches. I am surprised that we have to change Matèrne into Materne (remove
accents) to make ant build, but if this is needed, let it be.

Unless someone voices a concern, I will check in the patches this evening.

Antoine

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Ant 1.6beta2] Problem with task and ant-launcher.jar

[Christopher Lenz]

Stefan Bodewig wrote:
On Sun, 19 Oct 2003, Christopher Lenz <[EMAIL PROTECTED]> wrote:
The corresponding  invocation does not specifiy the
"includeantruntime" attribute, which defaults to true. So the Ant
runtime should be included in the classpath. However, the
ant-launcher.jar doesn't seem to be on the classpath here.
I'm not really sure whether it must be there, but it should be now
(using CVS HEAD).  includeantruntime="true" is supposed to put enough
of Ant into the CLASSPATH to run Ant's JUnit testrunner, and this
doesn't need ant-launcher.jar.
It used to include all of Ant in Ant 1.5.x, but this is no longer true
since we've split up optional.jar.  I've added ant-launcher.jar so
that you now should have enough in CLASSPATH to actually run Ant, but
you may find that you don't have access to any optional tasks.
Okay, thanks a lot Stefan. I'll try the change as soon as possible.
-chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

WG: ant FTP task: pb with date handling

[Antoine Lévy-Lambert]

Hi commons-user,

the ant ftp task is based on commons-net.

Is it possible to build into commons-net support for French locale directory
listings (so that dates and times are recognized).

Or is it supposed to be already there ???

Cheers,

Antoine
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 20. Oktober 2003 10:58
An: [EMAIL PROTECTED]
Betreff: ant FTP task: pb with date handling






Hi,

> *Warning: * there have been problems reported concerning the ftp get
> with newer attribute. Problems might be due to format of ls -l differing
> from what is expected by commons-net, for instance due to specificities
> of langage used by the ftp server in the directory listing. If you
> encounter such a problem, please send an email including a sample
>directory listing coming from your ftp server (ls -l on the ftp prompt).
>
> [EMAIL PROTECTED] 
>

This mail to let you know about the exotic ftp configuration I'm confronted
with
and that Ant doesn't handle well, as far as date checking is concerned
(depends or newer attribute).


The FTP servers we use are hosted by a french AIX 4.3.

Below is a sample ls -l on one of these FTP servers.

ftp> ls -l
200 PORT command successful.
150 Opening data connection for /bin/ls.
total 24
-rw-r--r--   1 wnsiduk  www   65 13 mar 2003  adviser.out
-rwxr-xr-x   1 wnsiduk  www   65 16 mai 2002  cnx.sh
-rw-r--r--   1 wnsiduk  www 1541 10 oct 16:47 smit.log
-rw-r--r--   1 wnsiduk  www0 21 fév 2003  smit.script
226 Transfer complete.


I'm not ready to propose any patch yet, as I don't master Java well enough,
but I can suggest a way of handling such situations.
I found this in TotalCommander (a file manager for Windows, and much more).

Below is a template definition I created for  TotalCommander to let it
display and sort files on date/time according to our exotic FTP listings:

Template1=pp !S*
TTT=janfévmaravrmaijunjulaoûsepoctnovdéc DD U n*

This template (see below for format definition) describes a listing
produced by an FTP server on a french AIX 4.3 we have.

Hoping this can help, I thank you for the tremendous work achieved so far
on Ant.
--
Laurent IZAC



--
Extracted from TotalCommander online help :

[...]
List of definition characters (upper/lowercase is important!):

Name-specific characters:

nFile name ( means 8 letter file name, n* see definition of *
below)

vVMS style file name: name.ext;1 or dirname.dir;1
. (a dot) Remove trailing spaces from file name and append further
characters separated by a dot (e.g. .nnn), see PC-NFSD sample
below.

Characters for date and time:
DDay
MMonth
TTT  Three letter month name (Jan, Feb, Mar, ...), supports English, German
and French.
TTT=12 month names with 3 letters each
Allows the definition of foreign language month names. Example (polish):
TTT=stylutmarkwimajczelipsiewrzpa¥lisgru

U Unix-style year/time mix, e.g. either "2000 " or "20:30" in the
same place
YYear
hHours
HHours modifier letter (a - a.m. time, p - p.m. time)
mMinutes
sSeconds

Characters for other file attributes:
SSize
S=1024Size multiplied with given value (here: 1024). Useful for servers
which return the size in blocks.
pUnix style permissions (e.g. -rwxrwxrwx, defines user rights)

ddir flag, defines a directory if this char is D or d, e.g. part of
text  or [DIR]
d=x  dir flag, the char defining a directory is given behind the = (see VOS
sample below)

Misc. characters:
*1. After any numeric field: use all digits up to first non-digit
character
 2. For name field not at line end: use all chars up to next space
 3. For name field at line end: use all chars until the end of the line
!Skip all characters until first space or end of line

$Skip all spaces/tabstops until next character or end of line
\Data continues on next line (max. 2 lines supported)
   Ignore character. Must not be at the beginning of a line, because
Windows would delete all leading spaces!
-(dash) Ignore character. Use this at the beginning of a line instead
of a space.
xExaclty 1 space. If there is a different character at this position,
ignore the whole line (e.g. to ignore lines above or below the file
listing, which show the free disk space etc).

Sample definition strings:

1. AIX Unix server:
Sample listing:

-rw-rw-r--   1 dso  posgroup2913 Mar 25 1999  .Xdefaults

drw-rw-r--   1 dso  posgroup2913 Mar 25 13:30 subdir1
Definition string:

pp   SSS TTT DD U n*

Or better:

pp !S* TTT DD U n*

Notes: The second definition is better because the owner and group names
may be longer, moving the size string to the right.

2. PC-NFSD:
Sample listing:

Re: Official (reserved?) namespace of Ant itself???

[Christopher Lenz]

peter reilly wrote:
On Monday 20 October 2003 10:53, Christopher Lenz wrote:
peter reilly wrote:
Note that introspection discovered elements are
in the ant:core namespace. This does make some
things a little difficult to use/explain:
   
 
   
 
 
   
 
 
   
 
   
Not to state the obvious, but this looks awfully wrong. 
Hence the example...
The problem which is perferable:

   
   
  blab ...
   
   
  blab..
   

or

   
   
  blab ...
   
   
  blab..
   

or both?
Hmm, not easy.
Maybe the following rule could be used: if the element defines the *name* of 
a nested element (as in addXXX, addConfiguredXXX and createXXX), the 
namespace of the element should be inherited by the nested elements. If the 
element only defines the interface of the nested element (as in add(XXX)), 
the namespace in which the concrete nested element was declared should be used.

Example 1 wouldn't be possible by the above rule AFAICT.
Example 2 would correspond to a task interface of:
  public class IfTask {
public void add(Condition c) { ... }
public TaskContainer createThen() { ... }
public TaskContainer createElse() { ... }
  }
  [or similar]
Note that I haven't really played with Antlib and namespaces in Ant yet, so 
that may very well be what's currently implemented. ;-)

-chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/docs/manual install.html

[peterreilly]

peterreilly2003/10/20 03:52:42

  Modified:docs/manual Tag: ANT_16_BRANCH install.html
  Log:
  Merge with HEAD
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.59.2.3  +2 -6  ant/docs/manual/install.html
  
  Index: install.html
  ===
  RCS file: /home/cvs/ant/docs/manual/install.html,v
  retrieving revision 1.59.2.2
  retrieving revision 1.59.2.3
  diff -u -r1.59.2.2 -r1.59.2.3
  --- install.html  14 Oct 2003 13:25:55 -  1.59.2.2
  +++ install.html  20 Oct 2003 10:52:42 -  1.59.2.3
  @@ -53,13 +53,9 @@
   
   
   For the current version of Ant, you will also need a JDK installed on
  -your system, version 1.1 or later. Some tasks work better on post-1.1 
systems;
  -some tasks only work on Java 1.2 and successors.
  -A future version of Ant -Ant 2.0- will require JDK 1.2 or later, though
  -Ant 1.x strives to retain 1.1 compatibility.
  +your system, version 1.2 or later.
   
  -Note: The Microsoft JVM/JDK is not adequate on its own, 
although the MS
  -compiler is supported.
  +Note: The Microsoft JVM/JDK is not supported.
   
   
   Note #2: If a JDK is not present, only the JRE runtime, 
then many tasks will not work.
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Ant1.6 beta1]

[Stefan Bodewig]

On Thu, 16 Oct 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:

> Could these two dates either be removed,

done.

> or changed back to plain text (instead of keyword)?

The problem is/was that nobody bothered to update them.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Ant 1.6beta2] Problem with task and ant-launcher.jar

[Stefan Bodewig]

On Sun, 19 Oct 2003, Christopher Lenz <[EMAIL PROTECTED]> wrote:

> The corresponding  invocation does not specifiy the
> "includeantruntime" attribute, which defaults to true. So the Ant
> runtime should be included in the classpath. However, the
> ant-launcher.jar doesn't seem to be on the classpath here.

I'm not really sure whether it must be there, but it should be now
(using CVS HEAD).  includeantruntime="true" is supposed to put enough
of Ant into the CLASSPATH to run Ant's JUnit testrunner, and this
doesn't need ant-launcher.jar.

It used to include all of Ant in Ant 1.5.x, but this is no longer true
since we've split up optional.jar.  I've added ant-launcher.jar so
that you now should have enough in CLASSPATH to actually run Ant, but
you may find that you don't have access to any optional tasks.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit JUnitTask.java

[bodewig]

bodewig 2003/10/20 03:48:48

  Modified:src/main/org/apache/tools/ant/taskdefs/optional/junit Tag:
ANT_16_BRANCH JUnitTask.java
  Log:
  Merge from HEAD
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.83.2.4  +2 -1  
ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java
  
  Index: JUnitTask.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java,v
  retrieving revision 1.83.2.3
  retrieving revision 1.83.2.4
  diff -u -r1.83.2.3 -r1.83.2.4
  --- JUnitTask.java14 Oct 2003 13:20:12 -  1.83.2.3
  +++ JUnitTask.java20 Oct 2003 10:48:47 -  1.83.2.4
  @@ -618,6 +618,7 @@
   public void init() {
   antRuntimeClasses = new Path(getProject());
   addClasspathEntry("/junit/framework/TestCase.class");
  +addClasspathEntry("/org/apache/tools/ant/launch/AntMain.class");
   addClasspathEntry("/org/apache/tools/ant/Task.class");
   
addClasspathEntry("/org/apache/tools/ant/taskdefs/optional/junit/JUnitTestRunner.class");
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit JUnitTask.java

[bodewig]

bodewig 2003/10/20 03:48:04

  Modified:src/main/org/apache/tools/ant/taskdefs/optional/junit
JUnitTask.java
  Log:
  Pull ant-launcher.jar into the classpath as well
  
  Revision  ChangesPath
  1.87  +2 -1  
ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java
  
  Index: JUnitTask.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java,v
  retrieving revision 1.86
  retrieving revision 1.87
  diff -u -r1.86 -r1.87
  --- JUnitTask.java14 Oct 2003 13:19:53 -  1.86
  +++ JUnitTask.java20 Oct 2003 10:48:04 -  1.87
  @@ -618,6 +618,7 @@
   public void init() {
   antRuntimeClasses = new Path(getProject());
   addClasspathEntry("/junit/framework/TestCase.class");
  +addClasspathEntry("/org/apache/tools/ant/launch/AntMain.class");
   addClasspathEntry("/org/apache/tools/ant/Task.class");
   
addClasspathEntry("/org/apache/tools/ant/taskdefs/optional/junit/JUnitTestRunner.class");
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23915] - Script task cannot cope with undefined task/type elements in buildfile

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23915

Script task cannot cope with undefined task/type elements in buildfile





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 10:47 ---
Here is an example showing the problem:


  

  a = 1

  
  

Hello world
  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/script antRun.pl runant.pl

[bodewig]

bodewig 2003/10/20 03:43:47

  Modified:src/script Tag: ANT_16_BRANCH antRun.pl runant.pl
  Log:
  Remove last-modified line
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.2.2.1   +0 -1  ant/src/script/antRun.pl
  
  Index: antRun.pl
  ===
  RCS file: /home/cvs/ant/src/script/antRun.pl,v
  retrieving revision 1.2
  retrieving revision 1.2.2.1
  diff -u -r1.2 -r1.2.2.1
  --- antRun.pl 1 Sep 2003 09:57:01 -   1.2
  +++ antRun.pl 20 Oct 2003 10:43:47 -  1.2.2.1
  @@ -11,7 +11,6 @@
   # this is akin to antRun.bat, and antRun the SH script 
   #
   # created: 2001-10-18
  -# last modified:   $Date$
   # author:  Jeff Tulley [EMAIL PROTECTED] 
   ###
   #be fussy about variables
  
  
  
  1.7.2.2   +0 -1  ant/src/script/runant.pl
  
  Index: runant.pl
  ===
  RCS file: /home/cvs/ant/src/script/runant.pl,v
  retrieving revision 1.7.2.1
  retrieving revision 1.7.2.2
  diff -u -r1.7.2.1 -r1.7.2.2
  --- runant.pl 22 Sep 2003 21:15:41 -  1.7.2.1
  +++ runant.pl 20 Oct 2003 10:43:47 -  1.7.2.2
  @@ -18,7 +18,6 @@
   # the code is not included. 
   #
   # created: 2000-8-24
  -# last modified:   $Date$
   # author:  Steve Loughran [EMAIL PROTECTED]
   ###
   #
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Macrodef and parallel in a recursive situation

[Jose Alberto Fernandez]

Peter, 

sounds great. How does your implementation using threadLocal
works when going across  or ? Just curious.

Jose Alberto

> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED] 
> Sent: 20 October 2003 09:59
> To: Ant Developers List
> Subject: Re: Macrodef and parallel in a recursive situation
> 
> 
> I have written the code to support local properties.
> While I was doing this, I realized that the attributes
> of a macrodef could/should be local properties as well, 
> removing some of the issues seen last week (use of attribute 
> in a bsf script and support of parallel/recursive).
> 
> The following shows it in using a new task called local.
> 
> 
>   
>   
> 
> prop1 is "${prop1}"
>   
>   
> prop1 is "${prop1}"
>   
> 
> 
> This ant test2 generates the following:
> 
> test1:
> prop1 is "a local value"
> 
> test2:
> prop1 is "a global value"
> 
> Each taskcontainer sets up a new local scope:
> 
>   
> 
> 
>   
>   prop2 is "${prop2}"
> 
> prop2 is "${prop2}"
>   
> 
> will generate the following:
> sequential:
> prop2 is "in sequential"
> prop2 is "in target"
> 
> The value part of  is optional, and  the local
> property may be set by a subsequent , 
> will only set it if the value is not set.
> 
>   
> 
> prop3 is "${prop3}"
> 
> 
> prop3 is "${prop3}"
>   
> 
> will generate the following:
> notset:
> prop3 is "${prop3}"
> prop3 is "is set"
> 
> prop3 is still a local variable and will not be seen outside 
> the target.
> 
> The local properties are thread local so the following works 
> as expected:
>   
> 
> 
>   
> 
> t1: prop4 is "${prop4}"
>   
>   
> 
> t2: prop4 is "${prop4}"
>   
>   
> 
> t3: prop4 is "${prop4}"
>   
> 
>   
> 
> parallel:
> t2: prop4 is "thread2"
> t1: prop4 is "thread1"
> t3: prop4 is "thread3"
> 
> Use with macrodef.
> -
> 
> Attributes may now be implemented as local properties, which 
> means that they will be seen as normal properties by ant 
> tasks - including script.
> 
>   
> 
>   
>   
> 
>   System.out.println("x is '" + 
> project.getProperty("x") + "'");
> 
>   
> 
> 
> 
>   
> 
> will generate:
> macro:
> x is 'this is x'
> 
> Macrodef does not do the attribute substitutions so the following
>   
> 
>   
>   
> 
>   System.out.println("x is '${x}'");
> 
>   
> 
> 
> 
>   
> will generate:
> macro2:
> x is '${x}'
> as  does not do property expansion.
> 
> A variation of the recurive macrodef last week may be done by:
>   
> 
>   
>   
>   
> 
>   
>   
> 
>   
>   
>datatype  = "int"
>   operand1  = "${current}"
>   operation = "-"
>   operand2  = "1"
>   result= "current"
>   />
> 
> 
> 
>   
> 
>   
> 
> 
> 
>   
>   
>   
> 
>   
> 
> The output is:
> recur:
> T: 3, C: 1
> T: 1, C: 4
> T: 2, C: 5
> T: 3, C: 0
> T: 1, C: 3
> T: 2, C: 4
> Thread: 3 done
> T: 1, C: 2
> T: 2, C: 3
> T: 1, C: 1
> T: 2, C: 2
> T: 1, C: 0
> T: 2, C: 1
> Thread: 1 done
> T: 2, C: 0
> Thread: 2 done
> 
> 
> 
> I realize that it is late in the day to get this
> into ant1.6, but I think that it will make macrodef
> much more usefull and easy to port current antcalls.
> 
> The changes are quite small (mostly to PropertyHelper).
> 
> Peter
> 
> On Saturday 18 October 2003 16:22, Jose Alberto Fernandez wrote:
> > > From: peter reilly [mailto:[EMAIL PROTECTED]
> > >
> > > I think that we may need a thread local variable to
> > > handle parallel.
> > >
> > > This would mean some deep messing with the Property handling.
> >
> > I do not see how thread locals would help here. I guess the 
> question 
> > is whether tasks in parallel should be able to modify the global 
> > properties in the frame, or should the changes be local to the 
> > parallel branch (and somehow joined at the end of execution).
> >
> > That would mean each parallel computation branch is independent. I 
> > guess I am suggesting the second type of implementation 
> proposed for 
> >  to be used instead for . I think 
> that would 
> > be a much more efficient way to do it. So here is how it would work:
> >
> > 1) Add new attribute independent (default false) to .
> >
> > 2) When independent is true, each thread will use a cloned project 
> > frame for its execution. So all properties and reference 
> manipulation 
> > will be independent of each other. When the thread ends, any new 
> > properties added in the cloned frame, will be added to the original 
> > parent frame, following the common rules for setting 
> properties. Which 
> > means that the first thread that finish will win on setting the 
> > pro

cvs commit: ant/src/script antRun.pl runant.pl

[bodewig]

bodewig 2003/10/20 03:42:41

  Modified:src/script antRun.pl runant.pl
  Log:
  Remove last-modified line
  
  Revision  ChangesPath
  1.3   +0 -1  ant/src/script/antRun.pl
  
  Index: antRun.pl
  ===
  RCS file: /home/cvs/ant/src/script/antRun.pl,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- antRun.pl 1 Sep 2003 09:57:01 -   1.2
  +++ antRun.pl 20 Oct 2003 10:42:41 -  1.3
  @@ -11,7 +11,6 @@
   # this is akin to antRun.bat, and antRun the SH script 
   #
   # created: 2001-10-18
  -# last modified:   $Date$
   # author:  Jeff Tulley [EMAIL PROTECTED] 
   ###
   #be fussy about variables
  
  
  
  1.9   +0 -1  ant/src/script/runant.pl
  
  Index: runant.pl
  ===
  RCS file: /home/cvs/ant/src/script/runant.pl,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- runant.pl 22 Sep 2003 21:10:10 -  1.8
  +++ runant.pl 20 Oct 2003 10:42:41 -  1.9
  @@ -18,7 +18,6 @@
   # the code is not included. 
   #
   # created: 2000-8-24
  -# last modified:   $Date$
   # author:  Steve Loughran [EMAIL PROTECTED]
   ###
   #
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Official (reserved?) namespace of Ant itself???

[Jose Alberto Fernandez]

I think we should stick to the XML namespace rules
as defined in XML. That is, if I get a NS-aware parser
and parse the ANT file, the resulting SAX events should
specify the correct name spaces for each element.

By correct I mean that if a task comes from an antlib
on space X, then the SAX for its start-element should be 
on X, and the SAX for all subelements defined by createBlah()
should also be in X and so on. Once an object for core
is in charged, the SAX for its elements should be in ant:core
and so on. 

Now, my question is what do I need to write in XML so that I get
that output. Notice that there are more than one way to write such XML
since you can use ns:foo="X" on any node and override the default 
from that point. 

As long as it is not worst than writing an XSLT I see no problem.

Jose Alberto

> From: peter reilly [mailto:[EMAIL PROTECTED] 
> 
> On Monday 20 October 2003 10:53, Christopher Lenz wrote:
> > peter reilly wrote:
> > > Note that introspection discovered elements are
> > > in the ant:core namespace. This does make some
> > > things a little difficult to use/explain:
> > >
> > > 
> > >   
> > > 
> > >   
> > >   
> > > 
> > >   
> > >   
> > > 
> > >   
> > > 
> >
> > Not to state the obvious, but this looks awfully wrong.
> Hence the example...
> 
> The problem which is perferable:
> 
> 
>
>
>   blab ...
>
>
>   blab..
>
> 
> 
> or
> 
>
>
>   blab ...
>
>
>   blab..
>
> 
> 
> or both?
> Peter
> 
> > Would it be
> > possible to have non-declared (i.e. 
> introspection-discovered) elements
> > inherit the namespace from the first declared ancestor? Of 
> course that
> > would need to exclude elements that correspond to built-in 
> types like
> > filesets, which again should be in the "ant:core" namespace ... :-/
> >
> > -chris
> >
> > > Peter
> > >
> > > On Monday 20 October 2003 10:05, peter reilly wrote:
> > >>The default ns for ant is "ant:core".
> > >>
> > >> > >> xmlns:ant="ant:core"
> > >> xmlns:ac="antlib:net.sf.antcontrib">
> > >>
> > >>  
> > >>This is a test!
> > >>
> > >>  echo This is also a test
> > >>
> > >>  
> > >>
> > >>
> > >>
> > >>as described in opps missing documentation.
> > >>
> > >>Peter
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23910] - \docs\manual\index.html still mentions support for JDK1.1

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23910

\docs\manual\index.html still mentions support for JDK1.1

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 10:40 ---
committed thanks,

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/docs/manual install.html

[peterreilly]

peterreilly2003/10/20 03:36:27

  Modified:docs/manual install.html
  Log:
  Remove reference to jdk 1.1
  PR: 23910
  Obtained from: Jose Alberto Fernandez
  
  Revision  ChangesPath
  1.61  +2 -6  ant/docs/manual/install.html
  
  Index: install.html
  ===
  RCS file: /home/cvs/ant/docs/manual/install.html,v
  retrieving revision 1.60
  retrieving revision 1.61
  diff -u -r1.60 -r1.61
  --- install.html  14 Oct 2003 13:25:49 -  1.60
  +++ install.html  20 Oct 2003 10:36:27 -  1.61
  @@ -52,13 +52,9 @@
   
   
   For the current version of Ant, you will also need a JDK installed on
  -your system, version 1.1 or later. Some tasks work better on post-1.1 
systems;
  -some tasks only work on Java 1.2 and successors.
  -A future version of Ant -Ant 2.0- will require JDK 1.2 or later, though
  -Ant 1.x strives to retain 1.1 compatibility.
  +your system, version 1.2 or later.
   
  -Note: The Microsoft JVM/JDK is not adequate on its own, 
although the MS
  -compiler is supported.
  +Note: The Microsoft JVM/JDK is not supported.
   
   
   Note #2: If a JDK is not present, only the JRE runtime, 
then many tasks will not work.
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Official (reserved?) namespace of Ant itself???

[peter reilly]

On Monday 20 October 2003 10:53, Christopher Lenz wrote:
> peter reilly wrote:
> > Note that introspection discovered elements are
> > in the ant:core namespace. This does make some
> > things a little difficult to use/explain:
> >
> > 
> >   
> > 
> >   
> >   
> > 
> >   
> >   
> > 
> >   
> > 
>
> Not to state the obvious, but this looks awfully wrong. 
Hence the example...

The problem which is perferable:


   
   
  blab ...
   
   
  blab..
   


or

   
   
  blab ...
   
   
  blab..
   


or both?
Peter

> Would it be
> possible to have non-declared (i.e. introspection-discovered) elements
> inherit the namespace from the first declared ancestor? Of course that
> would need to exclude elements that correspond to built-in types like
> filesets, which again should be in the "ant:core" namespace ... :-/
>
> -chris
>
> > Peter
> >
> > On Monday 20 October 2003 10:05, peter reilly wrote:
> >>The default ns for ant is "ant:core".
> >>
> >> >> xmlns:ant="ant:core"
> >> xmlns:ac="antlib:net.sf.antcontrib">
> >>
> >>  
> >>This is a test!
> >>
> >>  echo This is also a test
> >>
> >>  
> >>
> >>
> >>
> >>as described in opps missing documentation.
> >>
> >>Peter
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Official (reserved?) namespace of Ant itself???

[Christopher Lenz]

peter reilly wrote:
Note that introspection discovered elements are
in the ant:core namespace. This does make some
things a little difficult to use/explain:

  

  
  

  
  

  

Not to state the obvious, but this looks awfully wrong. Would it be possible 
to have non-declared (i.e. introspection-discovered) elements inherit the 
namespace from the first declared ancestor? Of course that would need to 
exclude elements that correspond to built-in types like filesets, which 
again should be in the "ant:core" namespace ... :-/

-chris
Peter
On Monday 20 October 2003 10:05, peter reilly wrote:
The default ns for ant is "ant:core".

 
   This is a test!
   
 echo This is also a test
   
 

as described in opps missing documentation.
Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ant FTP task: pb with date handling

[laurent . izac]

Hi,

> *Warning: * there have been problems reported concerning the ftp get
> with newer attribute. Problems might be due to format of ls -l differing
> from what is expected by commons-net, for instance due to specificities
> of langage used by the ftp server in the directory listing. If you
> encounter such a problem, please send an email including a sample
>directory listing coming from your ftp server (ls -l on the ftp prompt).
>
> [EMAIL PROTECTED] 
>

This mail to let you know about the exotic ftp configuration I'm confronted
with
and that Ant doesn't handle well, as far as date checking is concerned
(depends or newer attribute).


The FTP servers we use are hosted by a french AIX 4.3.

Below is a sample ls -l on one of these FTP servers.

ftp> ls -l
200 PORT command successful.
150 Opening data connection for /bin/ls.
total 24
-rw-r--r--   1 wnsiduk  www   65 13 mar 2003  adviser.out
-rwxr-xr-x   1 wnsiduk  www   65 16 mai 2002  cnx.sh
-rw-r--r--   1 wnsiduk  www 1541 10 oct 16:47 smit.log
-rw-r--r--   1 wnsiduk  www0 21 fév 2003  smit.script
226 Transfer complete.


I'm not ready to propose any patch yet, as I don't master Java well enough,
but I can suggest a way of handling such situations.
I found this in TotalCommander (a file manager for Windows, and much more).

Below is a template definition I created for  TotalCommander to let it
display and sort files on date/time according to our exotic FTP listings:

Template1=pp !S*
TTT=janfévmaravrmaijunjulaoûsepoctnovdéc DD U n*

This template (see below for format definition) describes a listing
produced by an FTP server on a french AIX 4.3 we have.

Hoping this can help, I thank you for the tremendous work achieved so far
on Ant.
--
Laurent IZAC


--
Extracted from TotalCommander online help :

[...]
List of definition characters (upper/lowercase is important!):

Name-specific characters:

nFile name ( means 8 letter file name, n* see definition of *
below)

vVMS style file name: name.ext;1 or dirname.dir;1
. (a dot) Remove trailing spaces from file name and append further
characters separated by a dot (e.g. .nnn), see PC-NFSD sample
below.

Characters for date and time:
DDay
MMonth
TTT  Three letter month name (Jan, Feb, Mar, ...), supports English, German
and French.
TTT=12 month names with 3 letters each
Allows the definition of foreign language month names. Example (polish):
TTT=stylutmarkwimajczelipsiewrzpa¥lisgru

U Unix-style year/time mix, e.g. either "2000 " or "20:30" in the
same place
YYear
hHours
HHours modifier letter (a - a.m. time, p - p.m. time)
mMinutes
sSeconds

Characters for other file attributes:
SSize
S=1024Size multiplied with given value (here: 1024). Useful for servers
which return the size in blocks.
pUnix style permissions (e.g. -rwxrwxrwx, defines user rights)

ddir flag, defines a directory if this char is D or d, e.g. part of
text  or [DIR]
d=x  dir flag, the char defining a directory is given behind the = (see VOS
sample below)

Misc. characters:
*1. After any numeric field: use all digits up to first non-digit
character
 2. For name field not at line end: use all chars up to next space
 3. For name field at line end: use all chars until the end of the line
!Skip all characters until first space or end of line

$Skip all spaces/tabstops until next character or end of line
\Data continues on next line (max. 2 lines supported)
   Ignore character. Must not be at the beginning of a line, because
Windows would delete all leading spaces!
-(dash) Ignore character. Use this at the beginning of a line instead
of a space.
xExaclty 1 space. If there is a different character at this position,
ignore the whole line (e.g. to ignore lines above or below the file
listing, which show the free disk space etc).

Sample definition strings:

1. AIX Unix server:
Sample listing:

-rw-rw-r--   1 dso  posgroup2913 Mar 25 1999  .Xdefaults

drw-rw-r--   1 dso  posgroup2913 Mar 25 13:30 subdir1
Definition string:

pp   SSS TTT DD U n*

Or better:

pp !S* TTT DD U n*

Notes: The second definition is better because the owner and group names
may be longer, moving the size string to the right.

2. PC-NFSD:
Sample listing:

prog1exe 2,563,136 06-10-99  10:00a
temp  01-27-97   3:41p

Definition string:

.nnn  dSSS MM DD YY  hh mmH

Notes: The commas in numeric fields are detected automatically. This string
gives an error of 1 for all directories because there is no size field, but
errors up to 2 are ignored by Total Commander if there is no second
definition string - otherwise the string giving the smaller error is used.

Re: Official (reserved?) namespace of Ant itself???

[peter reilly]

Note that introspection discovered elements are
in the ant:core namespace. This does make some
things a little difficult to use/explain:


  

  
  

  
  

  


Peter
On Monday 20 October 2003 10:05, peter reilly wrote:
> The default ns for ant is "ant:core".
>
>   xmlns:ant="ant:core"
>  xmlns:ac="antlib:net.sf.antcontrib">
>
>   
> This is a test!
> 
>   echo This is also a test
> 
>   
>
> 
>
> as described in opps missing documentation.
>
> Peter
>
> On Friday 17 October 2003 21:37, Dominique Devienne wrote:
> > Peter and al.,
> >
> > I've started using Ant 1.6, and I *really* like the new support
> > for XML namespaces, so much so that I'm creating AntLibs for all
> > custom tasks I use (mine own, Ant-Contrib, CppTasks, etc...).
> >
> > One thing that's missing for me in the build snippet below is the
> > namespace URI for the default namespace (the xmlns="URI" one).
> >
> >  >  xmlns:bm="antlib:com.lgc.buildmagic">
> >
> >... 
> >
> >   
> >
> >   
> > 
> >   
> >
> >   ...
> >
> > 
> >
> > As it stands,  /  /  / 
> > are in no namespace at all. This hurts my XML sensibilities, and
> > also it will eventually hurt when people (like me) start doing
> > AntLib-specific XML validation (for editing purposes most likely)
> > using either W3C XML Schema, or Relax NG. OK, it might not be that
> > much of a problem, but still...
> >
> > Also, suppose someone would like to embeb Ant build snippets into
> > another XML document/top-level XML element from a different
> > namespace? Or even not have a default namespace at all:
> >
> > C:\oss\org_apache\antx\buildtools>ant -f empty-xmlns.xml
> > Buildfile: empty-xmlns.xml
> >
> > BUILD FAILED
> > C:\oss\org_apache\antx\buildtools\empty-xmlns.xml:8: Unexpected element
> > "ant:project" project
> >
> > Total time: 0 seconds
> > C:\oss\org_apache\antx\buildtools>type empty-xmlns.xml
> > 
> >
> > 
> >  >  xmlns:ant="Ant URI???"
> >  xmlns:bm="antlib:com.lgc.buildmagic">
> >
> >   
> > This is a test!
> > 
> >   
> >
> > 
> >
> > Shouldn't one be able to use this? Am I wrong in assuming the above
> > is valid XML, and thus should be accepted in Ant (provided Ant like
> > the URI)?
> >
> > I'd like the know the official URI for Ant 1.6, and also have the build
> > script above work correctly before Ant 1.6 ships. Thanks, --DD
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Official (reserved?) namespace of Ant itself???

[peter reilly]

The default ns for ant is "ant:core".



  
This is a test!

  echo This is also a test

  



as described in opps missing documentation.

Peter

On Friday 17 October 2003 21:37, Dominique Devienne wrote:
> Peter and al.,
>
> I've started using Ant 1.6, and I *really* like the new support
> for XML namespaces, so much so that I'm creating AntLibs for all
> custom tasks I use (mine own, Ant-Contrib, CppTasks, etc...).
>
> One thing that's missing for me in the build snippet below is the
> namespace URI for the default namespace (the xmlns="URI" one).
>
>   xmlns:bm="antlib:com.lgc.buildmagic">
>
>... 
>
>   
>
>   
> 
>   
>
>   ...
>
> 
>
> As it stands,  /  /  / 
> are in no namespace at all. This hurts my XML sensibilities, and
> also it will eventually hurt when people (like me) start doing
> AntLib-specific XML validation (for editing purposes most likely)
> using either W3C XML Schema, or Relax NG. OK, it might not be that
> much of a problem, but still...
>
> Also, suppose someone would like to embeb Ant build snippets into
> another XML document/top-level XML element from a different
> namespace? Or even not have a default namespace at all:
>
> C:\oss\org_apache\antx\buildtools>ant -f empty-xmlns.xml
> Buildfile: empty-xmlns.xml
>
> BUILD FAILED
> C:\oss\org_apache\antx\buildtools\empty-xmlns.xml:8: Unexpected element
> "ant:project" project
>
> Total time: 0 seconds
> C:\oss\org_apache\antx\buildtools>type empty-xmlns.xml
> 
>
> 
>   xmlns:ant="Ant URI???"
>  xmlns:bm="antlib:com.lgc.buildmagic">
>
>   
> This is a test!
> 
>   
>
> 
>
> Shouldn't one be able to use this? Am I wrong in assuming the above
> is valid XML, and thus should be accepted in Ant (provided Ant like
> the URI)?
>
> I'd like the know the official URI for Ant 1.6, and also have the build
> script above work correctly before Ant 1.6 ships. Thanks, --DD
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Macrodef and parallel in a recursive situation

[peter reilly]

I have written the code to support local properties.
While I was doing this, I realized that the attributes
of a macrodef could/should be local properties as well,
removing some of the issues seen last week (use of
attribute in a bsf script and support of parallel/recursive).

The following shows it in using a new task called local.


  
  

prop1 is "${prop1}"
  
  
prop1 is "${prop1}"
  


This ant test2 generates the following:

test1:
prop1 is "a local value"

test2:
prop1 is "a global value"

Each taskcontainer sets up a new local scope:

  


  
  prop2 is "${prop2}"

prop2 is "${prop2}"
  

will generate the following:
sequential:
prop2 is "in sequential"
prop2 is "in target"

The value part of  is optional, and  the local
property may be set by a subsequent , 
will only set it if the value is not set.

  

prop3 is "${prop3}"


prop3 is "${prop3}"
  

will generate the following:
notset:
prop3 is "${prop3}"
prop3 is "is set"

prop3 is still a local variable and will not be seen outside the target.

The local properties are thread local so the following works as expected:
  


  

t1: prop4 is "${prop4}"
  
  

t2: prop4 is "${prop4}"
  
  

t3: prop4 is "${prop4}"
  

  

parallel:
t2: prop4 is "thread2"
t1: prop4 is "thread1"
t3: prop4 is "thread3"

Use with macrodef.
-

Attributes may now be implemented as local properties, which means that
they will be seen as normal properties by ant tasks - including script.

  

  
  

  System.out.println("x is '" + project.getProperty("x") + "'");

  



  

will generate:
macro:
x is 'this is x'

Macrodef does not do the attribute substitutions so the following
  

  
  

  System.out.println("x is '${x}'");

  



  
will generate:
macro2:
x is '${x}'
as  does not do property expansion.

A variation of the recurive macrodef last week may be done by:
  

  
  
  

  
  

  
  




  

  



  
  
  

  

The output is:
recur:
T: 3, C: 1
T: 1, C: 4
T: 2, C: 5
T: 3, C: 0
T: 1, C: 3
T: 2, C: 4
Thread: 3 done
T: 1, C: 2
T: 2, C: 3
T: 1, C: 1
T: 2, C: 2
T: 1, C: 0
T: 2, C: 1
Thread: 1 done
T: 2, C: 0
Thread: 2 done



I realize that it is late in the day to get this
into ant1.6, but I think that it will make macrodef
much more usefull and easy to port current antcalls.

The changes are quite small (mostly to PropertyHelper).

Peter

On Saturday 18 October 2003 16:22, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > I think that we may need a thread local variable to
> > handle parallel.
> >
> > This would mean some deep messing with the Property handling.
>
> I do not see how thread locals would help here. I guess the
> question is whether tasks in parallel should be able to modify
> the global properties in the frame, or should the changes be
> local to the parallel branch (and somehow joined at the end of
> execution).
>
> That would mean each parallel computation branch is
> independent. I guess I am suggesting the second type of
> implementation proposed for  to be used instead
> for . I think that would be a much more efficient way
> to do it. So here is how it would work:
>
> 1) Add new attribute independent (default false) to .
>
> 2) When independent is true, each thread will use a cloned project
> frame for its execution. So all properties and reference manipulation
> will be independent of each other. When the thread ends, any new
> properties added in the cloned frame, will be added to the original
> parent frame, following the common rules for setting properties.
> Which means that the first thread that finish will win on setting
> the property, if another thread ends later and tries to set the same
> variable, it will loose. For references, we need to copy any changes
> and due to its semantics all threads will contribute as they end.
>
> 3) When independent is false, parallel works as today (for backward
> compatibility), all threads see each others changes.
>
> This rules seem easy programable without big changes to CORE.
>
> I would still like having  which could be implemented
> as per the first description proposed below.
>
> Jose Alberto
>
> > Peter
> >
> > On Friday 17 October 2003 17:57, Jose Alberto Fernandez wrote:
> > > > From: peter reilly [mailto:[EMAIL PROTECTED]
> > > >
> > > > I would rather have Jose's idea of a  task.
> > > >
> > > > This could be used outside of macrodef.
> > > >
> > > > The only problem is the implementation.
> > >
> > > Indeed, there is an easy implementation but will not solve
> >
> > the case of
> >
> > > , because the local definition would really be a
> >
> > te

Re: [Ant 1.6beta2] Problem with task and ant-launcher.jar

[Stefan Bodewig]

On Sun, 19 Oct 2003, Christopher Lenz <[EMAIL PROTECTED]> wrote:

> The corresponding  invocation does not specifiy the
> "includeantruntime" attribute, which defaults to true. So the Ant
> runtime should be included in the classpath. However, the
> ant-launcher.jar doesn't seem to be on the classpath here. If I
> specifically include ant-launcher.jar in the test classpath, the
> tests run successfully again.

OK, I see where the problem is and will fix it today.

Thanks

Stefan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23927] New: - setting jdk on javadoc

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23927

setting jdk on javadoc

   Summary: setting jdk on javadoc
   Product: Ant
   Version: 1.6Beta
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In the javac task the executable is settable. The same has to be possible on 
javadoc, because sometimes you have to use another jdk as that running ant 
below.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

bug 20721

[Sean Bridges]

Hello,

Could someone take a look at bug 20721
(http://issues.apache.org/bugzilla/show_bug.cgi?id=20721)

The issue is adding a comment argument to the
vssCheckout task.  At work we use the vssCheckout
command, but we found it prompted the user to give a
comment.  We are currently maintaining our own branch
of the vssCheckout task with the comment option.

Ive posted the  to add the comment option with the bug
report, and Im just waiting for someone to commit it. 


Im looking forward to upgrading to ant 1.6 when it is
out, and its a pain to have to maintain a seperate
version of this task.

Thanks,

Sean

__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]