DO NOT REPLY [Bug 29391] - javac task uses user.dir for temporary file instead of java.io.tmpdir

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29391

javac task uses user.dir for temporary file instead of java.io.tmpdir





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 19:45 ---
Yes, you are right.  It happens that this is being called from withing Jasper,
which I have no way to modify to add the tempdir.  I can go and ask tomcat folks
to make this change -- it will be a race of who releases first though :-)  And
when your change is out their change would not be needed anymore.

My preference for the change you just made is that it will always work, what is
some desirable quality for a default.

W.r.t. how we were affected:  Our server JOnAS is started as a system service. 
I would have guessed that the PWD would be /etc/init.d or /usr/share/jonas or
some other system directory -- I have no idea why I got "/".  I've printed from
the javac task:

   [javac] userDir="null"
   [javac] userDirName="/"
   [javac] userDir2="/" 

In any case we would be in trouble as most of these directories are not writable
or should not be writen to anyway (even if the permissions allowed writing by
the 'jonas' user).

Someone wrote a test program to verify the JVM (IBM 1.4.1 and BEA 1.4.2 yeld the
same results):

| $ cat /tmp/Main.java
| public class Main {
| public static void main(String[] s) {
| System.out.println("user.dir=" + System.getProperty("user.dir"));
| System.out.println("user.home=" + 
System.getProperty("user.home"));
| }
| }
| $ cd /var; java -cp /tmp Main
| user.dir=/var
| user.home=/home/vadim
| $ cd /usr/share/; java -cp /tmp Main
| user.dir=/usr/share
| user.home=/home/vadim


I am happy with your solution.  I had hopes it would be in 1.6.2 though.

We here will have to distribute a modified version of Ant 1.6.1, or a modified
version of Jasper (with the tempdir) --  or find a way to have the PWD be
something like /tmp.  :-(

Thanks for the prompt response.

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

RE: Alias names for imported targets

[Jose Alberto Fernandez]

> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED] 
> Sent: 04 June 2004 19:26
> To: 'Ant Developers List'
> Subject: RE: Alias names for imported targets
> 
> 
> > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > > On Fri, 4 Jun 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > > > This allows to bypass the target override, and thus bypass 
> > > > whatever the overridden target does.
> > >
> > > Right.  But I already can bypass it if the target is overridden 
> > > since I get the aliased name then.  If this type of bypassing is 
> > > wrong, we shouldn't allow it in any way.
> > >
> > 
> > This is one of my pifs with the current import, a battle I think I 
> > lost. Or maybe I won (I cannot remember which side I was :-(  )
> 
> Whoa, this is everything I tried and tried to explain, except 
> never as clearly, and I for sure lost that battle! I may be 
> wrong, but the way I remember it, you were in the camp that won ;-)
> 
> Thanks for this analysis. It's a lost cause, but thanks. --DD

Well, we could always offer using the "id" way as an alternative.
And if it picks up, deprecate the other one in ANT 2.0 (2.0 get it :-) )

In any case, I am not sure how to do it. Does anyone has an idea?
We could write an experimental  task with the diferent
behaviour to explore.

Jose Alberto

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

RE: Generic tasks/types WAS Possible Ant 1.7 alpha bug: property expansion.

[Matt Benson]

--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
[SNIP]
But are there enough usages
> as to grant the 
> definition of a full framework for this pattern.

That's backwards... the original idea was not a full
framework to support this pattern... this pattern is
only one possible way to exploit having 1 or 2 custom
tasks that basically behave as inline
<(task|type)def>s.  Hardly a full framework, unless I
miss my guess.  This is one of my pet ideas, and as
with most, I no longer recall the original use-case
for which I wanted these.  Probably convenience, as I
mentioned before...

-Matt




__
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

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

RE: Alias names for imported targets

[Jose Alberto Fernandez]

Looks like spaguetti buildfiles to me.

No ofence, but if the build have this kinds of fragile
dependencies, will anyone else understan what is going on
6 month from now? That is what is wrong with spaguetti code.

All this restriction in OO inheritance are there to limit
developers capability of writing spaguetti. We still do, but...

Jose Alberto

> -Original Message-
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] 
> Sent: 04 June 2004 17:47
> To: [EMAIL PROTECTED]
> Subject: Re: Alias names for imported targets
> 
> 
> Dominique Devienne wrote:
> 
> >>From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
> >>I've looked into the code (gosh, I still remember part of 
> it :-) The 
> >>following path is OTOMH, without even compiling, it should 
> be a start.
> > 
> > Implementing this is not the issue...
> 
> I know, I haven't replied to /your/ mail, but Stefan's original one.
> 
> In any case, the reason is simple: sometimes it happens that 
> I want to 
> rely on *that* *particular* task in *that* imported 
> buildfile, no matter 
> what happens in the future.
> 
> Imagine that I depend from an "init" task in an imported 
> buildfile... I 
> would depend on it in many targets. Now, imagine, and it's 
> not that far 
> fetched, that I have another init target that is imported or defined, 
> and that I have to recheck all the places where I have declared my 
> dependency...
> 
> It all boils down to what you want to call.
> Personally I prefer to *declare* what I want, not go check 
> later that an 
> extra target breaks my initial intentions (that are surely 
> forgotten by 
> that time).
> 
> Is it clear now?
> 
> -- 
> Nicola Ken Barozzi   [EMAIL PROTECTED]
>  - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> -
> 
> 
> -
> 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: Generic tasks/types WAS Possible Ant 1.7 alpha bug: property expansion.

[Jose Alberto Fernandez]

Your example has this assumption, quite thin for the general case
that no matter what accion, the set of other attributes and
elements must be exactly the same.

I really do not see to much of the usability gain in something like
that.
Usually you expect different input for different actions. And when that
is the case, then the whole pattern is unusable. Now there may be some 
cases when it will work. But are there enough usages as to grant the 
definition of a full framework for this pattern.

I doubt it

Jose Alberto

> From: Dominique Devienne [mailto:[EMAIL PROTECTED] 
> 
> 
> One of the useful bit his proposal allowed was to 
> conditionally execute one mode or the other thanks to 
> mode="${mode}", where mode can be configured/computed 
> before-hand. If we had a way to configure and execute a task 
> in a similar indirect way, we'd achieve the same goal, will 
> still using different tasks. Here's what I mean:
> 
> You have tasks A and B which are interchangeable, i.e. take 
> the same attributes and nested elements, but do different things.
> 
> Instead of doing:
> 
>   if some-condition
> do-A
>   else
> do-B
> 
> or doing Magesh's
> 
>   
> some-condition
>   
>   
>   
> [elements]
>   
> 
> We'd do something like:
> 
>   
> some-condition
>   
>   
>   
> [elements]
>   
> 
> This allows the necessary indirection, and avoids having to 
> Duplicate all the attributes and elements in an .
> 
> This is similar to XSL's , where the great 
> majority of time you just output the element directly, as in 
> , but sometime need to dynamically set the elements name, 
> thanks to .
> 
> Anyways, I hope this makes sense. --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]

cvs commit: ant/docs/manual/CoreTasks javac.html

[mbenson]

mbenson 2004/06/04 11:29:57

  Modified:docs/manual/CoreTasks javac.html
  Log:
  Changed default tempdir to java.io.tmpdir instead of user.dir.
  PR: 29391, 4590
  
  Revision  ChangesPath
  1.46  +3 -2  ant/docs/manual/CoreTasks/javac.html
  
  Index: javac.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTasks/javac.html,v
  retrieving revision 1.45
  retrieving revision 1.46
  diff -u -r1.45 -r1.46
  --- javac.html9 Feb 2004 21:50:05 -   1.45
  +++ javac.html4 Jun 2004 18:29:57 -   1.46
  @@ -344,8 +344,9 @@
 This is only used if the task is forked and the
 command line args length exceeds 4k.
 Since Ant 1.6.
  -No; default is the current working
  -   directory.
  +
  +  No; default is java.io.tmpdir.
  +
 
   
   
  
  
  

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

RE: Alias names for imported targets

[Dominique Devienne]

> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > On Fri, 4 Jun 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > > This allows to bypass the target override, and thus bypass whatever
> > > the overridden target does.
> >
> > Right.  But I already can bypass it if the target is
> > overridden since I get the aliased name then.  If this type
> > of bypassing is wrong, we shouldn't allow it in any way.
> >
> 
> This is one of my pifs with the current import, a battle I think I lost.
> Or maybe I won (I cannot remember which side I was :-(  )

Whoa, this is everything I tried and tried to explain, except never as
clearly, and I for sure lost that battle! I may be wrong, but the way I
remember it, you were in the camp that won ;-)

Thanks for this analysis. It's a lost cause, but thanks. --DD

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

RE: Alias names for imported targets

[Jose Alberto Fernandez]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> 
> On Fri, 4 Jun 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> 
> > This allows to bypass the target override, and thus bypass whatever 
> > the overridden target does.
> 
> Right.  But I already can bypass it if the target is 
> overridden since I get the aliased name then.  If this type 
> of bypassing is wrong, we shouldn't allow it in any way.
> 

This is one of my pifs with the current import, a battle I think I lost.
Or maybe I won (I cannot remember which side I was :-(  )

As in any inheritance based language, what you need is two things:

1) Been able to override to change behaviour.
2) Been able, from the overriding module (project) to call the original
behaviour that you overrode(sp?).

