Re: [PMC-VOTE] Ant 1.5.4

[Bruce Atherton]

At 09:09 AM 8/12/2003 +0200, Stefan Bodewig wrote:
Please vote for/against these archives as the 1.5.4 release.  Here's
my +1 for starters.
+1

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

RE: [PMC-VOTE] Ant 1.5.4

[Christoph Wilhelms]

+1

> [It is the PMC's responsibility to ensure that our releases 
> are OK, so only PMC member votes are binding, that shouldn't 
> stop anybody else from speking her/his mind.]
> 
> Conor has created the 1.5.4 distribution, it can be found at 
.  In addition I've diffed
the source and binary releases of 1.5.3-1 against their corresponding
files and the results are in that directory as well (*-dist.diff).



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

DO NOT REPLY [Bug 22361] New: - Copy with glob mapper maps AND copies originals

[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=22361

Copy with glob mapper maps AND copies originals

   Summary: Copy with glob mapper maps AND copies originals
   Product: Ant
   Version: 1.5.3
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


---
Using following XML fragment
---



  

  


  




---
Results
---

Tools_copy_blueprint_one_org:
 [copy] Copying 6 files to D:\TEMP\SDNA50\tools\blueprint
 [copy] Copying D:\SEDONA\intarsia5.0\installer\tools\blueprint\actors.csv t
o D:\TEMP\SDNA50\tools\blueprint\ORA1_actors.csv
 [copy] Copying D:\SEDONA\intarsia5.0\installer\tools\blueprint\workgroups.c
sv to D:\TEMP\SDNA50\tools\blueprint\ORA1_workgroups.csv
 [copy] Copying D:\SEDONA\intarsia5.0\installer\tools\blueprint\servlet_perm
issions.csv to D:\TEMP\SDNA50\tools\blueprint\ORA1_servlet_permissions.csv
 [copy] Copying D:\SEDONA\intarsia5.0\installer\tools\blueprint\subscription
s.csv to D:\TEMP\SDNA50\tools\blueprint\ORA1_subscriptions.csv
 [copy] Copying D:\SEDONA\intarsia5.0\installer\tools\blueprint\users.csv to
 D:\TEMP\SDNA50\tools\blueprint\ORA1_users.csv
 [copy] Copying D:\SEDONA\intarsia5.0\installer\tools\blueprint\channels.csv
 to D:\TEMP\SDNA50\tools\blueprint\ORA1_channels.csv

---
Expectation
---

Expecting to get six mapped (renamed) files Ant claimed to have copied in the
output given above.  However, I get 12 files in the destination directory -- the
six expected mapped names, PLUS the six orginal names.

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

CVS down?

[Martijn Kruithof]

Hi,
Can it be that public CVS is currently down?
I seem to not be able to do updats / create patches anymore.
Kind Regards, Martijn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22326] - remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader

