DO NOT REPLY [Bug 5907] - ExecTask waits regardless of what you are executing

[bugzilla]

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

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

ExecTask waits regardless of what you are executing





--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 23:36 ---
Has any validation of this patch been made yet?  Why is the status still "NEW"?

DO NOT REPLY [Bug 16270] - copy date bug when copying from ntfs to samba mounted drive

[bugzilla]

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

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

copy date bug when copying from ntfs to samba mounted drive





--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 21:25 ---
Have a look at the  selector for filesets; it takes a granularity in
milliseconds.

could you use this selector in your copy fileset, with a large enough
granularity to work around the problem?

(we also have a different selector which does byte-for-byte compares, but this
would implictly contain the network load you are scared of -though it supports
granularity too)

DO NOT REPLY [Bug 16414] - Task: - Entering text on the same line as the quest ion

[bugzilla]

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

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

Task: - Entering text on the same line as the quest ion

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 21:20 ---
I dont think this is possible, given that the message is routed via the ant
listener/logger infrastructure... it is up to the current logger to choose how
it displays the message, and not the  task itself.

sorry.

DO NOT REPLY [Bug 16431] - Mutable properties

[bugzilla]

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

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

Mutable properties





--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 21:19 ---
Dima,

I am going to close this as wontfix unless you can come up with a good argument
for mutability. Ant properties are not variables, and immutability is powerful,
once you get used to the 'whoever sets it first, wins' concept.

DO NOT REPLY [Bug 18400] - add failonerror to target

[bugzilla]

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

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

add failonerror to target

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 21:15 ---
jhuang: have you looked at the  stuff in ant-contrib.sf.net? These
would seem to meet your needs in a cleaner, more structured manner.

I dont see any likelihood that targets will add failonerror; try/catch is a
better model as you can detect and act on failure, rather than just ignore it,

DO NOT REPLY [Bug 19180] - enhancement to mail / email smtp task to support smtp over tls/ssl

[bugzilla]

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

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

enhancement to mail / email smtp task to support smtp over tls/ssl





--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 21:11 ---
Is this part of JavaMail? Are you able/willing to write all the code to do this
if not?

DO NOT REPLY [Bug 19517] - VB 6 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=19517

VB 6 task

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 21:09 ---
no. At least, not in the ant core codebase. You are free to write your own task 
:)

the  task and the  task ar similar enough that they share a lot of
code, and are likely to evolve over time. But VB6? It's on care and maintenance,
is it not? It shipped in 1998 or 1998 as I recall, which makes it 4-5 years old.
With 400+ plus bugs in ant right now, I am going to have to run from this one. 

If you do want a VB6 project, ant-contrib.sf.net would be a place that could be
willing to host it, but you would still be left to code it yourself. They
maintain the C++ tasks.

sorry,

-steve

DO NOT REPLY [Bug 20062] - Create flag to control System.exit() call in org.apache.tools.ant.Main

[bugzilla]

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

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

Create flag to control System.exit() call in org.apache.tools.ant.Main





--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 21:01 ---
well, the normal way to embed ant is to create your own Project class and drive
it from there. But if you want to have better embedding of main, the way to do
it would be to have a public inner main method that returned an exit code,
leaving the existing main class to drive system.exit()

DO NOT REPLY [Bug 20137] - Invalid creator ID on build of ant

[bugzilla]

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

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

Invalid creator ID on build of ant

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 20:59 ---
Closing this as not an ant bug, just an ant use issue.

DO NOT REPLY [Bug 20153] - zip/unzip tasks - last modified dates off by an hour

[bugzilla]

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

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

zip/unzip tasks - last modified dates off by an hour





--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 20:58 ---
I dont know where the problem lies. With a combination of local+remote systems,
tz transition and the many layers of code, who knows. 

Now, if you want to track down the problem, I'm sure we will accept a bug fix
that you can find. But it seems to me like this will be one of those
nearly-impossible-to-replicate situations that are hard to deal with.