(1) we acomplish, but (2) I do not think we did right.
Here what we needed was having "super" (or in our case since we have
multiple inheritance)
to be able to refer to several supers. But we did not do that, we do not
give access
just to the previous definitions (super) we kind of gave access to all
definitions
which I am sure will create spaguetti builds in the future.

I remember someone pointing out that our big mistake on  was 
that we use the name of the project being imported and not a name local
to the importing 
build as the way to refer to "super", this in escence breaks visibility
rules.

So if we have:
imported.xml:

  


build.xml:

  

  


The depends list shows the issue, the first target "foo.baz" requires
the writer of build.xml to know not only the name of the imported file
but also details about its content (beside the contract of providing a
"baz" target.

The second target "there.baz" does not require build.xml to know about
the internals of imported.xml. More over, there is no way to talk
about things further imported, since the only thing you have is your
local ids (or that is the idea).

Now this is not easy, since requires visibility rules much more dinamic
than
the syntactic rewriting we have today.


> I don't have a real world use-case, granted, my major reason 
> is consistency - I want to be able to write depends="foo.bar" 
> and not care whether it has been overridden or not.

Not sure if this is just adding more logs into the fire (as we say in
spanish)

Jose Alberto

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

DO NOT REPLY [Bug 28897] - Enhance the Replace task

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28897

Enhance the Replace task

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

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

DO NOT REPLY [Bug 28884] - Keep the properties set after or .

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28884

Keep the properties set after  or .

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 18:12 ---
Not only does it mean that there is a real need for this functionality, it also 
means that this functionality is here among us and available via ant-contrib 
and Antelope!  Yay!

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

Re: cvs commit: ant/src/etc/testcases/taskdefs/optional xmlvalidate.xml

[Antoine Lévy-Lambert]

Stefan Bodewig wrote:
On 2 Jun 2004, <[EMAIL PROTECTED]> wrote:
 

 -Aslak Hellesøy
 +Aslak Helles?y
   

What OS are you running Antoine?
 

Sorry Stefan, I got online again only now.
I am running Windows 2000 German, and I did I think the edit with IDEA, 
then committed it with GNU cvs under cygwin.

Not sure which piece of software corrupted the accentuated characters.
Cheers,
Antoine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: commit emails

[Antoine Lévy-Lambert]

Sorry for the spam,
I had put my own address at apache dot org in an anti-spam filter, 
because I was receiving viruses
with my address (forged).

So the commit mails were in my Spam-Suspicion folder.
Cheers,
Antoine
Stefan Bodewig wrote:
On Wed, 02 Jun 2004, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
 

Is it possible that the sending of commit emails is perturbated ? or
is my contributor email antoine at apache dot org currently blocked
on the distribution list [EMAIL PROTECTED] ?
   

Your commit mails have never entered the moderation queue (at least I
never saw them) and have made it to the dev list, so things seem to
work OK.  Maybe there's just been a temporary mail-hickup.
Stefan
 


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

DO NOT REPLY [Bug 29391] - javac task uses user.dir for temporary file instead of java.io.tmpdir

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29391

javac task uses user.dir for temporary file instead of java.io.tmpdir





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 18:08 ---
Oh, and it wasn't originally created in java.io.tmpdir... I wrote that when I 
first started researching the issue.  Looks like it was originally created in 
the JVM startup directory which is usually but might not be = user.dir .


ANYWAY...

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

DO NOT REPLY [Bug 29391] - javac task uses user.dir for temporary file instead of java.io.tmpdir

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29391

javac task uses user.dir for temporary file instead of java.io.tmpdir





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 18:01 ---
And of course that should have been .  I 
left the 'e' out of the attribute name.

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

DO NOT REPLY [Bug 29391] - javac task uses user.dir for temporary file instead of java.io.tmpdir

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29391

javac task uses user.dir for temporary file instead of java.io.tmpdir

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
Summary|Default for javac 'tempdir' |javac task uses user.dir for
   |should be the system temp   |temporary file instead of
   |directory, not the current  |java.io.tmpdir
   |directory   |



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 17:59 ---
In fact the temp file, AFAICT, originally was created in java.io.tmpdir, but 
was changed to user.dir .  See bug 4590.  I think the solution was not effected 
by creating the file in user.dir, but by specifying the location of the file 
explicitly.  I am inclined to change this to java.io.tmpdir, because I agree 
that's where it belongs, but I don't know that it is actually the source of 
your distress...

user.dir is not = HOME or ~, it is equivalent to $PWD .  So given the fact that 
javac creates the temp file in the current directory, if your user does not 
have permission to create files at the root, that would probably be your 
problem.  The easiest workaround for you now is to use javac 
tmpdir="${java.io.tmpdir}".

As to the java.io.tmpdir issue... I have made the change and committed it to 
CVS HEAD.  I do NOT plan to merge this for 1.6.2 .  I'd rather let it sit in 
the main branch for awhile to make sure there are no issues.

Thanks

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

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/compilers DefaultCompilerAdapter.java

[mbenson]

mbenson 2004/06/04 10:51:21

  Modified:.WHATSNEW
   src/main/org/apache/tools/ant/taskdefs/compilers
DefaultCompilerAdapter.java
  Log:
  Changed default tempdir to java.io.tmpdir instead of user.dir.  See what 
breaks.
  PR: 29391, 4590
  
  Revision  ChangesPath
  1.615 +3 -1  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.614
  retrieving revision 1.615
  diff -u -r1.614 -r1.615
  --- WHATSNEW  4 Jun 2004 12:25:13 -   1.614
  +++ WHATSNEW  4 Jun 2004 17:51:21 -   1.615
  @@ -26,7 +26,9 @@
   
   *  supports loading from a resource.
   
  -*  accepts nested conditions.
  +*  accepts a nested .
  +
  +* Changed default tempdir for  from user.dir to java.io.tmpdir.
   
   Changes from Ant 1.6.1 to current Ant 1.6 CVS version
   =
  
  
  
  1.48  +2 -6  
ant/src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java
  
  Index: DefaultCompilerAdapter.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java,v
  retrieving revision 1.47
  retrieving revision 1.48
  diff -u -r1.47 -r1.48
  --- DefaultCompilerAdapter.java   9 Mar 2004 16:48:13 -   1.47
  +++ DefaultCompilerAdapter.java   4 Jun 2004 17:51:21 -   1.48
  @@ -396,12 +396,8 @@
   && firstFileName >= 0) {
   PrintWriter out = null;
   try {
  -File userDir = getJavac().getTempdir();
  -if (userDir == null) {
  -String userDirName = System.getProperty("user.dir");
  -userDir = new File(userDirName);
  -}
  -tmpFile = fileUtils.createTempFile("files", "", userDir);
  +tmpFile = fileUtils.createTempFile(
  +"files", "", getJavac().getTempdir());
   tmpFile.deleteOnExit();
   out = new PrintWriter(new FileWriter(tmpFile));
   for (int i = firstFileName; i < args.length; i++) {
  
  
  

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

DO NOT REPLY [Bug 29391] - Default for javac 'tempdir' should be the system temp directory, not the current 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://issues.apache.org/bugzilla/show_bug.cgi?id=29391

Default for javac 'tempdir' should be the system temp directory, not the 
current directory

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|javac task uses user.dir for|Default for javac 'tempdir'
   |temporary file instead of   |should be the system temp
   |java.io.tmpdir  |directory, not the current
   ||directory



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 17:52 ---
Old Subject: javac task uses user.dir for temporary file instead of 
java.io.tmpdir

Adjusted subject.

I know understand that this was the intended default for javac 'tempdir'. 
However, servers may be running this to, for instance, compile some code (like
in JSP pages etc.).  The current directory can be some system directory for
instance.  It is quite unpredictable when you will get a command line > 4k, so
this causes a problem in some places, not in others.

java.io.tmpdir will always work (or lots of other things will not work as well),
so that should be the default.

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

DO NOT REPLY [Bug 29397] New: - old link on external tasks pages

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29397

old link on external tasks pages

   Summary: old link on external tasks pages
   Product: Ant
   Version: unspecified
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


On http://ant.apache.org/external.html, http://www.smartkey.co.uk/antic.html
should be http://www.smartkey.co.uk/tools/antic/antic.html

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

RE: DispatchTask

[Magesh Umasankar]

Subject:RE: DispatchTask
From:   Dominique Devienne 
Date:   2004-06-04 15:14:02

> public static void dispatchAction(String action, Task target) { ... }
>
> or 
> 
> public static void dispatchAction(String action, Object target) { ... }
> 
> to make it fully bean friendly.
> 
> Then it's just the matter of writer
> 
> execute() { TasktUtils.dispatchAction(_action, this); }
> 
> And one can use any 'action' attribute one wants.
> 
> When it can be avoided, I prefer to keep my single inheritance
> choices open. --DD

Nice idea.  I was thinking of the following:

Option 1: Allow task writer to just extend DispatchTask

interface IDispatchTask {
public String getActionParameter();
}

abstract class DispatchTask extends Task implements IDispatchTask {
public String getActionParameter() {
return "action";
}
public void setAction(String action) {...}
public String getAction() {...}
public final void execute() throws BuildException {
//Nothing here - Ant's modified introspection would take care 
//of executing the correct method
}
}

Option 2: Impelement IDispatchTask along similar lines of 
DispatchTask and still have Ant work out the details of 
which method to execute when.

Option 3: Let the user invoke the dispatcher manually
(your approach)

I'll try to implement it such that all these are possible...  
The neat thing with option 1 is that the user does not have 
to implement a dummy execute method to just dispatch stuff 
out.  But I do see your point of not wanting to extend if
avoidable.

Cheers,
Magesh

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

DO NOT REPLY [Bug 29395] - ant modifies files while copying

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29395

ant modifies files while copying





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 17:21 ---
Copy should operate in binary mode
if there is no modification to be done
on the files.

If the copy needs to apply a filterchain
or a filterset to the files, it uses
character based coping using the default
character encoding. For binary files this
will have the effect of doubling the file size.


Are you sure that the files have not been
copied by another copy in your build file?

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

DO NOT REPLY [Bug 29396] New: - Allow P4Change to edit changelists as well

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29396

Allow P4Change to edit changelists as well

   Summary: Allow P4Change to edit changelists as well
   Product: Ant
   Version: 1.6.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The Perforce server may rename changelists upon submission, which in our
environments occurs often. In case the change number as obtained by ${p4.change}
is used for versioning purposes (as we do) in the MANIFEST.MF of jar files
generated during the automated build process there is the chance there is no
direct relation between the build number and the final change number under which
the nightly has been submitted.

In case p4change would allow us to edit a created but still not submitted
changelist then we could at least put the original changelist number in the
description. That way we can always track the final changelist number back to
the  build number.

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

Re: Possible Ant 1.7 alpha bug: property expansion.

[Jack J. Woehr]

Matt Benson wrote:

> One (slightly messy) solution might be to decouple the
> parsing and substitution... thinking out loud here so
> forgive any glaring omissions or errors...

What I haven't figured out yet is why you bother to parse in the complicated
fashion you do in PropertyHelper.parsePropertyString() ... is this structure
being kept around somewhere for access by some other client of PropertyHelper?

--
Jack J. Woehr  # We have gone from the horse and buggy
Senior Consultant  # to the moon rocket in one lifetime, but
Purematrix, Inc.   # there has not been a corresponding moral
www.purematrix.com # growth in mankind. - Dwight D. Eisenhower




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

Re: Alias names for imported targets

[Nicola Ken Barozzi]

Nicola Ken Barozzi wrote:...
task->target
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Alias names for imported targets

[Nicola Ken Barozzi]

Dominique Devienne wrote:
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
I've looked into the code (gosh, I still remember part of it :-)
The following path is OTOMH, without even compiling, it should be a start.
Implementing this is not the issue... 
I know, I haven't replied to /your/ mail, but Stefan's original one.
In any case, the reason is simple: sometimes it happens that I want to 
rely on *that* *particular* task in *that* imported buildfile, no matter 
what happens in the future.

Imagine that I depend from an "init" task in an imported buildfile... I 
would depend on it in many targets. Now, imagine, and it's not that far 
fetched, that I have another init target that is imported or defined, 
and that I have to recheck all the places where I have declared my 
dependency...

It all boils down to what you want to call.
Personally I prefer to *declare* what I want, not go check later that an 
extra target breaks my initial intentions (that are surely forgotten by 
that time).

Is it clear now?
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible Ant 1.7 alpha bug: property expansion.

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
[SNIP]
> I don't see any easy way to defer the actual string
> tokenization to
> the individual PropertyHelpers of the chain, so we
> may be better
> served by defining a more useful algorithm at the
> top.

One (slightly messy) solution might be to decouple the
parsing and substitution... thinking out loud here so
forgive any glaring omissions or errors...

interface oata.PropertyParser {
  void parsePropertyString(String value,
   Vector fragments, Vector propertyRefs);}

BC could be preserved by making the existing
PropertyHelper abstract and add:
public class oata.helper.DefaultPropertyHelper
 extends oata.PropertyHelper
 implements oata.PropertyParser {}

... and modify PropertyHelper:
  add
public static PropertyParser
getPropertyParser(Project)
  modify
public static PropertyHelper
getPropertyHelper(Project)

  so that the default set for each is a
DefaultPropertyHelper, with an "ant.PropertyParser"
reference added corresponding to "ant.PropertyHelper".

?

-Matt




__
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

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

RE: Generic tasks/types WAS Possible Ant 1.7 alpha bug: property expansion.

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> This actually ties back to what Magesh proposed (the
> dispatch task).
> 
> One of the useful bit his proposal allowed was to
> conditionally
> execute one mode or the other thanks to
> mode="${mode}", where
> mode can be configured/computed before-hand. If we
> had a way to
> configure and execute a task in a similar indirect
> way, we'd achieve
> the same goal, will still using different tasks.
[SNIP]

Your example here was a good one for some of the
capabilities this type of thing would have (besides
accommodating my enthusiasm for brevity).  Maybe we
could handle tasks/types with a single tag/class.  
 or perhaps ?  Opinions?  I don't think
this qualifies as entirely replacing Magesh's proposal
since, as he implied, some developers may WANT to keep
the related "operations" or modes in a single
implementing class, for whatever reasons.  But either
would definitely work nicely with conditions.

-Matt




__
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

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

DO NOT REPLY [Bug 29395] New: - ant modifies files while copying

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29395

ant modifies files while copying

   Summary: ant modifies files while copying
   Product: Ant
   Version: 1.6.1
  Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
  Severity: Normal
  Priority: Other
 Component: Build Process
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I dont actually know whether its a bug or its a problem with my script.This is
the portion of script i used  

"
 
 "

i have some image files in the src directory .After executing the script ant
copies these files to the build directory,the size of the files are modifed to
almost double.and also my java program cannot open these files as they are
invalid. i comodified my script as follows 

 
  
  
  

now its working properly

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

RE: Generic tasks/types WAS Possible Ant 1.7 alpha bug: property expansion.

[Dominique Devienne]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> On Fri, 4 Jun 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
> > If there is any reason why we couldn't/shouldn't have
> > a generic  DynamicConfigurator that could
> > execute an arbitrary task by classname, and a generic
> >  or , probably also a
> > DynamicConfigurator, to instantiate (and optionally
> > configure) an arbitrary object, usu. to set as a
> > reference, but possibly for other things as well...
> 
> Ahh!!
> 
> No, I don't see any reason why we shouldn't have a task/type like
> this.

This actually ties back to what Magesh proposed (the dispatch task).

One of the useful bit his proposal allowed was to conditionally
execute one mode or the other thanks to mode="${mode}", where
mode can be configured/computed before-hand. If we had a way to
configure and execute a task in a similar indirect way, we'd achieve
the same goal, will still using different tasks. Here's what I mean:

You have tasks A and B which are interchangeable, i.e. take the
same attributes and nested elements, but do different things.

Instead of doing:

if some-condition
do-A
  else
do-B

or doing Magesh's


  some-condition

  

[elements]


We'd do something like:


  some-condition

  

[elements]
  

This allows the necessary indirection, and avoids having to
Duplicate all the attributes and elements in an .

This is similar to XSL's , where the great majority
of time you just output the element directly, as in , but
sometime need to dynamically set the elements name, thanks to
.

Anyways, I hope this makes sense. --DD



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

RE: DO NOT REPLY [Bug 29382] - GenKey task depends on path for java keytool

[Dominique Devienne]

> --- Additional Comments From [EMAIL PROTECTED]  2004-06-04 07:47 
> DD,  should work fine since it uses
> JavaEnvUtils.getJdkExecutable in Javac.getSystemJavac via two
> indirections.

Hmmm. Just yesterday, a user couldn't  inside of
IntelliJ. The fix was to add $JAVA_HOME/bin to the Path before launching
the IDE. How can that be then? We're using 1.6.1.

Anyways, it's working now, and I have other things to do, so I won't try
to find out how that's possible. My interpretation of the symptoms and
what fixed it was wrong. Sorry about that. --DD

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

RE: DispatchTask

[Dominique Devienne]

> From: Magesh Umasankar [mailto:[EMAIL PROTECTED]
> > > I'd like to introduce the concept of a DispatchTask to Ant.
> >
> > Do you think a task with a mode/action that selects the method to run
> > instead of execute is really that common?
> 
> Well, it is a pretty common pattern used to group closely related
> sub-actions
> together while avoiding messy conditionals (like in our very own FTP).  On
> a
> tangential note, Struts has a similar concept called DispatchAction, which
> is
> popular.  A couple of third-party task implementations that use 'actions'
> instead
> of defining individual tasks are:
> - Weblogic's wlserver that allows startup, shutdown, connect and reboot as
> action options.
> - Dale Anson's Stopwatch task at Ant-contrib (a very nice use-case for
> DispatchTask)
> that allows start, stop, elapsed and total as action options.
> I'm sure there are plenty more...

OK, you've convinced me Magesh ;-) I've just posted a message on another
thread that proposed an alternative, but for the stopwatch example, the
action attribute (or mode, or command) seems like the simpler alternative.

Maybe we just don't need a DispatchTask, but a simple static utility method
that does the dispatching instead?

Could take the form of

public static void dispatchAction(String action, Task target) { ... }

or 

public static void dispatchAction(String action, Object target) { ... }

to make it fully bean friendly.

Then it's just the matter of writer

execute() { TasktUtils.dispatchAction(_action, this); }

And one can use any 'action' attribute one wants.

When it can be avoided, I prefer to keep my single inheritance
choices open. --DD

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

RE: Alias names for imported targets

[Dominique Devienne]

> From: Erik Hatcher [mailto:[EMAIL PROTECTED]
> 
> pasted from my original message on this:
> 
> imported.xml
> 
>   
> 
> 
> build.xml
> 
>   
>   
> 
> 
> Doesn't work, since some-target is not overridden.
> 
> --
> It would be nice if imported.some-target existed as an alias always.

I saw your message Erik. So what's preventing you from writing:

build.xml

  
  


??? This is much better anyway, because if you do override some-target,
we'd most likely want another-target to use the overridden some-target.

So no, I still don't see the need for this. --DD

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

RE: Alias names for imported targets

[Dominique Devienne]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> 
> I don't have a real world use-case, granted, my major reason is
> consistency - I want to be able to write depends="foo.bar" and not
> care whether it has been overridden or not.

Yeah, that's the part I don't like. Beside the target that actually
overrides a target, I don't think anyone else should have access to
the overridden target.

You should just write depends="bar", and not care whether it has been
overridden or not IMHO. If somebody (you ;-) override 'bar', that's
the one you should be using, not the overridden one. --DD

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

cvs commit: ant TODO

[mbenson]

mbenson 2004/06/04 08:45:07

  Modified:.Tag: ANT_16_BRANCH TODO
  Log:
  Add Target.getIf/Unless()
  PR: 29320
  Submitted by: Christophe Labouisse
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.3.2.5   +3 -0  ant/Attic/TODO
  
  Index: TODO
  ===
  RCS file: /home/cvs/ant/Attic/TODO,v
  retrieving revision 1.3.2.4
  retrieving revision 1.3.2.5
  diff -u -r1.3.2.4 -r1.3.2.5
  --- TODO  4 Jun 2004 15:09:25 -   1.3.2.4
  +++ TODO  4 Jun 2004 15:45:07 -   1.3.2.5
  @@ -43,3 +43,6 @@
   
   *  creates empty
 archive. [Stefan]
  +
  +* merge Target.getIf/Unless() from HEAD [Matt]
  +
  
  
  

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

DO NOT REPLY [Bug 29320] - The target object does not have getter for if/unless conditions.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29320

The target object does not have getter for if/unless conditions.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 15:44 ---
Committed to CVS HEAD; will merge to the 1.6 branch for 1.6.2

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

cvs commit: ant CONTRIBUTORS

[mbenson]

mbenson 2004/06/04 08:40:22

  Modified:.CONTRIBUTORS
  Log:
  Add Christophe Labouisse
  PR: 29320
  
  Revision  ChangesPath
  1.22  +2 -1  ant/CONTRIBUTORS
  
  Index: CONTRIBUTORS
  ===
  RCS file: /home/cvs/ant/CONTRIBUTORS,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- CONTRIBUTORS  4 Jun 2004 07:44:53 -   1.21
  +++ CONTRIBUTORS  4 Jun 2004 15:40:22 -   1.22
  @@ -20,9 +20,10 @@
   Charles Hudak
   Charlie Hubbard
   Chris Povirk
  +Christoph Wilhelms
  +Christophe Labouisse
   Christopher A. Longo
   Christopher Charlier
  -Christoph Wilhelms
   Conor MacNeill
   Craeg Strong
   Craig Cottingham
  
  
  

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

cvs commit: ant/src/main/org/apache/tools/ant Target.java

[mbenson]

mbenson 2004/06/04 08:39:16

  Modified:src/main/org/apache/tools/ant Target.java
  Log:
  Add getIf() and getUnless() to Target.
  PR: 29320
  Submitted by: Christophe Labouisse
  
  Revision  ChangesPath
  1.53  +20 -0 ant/src/main/org/apache/tools/ant/Target.java
  
  Index: Target.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/Target.java,v
  retrieving revision 1.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- Target.java   26 Apr 2004 17:49:51 -  1.52
  +++ Target.java   4 Jun 2004 15:39:16 -   1.53
  @@ -247,6 +247,16 @@
   }
   
   /**
  + * Returns the "if" property condition of this target.
  + *
  + * @return the "if" property condition or null if no
  + * "if" condition had been defined.
  + */
  +public String getIf() {
  +return ("".equals(ifCondition) ? null : ifCondition);
  +}
  +
  +/**
* Sets the "unless" condition to test on execution. This is the
* name of a property to test for existence - if the property
* is set, the task will not execute. The property goes
  @@ -261,6 +271,16 @@
*/
   public void setUnless(String property) {
   this.unlessCondition = (property == null) ? "" : property;
  +}
  +
  +/**
  + * Returns the "unless" property condition of this target.
  + *
  + * @return the "unless" property condition or null
  + * if no "unless" condition had been defined.
  + */
  +public String getUnless() {
  +return ("".equals(unlessCondition) ? null : unlessCondition);
   }
   
   /**
  
  
  

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

RE: Alias names for imported targets

[Dominique Devienne]

> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
> I've looked into the code (gosh, I still remember part of it :-)
> The following path is OTOMH, without even compiling, it should be a start.

Implementing this is not the issue... --DD

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

Re: Alias names for imported targets

[Stefan Bodewig]

On Fri, 4 Jun 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:

> This allows to bypass the target override, and thus bypass whatever
> the overridden target does.

Right.  But I already can bypass it if the target is overridden since
I get the aliased name then.  If this type of bypassing is wrong, we
shouldn't allow it in any way.

I don't have a real world use-case, granted, my major reason is
consistency - I want to be able to write depends="foo.bar" and not
care whether it has been overridden or not.

Stefan

PS:

> I'm not -1, and even then it'd be non-binding, but I don't
> understand the need for this.

This isn't a vote at all, so binding or not wouldn't matter.  Outside
of the legal world, your opinion here certainly matters, whether you
are a committer or not.

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

Re: DispatchTask

[Stefan Bodewig]

On Fri, 4 Jun 2004, Magesh Umasankar <[EMAIL PROTECTED]> wrote:

> I don't see it as a debate on whether multiple tasks are better
> Vs. mutiple actions per task.  DispatchTask is to be viewed as an
> alternative to writing multiple tasks and must be used diligently.
> It is just a question of style and a question of choice.

Fair enough.

I probably wouldn't use it, so don't expect me to +1 it, but I'm far
from stopping you as well.

Stefan

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

cvs commit: ant TODO

[mbenson]

mbenson 2004/06/04 08:09:25

  Modified:.Tag: ANT_16_BRANCH TODO
  Log:
  Assigned mine to me.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.3.2.4   +8 -8  ant/Attic/TODO
  
  Index: TODO
  ===
  RCS file: /home/cvs/ant/Attic/TODO,v
  retrieving revision 1.3.2.3
  retrieving revision 1.3.2.4
  diff -u -r1.3.2.3 -r1.3.2.4
  --- TODO  4 Jun 2004 13:00:17 -   1.3.2.3
  +++ TODO  4 Jun 2004 15:09:25 -   1.3.2.4
  @@ -5,21 +5,21 @@
   anybody else (assignments look like [Stefan]) to yourself - and please
   remove items from this list once they are complete.
   
  -* merge nested and container s from HEAD
  +* merge nested and container s from HEAD [Matt]
   
  -* merge s from HEAD
  +* merge s from HEAD [Matt]
   
  -* merge " from resource" from HEAD
  +* merge " from resource" from HEAD [Matt]
   
  -* merge " nested  instead of if/unless" from HEAD
  +* merge " nested  instead of if/unless" from HEAD [Matt]
   
  -* merge cygwin changes for ant script from HEAD
  +* merge cygwin changes for ant script from HEAD [Matt]
   
  -* merge Target.set/getLocation() from HEAD
  +* merge Target.set/getLocation() from HEAD [Matt]
   
  -* merge " differentiates between empty & up-to-date" from HEAD
  +* merge " differentiates between empty & up-to-date" from HEAD [Matt]
   
  -* Fix the Xml validation with scheam
  +* Fix the Xml validation with schema
   
   * Fix or at least document support for tomcat 5.0 jsp
   
  
  
  

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

Re: DispatchTask

[Magesh Umasankar]

From:   Stefan Bodewig 
Date:   2004-06-04 12:45:50

Hi Stefan,

> > I'd like to introduce the concept of a DispatchTask to Ant.
>
> Do you think a task with a mode/action that selects the method to run
> instead of execute is really that common?

Well, it is a pretty common pattern used to group closely related
sub-actions
together while avoiding messy conditionals (like in our very own FTP).  On a
tangential note, Struts has a similar concept called DispatchAction, which
is
popular.  A couple of third-party task implementations that use 'actions'
instead
of defining individual tasks are:
- Weblogic's wlserver that allows startup, shutdown, connect and reboot as
action options.
- Dale Anson's Stopwatch task at Ant-contrib (a very nice use-case for
DispatchTask)
that allows start, stop, elapsed and total as action options.
I'm sure there are plenty more...

> It looks like one could start a debate over whether those shouldn't
> better be split into several separate tasks.  Even in Ant we have both
> extremes, compare the clearcase/VSS or starteam tasks on the one and
> ftp on the other side.  Whenever I touch ftp it feels as if it should
> have been multiple tasks instead - so I'm in the multiple task camp
> and probably wouldn't use DispatchTask myself.

I don't see it as a debate on whether multiple tasks are better Vs. mutiple
actions per task.  DispatchTask is to be viewed as an alternative to
writing multiple tasks and must be used diligently.  It is just a question
of style and a question of choice.

> Stefan

Cheers,
Magesh

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

DO NOT REPLY [Bug 27411] - Ant 1.6.1 breaks with Jikes 1.19

[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://issues.apache.org/bugzilla/show_bug.cgi?id=27411

Ant 1.6.1 breaks with Jikes 1.19





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 15:05 ---
It doesn't seem like a duplicate for me.  I have removed target attributes from
my Ant scripts since then, and I have just upgraded to Jikes 1.21, so I am not
sure if, by some chance, target attribute would be okay with the most recent 
Jikes.

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

Re: Alias names for imported targets

[Nicola Ken Barozzi]

Stefan Bodewig wrote:
Hi,
Erik already brought that up.  Target foo imported from project named
bar is known as "foo" in my build file unless I override it (in which
case it becomes "bar.foo".  I'd like to have the alias name "bar.foo"
available even if I don't override it.
I haven't looked into the code yet, but are there any principal
objections?  Target time-frame would be 1.6.2.
I've looked into the code (gosh, I still remember part of it :-)
The following path is OTOMH, without even compiling, it should be a start.
Index: ProjectHelper2.java
===
RCS file: 
/home/cvspublic/ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java,v
retrieving revision 1.46
diff -u -r1.46 ProjectHelper2.java
--- ProjectHelper2.java	26 Apr 2004 17:49:51 -	1.46
+++ ProjectHelper2.java	4 Jun 2004 14:49:03 -
@@ -823,14 +823,36 @@
 }
 }

+Target fullTarget = null;
+
+if (context.isIgnoringProjectTag()) {
+fullTarget = new Target();
+}
+
 if (name != null) {
 target.setName(name);
 project.addOrReplaceTarget(name, target);
+if (fullTarget!=null) {
+   fullTarget.setProject(target.getProject());
+   fullTarget.setLocation(target.getLocation());
+   context.addTarget(fullTarget);
+   fullTarget.setIf(target.getIf());
+   fullTarget.setUnless(target.getUnless());
+   fullTarget.setDescription(target.getDescription());
+
+   String 
newName=project.addOrReplaceTarget(context.getCurrentProjectName()
++ "." + name, target);
+   fullTarget.setName(newName);
+   project.addOrReplaceTarget(newName, fullTarget);
+}
 }

 // take care of dependencies
 if (depends.length() > 0) {
 target.setDepends(depends);
+if (fullTarget!=null) {
+fullTarget.setDepends(depends);
+}
 }
 }
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Alias names for imported targets

[Erik Hatcher]

On Jun 4, 2004, at 10:19 AM, Dominique Devienne wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Erik already brought that up.  Target foo imported from project named
bar is known as "foo" in my build file unless I override it (in which
case it becomes "bar.foo".  I'd like to have the alias name "bar.foo"
available even if I don't override it.
I haven't looked into the code yet, but are there any principal
objections?  Target time-frame would be 1.6.2.
Kinda... This allows to bypass the target override, and thus bypass
whatever the overridden target does. It's kind of like allowing any
class in Java to use C++'s Class::method(), i.e. static binding when
dynamic binding to any overridden method() was the intent.
Or perhaps I misunderstand the issue. I guess I don't understand the
purpose of this. Targets are akin to Java interfaces to me, i.e. they
define a contract, and if a 'derived' build script overrides target
A for example, what's the meaning of this same build script also
calling base.A (outside of the derived A itself), or worse, what's the
meaning of a further derived2 script to call base.A, bypassing
derived.A (derived2 imports derived, which import base)?
I'm not -1, and even then it'd be non-binding, but I don't understand
the need for this. --DD
pasted from my original message on this:
imported.xml
   
 
   
build.xml
   
 
 
   
Doesn't work, since some-target is not overridden.
--
It would be nice if imported.some-target existed as an alias always.
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Generic tasks/types WAS Possible Ant 1.7 alpha bug: property expansion.

[Stefan Bodewig]

On Fri, 4 Jun 2004, Matt Benson <[EMAIL PROTECTED]> wrote:

> If there is any reason why we couldn't/shouldn't have
> a generic  DynamicConfigurator that could
> execute an arbitrary task by classname, and a generic
>  or , probably also a
> DynamicConfigurator, to instantiate (and optionally
> configure) an arbitrary object, usu. to set as a
> reference, but possibly for other things as well...

Ahh!!

No, I don't see any reason why we shouldn't have a task/type like
this.

Stefan

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

RE: Alias names for imported targets

[Dominique Devienne]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Erik already brought that up.  Target foo imported from project named
> bar is known as "foo" in my build file unless I override it (in which
> case it becomes "bar.foo".  I'd like to have the alias name "bar.foo"
> available even if I don't override it.
> 
> I haven't looked into the code yet, but are there any principal
> objections?  Target time-frame would be 1.6.2.

Kinda... This allows to bypass the target override, and thus bypass
whatever the overridden target does. It's kind of like allowing any
class in Java to use C++'s Class::method(), i.e. static binding when
dynamic binding to any overridden method() was the intent.

Or perhaps I misunderstand the issue. I guess I don't understand the
purpose of this. Targets are akin to Java interfaces to me, i.e. they
define a contract, and if a 'derived' build script overrides target
A for example, what's the meaning of this same build script also
calling base.A (outside of the derived A itself), or worse, what's the
meaning of a further derived2 script to call base.A, bypassing
derived.A (derived2 imports derived, which import base)?

I'm not -1, and even then it'd be non-binding, but I don't understand
the need for this. --DD

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

Re: Alias names for imported targets

[Erik Hatcher]

I would *love* for this to be in 1.6.2
Alas, I've no time in the near future to look into it myself though, 
sorry.

Erik
On Jun 4, 2004, at 8:13 AM, Stefan Bodewig wrote:
Hi,
Erik already brought that up.  Target foo imported from project named
bar is known as "foo" in my build file unless I override it (in which
case it becomes "bar.foo".  I'd like to have the alias name "bar.foo"
available even if I don't override it.
I haven't looked into the code yet, but are there any principal
objections?  Target time-frame would be 1.6.2.
Stefan
-
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: Generic tasks/types WAS Possible Ant 1.7 alpha bug: property expansion.

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Jun 2004, Matt Benson
> 
> Sorry, what is your question?
> 

If there is any reason why we couldn't/shouldn't have
a generic  DynamicConfigurator that could
execute an arbitrary task by classname, and a generic
 or , probably also a
DynamicConfigurator, to instantiate (and optionally
configure) an arbitrary object, usu. to set as a
reference, but possibly for other things as well...

Kind of a shortcut to ing something you only
want to use once, or set dynamically...

-Matt





__
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

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

RE: Ant 1.6.2 TODO list

[Jan . Materne]

> >   Should it be part of 1.6.2 or not?
> 
> I'd trust your judgement here.  If the changes are important enough to
> get released immediately, put them in.  If you know it will take a
> longer time than the other pieces of the list and think it could wait
> for a 1.6.3 release in six months or so - defer it.

I wont add it to the list so that it doesnt stop the release.
If I´d finished before I can add the changes to the 16-branch :-)

Jan

Re: Ant 1.6.2 TODO list

[Christophe Labouisse]

Hi,

Stefan Bodewig said:

> A few minutes ago I've committed a TODO list to the 1.6 branch, please
> go ahead and add items (but please only if you are willing to work on
> them yourself) and/or assign existing items to yourself.

I added a enhancement request (bug #29320) a couple of days ago and I
really like to have it included in ant 1.6.2. I already attached a patch
for this but I don't know if I can provide any more help.

Cheers

Christophe

-- 


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

DO NOT REPLY [Bug 29391] New: - javac task uses user.dir for temporary file instead of java.io.tmpdir

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29391

javac task uses user.dir for temporary file instead of java.io.tmpdir

   Summary: javac task uses user.dir for temporary file instead of
java.io.tmpdir
   Product: Ant
   Version: 1.6.1
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We run our server as a service in the system and the execution of a javac Ant
task results in a file not found exception.  It is a temporary file and the name
end up being /file

This call to System.getProperty("user.dir") is returning "/" (not sure why as
the user under which the server is run has HOME=/usr/share/jonas).

I don't know why it uses a System.getProperty("user.dir") and not a
System.getProperty("java.io.tmpdir").  It looks wrong to me... 

Independently of what cause the 'user.dir' to return the wrong value I believe
it should be changed to the 'java.io.tmpdir' one.  There may be cases where the
userid under which the server is run has no home directory assigned or it is not
writable.  And tem files should go to /tmp.


Here it is from Ant 1.6.1 DefaultCompilerAdapter.java:

protected int executeExternalCompile(String[] args, int firstFileName,
 boolean quoteFiles) {
String[] commandArray = null;
File tmpFile = null;


try {
/*
 * Many system have been reported to get into trouble with
 * long command lines - no, not only Windows .
 *
 * POSIX seems to define a lower limit of 4k, so use a temporary
 * file if the total length of the command line exceeds this limit.
 */
if (Commandline.toString(args).length() > 4096
&& firstFileName >= 0) {
PrintWriter out = null;
try {
File userDir = getJavac().getTempdir();
if (userDir == null) {
String userDirName = System.getProperty("user.dir");
userDir = new File(userDirName);
}
tmpFile = fileUtils.createTempFile("files", "", userDir);
tmpFile.deleteOnExit();
out = new PrintWriter(new FileWriter(tmpFile));
for (int i = firstFileName; i < args.length; i++) {
if (quoteFiles && args[i].indexOf(" ") > -1) {
args[i] = args[i].replace('\\', '/');
out.println("\"" + args[i] + "\"");
} else {
out.println(args[i]);
}
}
out.flush();
commandArray = new String[firstFileName + 1];
System.arraycopy(args, 0, commandArray, 0, firstFileName);
commandArray[firstFileName] = "@" + tmpFile;
} catch (IOException e) {
throw new BuildException("Error creating temporary file",  
   <= EXCEPTION THROWN HERE
 e, location);

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

DO NOT REPLY [Bug 22865] - Zip whenempty attribute is broken

[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://issues.apache.org/bugzilla/show_bug.cgi?id=22865

Zip whenempty attribute is broken

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 AssignedTo|[EMAIL PROTECTED]  |[EMAIL PROTECTED]
 Status|REOPENED|NEW
   Target Milestone|--- |1.6.2



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 13:00 ---
I see.  **/* doesn't match "" while not having any includes pattern (i.e. having
** as implicit includes pattern) does.  addResources later skips the "" name.

Unfortunately the trivial fix to exclude "" in grabResources would conflict with
prefix or fullpath attributes.  Hmm, grabResources has access to the FileSets as
well.  I'll look into it.

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

cvs commit: ant TODO

[bodewig]

bodewig 2004/06/04 06:00:17

  Modified:.Tag: ANT_16_BRANCH TODO
  Log:
  one more reproducable and simple bug
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.3.2.3   +2 -0  ant/Attic/TODO
  
  Index: TODO
  ===
  RCS file: /home/cvs/ant/Attic/TODO,v
  retrieving revision 1.3.2.2
  retrieving revision 1.3.2.3
  diff -u -r1.3.2.2 -r1.3.2.3
  --- TODO  4 Jun 2004 12:00:45 -   1.3.2.2
  +++ TODO  4 Jun 2004 13:00:17 -   1.3.2.3
  @@ -41,3 +41,5 @@
   * telnet doesn't disconnect properly (PR 25935) [Stefan unless Peter
 is faster].
   
  +*  creates empty
  +  archive. [Stefan]
  
  
  

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

Re: DispatchTask

[Stefan Bodewig]

Hi Magesh,

nice to read from you.

On Wed, 2 Jun 2004, Magesh Umasankar <[EMAIL PROTECTED]> wrote:

> I'd like to introduce the concept of a DispatchTask to Ant.

Do you think a task with a mode/action that selects the method to run
instead of execute is really that common?

It looks like one could start a debate over whether those shouldn't
better be split into several separate tasks.  Even in Ant we have both
extremes, compare the clearcase/VSS or starteam tasks on the one and
ftp on the other side.  Whenever I touch ftp it feels as if it should
have been multiple tasks instead - so I'm in the multiple task camp
and probably wouldn't use DispatchTask myself.

Stefan

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

Re: How to deal with RuntimeExceptions thrown by tasks?

[Stefan Bodewig]

On Fri, 4 Jun 2004, Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:

> ANT is stoping for these exceptions :-) but whether keepGoing should
> continue, I would settle here for simplicity and using the new
> signature say that Error will stop and BuildException may continue.

Works for me.

Stefan

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

Re: Ant 1.6.2 TODO list

[Stefan Bodewig]

On Fri, 4 Jun 2004, Jan Materne <[EMAIL PROTECTED]> wrote:

> - Ant 1.6.2 is ready for final build if all TODOs are done?

that's the idea.

>   Should it be part of 1.6.2 or not?

I'd trust your judgement here.  If the changes are important enough to
get released immediately, put them in.  If you know it will take a
longer time than the other pieces of the list and think it could wait
for a 1.6.3 release in six months or so - defer it.

Stefan

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

Re: Ant 1.6.2 release?

[Peter Reilly]

Stefan Bodewig wrote:
I see.  Looking into DirectoryScanner it seems not that easy to fix
since the scanner will either recurse into x or exclude x based on the
followSymlink setting so anything we'd want to do would not only
affect Delete but probably any other task using DirectoryScanner as
well.
 

I was thinking more in terms of adding an attribute to the delete task

But, it does need to interact with the fileset "symfollowsymlinks" 
attribute in some way to
make things consistent, or perhaps a "treatsymlinksasfiles" attribute to 
filesets, which
 sets if  "treatsymlinkasfiles" is set.

Peter
Stefan
-
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 26057] - Need CutFilter in FilterChain

[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://issues.apache.org/bugzilla/show_bug.cgi?id=26057

Need CutFilter in FilterChain

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

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

DO NOT REPLY [Bug 25633] - macrodef should support default element node

[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://issues.apache.org/bugzilla/show_bug.cgi?id=25633

macrodef should support default element node

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6.2
Version|1.7Alpha (nightly)  |1.6.1



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 12:28 ---
Added to Ant cvs, will be in ant 1.6.2

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

cvs commit: ant WHATSNEW

[peterreilly]

peterreilly2004/06/04 05:26:13

  Modified:.Tag: ANT_16_BRANCH WHATSNEW
  Log:
  sync
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.503.2.98 +5 -0  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.503.2.97
  retrieving revision 1.503.2.98
  diff -u -r1.503.2.97 -r1.503.2.98
  --- WHATSNEW  4 Jun 2004 07:47:59 -   1.503.2.97
  +++ WHATSNEW  4 Jun 2004 12:26:12 -   1.503.2.98
  @@ -170,6 +170,11 @@
   
   * A binary option has been added to . Bugzilla Report 26312.
   
  +* Added DynamicConfiguratorNS, an namespace aware version of
  +  DynamicConfigurator. Bugzilla Report 28436.
  +
  +* Add implicit nested element to . Bugzilla Report 25633.
  +
   Changes from Ant 1.6.0 to Ant 1.6.1
   =
   
  
  
  

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

DO NOT REPLY [Bug 25749] - add "don't get rid of subdirs" and "only sync specified file mask" options to Sync task

[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://issues.apache.org/bugzilla/show_bug.cgi?id=25749

add "don't get rid of subdirs" and "only sync specified file mask" options to 
Sync task

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 12:30 ---


*** This bug has been marked as a duplicate of 21832 ***

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

DO NOT REPLY [Bug 21832] - sync task to ignore destination 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://issues.apache.org/bugzilla/show_bug.cgi?id=21832

sync task to ignore destination files

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 12:30 ---
*** Bug 25749 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 24680] - [PATCH] set threadContextLoader for xslt task

[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://issues.apache.org/bugzilla/show_bug.cgi?id=24680

[PATCH] set threadContextLoader for xslt task

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6.2

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

cvs commit: ant WHATSNEW

[peterreilly]

peterreilly2004/06/04 05:25:13

  Modified:.WHATSNEW
  Log:
  update WHATSNEW for dynamicconfiguratorNS and for implicit nested elements
in macrodef
  
  Revision  ChangesPath
  1.614 +5 -0  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.613
  retrieving revision 1.614
  diff -u -r1.613 -r1.614
  --- WHATSNEW  4 Jun 2004 07:44:53 -   1.613
  +++ WHATSNEW  4 Jun 2004 12:25:13 -   1.614
  @@ -200,6 +200,11 @@
   
   * A binary option has been added to . Bugzilla Report 26312.
   
  +* Added DynamicConfiguratorNS, an namespace aware version of
  +  DynamicConfigurator. Bugzilla Report 28436.
  +
  +* Add implicit nested element to . Bugzilla Report 25633.
  +
   Changes from Ant 1.6.0 to Ant 1.6.1
   =
   
  
  
  

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

DO NOT REPLY [Bug 21832] - sync task to ignore destination 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://issues.apache.org/bugzilla/show_bug.cgi?id=21832

sync task to ignore destination files

[EMAIL PROTECTED] changed:

   What|Removed |Added

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

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

DO NOT REPLY [Bug 22914] - Error using rmic compiler

[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://issues.apache.org/bugzilla/show_bug.cgi?id=22914

Error using rmic compiler

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

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

Alias names for imported targets

[Stefan Bodewig]

Hi,

Erik already brought that up.  Target foo imported from project named
bar is known as "foo" in my build file unless I override it (in which
case it becomes "bar.foo".  I'd like to have the alias name "bar.foo"
available even if I don't override it.

I haven't looked into the code yet, but are there any principal
objections?  Target time-frame would be 1.6.2.

Stefan

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

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs ImportTest.java

[peterreilly]

peterreilly2004/06/04 05:09:38

  Modified:src/main/org/apache/tools/ant/taskdefs Tag: ANT_16_BRANCH
ImportTask.java
   src/testcases/org/apache/tools/ant/taskdefs Tag:
ANT_16_BRANCH ImportTest.java
  Added:   src/etc/testcases/taskdefs/import/symlinks/d1 Tag:
ANT_16_BRANCH p1.xml
   src/etc/testcases/taskdefs/import/symlinks/d2 Tag:
ANT_16_BRANCH p2.xml
   src/etc/testcases/taskdefs/import/symlinks/d3a Tag:
ANT_16_BRANCH p3.xml
  Log:
  Sync the import canonical change - 28505
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.16.2.11 +0 -9  
ant/src/main/org/apache/tools/ant/taskdefs/ImportTask.java
  
  Index: ImportTask.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/ImportTask.java,v
  retrieving revision 1.16.2.10
  retrieving revision 1.16.2.11
  diff -u -r1.16.2.10 -r1.16.2.11
  --- ImportTask.java   14 Apr 2004 08:21:35 -  1.16.2.10
  +++ ImportTask.java   4 Jun 2004 12:09:38 -   1.16.2.11
  @@ -131,8 +131,6 @@
   }
   }
   
  -importedFile = new File(getPath(importedFile));
  -
   if (importStack.contains(importedFile)) {
   getProject().log(
   "Skipped already imported file:\n   "
  @@ -148,11 +146,4 @@
   }
   }
   
  -private static String getPath(File file) {
  -try {
  -return file.getCanonicalPath();
  -} catch (IOException e) {
  -return file.getAbsolutePath();
  -}
  -}
   }
  
  
  
  No   revision
  No   revision
  1.1.2.1   +0 -0  ant/src/etc/testcases/taskdefs/import/symlinks/d1/p1.xml
  
  Index: p1.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/import/symlinks/d1/p1.xml,v
  retrieving revision 1.1
  retrieving revision 1.1.2.1
  diff -u -r1.1 -r1.1.2.1
  
  
  
  No   revision
  No   revision
  1.1.2.1   +0 -0  ant/src/etc/testcases/taskdefs/import/symlinks/d2/p2.xml
  
  Index: p2.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/import/symlinks/d2/p2.xml,v
  retrieving revision 1.1
  retrieving revision 1.1.2.1
  diff -u -r1.1 -r1.1.2.1
  
  
  
  No   revision
  No   revision
  1.1.2.1   +0 -0  ant/src/etc/testcases/taskdefs/import/symlinks/d3a/p3.xml
  
  Index: p3.xml
  ===
  RCS file: 
/home/cvs/ant/src/etc/testcases/taskdefs/import/symlinks/d3a/p3.xml,v
  retrieving revision 1.1
  retrieving revision 1.1.2.1
  diff -u -r1.1 -r1.1.2.1
  
  
  
  No   revision
  No   revision
  1.6.2.6   +39 -3 
ant/src/testcases/org/apache/tools/ant/taskdefs/ImportTest.java
  
  Index: ImportTest.java
  ===
  RCS file: 
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/ImportTest.java,v
  retrieving revision 1.6.2.5
  retrieving revision 1.6.2.6
  diff -u -r1.6.2.5 -r1.6.2.6
  --- ImportTest.java   9 Mar 2004 17:02:01 -   1.6.2.5
  +++ ImportTest.java   4 Jun 2004 12:09:38 -   1.6.2.6
  @@ -17,6 +17,9 @@
   
   package org.apache.tools.ant.taskdefs;
   
  +import java.io.File;
  +import java.io.IOException;
  +
   import org.apache.tools.ant.BuildException;
   import org.apache.tools.ant.BuildFileTest;
   import org.apache.tools.ant.Location;
  @@ -51,8 +54,12 @@
   
   public void testSerial() {
   
configureProject("src/etc/testcases/taskdefs/import/subdir/serial.xml");
  -assertLogContaining(
  -"Unnamed2.xmlUnnamed1.xmlSkipped already imported file");
  +assertLogContaining("Unnamed2.xmlUnnamed1.xml");
  +String fullLog = getFullLog();
  +String substring = "Skipped already imported file";
  +assertTrue("expecting full log to contain \"" + substring
  ++ "\" full log was \"" + fullLog + "\"",
  +fullLog.indexOf(substring) >= 0);
   }
   
   // allow this as imported in targets are only tested when a target is run
  @@ -105,5 +112,34 @@
   "Did not see build exception",
   false);
   }
  -}
   
  +public void testSymlinkedImports() throws Exception {
  +String ln = "/usr/bin/ln";
  +if (!new File(ln).exists()) {
  +ln = "/bin/ln";
  +}
  +if (!new File(ln).exists()) {
  +// Running on Windows or something, so skip it.
  +return;
  +}
  +String symlink = "src/etc/testcases/taskdefs/impo

DO NOT REPLY [Bug 20408] - Allow passing arguments to javac globally

[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://issues.apache.org/bugzilla/show_bug.cgi?id=20408

Allow passing arguments to javac globally

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 12:10 ---
I think  will do just fine as well.

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

DO NOT REPLY [Bug 5270] - Ant task - allow multiple targets

[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://issues.apache.org/bugzilla/show_bug.cgi?id=5270

Ant task - allow multiple targets

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 12:06 ---
*** Bug 6368 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 6368] - Wild card as a target name or comma separated target name

[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://issues.apache.org/bugzilla/show_bug.cgi?id=6368

Wild card as a target name or comma separated target name

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 12:06 ---


*** This bug has been marked as a duplicate of 5270 ***

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

DO NOT REPLY [Bug 18945] - subversion

[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://issues.apache.org/bugzilla/show_bug.cgi?id=18945

subversion

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 12:04 ---
*** Bug 29344 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 29344] - support for subversion (SVN)

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29344

support for subversion (SVN)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 12:04 ---


*** This bug has been marked as a duplicate of 18945 ***

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

cvs commit: ant TODO

[bodewig]

bodewig 2004/06/04 05:00:45

  Modified:.Tag: ANT_16_BRANCH TODO
  Log:
  pass 1 through bugzilla
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.3.2.2   +5 -0  ant/Attic/TODO
  
  Index: TODO
  ===
  RCS file: /home/cvs/ant/Attic/TODO,v
  retrieving revision 1.3.2.1
  retrieving revision 1.3.2.2
  diff -u -r1.3.2.1 -r1.3.2.2
  --- TODO  4 Jun 2004 08:16:26 -   1.3.2.1
  +++ TODO  4 Jun 2004 12:00:45 -   1.3.2.2
  @@ -36,3 +36,8 @@
   *  and JDK 1.5 [Stefan hopes that Stephane solves it for
 him, otherwise he'll do it himself]
   
  +* symlink creates cyclic links. [Stefan]
  +
  +* telnet doesn't disconnect properly (PR 25935) [Stefan unless Peter
  +  is faster].
  +
  
  
  

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

DO NOT REPLY [Bug 27976] - excludes in filesets doesnt work

[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://issues.apache.org/bugzilla/show_bug.cgi?id=27976

excludes in filesets doesnt work

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

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

DO NOT REPLY [Bug 27533] - input task behaviour when validargs and defaultvalue specified

[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://issues.apache.org/bugzilla/show_bug.cgi?id=27533

input task behaviour when validargs and defaultvalue specified

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement

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

DO NOT REPLY [Bug 27411] - Ant 1.6.1 breaks with Jikes 1.19

[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://issues.apache.org/bugzilla/show_bug.cgi?id=27411

Ant 1.6.1 breaks with Jikes 1.19





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 11:46 ---
This is because Ant 1.5.x ignored the -target switch for jikes, see Bug 20580.

I don't understand why your compilation fails for target 1.4, but this is a
different story.  A duplicate of Bug 26404 in some way?

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

DO NOT REPLY [Bug 27170] - Error occurs in references parameter in if space in directory name

[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://issues.apache.org/bugzilla/show_bug.cgi?id=27170

Error occurs in references parameter in  if space in directory name

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 11:41 ---
*** Bug 29252 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 29252] - Parameters with spaces need to be quoted in temporary command 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://issues.apache.org/bugzilla/show_bug.cgi?id=29252

Parameters with spaces need to be quoted in temporary command files

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 11:41 ---


*** This bug has been marked as a duplicate of 27170 ***

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

DO NOT REPLY [Bug 26645] - war update is not working in Linux box

[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://issues.apache.org/bugzilla/show_bug.cgi?id=26645

war update is not working in Linux box





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 11:37 ---
Can you please compare the timestamps of the files you expect to be newer (so
that war needs an update) with the timestamps inside the archive?  This bug may 
be
related to bug 17934.

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

DO NOT REPLY [Bug 26097] - scp task truncates directory names with spaces at the space

[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://issues.apache.org/bugzilla/show_bug.cgi?id=26097

scp task truncates directory names with spaces at the space

[EMAIL PROTECTED] changed:

   What|Removed |Added

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

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

DO NOT REPLY [Bug 26020] - doesn't close files properly

[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://issues.apache.org/bugzilla/show_bug.cgi?id=26020

 doesn't close files properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Writing to a file.  | doesn't close files
   ||properly

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

DO NOT REPLY [Bug 24194] - ignores includes attribute

[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://issues.apache.org/bugzilla/show_bug.cgi?id=24194

 ignores includes attribute





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 10:49 ---
The reason is the constructor of DotnetCompile which implicitly adds the pattern
*.cs to the includes list.

I'm not sure how to fix it without breaking backwards compatibility.

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

DO NOT REPLY [Bug 25674] - delete with followSymlinks=false fails if pointed at non-existant 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://issues.apache.org/bugzilla/show_bug.cgi?id=25674

delete with followSymlinks=false fails if pointed at non-existant directory





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 11:11 ---
There is a typo in your example build file (your create testexits without an s
in front of the last t).

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

DO NOT REPLY [Bug 29320] - The target object does not have getter for if/unless conditions.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29320

The target object does not have getter for if/unless conditions.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

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

DO NOT REPLY [Bug 25181] - [PATCH] symlink task creates cyclic symlinks

[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://issues.apache.org/bugzilla/show_bug.cgi?id=25181

[PATCH] symlink task creates cyclic symlinks

[EMAIL PROTECTED] changed:

   What|Removed |Added

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

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

DO NOT REPLY [Bug 24866] - java.io.FileNotFoundException in

[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://issues.apache.org/bugzilla/show_bug.cgi?id=24866

java.io.FileNotFoundException in 

DO NOT REPLY [Bug 24194] - unconditionally adds *.cs as include pattern to the implicit fileset

[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://issues.apache.org/bugzilla/show_bug.cgi?id=24194

 unconditionally adds *.cs as include pattern to the implicit fileset

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary| ignores includes  | unconditionally adds
   |attribute   |*.cs as include pattern to
   ||the implicit fileset

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

DO NOT REPLY [Bug 24196] - When the drive letter of a mapped network drive is not explicitly specified in a path element, the location of the path element is indeterminate to the java task (and perhaps to other tasks, too).

[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://issues.apache.org/bugzilla/show_bug.cgi?id=24196

When the drive letter of a mapped network drive is not explicitly specified in 
a path element, the location of the path element is indeterminate to the java 
task (and perhaps to other tasks, too).





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 10:52 ---
Can you run this with -verbose or even -debug please?  Or at least echo the
value of test.path (convert it to a property and echo the property).

Prepending ${basedir} in the location attribute is not needed at all, but it
shouldn't do any harm either.

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

RE: How to deal with RuntimeExceptions thrown by tasks?

[Jose Alberto Fernandez]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> 
> I'm not sure I'm really able to capture the issue completely 
> but I'll try.  The discussion so far has been around  
> and friends, but maybe there is something deeper.
> 

To me the issue goes beyound . It is more about having
a stricter invariant on what to expect as a result from
calling Task.perform(). The current signature really is:

public void  perform() throws BuildException, RuntimeException, Error;

I would prefer a tighter signature:

public void perform() throws BuildException, Error;

and here Error is a fatal condition that should just stop ANT.

> The code that handles the keepGoing mode explicitly only 
> handles BuildExceptions - all other exceptions cause Ant to 
> abort immediately.
> 
> The questions I've seen so far:
> 
> * should Ant continue in the presence of other RuntimeExceptions if
>   keepGoing is set?
> 

Given my view point above, the question would be about Error.

> * or simply wrap any other RuntimeException into a BuildException?
> 
This I want.

> * maybe even do this in Task#perform so that no RuntimeException ever
>   propagates outside of the Task execution?
> 

Yes probably the correct place for it.

>   This may need to be done in Target#performTasks or even
>   Target#execute once again since tasks can override perform.
> 

I guess this is not needed.

> * should Ant do this with all RuntimeExceptions or exclude some where
>   continuing may be wrong (SecurityException for example?)
> 

ANT is stoping for these exceptions :-) but whether keepGoing should
continue,
I would settle here for simplicity and using the new signature say that
Error will stop and BuildException may continue.

Jose Alberto

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

RE: Ant 1.6.2 TODO list

[Jan . Materne]

What should be written there?
- Ant 1.6.2 is ready for final build if all TODOs are done?
  Which means that we need a timeframe. E.g. my next (actual) topic
  is the Continuus section. But I´d to wait because the job needs much
  time at the moment.
  I think I´ll need until June for that - then testing :-) Should it
  be part of 1.6.2 or not?

Jan

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 04, 2004 10:28 AM
> To: [EMAIL PROTECTED]
> Subject: Ant 1.6.2 TODO list
> 
> 
> Hi,
> 
> A few minutes ago I've committed a TODO list to the 1.6 branch, please
> go ahead and add items (but please only if you are willing to work on
> them yourself) and/or assign existing items to yourself.
> 
> I've added a few items of my own and intend to look through bugzilla
> today to make "my list" complete.
> 
> What I'd like to do is calling the list closed on Monday - after that
> only showstoppers should be added and we'd have a clear roadmap for
> 1.6.2.
> 
> OK?
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

DO NOT REPLY [Bug 22865] - Zip whenempty attribute is broken

[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://issues.apache.org/bugzilla/show_bug.cgi?id=22865

Zip whenempty attribute is broken





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 10:12 ---
Here is my test build.xml file

  





  
  




 
  


The problem is the "basedir" attribute, this causes
Zip#grabResources() to return an entry.

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

DO NOT REPLY [Bug 29067] - junit stylesheets should use redirect URI

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29067

junit stylesheets should use redirect URI





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 08:15 ---
Santiago

> I can check exactly from what version

please do.  It would break Xalan-J 1 support, but this may be OK - we'd like to
know for sure which Xalan-J 2 versions we'd break.

This report is related to bug 27541

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

DO NOT REPLY [Bug 28426] - DynamicConfiguratorNS

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28426

DynamicConfiguratorNS

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6.2
Version|1.7Alpha (nightly)  |1.6.1



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 08:11 ---
AFAICT we can close this now.

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

DO NOT REPLY [Bug 22865] - Zip whenempty attribute is broken

[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://issues.apache.org/bugzilla/show_bug.cgi?id=22865

Zip whenempty attribute is broken





--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 09:58 ---
If coreear is empty I get no zip.  Do you have a self-contained testcase?

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

Ant 1.6.2 TODO list

[Stefan Bodewig]

Hi,

A few minutes ago I've committed a TODO list to the 1.6 branch, please
go ahead and add items (but please only if you are willing to work on
them yourself) and/or assign existing items to yourself.

I've added a few items of my own and intend to look through bugzilla
today to make "my list" complete.

What I'd like to do is calling the list closed on Monday - after that
only showstoppers should be added and we'd have a clear roadmap for
1.6.2.

OK?

Stefan

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

Re: Ant 1.6.2 release?

[Stefan Bodewig]

On Fri, 04 Jun 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:
> 
>>On Thu, 27 May 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:

>>> 4) search paths for the import task
>>
>>Could you please expand on that?
>>
> This is something that could be done post 1.6.2.
> The idea is that  would
> be a bit like #include from cpp where there is an INCLUDEPATH
> that specifies where to look for "x.xml".

OK, I'd rather defer that after 1.6.2.

>>> 5) add delete on exit feature to the  task - needed to
>>> antlib devl on windows
>>
>>What does this do?
>>
> One would need to do something like:
> 
>   
> 
> 
> There has been some discussion in ant-dev on this subject:

OK, I see.  Doesn't look to difficult to implement, but harder to
provide decent feedback to the user: "Could not delete file X, will
try to delete it again later"?

You can add it to the list as far as I'm concerned.

>>> 6) add a do not follow symbolic links option to  task
>>
>>When is this needed?
>
> One could have a build directory:
> build
>  y
>  x -> something outside the build directory that should not be deleted
> 
> One cannot use the delete task to delete the build directory
> completely.

I see.  Looking into DirectoryScanner it seems not that easy to fix
since the scanner will either recurse into x or exclude x based on the
followSymlink setting so anything we'd want to do would not only
affect Delete but probably any other task using DirectoryScanner as
well.

Stefan

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

DO NOT REPLY [Bug 16351] - JspC/Java task - compile error via ANT for Jsps using Tomcat 4.1.18

[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://issues.apache.org/bugzilla/show_bug.cgi?id=16351

JspC/Java task - compile error via ANT for Jsps using Tomcat 4.1.18

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6



--- Additional Comments From [EMAIL PROTECTED]  2004-06-04 09:03 ---
Since people now complain that the task doesn't work for Tomcat 5 anymore while
it did for Tomcat 4 I'll simply assume that the issues listed here have been
resolved one way or another between 1.5.1 and 1.6.1 - picking 1.6 as a likely
candidate.

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

Re: Ant 1.6.2 release?

[Peter Reilly]

Stefan Bodewig wrote:
On Thu, 27 May 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
 

1) implicit element for macrodef
move from head to 1.6 branch
2) DynamicElementNS
move from head to 1.6 branch
   

Those are done, correct?
 

Just a few minutes ago :-)
3) Allow nested elements discovered by refection on to be
   in the ant default namespace uri as well as the task's/types
   namespace uri (the current rules are difficult to follow and
   make build scripts look like line noise :-( aka xml ns hell)
   

Could you please (re-)start a dedicated thread for this so we have all
the details can resolve this once and for all time (well, a months or
two would be fine 8-)
 

Ok,
I will get my thoughts together and compose an e-mail with references to
the previous discussions.
 

Other things - maybe after 1.6.2
1)  the antlibresolve task
   

after 1.6.2
 

Ok.
 

2)  concat support for binary files
   

Done, correct?
 

Yes.
 

3)  fix some classloading issues:
 a) set the parent classloader in createClassloader() - most
 likely a good thing and
   

I agree, but we may want to reopen this as a discussion in a separate
thread for more visibility.
 

Correct.
 

4) search paths for the import task
   

Could you please expand on that?
 

This is something that could be done post 1.6.2.
The idea is that  would
be a bit like #include from cpp where there is an INCLUDEPATH
that specifies where to look for "x.xml".
There has been a discussion on these issues,
http://marc.theaimsgroup.com/?l=ant-user&m=108187987209772&w=2
 

5) add delete on exit feature to the  task - needed to
antlib devl on windows
   

What does this do?
 

I was experimenting with an internal antlib.
And needed to remove the jar file from .ant/lib directory
so that the build was not affected by the classes in
the antlib jar file.
 
   
   
 
   
 
Doing this is not possible on windows as the jar file is "open".
One would need to do something like:
   
 
   
There has been some discussion in ant-dev on this subject:
http://marc.theaimsgroup.com/?t=10766343392&r=1&w=2
6) add a do not follow symbolic links option to  task
   

When is this needed?  Why is the symlink support in  not
sufficient?
 

I see that this is an old issue:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1550
I do not think that this is sufficient.
see:
http://marc.theaimsgroup.com/?l=ant-user&m=107877912817024&w=2
The example is :
<>"
  
   
  
which doesn't follow symlinks but also doesn't delete the symlinks
themselves."
One could have a build directory:
build
y
x -> something outside the build directory that should not be deleted
One cannot use the delete task to delete the build directory completely.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to deal with RuntimeExceptions thrown by tasks?

[Stefan Bodewig]

On Fri, 04 Jun 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:

> Task#perform is a "final" method.

Ouch.  Thanks 8-)

I vaguelly recall overriding perform in Sequential once, but I maybe
wrong (did I override maybeConfigure?)

OK, one less point to talk about.

Stefan

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