[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=22326

remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 19:44 ---
Currently I am also looking at packages types  - zip, and I think about marking
some methods and classes deprecated for their only purpose is to work around 1.1
- 1.2 differences, is this ok?

Further I would like to bring up the question if it is really good to introduce
WeakishReference in 1.6 (at least according to the @since tags in the code). As
1.6 need not compile against 1.1 and the only purpose of this class (and
WeakishReference12 is to work around a 1.1 / 1.2 difference. (I would definetely
have marked it deprecated if it is ok to mark them deprecated, but it seems a
bit silly to introduce a new class in a new release that is deprecated from the
start.)

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

RE: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/option al/net FTP.java

[Dominique Devienne]

VFS is very interesting, but if you make Ant dependent upon it, then there's
a circular dependency between the two, since VFS is dependent upon Ant to
build *and* for its own custom Ant tasks...

Which is why Ant core still is standalone, except for the XML parser. I'm
not against this dependency, I'm just saying it has to be thought out
carefully, and dealt with on the GUMP side as well (but on that side, we
have super Stefan to fix everything ;-)

--DD

> -Original Message-
> From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 12, 2003 11:39 AM
> To: Ant Developers List
> Subject: Re: cvs commit:
> ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
> 
> Once ant 1.6 is released, I would like to discuss again the topic of
> "Resource(s)" and/or Jakarta-Common VFS. I would like to evaluate the use
> of
> Jakarta-Common VFS in ant, so that ant does not need to reinvent the wheel
> for everything. Just a thought at the moment, might be wrong.

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

Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java

[Gus Heck]

Antoine Levy-Lambert wrote:
- Original Message -
From: "Gus Heck" <[EMAIL PROTECTED]>
Sent: Tuesday, August 12, 2003 4:10 PM
 

Antoine,
Since you have recently been playing with symlinks/FTP what are your
thoughts on bug 14320?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14320
   

First the bad news : I do not have the time to work on this in the frame of
ant 1.6. I am concerned that this might open a large Pandora box. :-(
 

Fair enough :)
Once ant 1.6 is released, I would like to discuss again the topic of
"Resource(s)" and/or Jakarta-Common VFS. I would like to evaluate the use of
Jakarta-Common VFS in ant, so that ant does not need to reinvent the wheel
for everything. Just a thought at the moment, might be wrong.
 

hmm I should find out what Jakarta-Common VFS is :)

Manipulating the symbolic link as a link is doable in a portable way for
packaging tasks (zip, jar, war, ear, tar). I am not sure what is the API to
find the target of the symbolic link (do an exec of ls -L and read the
result, or go the JNI route ?) ...
 

Parsing command line output seems dicey and brittle.
*** We need another attribute for filesets and directoryscanner called
preservesymlinks. ***

I can imagine that one could add an atribute that caused an OS check and if
we
it is a *nix set a flag that caused copy to use FileUtils.isSymbolicLink to
identify symlinks. symlinks could then be reproduced in either absolute form
or
minimum relative form or not reproduced in the destination directory based
on an
atribute such as copySymlinksAs="none"|"absolute"|"minRelative"
I don't know how much time I can put into it, but I'd be willing to try that
if
it sounds like a good idea to anyone else.


Does "minRelative" mean relative to the root dir of the fileset ?
Maybe "asis" would be a good option too, to copy somelink -> ../../foo/bar
as ../../foo/bar

 

/usr/local/storage/links/link2foo -> /usr/local/storage/gus/baz/bar/foo
is also equivalent to the following
/usr/local/storage/links/lin2foo -> 
../../../../user/local/storage/gus/baz/bar/foo
/usr/local/storage/links/lin2foo -> ../../../local/storage/gus/baz/bar/foo
/usr/local/storage/links/lin2foo -> ../../storage/gus/baz/bar/foo
/usr/local/storage/links/lin2foo -> ../gus/baz/bar/foo

The last of these is what I call minRelative. (I don't know if there is 
a more standard term).
I currently convert all links in my website to this form by execing the 
linux command
(not the ant task): "symlinks -rcs" from the document root twice. The 
first invocation changes absolute to relative, and the second reduces 
the lenghthy links to minimal links. I do not know if this command is 
available on other *nix platforms.

It should also be possible to compare the canoniacal path of the dir the 
link is to be created in and the canonical path of the target of the 
link and calculate the minimum number of ../ 's needed to create the 
link and get "minRelative" that way.

Maintaining asis requires direct knowledge of which of the 4 
posibilities above was on the file system, and probably does require 
parsing output of ln or ls or whatever. "minRelative" links are of 
particular to me interest because they are the least likely to break 
when moving directories containing links around. The first of the 4 
relative links always breaks, if it gets moved up or down a level, but 
if I move /usr/local/storage to /usr/local/old/storage then the last two 
forms still work. My website build creates links in a tempdir before 
moving the whole thing to where the world can see it (assuming all went 
well).

This attribute would only be legal with followsymlinks="false" (since true
means manipulate the objects pointed to by the links).
Then we need to define task by task how to use
preservesymlinks/copysimlinks="none"|"absolute"|"minRelative"


Symbolic links do not exist in Windows (for ant's FileUtils#isSymbolicLink)
Symbolic links can be created via the symlink task, which relies on ln -s
available in the operating system

agree

.lnk files exist
non .lnk links exist
not aware of command line utility distributed with all versions of the OS to
do this
aware of ln.exe in cygwin
aware of shortcut.exe, a program which is part of the Windows NT resource
kit of Microsoft

lnk files have substantial functional differences. a .lnk to a directory 
cannot be included in the middle of a path as such: 
C:\projects\ant.lnk\src\main ... this won't work, but of course does 
work with symlinks. I have heard that there is something like symlinks 
out there called "reparse points" but I really don't know anything other 
than the name. (google searches a year ago wern't too fruitful on the 
topic, but this may have changed).


the area where symbolic links support should be least problematic,
except for possible exceptions due to media not accepting symbolic links


Apart from ,  packaging tasks are good candidates for having the
option of copying/preserving symbolic links. They would only be impacted if
they run 

[DOCPATCH] javac task doc

[Shatzer, Larry]

The default for verbose is off. Let's mention that in the docs. :)

(Sorry if my mailer wraps this, sometimes attachments don't make it through,
but the patch should be pretty straight forward as what to do).

-- Larry

Index: docs/manual/CoreTasks/javac.html
===
RCS file: /home/cvspublic/ant/docs/manual/CoreTasks/javac.html,v
retrieving revision 1.40
diff -u -r1.40 javac.html
--- docs/manual/CoreTasks/javac.html15 May 2003 12:44:00 -  1.40
+++ docs/manual/CoreTasks/javac.html12 Aug 2003 17:37:29 -
@@ -243,7 +243,7 @@
   
   
 verbose
-Asks the compiler for verbose output.
+Asks the compiler for verbose output; defaults to
off.
 No
   
   

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

Re: Recursive properties resolution ?

[Steve Loughran]

Emmanuel FELLER wrote:
Hi,
I read the archive about the recursive properties and I am not convinced
so i would like to reopen the debate. (Or i may have missed the good
mail, if so correct me).
Excuse the long mail, but i prefer explain all my problem.
I do the all J2EE project build of my firm, the build process is exactly
the same for all the 8 projects on the 3 environnements (execpt
properties). So I did build files that accept param and all the param
are given in a properties file.
Now the dev are finishing and we will include some new environnement
like pre-production, production, debugging.
We cannot stay any more with one properties file for 1(project/env). We
had 24 properties file, now we will have more than 50 (and new projects
are comming).
Some properties are project and environnement independant, others are
project dependant, others are environnement dependant, others are both
project and environnement dependant.
So if i keep multiple file (one per project/env couple), i have multiple
and cross redundancy. And i have no way to define the env properties,
after the project properties and after project/env properties as they
are mixed and cross defined. (i tried without succes).
In this case I do not see what I can do to solve this without recursive
properties resolution.
-have multiple properties files...one per deployment target, one per 
project, one per local installation.

-use property expansion to decide which properties files to load
e.g. a system would have
system.properties:
deploy.target=chamonix
chamonix:properties
deploy.platform=jboss
deploy.process=ftp
jboss.properties:
install.buildfile.name=jboss.xml
build.properties:
build.compiler=jikes
deploy.username=stevo
deploy.password=stevo
the project then does

  //loads chamonix.properties

//finally we can call our install routine

  

This gives you: dynamic configuration, and property file control. One 
propfile/build file per app server platform, one per system with sys 
config details, one per user with user options.


What do you mind ? Should I develope with for an ant-contrib task as you
reject this for ant2
(http://jakarta.apache.org/ant/ant2/requested-features.html) ?
if ant-contrib tasks work for you, use them.

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

Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java

[Antoine Levy-Lambert]

- Original Message -
From: "Gus Heck" <[EMAIL PROTECTED]>
Sent: Tuesday, August 12, 2003 4:10 PM


> Antoine,
>
> Since you have recently been playing with symlinks/FTP what are your
> thoughts on bug 14320?
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14320
>

First the bad news : I do not have the time to work on this in the frame of
ant 1.6. I am concerned that this might open a large Pandora box. :-(

Once ant 1.6 is released, I would like to discuss again the topic of
"Resource(s)" and/or Jakarta-Common VFS. I would like to evaluate the use of
Jakarta-Common VFS in ant, so that ant does not need to reinvent the wheel
for everything. Just a thought at the moment, might be wrong.



Then concerning bug 14320 specifically :

Changing followsymlinks="false" to preserve symbolic links as symbolic links
would be a breach of behavioral compatibility, not fixing a bug.

The implemented semantics of followsymlinks="false" is like an exclude of
the symbolic links ***and*** of the files and directories pointed to by the
symbolic links if they are not "covered" by another include pattern which
does not use the link.

*** The DirectoryScanner and the tasks that use it (nearly everything that
deals with filesets in ant, or maybe 80% of ant) do not contain any
provision to manipulate symbolic links as links. ***

If the user chooses the option followsymlinks="true" in the fileset
definition, which in turn gets transmitted to the fileset in
AbstractFileSet#getDirectoryScanner(Project p), the files and/or directories
*** pointed to by the links *** (not the links themselves ) are manipulated
by the task using FileSet/DirectoryScanner.

The symbolic links *** as such *** are never manipulated on the target side
of a task that I know of (except symlink of course).

Manipulating the symbolic link as a link is doable in a portable way for
packaging tasks (zip, jar, war, ear, tar). I am not sure what is the API to
find the target of the symbolic link (do an exec of ls -L and read the
result, or go the JNI route ?) ...


*** We need another attribute for filesets and directoryscanner called
preservesymlinks. ***

I can imagine that one could add an atribute that caused an OS check and if
we
it is a *nix set a flag that caused copy to use FileUtils.isSymbolicLink to
identify symlinks. symlinks could then be reproduced in either absolute form
or
minimum relative form or not reproduced in the destination directory based
on an
atribute such as copySymlinksAs="none"|"absolute"|"minRelative"
I don't know how much time I can put into it, but I'd be willing to try that
if
it sounds like a good idea to anyone else.


Does "minRelative" mean relative to the root dir of the fileset ?
Maybe "asis" would be a good option too, to copy somelink -> ../../foo/bar
as ../../foo/bar



This attribute would only be legal with followsymlinks="false" (since true
means manipulate the objects pointed to by the links).

Then we need to define task by task how to use
preservesymlinks/copysimlinks="none"|"absolute"|"minRelative"


Symbolic links do not exist in Windows (for ant's FileUtils#isSymbolicLink)
Symbolic links can be created via the symlink task, which relies on ln -s
available in the operating system


.lnk files exist
non .lnk links exist
not aware of command line utility distributed with all versions of the OS to
do this
aware of ln.exe in cygwin
aware of shortcut.exe, a program which is part of the Windows NT resource
kit of Microsoft


the area where symbolic links support should be least problematic,
except for possible exceptions due to media not accepting symbolic links




Apart from ,  packaging tasks are good candidates for having the
option of copying/preserving symbolic links. They would only be impacted if
they run on UNIX.

Antoine



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

Re: [PMC-VOTE] Ant 1.5.4

[Steve Loughran]

Stefan Bodewig wrote:
[It is the PMC's responsibility to ensure that our releases are OK, so
only PMC member votes are binding, that shouldn't stop anybody else
from speking her/his mind.]
Conor has created the 1.5.4 distribution, it can be found at
.  In addition I've diffed
the source and binary releases of 1.5.3-1 against their corresponding
files and the results are in that directory as well (*-dist.diff).
All javadocs differ, but I've verified that the only changes are style
changes.
Please vote for/against these archives as the 1.5.4 release.  Here's
my +1 for starters.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22020] - [PATCH] addition to 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=22020

[PATCH] addition to  task

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|addition to  task |[PATCH] addition to
   || task

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

DO NOT REPLY [Bug 22345] - In J2SDK 1.5.0 (Tiger) enum is a keyword

[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=22345

In J2SDK 1.5.0 (Tiger) enum is a keyword





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 15:19 ---
But such a useful feature ;-)

No need for EnumeratedAttribute anymore (stay for backward compat anymore of 
course), which was really a pain to use programmatically. The new enum facility 
of 1.5 has everything Ant needs to convert from String to Enum I think. --DD

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

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

[conor]

conor   2003/08/12 08:15:06

  Modified:src/main/org/apache/tools/ant AntClassLoader.java
ComponentHelper.java
  Log:
  Rename some enums ...
  
  Revision  ChangesPath
  1.75  +3 -3  ant/src/main/org/apache/tools/ant/AntClassLoader.java
  
  Index: AntClassLoader.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/AntClassLoader.java,v
  retrieving revision 1.74
  retrieving revision 1.75
  diff -u -w -u -r1.74 -r1.75
  --- AntClassLoader.java   25 Jul 2003 18:40:53 -  1.74
  +++ AntClassLoader.java   12 Aug 2003 15:15:06 -  1.75
  @@ -509,14 +509,14 @@
   public String getClasspath() {
   StringBuffer sb = new StringBuffer();
   boolean firstPass = true;
  -Enumeration enum = pathComponents.elements();
  -while (enum.hasMoreElements()) {
  +Enumeration componentEnum = pathComponents.elements();
  +while (componentEnum.hasMoreElements()) {
   if (!firstPass) {
   sb.append(System.getProperty("path.separator"));
   } else {
   firstPass = false;
   }
  -sb.append(((File) enum.nextElement()).getAbsolutePath());
  +sb.append(((File) 
componentEnum.nextElement()).getAbsolutePath());
   }
   return sb.toString();
   }
  
  
  
  1.20  +3 -3  ant/src/main/org/apache/tools/ant/ComponentHelper.java
  
  Index: ComponentHelper.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/ComponentHelper.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -w -u -r1.19 -r1.20
  --- ComponentHelper.java  21 Jul 2003 10:10:06 -  1.19
  +++ ComponentHelper.java  12 Aug 2003 15:15:06 -  1.20
  @@ -528,10 +528,10 @@
   synchronized (createdTasks) {
   Vector v = (Vector) createdTasks.get(type);
   if (v != null) {
  -Enumeration enum = v.elements();
  -while (enum.hasMoreElements()) {
  +Enumeration taskEnum = v.elements();
  +while (taskEnum.hasMoreElements()) {
   WeakishReference ref =
  -(WeakishReference) enum.nextElement();
  +(WeakishReference) taskEnum.nextElement();
   Task t = (Task) ref.get();
   //being a weak ref, it may be null by this point
   if (t != null) {
  
  
  

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

DO NOT REPLY [Bug 22345] - In J2SDK 1.5.0 (Tiger) enum is a keyword

[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=22345

In J2SDK 1.5.0 (Tiger) enum is a keyword





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 15:08 ---
This is going to be a massive PITA :-(

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

DO NOT REPLY [Bug 22347] - java task with BufferedReader hangs

[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=22347

java task with BufferedReader hangs





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 15:00 ---
In Ant 1.5, you can use the  task to collect input from the user. Not
sure what else your java task does but if the input is for use in Ant, use 
.

It would also be good to have a look at the Ant 1.6 nightly builds and try out
the input management there.

I'm not sure why it is not working for you. This is the code I used

import java.io.*;

public class Test {
static public void main(String[] args) {
try {
BufferedReader br = new BufferedReader(new
InputStreamReader(System.in));
System.out.println("Enter a line");
String line = br.readLine();
System.out.println("Line is " + line);
}
catch (IOException ioe) {
ioe.printStackTrace();
}
}
}

I get the following results

Ant 1.5.3, forked - hangs
Ant 1.5.3, not-forked => works
Ant 1.6alpha, forked => prints Line is null without waiting
Ant 1.6alpha, not-forked => works
Ant 1.6alpha, not-forked, -noinput flag => fails with EOF exception
java.io.EOFException: No input provided for project

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

DO NOT REPLY [Bug 22179] - Wrong Class Version

[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=22179

Wrong Class Version

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 14:33 ---
I'm marking as WORKSFORME. Let me know if you can't resolve the issue.

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

Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java

[Gus Heck]

Antoine,
Since you have recently been playing with symlinks/FTP what are your 
thoughts on bug 14320?

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14320
-Gus
Stefan Bodewig wrote:
On Wed, 6 Aug 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
 

1) concerning the inclusion of "" in includedDirectories
   1a) change the implementation of RM_DIR
   in order not to delete the root dir of the fileset
   or
   1b) revert the inclusion of "" in includedDirectories and change
   the tests + document the difference with DirectoryScanner
   

or our all time backwards compatibility saving option
1c) add a new attribute to  that controls the behavior.
I'm not sure it's worth it, no real opinion other than we shouldn't
break backwards compatibility just to fix something that hasn't been
perceived as broken so far.
 

2) Concerning the symbolic links
   2a) keep the code change and simply mention it in WHATSNEW.
   Then users who do not want to download symbolic link directories
   can
simply set thecorresponding attribute to false.
or
   2b) add a flag in DirectoryScanner#setFollowSymlinks to record
   the fact that follow symlinks has been explicitly set to true,
   and only follow symlinks if the user mentioned it explicitly ?
   

or
2c) call setFollowSymlinks(false) in FTPDirectoryScanner's
constructor.  I.e. change the default value of the attribute and
document it that way.
I'd be in favor of 2c).
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: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java

[Gus Heck]

Antoine,
Since you have recently been playing with symlinks/FTP what are your 
thoughts on bug 14320?

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14320
-Gus
Stefan Bodewig wrote:
On Wed, 6 Aug 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
 

1) concerning the inclusion of "" in includedDirectories
   1a) change the implementation of RM_DIR
   in order not to delete the root dir of the fileset
   or
   1b) revert the inclusion of "" in includedDirectories and change
   the tests + document the difference with DirectoryScanner
   

or our all time backwards compatibility saving option
1c) add a new attribute to  that controls the behavior.
I'm not sure it's worth it, no real opinion other than we shouldn't
break backwards compatibility just to fix something that hasn't been
perceived as broken so far.
 

2) Concerning the symbolic links
   2a) keep the code change and simply mention it in WHATSNEW.
   Then users who do not want to download symbolic link directories
   can