My recommendation is to leave this as a WONTFIX, do a clean build, and move on
:( (recommendation 2 is everyone moves to GMT, uses time_t as a clock and does
away with leap seconds, but that is likely to encounter opposition from the rest
of humanity)

DO NOT REPLY [Bug 20194] New: - PlainJUnitResultFormatter produces poor output

[bugzilla]

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

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

PlainJUnitResultFormatter produces poor output

   Summary: PlainJUnitResultFormatter produces poor output
   Product: Ant
   Version: 1.5.3
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The results of a failing JUnit test run from ANT are poor.
The Ant JUnit task formatter produces the following:

Testcase: testAccessibleComponent3 took 0.474 sec
FAILED
TerminalAccessibleComponent.getAccessibleAt() NYI
junit.framework.AssertionFailedError:
TerminalAccessibleComponent.getAccessibleAt() NYI
at bean.accessibility.Base.testAccessibleComponent3(Base.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at support.EnhancedTestCase.runTest(EnhancedTestCase.java:25)

Testcase: testAccessibleComponent3Testcase: testChildren1 took 0.025 sec

It is the last line of this that is problematic. Basically, when a test fails,
there is a missing newline from the end of its output. The result is that the
start of the output of the next test is put on the same line.

This results in output that is *very* hard to read.

DO NOT REPLY [Bug 20153] - zip/unzip tasks - last modified dates off by an hour

[bugzilla]

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

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

zip/unzip tasks - last modified dates off by an hour





--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 17:11 ---
I have another interesting observation which (kind of) makes sense.
Untill now, I was zipping files that were older since the last
"day-light-savings".
Now my collection of files have some files that are newer than that
date. When I zip all files together, the files that are created after
the last "day-light-saving" instant have proper date, while the ones
that were created before have an hour off.
Does this mean ant/java does not handle day-light-saving very well, or
does it mean Windows does not provide enough info for java to be able
to figure this out ?

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

[bodewig]

bodewig 2003/05/23 07:23:58

  Modified:src/main/org/apache/tools/ant/taskdefs/optional/junit
JUnitTask.java
  Log:
  simplify patch a little further
  
  Revision  ChangesPath
  1.65  +3 -4  
ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java
  
  Index: JUnitTask.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java,v
  retrieving revision 1.64
  retrieving revision 1.65
  diff -u -r1.64 -r1.65
  --- JUnitTask.java23 May 2003 14:15:42 -  1.64
  +++ JUnitTask.java23 May 2003 14:23:58 -  1.65
  @@ -834,9 +834,8 @@
   try {
   log("Using System properties " + System.getProperties(),
   Project.MSG_VERBOSE);
  -Path userClasspath = commandline.getClasspath();
  -if (userClasspath != null) {
  -cl = createClassLoader();
  +cl = createClassLoader();
  +if (cl != null) {
   cl.setThreadContextLoader();
   }
   runner = new JUnitTestRunner(test, test.getHaltonerror(),
  
  
  

DO NOT REPLY [Bug 19953] - junit timeouts and formatter not found

[bugzilla]

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

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

junit timeouts and formatter not found

[EMAIL PROTECTED] changed:

   What|Removed |Added

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



--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 14:17 ---
should be fixed with nightly build 2003-05-24, I've committed a slightly
modified version of your patch.

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

[bodewig]

bodewig 2003/05/23 07:15:43

  Modified:.WHATSNEW
   src/main/org/apache/tools/ant/taskdefs/optional/junit
FormatterElement.java JUnitTask.java
  Log:
  Load formatter from user specified classpath - even in the timeout case.
  
  PR: 19953
  Submitted by: Mariano Benitez 
  
  Revision  ChangesPath
  1.424 +4 -0  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.423
  retrieving revision 1.424
  diff -u -r1.423 -r1.424
  --- WHATSNEW  23 May 2003 13:40:34 -  1.423
  +++ WHATSNEW  23 May 2003 14:15:41 -  1.424
  @@ -132,6 +132,10 @@
   * file names that include spaces need to be quoted inside the @argfile
 argument using  and JDK 1.4.  Bugzilla Report 16871.
   
  +*  didn't work with custom formatters that were only available
  +  on the user specified classpath when a timeout occured.  Bugzilla
  +  Report 19953.
  +
   Other changes:
   --
   * Six new Clearcase tasks added.
  
  
  
  1.12  +20 -2 
ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/FormatterElement.java
  
  Index: FormatterElement.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/FormatterElement.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- FormatterElement.java 7 Mar 2003 11:23:06 -   1.11
  +++ FormatterElement.java 23 May 2003 14:15:42 -  1.12
  @@ -1,7 +1,7 @@
   /*
* The Apache Software License, Version 1.1
*
  - * Copyright (c) 2001-2002 The Apache Software Foundation.  All rights
  + * Copyright (c) 2001-2003 The Apache Software Foundation.  All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
  @@ -57,6 +57,7 @@
   import java.io.File;
   import java.io.FileOutputStream;
   import java.io.OutputStream;
  +import org.apache.tools.ant.AntClassLoader;
   import org.apache.tools.ant.BuildException;
   import org.apache.tools.ant.types.EnumeratedAttribute;
   
  @@ -172,14 +173,31 @@
   return useFile;
   }
   
  +/**
  + * @since Ant 1.2
  + */
   JUnitResultFormatter createFormatter() throws BuildException {
  +return createFormatter(null);
  +}
  +
  +/**
  + * @since Ant 1.6
  + */
  +JUnitResultFormatter createFormatter(ClassLoader loader) 
  +throws BuildException {
  +
   if (classname == null) {
   throw new BuildException("you must specify type or classname");
   }
   
   Class f = null;
   try {
  -f = Class.forName(classname);
  +if (loader == null) {
  +f = Class.forName(classname);
  +} else {
  +f = loader.loadClass(classname);
  +AntClassLoader.initializeClass(f);
  +}
   } catch (ClassNotFoundException e) {
   throw new BuildException(e);
   }
  
  
  
  1.64  +37 -23
ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java
  
  Index: JUnitTask.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java,v
  retrieving revision 1.63
  retrieving revision 1.64
  diff -u -r1.63 -r1.64
  --- JUnitTask.java12 May 2003 14:00:09 -  1.63
  +++ JUnitTask.java23 May 2003 14:15:42 -  1.64
  @@ -835,26 +835,8 @@
   log("Using System properties " + System.getProperties(),
   Project.MSG_VERBOSE);
   Path userClasspath = commandline.getClasspath();
  -Path classpath = userClasspath == null
  -  ? null
  -  : (Path) userClasspath.clone();
  -if (classpath != null) {
  -if (includeAntRuntime) {
  -log("Implicitly adding " + antRuntimeClasses
  -+ " to CLASSPATH", Project.MSG_VERBOSE);
  -classpath.append(antRuntimeClasses);
  -}
  -
  -cl = getProject().createClassLoader(classpath);
  -cl.setParentFirst(false);
  -cl.addJavaLibraries();
  -log("Using CLASSPATH " + cl.getClasspath(),
  -Project.MSG_VERBOSE);
  -
  -// make sure the test will be accepted as a TestCase
  -cl.addSystemPackageRoot("junit");
  -// will cause trouble in JDK 1.1 if omitted
  -cl.addSystemPackageRoot("org.apache.tools.ant");
  +if (userClasspath != null) {
  +cl = createClassLoader();
  

DO NOT REPLY [Bug 20179] - Inline manifest causes jar to be rebuilt too often

[bugzilla]

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

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

Inline manifest causes jar to be rebuilt too often

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 13:54 ---
I respectfully disagree. Quoting from the Ant documentation:

"When using inline manifests, the Jar task will check whether the build file is
more recent that the Jar file when deciding whether to rebuild the Jar. This
will not take into account property file changes which may affect the resulting
Jar." 

Although it doesn't explicitly say what happens when property values set by the
tstamp task are used, I think it's fair to say that the second sentence above
hints that property values are not considered. I think that the documented
behaviour, as I interpret it, is preferable. Your suggested solution just moves
the problem to the manifest task, and I would still have to work around the
problem with uptodate checks.

Also, there are several examples in the Ant documentation where tstamp created
properties such as ${TODAY} are used with the "Implementation-Version"
attributes. As the examples are written, they would cause a rebuild at leas once
a day.

I hope that I'm completely wrong (or out cycling as we say in Sweden) and that
there is a simple way to get the current time into the manifest without uptodate
checks, but I really can't think of one!

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/windows Attrib.java

[bodewig]

bodewig 2003/05/23 06:40:37

  Modified:.WHATSNEW
   docs/manual/CoreTasks chmod.html conditions.html
   docs/manual/OptionalTasks attrib.html
   src/main/org/apache/tools/ant/taskdefs Chmod.java
Execute.java
   src/main/org/apache/tools/ant/taskdefs/optional/unix
AbstractAccessTask.java
   src/main/org/apache/tools/ant/taskdefs/optional/windows
Attrib.java
  Log:
  NonStop Kernel is Unix as far as Ant is concerned.
  
   doesn't like to be called with parallel.
  
   and  should also disable the addsourcefile attribute.
  
  Revision  ChangesPath
  1.423 +1 -1  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.422
  retrieving revision 1.423
  diff -u -r1.422 -r1.423
  --- WHATSNEW  19 May 2003 15:37:31 -  1.422
  +++ WHATSNEW  23 May 2003 13:40:34 -  1.423
  @@ -246,7 +246,7 @@
   
   * New filterreader .
   
  -* Support for HP's NonStop (Tandem) OS has been added.
  +* Support for HP's NonStop Kernel (Tandem) OS has been added.
   
   * 's basedir attribute is now optional if you specify nested
 filesets.  Bugzilla Report 18046.
  
  
  
  1.13  +1 -1  ant/docs/manual/CoreTasks/chmod.html
  
  Index: chmod.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTasks/chmod.html,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- chmod.html21 May 2003 08:55:35 -  1.12
  +++ chmod.html23 May 2003 13:40:36 -  1.13
  @@ -10,7 +10,7 @@
   Chmod
   Description
   Changes the permissions of a file or all files inside specified
  -directories. Right now it has effect only under Unix or NonStop (Tandem).
  +directories. Right now it has effect only under Unix or NonStop Kernel 
(Tandem).
   The permissions are also UNIX style, like the argument for the chmod 
command.
   See the section on directory based
   tasks, on how the inclusion/exclusion of files works, and how to
  
  
  
  1.18  +1 -1  ant/docs/manual/CoreTasks/conditions.html
  
  Index: conditions.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTasks/conditions.html,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- conditions.html   14 Mar 2003 16:01:03 -  1.17
  +++ conditions.html   23 May 2003 13:40:36 -  1.18
  @@ -92,7 +92,7 @@
 unix (for all Unix and Unix-like operating systems)
 netware (for Novell NetWare)
 os/2 (for OS/2)
  -  tandem (for HP's NonStop - formerly Tandem)
  +  tandem (for HP's NonStop Kernel - formerly Tandem)
 win9x for Microsoft Windows 95 and 98
 z/os for z/OS and OS/390
 os/400 for OS/400
  
  
  
  1.4   +0 -8  ant/docs/manual/OptionalTasks/attrib.html
  
  Index: attrib.html
  ===
  RCS file: /home/cvs/ant/docs/manual/OptionalTasks/attrib.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- attrib.html   21 May 2003 08:55:35 -  1.3
  +++ attrib.html   23 May 2003 13:40:36 -  1.4
  @@ -60,14 +60,6 @@
   No, default is file
 
 
  -maxparallel
  -Limit the amount of parallelism by passing at
  -  most this many sourcefiles at once.  Set it to <= 0 for
  -  unlimited.  Defaults to unlimited.
  -No
  -
  -  
  -  
   verbose
   Whether to print a summary after execution or not.
 Defaults to false.
  
  
  
  1.38  +1 -2  ant/src/main/org/apache/tools/ant/taskdefs/Chmod.java
  
  Index: Chmod.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Chmod.java,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- Chmod.java19 May 2003 12:18:08 -  1.37
  +++ Chmod.java23 May 2003 13:40:37 -  1.38
  @@ -263,7 +263,6 @@
   }
   
   protected boolean isValidOs() {
  -return (Os.isFamily("unix") || Os.isFamily("tandem")) 
  -&& super.isValidOs();
  +return Os.isFamily("unix") && super.isValidOs();
   }
   }
  
  
  
  1.55  +2 -3  ant/src/main/org/apache/tools/ant/taskdefs/Execute.java
  
  Index: Execute.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Execute.java,v
  retrieving revision 1.54
  retrieving revision 1.55
  diff -u -r1.54 -r1.55
  --- Execute.java  23 Apr 2003 15:57:43 -  1.54
  +++ Execute.java  23 May 2003 13:40:37 -  1.55
  @@ -231,8 +231,7 @@
   

Re: Enhance chgrp/chown?

[Stefan Bodewig]

On 23 May 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> On Thu, 22 May 2003, Gus Heck <[EMAIL PROTECTED]> wrote:
>
>> Have you found out anything about tandem/nonstop and chgrp chown
>> yet?
> 
> No, sorry.  I'll keep you posted.

OK, Tandem supports chown and chgrp, but at the same time,
Os.isFamily("unix") will be true for it so the special case isn't
needed (and not needed in Chown either where it is going to be removed
in a few minutes).

Stefan

DO NOT REPLY [Bug 20179] - Inline manifest causes jar to be rebuilt too often

[bugzilla]

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

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

Inline manifest causes jar to be rebuilt too often

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 11:25 ---
This is not a bug.

Your  task is specifying a manifest with different values from that
existing jar and that jar must therefore be rebuilt.

You probably should save the manifest to file using the manifest task and only
write the file when you want to update the time value in the manifest.

DO NOT REPLY [Bug 20179] New: - Inline manifest causes jar to be rebuilt too often

[bugzilla]

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

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

Inline manifest causes jar to be rebuilt too often

   Summary: Inline manifest causes jar to be rebuilt too often
   Product: Ant
   Version: 1.5.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When an inline manifest element is used, the dependency checking gets confused.
According to the documentation, the jar should be rebuilt if any dependent file
has been changed, including the build.xml itself. That is fine, but if an
expanded property used within the manifest element causes the resulting manifest
to be different from the one in the jar, the jar is rebuilt. I have an inline
manifest where the implementation version is constructed from properties
including one that is the time of day in hours and minutes. If at least one
minute has passed since the last rebuild, the jar is rebuilt again. This
behaviour makes it practically impossible to include build date and time in the
manifest.

DO NOT REPLY [Bug 5969] - Is SMTP authorization possible for MailLogger ??

[bugzilla]

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

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

Is SMTP authorization possible for MailLogger ??





--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 08:39 ---
Its fine if MailLogger *can* send through JavaMail, but it shouldn't be 
required.  The infrastructure 
is already in place to handle with/without JavaMail conditions, so it should be 
fine to add the 
authorization code.

DO NOT REPLY [Bug 13510] - CvsChangeLog should accept a branch as an optional parameter

[bugzilla]

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

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

CvsChangeLog should accept a branch as an optional parameter





--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 08:17 ---
Maybe a solution to that is use the current cvs command (which gets logs for 
all branches), and get branch infos during the output parsing process.

Also, using rlog could be an option of this task (knowing that the output is 
not quite the same in this case). But that's an other topic.

DO NOT REPLY [Bug 20174] New: - antClassloader can not handle signed jars

[bugzilla]

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

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

antClassloader can not handle signed jars

   Summary: antClassloader can not handle signed jars
   Product: Ant
   Version: 1.5.3
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

if I use the task 'taskdef' with the attribute 'classpath', the envelope of jars
loaded by this way are not available (aka: getSigners returns null)

Bye Thomas

DO NOT REPLY [Bug 13510] - CvsChangeLog should accept a branch as an optional parameter

[bugzilla]

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

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

CvsChangeLog should accept a branch as an optional parameter

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 08:13 ---
*** Bug 20163 has been marked as a duplicate of this bug. ***

DO NOT REPLY [Bug 20163] - CvsChangeLog task support for branches

[bugzilla]

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

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

CvsChangeLog task support for branches

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 08:12 ---
This enhancement is not done, but the request is a duplicate of 13510.

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

Re: Enhance chgrp/chown?

[Stefan Bodewig]

On Thu, 22 May 2003, Gus Heck <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:
>> On Wed, 21 May 2003, Gus Heck <[EMAIL PROTECTED]>
>> wrote:

>>>Another logicical addition to all 3 of them might be allowing
>>>dirsets.
>> I think the type="dir" attribute covers this, doesn't it?
> 
> I guess multiple ways of doing things just isn't popular with anyone
> around here.

Uhm, Perl used to be my favorite scripting language for quite some
time.  But probably not because of TIMTOWTDI 8-)

If there is an existing way to do a thing I have no problem with
adding another way if it improves consistency accross tasks.  But
there are not that many tasks supporting  (yet?).

> Makes me wonder why we have dirsets at all if we can't use them
> here, and only in a narrow way for subant...

The main reason for  has been as a nested element in .

> I suppose type="dir" is a pre-dirset feature on chmod,

Yes.

> These tasks are not yet released, so maybe they should take DirSets
> instead?

They inherit it from ExecuteOn, so they cannot un-use the attribute
(well, they could override the setter and throw an exception).

> Maybe fileset should have had a type="dir|file|both" instead of
> having Dirsets.

 always does the implict type="both" - it is the task that
decides whether it invokes getIncludedFiles or
getIncludedDirectories.  Take a look at the code of FileSet and
DirSet, they are identical.

We considered making dirsets and filesets interchangeable by having
dirset return the included directories in getIncludedFiles but decided
against it - not just because it was hackish but also because tasks
might rely on the fact that getIncludedFiles returns files and not
directories.

> What direction should I be taking with chgrp/chown here?

Thinking about it a second time - add  support to ExecuteOn.

> Given the constraints of back compatability, it seems that the only
> way to make life easy for the user is keep adding the new ways of
> referencing things (ie dirsets) to the old tasks in which they make
> sense.

True.

> ok I understand. Have you found out anything about tandem/nonstop
> and chgrp chown yet?

No, sorry.  I'll keep you posted.

Stefan

DO NOT REPLY [Bug 20137] - Invalid creator ID on build of ant

[bugzilla]

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

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

Invalid creator ID on build of ant

[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|1.1 |1.4



--- Additional Comments From [EMAIL PROTECTED]  2003-05-23 01:27 ---
the ant version is actually 1.4.

You said:
"To be sure, set fork=true failonerror=true in  and see what happens."

I did this and the build remains successful.  It doesn't fail.