simply set thecorresponding attribute to false.
or
   2b) add a flag in DirectoryScanner#setFollowSymlinks to record
   the fact that follow symlinks has been explicitly set to true,
   and only follow symlinks if the user mentioned it explicitly ?
   

or
2c) call setFollowSymlinks(false) in FTPDirectoryScanner's
constructor.  I.e. change the default value of the attribute and
document it that way.
I'd be in favor of 2c).
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 22347] - java task with BufferedReader hangs

[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=22347

java task with BufferedReader hangs





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 14:17 ---
Thank you for your helpful explanation. Initially task had following definition:



I tried to change value of the attribute fork to no, same result and behaviour.
Finally I removed the attribute at all:



Well, it couldn't read from standard input either and it hanged. But when I
killed ant, at least it has written the message to standard output. 

Basicly, if I understand it well, it is better not to read anything from
standard input from ant. Am I right? Thank you.

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

DO NOT REPLY [Bug 22347] - java task with BufferedReader hangs

[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=22347

java task with BufferedReader hangs

[EMAIL PROTECTED] changed:

   What|Removed |Added

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



--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 14:04 ---
I presume you are forking the  task. Your code should work if you don't
fork since you will then access System.in of the Ant VM. When forked, the 
task is run in a separate VM and no input is provided to this VM. Any attempt to
read input will hang that VM waiting for input that is never going to arrive.
The input you are typing is going to Ant's VM, not the one running your Java
code. The Ant VM isn't trying to read it's input, it's waiting for the external
VM to finish. The end result is that everything hangs.

Ant 1.6 has much better input handling. By default when forked, the external
VM's input stream is closed so that any attempts to read input will fail fast -
i.e. it won't hang. Your readLine will return null. You may, however, provide
input to the task from a file or an Ant property. 

It is not possible to connect the console to the forked  task in the
external VM. i.e. You cannot type into console and have that input provided to
the external VM. In general achieving this would be difficult given that more
than one task may be running in parallel and there is no way to know how much
input each task will want.

Finally Ant 1.6 adds a -noinput flag. This prevents even non-forked  tasks
from reading input. This can be useful if you don't want to inadvertently hang
an unattended Ant operation (say a continuous integration type of run).

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

DO NOT REPLY [Bug 22298] - "Copy" could take filelists where files are on different drives

[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=22298

"Copy" could take filelists where files are on different drives





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 13:53 ---
I stand corrected then :)

I differ with Peter and you then, as I see path as being abused this way. The 
FileList type clearly conveys the meaning of an arbitrary list of files which 
are all required to exists, whereas Path conveys an ordered list of files 
(often just directories, but extended to JAR/ZIP and URL in Java), that exist 
or not, used to look up stuff (executables, resources, etc...).

These are completely disjoint things, and Path should not be abused to take on 
this new meaning IMHO.

Thanks, --DD

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

[VOTE] Let's use archive.apache.org

[Stefan Bodewig]

Hi,

as some of you may know, there is a new virtual host called
archive.apache.org that is supposed to be the source for software
archeologists, much as our ant.apache.org/old-releases folder is now.

archive.apache.org is setup to rsync from www.apache.org/dist without
ever deleting anything, this means all new releases will end up there
eventually at one point in time.

I've gone ahead and copied over the contents of our old-releases
folder to this box and want to propose that we start using it instead
of /old-releases from now on.

The benefits I see:

* It is on cvs.apache.org, every committer has access to it.

* You don't need to copy files around after a release, just remove the
  non-zips.

* At a point in time, mirrors may want to pick up archive.apache.org
  as well - so we'd benefit from mirroring even for our old releases.

* we'd remove downloads and not (CVS-)controlled content from our
  website.

If this is accepted, I volunteer to update our ReleaseInstructions.

Stefan

BTW, I found that the source distribution of Ant 1.2 doesn't have a
signature - the binary distribution is signed.  Does anybody have an
old copy of the ZIP archive and can verify that the file on
archive.apache.org (or /old-releases) is the file it claims to be?  If
so, please sign it (or let me do it).

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

RE: beating the dead Ant 1.6 horse

[Dominique Devienne]

I'm also interested PropertyHelper, and in particular Costin's
experimental XPath based one. I'd like to be able to define
functions (defined as part of an AntLib) to operate directly on
property values, kind of like XPath functions, and it sounds like
property helper is the way to get this!?!? --DD

> -Original Message-
> From: Knut Wannheden [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 12, 2003 4:33 AM
> To: [EMAIL PROTECTED]
> Subject: Re: beating the dead Ant 1.6 horse
> 
> > > The others are antlib/namespace/polymorph stuff. I'm wondering if we
> can
> > > get to the point where the ant optional tasks are packaged as antlibs
> and
> > > potentially not added to the root loader if their supporting libraries
> are
> > > not also available to the root loader. This would allow them to be
> > > taskdef'd in later in a build.
> >
> > I would rather leave this for after 1.6 release.
> 
> And how about the new PropertyHelper which lets you plugin additional
> PropertyHelpers to process properties prefixed with a namespace, i.e.
> "foo:my-property"?
> 
> --
> knut

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

DO NOT REPLY [Bug 22345] - In J2SDK 1.5.0 (Tiger) enum is a keyword

[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=22345

In J2SDK 1.5.0 (Tiger) enum is a keyword





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 13:19 ---
Thanks - I will recompile (tomorrow :-)

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

DO NOT REPLY [Bug 22345] - In J2SDK 1.5.0 (Tiger) enum is a keyword

[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=22345

In J2SDK 1.5.0 (Tiger) enum is a keyword





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 13:17 ---
Hi Jan,
You have ran into a couple of problems that
have been fixed in current CVS.
Peter

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

DO NOT REPLY [Bug 22345] - In J2SDK 1.5.0 (Tiger) enum is a keyword

[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=22345

In J2SDK 1.5.0 (Tiger) enum is a keyword





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 13:12 ---
I am reading checkstyles doc. My first impression is that there is no build-in 
possibility (the IllegalRegexp module will find a valid 'enum' statement, too - 
I think). But it seems that it´s easy to write custom Checks.

I will try that. (But my local checkstyle installation is broken - something 
with the used  task).


Duplicated project name in import. Project CheckAnt defined first in C:\seu\cvs-
downloads\ant\ant\check.xml and again in C:\seu\cv
s-downloads\ant\ant\build.xml

BUILD FAILED
java.util.ConcurrentModificationException
at 
java.util.AbstractList$Itr.checkForComodificationAbstractList.java:448)
at java.util.AbstractList$Itr.next(AbstractList.java:419)
at org.apache.tools.ant.Target.execute(Target.java:316)
at org.apache.tools.ant.helper.ProjectHelper2.parse
(ProjectHelper2.java:127)
at org.apache.tools.ant.ProjectHelper.configureProject
(ProjectHelper.java:117)
at org.apache.tools.ant.Main.runBuild(Main.java:637)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:161)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:85)

Well, maybe tomorrow :-)

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

Re: [Patch] namespace and antlib

[peter reilly]

On Tuesday 12 August 2003 13:24, Stefan Bodewig wrote:
> On Tue, 12 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > On Tuesday 12 August 2003 12:36, Stefan Bodewig wrote:
> >> On Fri, 1 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> >> >>> >uri="antlib:net.sf.antcontrib"
> >> >classpath="/tmp/ant-contrib.jar"/>
> >>
> >> wouldn't the resource attribute be redundant in that case?
> >
> > Not in this case. The automatic lookup of
> > uri="antlib:net.sf.antcontrib" to net/sf/antcontrib/antlib.xml
> > resource currently is done once when the ns prefix is encountered
> > the first time - it does not take place at the  task.
>
> The obvious question would be: Why not?
The code handles build scripts like:

 (1)
  (2)
  echo helloworld







(1) will associate the ns prefix "ac" with the uri "antlib:net.sf.antcontrib"
(2) ComponentHelper#createComponent will call #checknamespace for
antlib:net.sf.antcontrib and maps it to the net/sf/antcontrib/antlib.xml
resource. It then creates a typedef task, and sets the uri and resource
to "antlib:..." and "net/sf..." and sets the onerror parameter to
"ignore", this will make available the antcontrib's definitions.
 ComponentHelper stores the fact that it has implicitly loaded in these
 definitions so that it does not do this again.
3) This will override the antcontribs' uris definition of shellscript.
4) This will execute the new definition.

> > I have changed this to ant:*,
>
> Hmm, what will be the replacement for antlib:*?

Users are allowed to use antlib:*. The restricted uri's are uris
that users are not allowed to use in .
>
> > as I found when testing that the current code reserves antcontrib:
> > and antelope: 
>
> Sure, I don't see a problem, though.
>
> > This makes sense, but would involve some messing with classloaders
> > and scanning of the jar files in ANT_HOME/antlibs.
>
> I know.
>
> > Each time I look at classloaders, my head melts down
>
> You are not alone ;-)
>
> Seriously, once you've started to really look into classloaders they
> are not that bad.  Only hard to do right (I'm not sure whether I've
> ever done so 8-).
There are sure a lot of things to keep in mind, junit support, classpath
delagate, antclassloader, project#setCoreLoader() (not used??) etc ;-)
Peter


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

DO NOT REPLY [Bug 22345] - In J2SDK 1.5.0 (Tiger) enum is a keyword

[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=22345

In J2SDK 1.5.0 (Tiger) enum is a keyword





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 12:30 ---
Hm - I'm not familiar with checkstyle, too.

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

DO NOT REPLY [Bug 22347] New: - java task with BufferedReader hangs

[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=22347

java task with BufferedReader hangs

   Summary: java task with BufferedReader hangs
   Product: Ant
   Version: 1.5
  Platform: PC
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

if I execute java task with following code, ant hangs and I have to kill it.


public static String readString(String message, String defaultValue) {
System.out.print(message+" ["+defaultValue+"]: ");
String input = null;

try {
BufferedReader reader = new BufferedReader(new
InputStreamReader(System.in));
input = reader.readLine();
if ( input==null || input.length()==0 )
return defaultValue;
else
return input;
} catch (IOException e) {
System.err.println("Cannot read from standard input! Reason:
"+e.getMessage());
return defaultValue;
}
}


It doesn't print to standard output anything (neither argument message). I may
press enter key many times, it add new line to screen, but the method doesn't
return. It block forever and I have to kill it :-(

It seems obvious, that I am not not first man who encountered this issue. See
following site:

http://bobcat.webappcabaret.net/javachina/faq/ant_01.htm#ant_adv_Q10

Any idea, why does this happen and how to avoid it? Thanks

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

Re: [Patch] namespace and antlib

[Stefan Bodewig]

On Tue, 12 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> On Tuesday 12 August 2003 12:36, Stefan Bodewig wrote:
>> On Fri, 1 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote:
>> >   > >uri="antlib:net.sf.antcontrib"
>> >classpath="/tmp/ant-contrib.jar"/>
>>
>> wouldn't the resource attribute be redundant in that case?
> 
> Not in this case. The automatic lookup of
> uri="antlib:net.sf.antcontrib" to net/sf/antcontrib/antlib.xml
> resource currently is done once when the ns prefix is encountered
> the first time - it does not take place at the  task.

The obvious question would be: Why not?

> I have changed this to ant:*,

Hmm, what will be the replacement for antlib:*?

> as I found when testing that the current code reserves antcontrib:
> and antelope: 

Sure, I don't see a problem, though.

> This makes sense, but would involve some messing with classloaders
> and scanning of the jar files in ANT_HOME/antlibs.

I know.

> Each time I look at classloaders, my head melts down

You are not alone ;-)

Seriously, once you've started to really look into classloaders they
are not that bad.  Only hard to do right (I'm not sure whether I've
ever done so 8-).

Stefan

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

DO NOT REPLY [Bug 22345] - In J2SDK 1.5.0 (Tiger) enum is a keyword

[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=22345

In J2SDK 1.5.0 (Tiger) enum is a keyword





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 12:24 ---
Good hint.

I am not familiar with checkstyle (checkstyle.sourceforge.net). Do you know how 
to include this as a new check? The checkstyle config for Ant is in 
http://cvs.apache.org/viewcvs.cgi/ant/src/etc/checkstyle/checkstyle-config and 
the appropriate buildfile in http://cvs.apache.org/viewcvs.cgi/ant/check.xml.

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

Re: [Patch] namespace and antlib

[peter reilly]

On Tuesday 12 August 2003 12:36, Stefan Bodewig wrote:
> On Fri, 1 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> >>uri="antlib:net.sf.antcontrib"
> >classpath="/tmp/ant-contrib.jar"/>
>
> wouldn't the resource attribute be redundant in that case?

Not in this case. The automatic lookup of uri="antlib:net.sf.antcontrib" to
net/sf/antcontrib/antlib.xml resource currently is done once when the
ns prefix is encountered the first time - it does not take place at
the  task.

>
> > 3) reserved uri's
>
> +1 on reserving the ant* protocol.

I have changed this to ant:*, as I found when testing
that the current code reserves antcontrib: and antelope: 

>
> > 5) antlibs in the classpath
>
> I'm leaning towards a repository of antlibs, say ANT_HOME/antlibs with
> classloader isolation between different antlibs and discovery on
> demand here.  I.e. don't force the antlib to live on Ant's core
> classloader - and avoid scanning of the repository unless an antlib:*
> URI has been used.

This makes sense, but would involve some messing with classloaders and
scanning of the jar files in ANT_HOME/antlibs. Each time I look at
classloaders, my head melts down

>
> > 6) adding new definitions to a uri
>
> What about overriding a definition?  Print a warning and succeed like
>  would do now?
Yes, there is no difference.
>
> +1 on the proposal in general.

Excellent.
Peter


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

Re: [Patch] namespace and antlib

[Stefan Bodewig]

On Fri, 1 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote:

>   uri="antlib:net.sf.antcontrib"
>classpath="/tmp/ant-contrib.jar"/>

wouldn't the resource attribute be redundant in that case?

> 3) reserved uri's

+1 on reserving the ant* protocol.

> 5) antlibs in the classpath

I'm leaning towards a repository of antlibs, say ANT_HOME/antlibs with
classloader isolation between different antlibs and discovery on
demand here.  I.e. don't force the antlib to live on Ant's core
classloader - and avoid scanning of the repository unless an antlib:*
URI has been used.

> 6) adding new definitions to a uri

What about overriding a definition?  Print a warning and succeed like
 would do now?

+1 on the proposal in general.

Stefan

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

Re: [Patch] namespace and antlib

[Stefan Bodewig]

On 12 Aug 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

...

you've already answered my questions in your response to DD, sorry.

Stefan

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

Re: [Patch] namespace and antlib

[Stefan Bodewig]

On Fri, 1 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote:

> ant:core is ant's namespace and the default namespace for
> definitions.

does that include the optional tasks?

If you reserve the ant* URI space, does that mean it will be
impossible to add third party tasks to the default namespace or does
"and the default namespace for definitions" mean that all s
without an URI will end up in the default namespace?

> antlib: is treated specially, when ant encounters a
> component (task, or type) that has a namespace uri of this form, ant
> will check if there is a resource of the name packege ->
> path/antlib.xml and if so it will load it up.

searching in the core classloader?  Or do you envision a special (and
separate) plugin store from which to load antlibs on demand?

Stefan

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

DO NOT REPLY [Bug 22338] - add a "minversion" and a "version" attribute to taskdef

[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=22338

add a "minversion" and a "version" attribute to taskdef





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 11:24 ---
It is not enough to check if there is greater-or-equal version available
than the version you have used originally with the project, because
software has sometimes non-backward compatible changes. So rather
something like this should be used:



where "compatible" is an *arbitrary* string, and then Ant should define
a standard interface by which the external task can be invoked to check
if it is compatible. So the external task is who parses the version
number or whatever version description it gets with attribute
"compatible", not Ant, and it is the external task who judges if he is
compatible or not, not Ant.

But... I wonder how many external task developers would take the trouble
to maintain this stuff.

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

DO NOT REPLY [Bug 22297] - Patch for new version of Kaffe

[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=22297

Patch for new version of Kaffe





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 10:59 ---
But older version of Kaffe, in particular version 1.0.6 the last one with a
proprietary filesystem layout, can't run Ant 1.5.3-1 so I think is possible to
ignore them for new releases of Ant.

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

Re: [PMC-VOTE] Ant 1.5.4

[Stefan Bodewig]

On Tue, 12 Aug 2003, Paul Nasrat <[EMAIL PROTECTED]> wrote:

> I mv'd /etc/ant.conf and it worked, now I have to work out how to
> get it to do this in the spec.

I assume that ant-conf is setting rpm_mode to true.  Maybe you can
override this in your spec somehow?

Stefan

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

Re: [PMC-VOTE] Ant 1.5.4

[Paul Nasrat]

On Tue, Aug 12, 2003 at 11:25:06AM +0200, Stefan Bodewig wrote:
> On Tue, 12 Aug 2003, Paul Nasrat <[EMAIL PROTECTED]> wrote:

> Maybe the wrapper script is pulling in an older ant.jar
> from somewhere (/etc/ant.conf?, /usr/share/java via rpm_mode being
> true?)

I mv'd /etc/ant.conf and it worked, now I have to work out how to get it
to do this in the spec.

So no objections here - just a gotcha for our end.

Paul 

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

Re: beating the dead Ant 1.6 horse

[Knut Wannheden]

> > The others are antlib/namespace/polymorph stuff. I'm wondering if we can
> > get to the point where the ant optional tasks are packaged as antlibs
and
> > potentially not added to the root loader if their supporting libraries
are
> > not also available to the root loader. This would allow them to be
> > taskdef'd in later in a build.
>
> I would rather leave this for after 1.6 release.

And how about the new PropertyHelper which lets you plugin additional
PropertyHelpers to process properties prefixed with a namespace, i.e.
"foo:my-property"?

--
knut




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

DO NOT REPLY [Bug 22323] - Problem with Copy when todir has a space in it

[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=22323

Problem with Copy when todir has a space in it





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 09:34 ---
What exactly is the problem?

The following works fine for me.









output: (using ant 1.5.3)
test:
   [delete] Deleting directory /home/preilly/proj/learning/space/targetdir/dir1
with space/dir2 with space
[mkdir] Created dir: /home/preilly/proj/learning/space/targetdir/dir1 with
space/dir2 with space
 [copy] Copying 1 file to /home/preilly/proj/learning/space/targetdir/dir1
with space/dir2 with space

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

Re: [PMC-VOTE] Ant 1.5.4

[Stefan Bodewig]

On Tue, 12 Aug 2003, Paul Nasrat <[EMAIL PROTECTED]> wrote:

> -1 doesn't build for me, though this could be me :(

I think so.

./bootstrap.sh works for me.

> core : 1.5.3

indicates that you have an older version of ant.jar in your CLASSPATH
somewhere - even though I cannot see it in the output.  Cann you add a
sh -x to the invocation of bootstrap/bin/ant at the end of
bootstrap.sh?  Maybe the wrapper script is pulling in an older ant.jar
from somewhere (/etc/ant.conf?, /usr/share/java via rpm_mode being
true?)

Stefan

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

Re: [PMC-VOTE] Ant 1.5.4

[Paul Nasrat]

On Tue, Aug 12, 2003 at 10:23:25AM +0100, peter reilly wrote:
> +1 
> 
> It builds fine for me.
> 
> ./bootstrap.sh
> ./build.sh
> export ANT_HOME `pwd`/dist
> cd dist/bin
> ./ant -version

Hmm, any idea why it might barf on mine (mine's not an official vote
anyway). If I run stuff manually it builds, but not through build.sh:

[EMAIL PROTECTED] apache-ant-1.5.4]$ ./build.sh
Invalid implementation version between Ant core and Ant optional tasks.
 core: 1.5.3
 optional: 1.5.4


./bootstrap/bin/ant -emacs -Dant.install=bootstrap
Buildfile: build.xml
 
prepare:
 
check_for_optional_packages:
 
build:
Copying 2 files to /home/pauln/tmp/apache-ant-1.5.4/build/classes
 
jars:
Building jar: /home/pauln/tmp/apache-ant-1.5.4/build/lib/ant.jar
 
dist-lite:
Copying 1 file to /home/pauln/tmp/apache-ant-1.5.4/dist/lib
 
main:
 
BUILD SUCCESSFUL
Total time: 9 seconds


Paul

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

Re: beating the dead Ant 1.6 horse

[peter reilly]

On Tuesday 12 August 2003 04:20, Conor MacNeill wrote:
> On Tue, 12 Aug 2003 06:53 am, Matt Benson wrote:
> > I know the quote is "there is no timeframe yet on this
> > release".  But is there a ballpark?  2003?  Some
> > particular half of 2004?
>
> Ant 1.6 is very much alive, IMHO.
>
> 2003. :-)
>
> IMHO, I would hope to have it soon (where soon is undefined :-)) but I want
> to resolve a few things first ...
>
> Import is one of them - and it is important to get right. There are many
> different views on this from simple include to include with simple renaming
> to something close to an object model and even xslt style operation. I've
> been a little busy lately to push this along. I'll be back ...
>
> The others are antlib/namespace/polymorph stuff. I'm wondering if we can
> get to the point where the ant optional tasks are packaged as antlibs and
> potentially not added to the root loader if their supporting libraries are
> not also available to the root loader. This would allow them to be
> taskdef'd in later in a build.

I would rather leave this for after 1.6 release.
Peter


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

Re: [PMC-VOTE] Ant 1.5.4

[peter reilly]

+1 

It builds fine for me.

./bootstrap.sh
./build.sh
export ANT_HOME `pwd`/dist
cd dist/bin
./ant -version

On Tuesday 12 August 2003 10:03, Paul Nasrat wrote:
> On Tue, Aug 12, 2003 at 09:09:27AM +0200, Stefan Bodewig wrote:
> > [It is the PMC's responsibility to ensure that our releases are OK, so
> > only PMC member votes are binding, that shouldn't stop anybody else
> > from speking her/his mind.]
>
> -1 doesn't build for me, though this could be me :(
>
> Building using jpackage spec, which runs boostrap and then I get:
>
> ...
> BUILD SUCCESSFUL
> Total time: 19 seconds
> ... Cleaning Up Build Directories
> ... Done Bootstrapping Ant Distribution
> Invalid implementation version between Ant core and Ant optional tasks.
>  core: 1.5.3
>  optional: 1.5.4
>
> Which seems odd, calling ant (1.5.3 jpackage) or ./bootstrap/bin/ant
> work. Output via sh -x:
>
> + test '!' -f bootstrap/lib/ant.jar -o '!' -x bootstrap/bin/ant -o '!'
> -x bootstrap/bin/antRun
> +
> LOCALCLASSPATH=lib/xercesImpl.jar:lib/xml-apis.jar:bootstrap/lib/ant.jar
> + DIRLIBS=lib/optional/*.jar
> + '[' 'lib/optional/*.jar' '!=' 'lib/optional/*.jar' ']'
> + false
> +
> CLASSPATH=lib/xercesImpl.jar:lib/xml-apis.jar:bootstrap/lib/ant.jar:/usr/sh
>are/java/jaxp_parser_impl.jar:/usr/share/java/xml-commons-apis.jar:/usr/shar
>e/java/antlr.jar:/usr/share/java/bcel.jar:/usr/share/java/jaf.jar:/usr/share
>/java/javacc.jar:/usr/share/java/javamail/mailapi.jar:/usr/share/java/junit.
>jar:/usr/share/java/log4j.jar:/usr/share/java/netcomponents.jar:/usr/share/j
>ava/oro.jar:/usr/share/java/regexp.jar:/usr/share/java/xml-commons-apis.jar:
>/usr/share/java/xalan-j2.jar + false
> + export CLASSPATH
> + '[' bootstrap '!=' '' ']'
> + ANT_INSTALL=-Dant.install=bootstrap
> + bootstrap/bin/ant -emacs -Dant.install=bootstrap jars
> Invalid implementation version between Ant core and Ant optional tasks.
>  core: 1.5.3
>  optional: 1.5.4
>
> Paul
>
> -
> 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: [PMC-VOTE] Ant 1.5.4

[Paul Nasrat]

On Tue, Aug 12, 2003 at 09:09:27AM +0200, Stefan Bodewig wrote:
> [It is the PMC's responsibility to ensure that our releases are OK, so
> only PMC member votes are binding, that shouldn't stop anybody else
> from speking her/his mind.]

-1 doesn't build for me, though this could be me :(

Building using jpackage spec, which runs boostrap and then I get:

...
BUILD SUCCESSFUL
Total time: 19 seconds
... Cleaning Up Build Directories
... Done Bootstrapping Ant Distribution
Invalid implementation version between Ant core and Ant optional tasks.
 core: 1.5.3
 optional: 1.5.4

Which seems odd, calling ant (1.5.3 jpackage) or ./bootstrap/bin/ant
work. Output via sh -x:

+ test '!' -f bootstrap/lib/ant.jar -o '!' -x bootstrap/bin/ant -o '!'
-x bootstrap/bin/antRun
+
LOCALCLASSPATH=lib/xercesImpl.jar:lib/xml-apis.jar:bootstrap/lib/ant.jar
+ DIRLIBS=lib/optional/*.jar
+ '[' 'lib/optional/*.jar' '!=' 'lib/optional/*.jar' ']'
+ false
+
CLASSPATH=lib/xercesImpl.jar:lib/xml-apis.jar:bootstrap/lib/ant.jar:/usr/share/java/jaxp_parser_impl.jar:/usr/share/java/xml-commons-apis.jar:/usr/share/java/antlr.jar:/usr/share/java/bcel.jar:/usr/share/java/jaf.jar:/usr/share/java/javacc.jar:/usr/share/java/javamail/mailapi.jar:/usr/share/java/junit.jar:/usr/share/java/log4j.jar:/usr/share/java/netcomponents.jar:/usr/share/java/oro.jar:/usr/share/java/regexp.jar:/usr/share/java/xml-commons-apis.jar:/usr/share/java/xalan-j2.jar
+ false
+ export CLASSPATH
+ '[' bootstrap '!=' '' ']'
+ ANT_INSTALL=-Dant.install=bootstrap
+ bootstrap/bin/ant -emacs -Dant.install=bootstrap jars
Invalid implementation version between Ant core and Ant optional tasks.
 core: 1.5.3
 optional: 1.5.4

Paul

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

DO NOT REPLY [Bug 22326] - remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader

[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=22326

remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 08:35 ---
Sorry I missed that part, I thought it could only be null for void or primitive
types. (Which AntClassLoader clearly isn't). 

I am updating and re-checking my patch.

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

DO NOT REPLY [Bug 22345] New: - In J2SDK 1.5.0 (Tiger) enum is a keyword

[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=22345

In J2SDK 1.5.0 (Tiger) enum is a keyword

   Summary: In J2SDK 1.5.0 (Tiger) enum is a keyword
   Product: Ant
   Version: unspecified
  Platform: All
   URL: http://jcp.org/en/jsr/detail?id=201
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi!

Tiger adds extensions to the Java Programming Language (JSR201). One is
"Enumerations", which required to add the new keyword enum.

I just made a grep (grep -lrw) over some sources and found some Apache projects
using enum as a word.

To be compliant with the new specification, please check that enum is not used
as a variable, field or method name.

Regards,
Robert

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

Recursive properties resolution ?

[Emmanuel FELLER]

Hi,

I read the archive about the recursive properties and I am not convinced
so i would like to reopen the debate. (Or i may have missed the good
mail, if so correct me).

Excuse the long mail, but i prefer explain all my problem.

I do the all J2EE project build of my firm, the build process is exactly
the same for all the 8 projects on the 3 environnements (execpt
properties). So I did build files that accept param and all the param
are given in a properties file.

Now the dev are finishing and we will include some new environnement
like pre-production, production, debugging.

We cannot stay any more with one properties file for 1(project/env). We
had 24 properties file, now we will have more than 50 (and new projects
are comming).

Some properties are project and environnement independant, others are
project dependant, others are environnement dependant, others are both
project and environnement dependant.

So if i keep multiple file (one per project/env couple), i have multiple
and cross redundancy. And i have no way to define the env properties,
after the project properties and after project/env properties as they
are mixed and cross defined. (i tried without succes).

In this case I do not see what I can do to solve this without recursive
properties resolution.

What do you mind ? Should I develope with for an ant-contrib task as you
reject this for ant2
(http://jakarta.apache.org/ant/ant2/requested-features.html) ?

Emmanuel


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

Re: [PMC-VOTE] Ant 1.5.4

[Erik Hatcher]

+1
On Tuesday, August 12, 2003, at 03:09  AM, Stefan Bodewig wrote:
[It is the PMC's responsibility to ensure that our releases are OK, so
only PMC member votes are binding, that shouldn't stop anybody else
from speking her/his mind.]
Conor has created the 1.5.4 distribution, it can be found at
.  In addition I've diffed
the source and binary releases of 1.5.3-1 against their corresponding
files and the results are in that directory as well (*-dist.diff).
All javadocs differ, but I've verified that the only changes are style
changes.
Please vote for/against these archives as the 1.5.4 release.  Here's
my +1 for starters.
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 22298] - "Copy" could take filelists where files are on different drives

[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=22298

"Copy" could take filelists where files are on different drives





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 07:34 ---
DD, I think your memory is failing on you 8-)

Even the very first version of FileList (written by Craeg Strong and committed
by myself) had the required dir attribute.

Making FileList and FileSet drop those requirements when dealing with absolute
paths is nothing that any committer would be opposed to AFAICT, the only point
is that it has to keep working without breaking any tasks.

For , I'm with Peter here.  It would probably be better to make 
support nested s.  In a sense  has become our FileCollection
implementation as it can be used as a container for , , 
and .

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

DO NOT REPLY [Bug 22297] - Patch for new version of Kaffe

[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=22297

Patch for new version of Kaffe





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 07:29 ---
But your patch would break Ant for users of older versions of Kaffe.  I'd prefer
a patch that made Ant with Kaffe 1.1.x and 1.0.x.

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

cvs commit: ant/xdocs mail.xml

[bodewig]

bodewig 2003/08/12 00:25:00

  Modified:docs mail.html
   xdocsmail.xml
  Log:
  mail-archives should be used now, even if it doesn't work either
  
  Revision  ChangesPath
  1.23  +3 -3  ant/docs/mail.html
  
  Index: mail.html
  ===
  RCS file: /home/cvs/ant/docs/mail.html,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- mail.html 11 Aug 2003 13:24:35 -  1.22
  +++ mail.html 12 Aug 2003 07:25:00 -  1.23
  @@ -178,7 +178,7 @@
 anyway.
   These lists are archived at
   
  -  http://archives.apache.org/eyebrowse/ViewLists";>List 
Index on archives.apache.org
  +  http://mail-archives.apache.org/eyebrowse/ViewLists";>List Index on 
mail-archives.apache.org
 http://ant.apache.org/mail/";>Full mbox archives of 
all lists
 http://marc.theaimsgroup.com/";>Mailing list 
Archives
   
  @@ -191,7 +191,7 @@
 mailto:[EMAIL PROTECTED]">Subscribe
 mailto:[EMAIL PROTECTED]">Unsubscribe
   
 http://marc.theaimsgroup.com/?l=ant-user&r=1&w=2";>Archive
   
  @@ -207,7 +207,7 @@
 mailto:[EMAIL PROTECTED]">Subscribe
 mailto:[EMAIL PROTECTED]">Unsubscribe
   
 http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2";>Archive
   
  
  
  
  1.8   +3 -3  ant/xdocs/mail.xml
  
  Index: mail.xml
  ===
  RCS file: /home/cvs/ant/xdocs/mail.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- mail.xml  11 Aug 2003 13:24:35 -  1.7
  +++ mail.xml  12 Aug 2003 07:25:00 -  1.8
  @@ -23,7 +23,7 @@
 These lists are archived at
   
   
  -  http://archives.apache.org/eyebrowse/ViewLists";>List 
Index on archives.apache.org
  +  http://mail-archives.apache.org/eyebrowse/ViewLists";>List Index on 
mail-archives.apache.org
 http://ant.apache.org/mail/";>Full mbox archives of 
all lists
 http://marc.theaimsgroup.com/";>Mailing list 
Archives
   
  @@ -34,7 +34,7 @@
 mailto:[EMAIL PROTECTED]">Subscribe
 mailto:[EMAIL PROTECTED]">Unsubscribe
   
 http://marc.theaimsgroup.com/?l=ant-user&r=1&w=2";>Archive
   
  @@ -50,7 +50,7 @@
 mailto:[EMAIL PROTECTED]">Subscribe
 mailto:[EMAIL PROTECTED]">Unsubscribe
   
 http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2";>Archive
   
  
  
  

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

Re: [PMC-VOTE] Ant 1.5.4

[Conor MacNeill]

On Tue, 12 Aug 2003 05:09 pm, Stefan Bodewig wrote:
>
> Please vote for/against these archives as the 1.5.4 release.  Here's
> my +1 for starters.
>

+1

Conor


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

DO NOT REPLY [Bug 22326] - remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader

[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=22326

remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 07:26 ---
> This one constructor that doesn't actually claims in the javadoc that the 
> parent
> is set to the classloader that loaded this class, as is done in setParent if 
> the
> parent == null.

and the javadocs of Class#getClassLoader

| Returns the class loader for the class. Some implementations may use null to
| represent the bootstrap class loader. This method will return null in such
| implementations if this class was loaded by the bootstrap class loader.

so for "some implementations" the parent may be null.

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

DO NOT REPLY [Bug 22326] - remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader

[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=22326

remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 07:17 ---
It seems, according to the javadoc to be a bug if parent == null, all
constructors (except for 1) use the setParent method always, which always sets
the parent to a non null value. 
This one constructor that doesn't actually claims in the javadoc that the parent
is set to the classloader that loaded this class, as is done in setParent if the
parent == null. So I also updated that constructor and removed all checks on
parent == null from the code (except for the one in the setParent).

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

[PMC-VOTE] Ant 1.5.4

[Stefan Bodewig]

[It is the PMC's responsibility to ensure that our releases are OK, so
only PMC member votes are binding, that shouldn't stop anybody else
from speking her/his mind.]

Conor has created the 1.5.4 distribution, it can be found at
.  In addition I've diffed
the source and binary releases of 1.5.3-1 against their corresponding
files and the results are in that directory as well (*-dist.diff).

All javadocs differ, but I've verified that the only changes are style
changes.

Please vote for/against these archives as the 1.5.4 release.  Here's
my +1 for starters.

Stefan

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

DO NOT REPLY [Bug 22326] - remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader

[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=22326

remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 07:06 ---
Created an attachment (id=7767)
improved patch with comments from conor taken into account

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

DO NOT REPLY [Bug 22338] New: - add a "minversion" and a "version" attribute to taskdef

[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=22338

add a "minversion" and a "version" attribute to taskdef

   Summary: add a "minversion" and a "version" attribute to taskdef
   Product: Ant
   Version: 1.5.3
  Platform: All
   URL: http://ant.apache.org/manual/CoreTasks/taskdef.html
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


different versions of an externally defined task may not all be suited for
building my project.

Since the external task I use also has a command-line interface, I first thought
to grab its version via "--version" exec call and then fail if I am not happy
with the output.
But as  doesn't have a  and even that would be
cumbersome if the version numbering is something like 0.8.11, I suggest the
addition of two new attributes to taskdef in order to be able to ensure inside
the build.xml that appropriate versions of an external task are taken.

Therefore, a "minversion" attribute that ensures that at least a certain version
of the external task is used appears to be useful. The ant-execution could fail
if the specified version number or higher is not met. (I assume that such an
additional attribute would require the cooperation of the author of the external
task).

Similarly, if the exact "version" is not availabe from an external task the
build would abort as well.


P.S.: One could try to do this with an  condition on the taskdef's
installation path, but even then, a) "non-cardinal" version numbering is likely
to make this cumbersome, b) some external tasks simply have a jar copied into
$ANT_HOME/lib and c) it appears to be good practice to access installations with
pathto/bin/programName/curr/bin/commandName with "curr" being a symbolic link to
a directory with the name of the version currently in production use.

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

Re: beating the dead Ant 1.6 horse

[Conor MacNeill]

On Tue, 12 Aug 2003 06:53 am, Matt Benson wrote:
> I know the quote is "there is no timeframe yet on this
> release".  But is there a ballpark?  2003?  Some
> particular half of 2004?
>

Ant 1.6 is very much alive, IMHO.

2003. :-)

IMHO, I would hope to have it soon (where soon is undefined :-)) but I want to 
resolve a few things first ...

Import is one of them - and it is important to get right. There are many 
different views on this from simple include to include with simple renaming 
to something close to an object model and even xslt style operation. I've 
been a little busy lately to push this along. I'll be back ...

The others are antlib/namespace/polymorph stuff. I'm wondering if we can get 
to the point where the ant optional tasks are packaged as antlibs and 
potentially not added to the root loader if their supporting libraries are 
not also available to the root loader. This would allow them to be taskdef'd 
in later in a build.

Conor


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

beating the dead Ant 1.6 horse

[Matt Benson]

I know the quote is "there is no timeframe yet on this
release".  But is there a ballpark?  2003?  Some
particular half of 2004?

Thanks,
Matt

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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

DO NOT REPLY [Bug 22326] - remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader

[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=22326

remove deprecated / 1.1 issues packages ant and ant.filters - ant.loader





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 01:19 ---
Just a few comments on the AntClassLoader changes:

The initializeClass method is no longer used within Ant. Nevertheless it can be
upgraded. The change you have made is, however, not correct. There is no
guarantee that Class.forName is going to find the given class. You really need
to ask the class for its loader and then use that loader to load and initialise
the class, using the three arg version of Class.forName.

Your change to findBaseClass will fail if parent is null, which it can be.

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