Re: AW: [patch] FTP.java - adding support for new features in com mons-net 1.4.0 and performance improvement

[Antoine Levy-Lambert]

Steve Cohen wrote:
[EMAIL PROTECTED] wrote:
Neeme Praks wrote:
Ok, commons-net 1.4.0 has been released now.
How can we proceed?
Since there is apparently an Ant 1.6.4 version coming out on May 
19th and since Neeme Praks has already submitted a patch to 
accomodate it, why not try to get this into that release?  As the 
author of the commons-net code that Mr. Praks is relying on, and an 
Ant committer, I would be happy to take a look at his code and 
"sponsor" it for the 1.6.4 release.

I realize that there may be other deadlines here.  What do other Ant 
committers think?

Steve Cohen


If the tests pass - why not?  :-)
Jan
I realize that the discussion has moved well beyond this point, but I 
wanted to discuss "the tests" and what is meant by that.

I think you mean, in this case,
/src/testcases/org/apache/tools/ant/taskdefs/optional/net/FTPTest.java, 
right?

I have applied the latest revised patch from Neeme Praks with a few 
modifications.  We had a couple of iterations as I explained to him 
the way I thought the task should work, and he has coded it to those 
specifications, including only support for the new commons-net 
features and not including the retry and speedup improvements from his 
original patch which need more study.

The tests mentiuned above all passed, once I changed
/src/etc/testcases/taskdefs/optional/net/ftp.xml so that the 
"ftp.password" property was redefined as my password on my system.  
The original had a password of "sunshine".  Without that change all 
the tests failed.

Of course this is OK. I wrote this test, and I entered a phony password 
in the ftp.xml file. The idea is that the tester can run the test with a 
-D"ftp.password=mypassword"


Is that the recommended practice for this test?  Or is the test 
assuming  some particular ftp server configuration that most servers 
have and my system does not?  (I do not normally turn an ftp server on 
on my system and just accepted the default).

Assuming that all the above is correct, I am satisfied that the code 
breaks nothing and am therefore committing it.

However, it does seem to me that this test case is rather incomplete, 
and could be beefed up in several ways to test these and other recent 
features of commons-net which are not being tested here.

Feel free to expand this test. I created this test to check that the 
pattern selection features of the ftp task work, when I refactored it.

I guess what I am asking is what the scope of these tests is.  Who 
runs them, when, and how?  (Do they change the password as I had to?).

I believe almost no one runs these tests, except committers who are 
changing the ftp task. To make this test work in gump, there would be 
the need to install on the gump machine a standard ftp server used to 
run the tests.

I've also committed install.html to indicate that from here forward, 
commons.net >= 1.4.0 is required.

If commons.net 1.4.0 is required, is it not a big constraing for the 
1.6.4 release ?

I am working on revised manual page for the ftp task which has 
optional new attributes but I want to tweak that a bit more.


+1
Antoine





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

DO NOT REPLY [Bug 34884] New: - broken html tag in exec doc

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34884

   Summary: broken html tag in exec doc
   Product: Ant
   Version: 1.6.3
  Platform: All
   URL: http://ant.apache.org/manual/index.html
OS/Version: All
Status: NEW
  Severity: minor
  Priority: P2
 Component: Documentation
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


broken html tag in exec doc

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

SVN repo?

[Kev Jackson]

Just a quickie, what's the URL for the SVN repo for Ant?  The website 
still lists the CVS

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

cvs commit: ant/lib libraries.properties

[scohen]

scohen  2005/05/11 21:21:01

  Modified:lib  libraries.properties
  Log:
  Adapt Ant to use the new functionalities of commons-net 1.4.0 to enable 
greater configurability of the server:
  Month names other than English, date formats other than the standard ones 
(such as all-numeric timestamps
  on unix), and different server time zones can now be supported in Ant.
  PR:30706, 33443
  Submitted by: Neeme Praks
  Reviewed by: Steve Cohen
  CVS: --
  CVS: PR:
  CVS:   If this change addresses a PR in the problem report tracking
  CVS:   database, then enter the PR number(s) here.
  CVS: Obtained from:
  CVS:   If this change has been taken from another system, such as NCSA,
  CVS:   then name the system in this line, otherwise delete it.
  CVS: Submitted by:
  CVS:   If this code has been contributed to Apache by someone else; i.e.,
  CVS:   they sent us a patch or a new module, then include their name/email
  CVS:   address here. If this is your work then delete this line.
  CVS: Reviewed by:
  CVS:   If we are doing pre-commit code reviews and someone else has
  CVS:   reviewed your changes, include their name(s) here.
  CVS:   If you have not had it reviewed then delete this line.
  
  Revision  ChangesPath
  1.3   +1 -1  ant/lib/libraries.properties
  
  Index: libraries.properties
  ===
  RCS file: /home/cvs/ant/lib/libraries.properties,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- libraries.properties  28 Jan 2005 23:18:32 -  1.2
  +++ libraries.properties  12 May 2005 04:21:01 -  1.3
  @@ -5,7 +5,7 @@
   bcel.version=5.1
   bsf.version=2.3.0
   bsh.version=2.0.b1
  -commons-net.version=1.2.2
  +commons-net.version=1.4.0
   commons-logging.version=1.0.4
   jdepend.version=2.7
   junit.version=3.8.1
  
  
  

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

Re: AW: [patch] FTP.java - adding support for new features in com mons-net 1.4.0 and performance improvement

[Steve Cohen]

[EMAIL PROTECTED] wrote:
Neeme Praks wrote:
Ok, commons-net 1.4.0 has been released now.
How can we proceed?
Since there is apparently an Ant 1.6.4 version coming out on May 19th 
and since Neeme Praks has already submitted a patch to accomodate it, 
why not try to get this into that release?  As the author of the 
commons-net code that Mr. Praks is relying on, and an Ant 
committer, I 
would be happy to take a look at his code and "sponsor" it 
for the 1.6.4 
release.

I realize that there may be other deadlines here.  What do other Ant 
committers think?

Steve Cohen

If the tests pass - why not?  :-)
Jan
I realize that the discussion has moved well beyond this point, but I 
wanted to discuss "the tests" and what is meant by that.

I think you mean, in this case,
/src/testcases/org/apache/tools/ant/taskdefs/optional/net/FTPTest.java, 
right?

I have applied the latest revised patch from Neeme Praks with a few 
modifications.  We had a couple of iterations as I explained to him the 
way I thought the task should work, and he has coded it to those 
specifications, including only support for the new commons-net features 
and not including the retry and speedup improvements from his original 
patch which need more study.

The tests mentiuned above all passed, once I changed
/src/etc/testcases/taskdefs/optional/net/ftp.xml so that the 
"ftp.password" property was redefined as my password on my system.  The 
original had a password of "sunshine".  Without that change all the 
tests failed.

Is that the recommended practice for this test?  Or is the test assuming 
 some particular ftp server configuration that most servers have and my 
system does not?  (I do not normally turn an ftp server on on my system 
and just accepted the default).

Assuming that all the above is correct, I am satisfied that the code 
breaks nothing and am therefore committing it.

However, it does seem to me that this test case is rather incomplete, 
and could be beefed up in several ways to test these and other recent 
features of commons-net which are not being tested here.

I guess what I am asking is what the scope of these tests is.  Who runs 
them, when, and how?  (Do they change the password as I had to?).

I've also committed install.html to indicate that from here forward, 
commons.net >= 1.4.0 is required.

I am working on revised manual page for the ftp task which has optional 
new attributes but I want to tweak that a bit more.





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

cvs commit: ant/docs/manual install.html

[scohen]

scohen  2005/05/11 21:04:59

  Modified:src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
   docs/manual install.html
  Log:
  Adapt Ant to use the new functionalities of commons-net 1.4.0 to enable 
greater configurability of the server:
  Month names other than English, date formats other than the standard ones 
(such as all-numeric timestamps
  on unix), and different server time zones can now be supported in Ant.
  PR:30706, 33443
  Submitted by: Neeme Praks
  Reviewed by: Steve Cohen
  CVS: --
  CVS: PR:
  CVS:   If this change addresses a PR in the problem report tracking
  CVS:   database, then enter the PR number(s) here.
  CVS: Obtained from:
  CVS:   If this change has been taken from another system, such as NCSA,
  CVS:   then name the system in this line, otherwise delete it.
  CVS: Submitted by:
  CVS:   If this code has been contributed to Apache by someone else; i.e.,
  CVS:   they sent us a patch or a new module, then include their name/email
  CVS:   address here. If this is your work then delete this line.
  CVS: Reviewed by:
  CVS:   If we are doing pre-commit code reviews and someone else has
  CVS:   reviewed your changes, include their name(s) here.
  CVS:   If you have not had it reviewed then delete this line.
  
  Revision  ChangesPath
  1.68  +118 -0
ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
  
  Index: FTP.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java,v
  retrieving revision 1.67
  retrieving revision 1.68
  diff -u -r1.67 -r1.68
  --- FTP.java  14 Mar 2005 19:24:58 -  1.67
  +++ FTP.java  12 May 2005 04:04:59 -  1.68
  @@ -17,6 +17,7 @@
   package org.apache.tools.ant.taskdefs.optional.net;
   
   import org.apache.commons.net.ftp.FTPClient;
  +import org.apache.commons.net.ftp.FTPClientConfig;
   import org.apache.commons.net.ftp.FTPFile;
   import org.apache.commons.net.ftp.FTPReply;
   import java.io.BufferedInputStream;
  @@ -109,6 +110,13 @@
   private boolean preserveLastModified = false;
   private String chmod = null;
   private String umask = null;
  +private String systemKeyConfig = null;
  +private String defaultDateFormatConfig = null;
  +private String recentDateFormatConfig = null;
  +private String serverLanguageCodeConfig = null;
  +private String serverTimeZoneConfig = null;
  +private String shortMonthNamesConfig = null;
  +private boolean isConfigurationSet = false;
   
   protected static final String[] ACTION_STRS = {
   "sending",
  @@ -1243,6 +1251,76 @@
   this.ignoreNoncriticalErrors = ignoreNoncriticalErrors;
   }
   
  +private void configurationHasBeenSet() {
  +this.isConfigurationSet = true;
  +}
  +
  +/**
  + * Method for setting FTPClientConfig remote system key.
  + * 
  + * @param systemKeyConfig
  + * @see org.apache.commons.net.ftp.FTPClientConfig
  + */
  +public void setSystemKeyConfig(String systemKey) {
  +this.systemKeyConfig = systemKey;
  +configurationHasBeenSet();
  +}
  +
  +/**
  + * Delegate method for 
FTPClientConfig.setDefaultDateFormatStr(String).
  + * 
  + * @param defaultDateFormatConfig
  + * @see org.apache.commons.net.ftp.FTPClientConfig
  + */
  +public void setDefaultDateFormatConfig(String defaultDateFormat) {
  +this.defaultDateFormatConfig = defaultDateFormat;
  +configurationHasBeenSet();
  +}
  +
  +/**
  + * Delegate method for 
FTPClientConfig.setRecentDateFormatStr(String).
  + * 
  + * @param recentDateFormatConfig
  + * @see org.apache.commons.net.ftp.FTPClientConfig
  + */
  +public void setRecentDateFormatConfig(String recentDateFormat) {
  +this.recentDateFormatConfig = recentDateFormat;
  +configurationHasBeenSet();
  +}
  +
  +/**
  + * Delegate method for 
FTPClientConfig.setServerLanguageCode(String).
  + * 
  + * @param serverLanguageCodeConfig
  + * @see org.apache.commons.net.ftp.FTPClientConfig
  + */
  +public void setServerLanguageCodeConfig(String serverLanguageCode) {
  +this.serverLanguageCodeConfig = serverLanguageCode;
  +configurationHasBeenSet();
  +}
  +
  +/**
  + * Delegate method for 
FTPClientConfig.setServerTimeZoneId(String).
  + * 
  + * @param serverTimeZoneConfig
  + * @see org.apache.commons.net.ftp.FTPClientConfig
  + */
  +public void setServerTimeZoneConfig(String serverTimeZoneId) {
  +this.serverTimeZoneConfig = serverTimeZoneId;
  +configurationHasBeenSet();
  +}
  +
  +/**
  + * Delegate method for 
FTPClientConfig.setShortMonthNames(String).
  + * 
  + * @param shortMonthNamesCon

re: jpackage and auto-download

[Steve Loughran]

Steve Cohen wrote:
On decoupling in general:
I recently spent some time looking over jpackage.org.  Have you guys 
seen this operation?  Their basic mission is to convert all of 
open-source java into RPMs.  They don't like builds that depend on 
downloading stuff from the internet.  Etc.  They hate circular 
dependencies.  They're somewhat annoyed with Ant.  It's hard to talk to 
them.  There is a real culture clash between the Java open-source world 
as it has evolved and their world.


While I stuck in a room in Edinburgh two weeks ago, at a workshop on the 
role of XML in configuration management, I actually discovered that one 
of my fellow participants was a jpackage person (Carwen). We had a good 
chat.

Yes, automated d/l irritates them, but apparently they got Maven to make 
a change which works.

The rationale for RPM-ing the java stuff is twofold. One, you can 
integrate with RPM-based linux distros. If you get Java on Suse or 
RedHat linux, you get it via jpackage. So they are one of the primary 
distribution channels for java-for-linux-users. Maybe not developers, 
but definately Java users on linux.

The other rationale comes from configuration management tools. Not SCM, 
but big system config management. Such as 1200 machines on a university, 
or 3000 nodes in a grid farm, 20,000 corporate systems. Here, having 
everything locked down is part of the design: you have total control of 
your system config, and no surprises. If you want every app to run 
againt 1.0.5 of commons logging, against version 1.0.4, you just declare 
that in your central CM system, and have it push out the dependency to 
your many thousands of nodes.

The trouble with this approach (to be precise, RPMs in general), is that 
Java dependency stuff is very much a per-instance thing, rather than 
global. That is, I may want multiple JREs on my system, some apps run 
against 1,4, others on 1.5, different third party library choices are 
made per app, not system wide.  We use this in pull-model configuration 
management -you deploy something that declares a dependency on 
commons-logging-1.0.5 and the runtime pulls it in on demand. If you want 
to switch to 1.0,6, just change the config file and redeploy.

This is actually a contrast to classic WAR/EAR deploy where you make 
half your choices at build time (the contents of WAR/lib), and half the 
choices are made for you without any control (JRE, App server 
configration). We (smartfrog team hat on) are trying to let you describe 
in a single descriptor how you want a full app server configured, and 
we'll bring it up.

Push-model (RPMs &c) and pull-model can coexist, provided the pull 
components know to look in the well-known locations for JARs first. This 
is a matter of talking between teams, then looking in the right places 
in the filesys. You can also pull from installation-specific locations. 
Indeed, the way I'd deploy our stuff  in a grid farm would be to put all 
the libs (including sun ones) into a repository on the NAS 
infrastructure, sign all the libraries (if possible), then run things 
locally. More secure, more locked down.

One area where pom-driven dependencies are already an issue for me is 
that what you run with != what you build with, and even more, !=what 
they built with. I have the right to run with Xerces 2.6.2, even if the 
app was built against xerces2.6.2, and jaxen against dom4j. The way the 
maven stuff currently works is the pom is taken as rules, not hints, and 
you get the dependencies of other tools build time, not your build or 
runtime requirements. That is wrong. Everything up to deployment time, 
maybe even including WAR/lib files are just hints, hints you can 
reconfigure (and then test against). "Can reconfigure" - I am not 
endorsing Sun's endorsed library mechanism, which is wrong because it 
overrides without asking, or JBoss's parent-first classloader which is 
equally wrong. Both are built on the assumption that the JRE and J2EE 
engine know more than the app as to what versions of things they need.

> I am not convinced that what they are doing is practical (and it's
> certainly a HUGE task they've set for themselves), but I did spend a
> little time looking at what they're doing and it did get me thinking
> about the structure of Ant.  In that world, they have a heck of a time
> building Ant from source since Ant (its optional tasks, anyway) depend
> on things like commons-net, which depend on Ant to build.  Chicken-egg
> again.
Ant is nearly at the bottom of the food chain; It and an XML parser are 
what everything else needs. This makes it more brittle than others, at 
least in bootstrap. We dont bootstrap on kaffe, for example.

It seems to me that Ant is really at least two beasts:
1. a tool for running strictly java compiles and packaging into jars, 
wars, etc.

2. other related tools that are very useful to the typical build-meister
(ftp, support for version control systems, etc.)
3. an embeddable tool for things to use

[Ant Wiki] Update of "AntTasks" by test

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ant Wiki" for change 
notification.

The following page has been changed by test:
http://wiki.apache.org/ant/AntTasks

--
  
  On Windows the Exec task does not find the executable file if its directory 
was double quoted in the PATH environment variable. (Execute failed ... error 
2: which means file not found.)
  
+ == The Unzip Task ==
+ 
+ How to unzip the content of a subdirectory of a zip file without the path to 
the subdirectory. For example, if a zip file has a directory dir1/dir2, how to 
unzip dir2 into dir3 so that dir3 contains only dir2, not dir1/dir2?
+ 
  
  CategoryCategory
  

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

DO NOT REPLY [Bug 34878] - Null Pointer Exception when include specifies a non-existent file and casesensitive is false

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34878


[EMAIL PROTECTED] changed:

   What|Removed |Added

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




--- Additional Comments From [EMAIL PROTECTED]  2005-05-12 00:35 ---
This looks like the NPE fixed a couple of days ago.  Feel free to reopen if Ant
1.6.4 does not solve this problem (it will be out by the end of the month).

Thanks,
Matt

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 34878] New: - Null Pointer Exception when include specifies a non-existent file and casesensitive is false

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34878

   Summary: Null Pointer Exception when include specifies a non-
existent file and casesensitive is false
   Product: Ant
   Version: 1.6.3
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P3
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Ran into this problem after upgrading from Ant 1.6.1 to 1.6.3. The following
task fails with a NullPointerException at line 875 in DirectoryScanner.java 
(DirectoryScanner.checkIncludePatterns()) if bar.txt does not exist and the
casesensitive attribute is false.. The task works fine (i.e., copies nothing)
when casesensitive is false if I use a wildcard somewhere in the filename.


  

  


Here's the last part of the stacktrace:
java.lang.NullPointerException
at org.apache.tools.ant.DirectoryScanner.checkIncludePatterns(DirectoryS
canner.java:875)
at org.apache.tools.ant.DirectoryScanner.scan(DirectoryScanner.java:808)

at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(Abstra
ctFileSet.java:358)
at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:404)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExe
cutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

cvs commit: ant WHATSNEW

[mbenson]

mbenson 2005/05/11 12:37:30

  Modified:.Tag: ANT_16_BRANCH WHATSNEW
  Log:
  merge
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.503.2.225 +8 -2  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.503.2.224
  retrieving revision 1.503.2.225
  diff -u -r1.503.2.224 -r1.503.2.225
  --- WHATSNEW  10 May 2005 07:37:29 -  1.503.2.224
  +++ WHATSNEW  11 May 2005 19:37:30 -  1.503.2.225
  @@ -7,14 +7,20 @@
   Fixed bugs:
   ---
   
  -* Sun javah failed with java.lang.NoClassDefFoundError. Bugzilla report
  -  34681.
  +* Sun javah failed with java.lang.NoClassDefFoundError.
  +  Bugzilla report 34681.
   
   * DirectoryScanner.slowScan() was broken. Bugzilla report 34722.
   
   * DirectoryScanner.scan() could throw a NullPointerException on
 case-insensitive filesystems (read Windows or MacOS X).
   
  +* Get w/authentication failed with ArrayOutOfBoundsExceptions.
  +  Bugzilla report 34734.
  +
  +* Granularity attribute for  task was undocumented.
  +  Bugzilla report 34871.
  +
   Other changes:
   --
   
  
  
  

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

cvs commit: ant WHATSNEW

[mbenson]

mbenson 2005/05/11 12:37:14

  Modified:.WHATSNEW
  Log:
  1.6.4 changes
  
  Revision  ChangesPath
  1.819 +8 -2  ant/WHATSNEW
  
  Index: WHATSNEW
  ===
  RCS file: /home/cvs/ant/WHATSNEW,v
  retrieving revision 1.818
  retrieving revision 1.819
  diff -u -r1.818 -r1.819
  --- WHATSNEW  10 May 2005 07:37:03 -  1.818
  +++ WHATSNEW  11 May 2005 19:37:13 -  1.819
  @@ -199,14 +199,20 @@
   Fixed bugs:
   ---
   
  -* Sun javah failed with java.lang.NoClassDefFoundError. Bugzilla report
  -  34681.
  +* Sun javah failed with java.lang.NoClassDefFoundError.
  +  Bugzilla report 34681.
   
   * DirectoryScanner.slowScan() was broken. Bugzilla report 34722.
   
   * DirectoryScanner.scan() could throw a NullPointerException on
 case-insensitive filesystems (read Windows or MacOS X).
   
  +* Get w/authentication failed with ArrayOutOfBoundsExceptions.
  +  Bugzilla report 34734.
  +
  +* Granularity attribute for  task was undocumented.
  +  Bugzilla report 34871.
  +
   Other changes:
   --
   
  
  
  

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

DO NOT REPLY [Bug 34722] - Cenqua clover failure's with ant 1.6.3

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34722


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|1.7 |1.6.4




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 34681] - javah task fails with java.lang.NoClassDefFoundError

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34681


[EMAIL PROTECTED] changed:

   What|Removed |Added

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




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 34872] - Using get task with authentication causes ArrayIndexOutOfBoundsException

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34872


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2005-05-11 21:07 ---


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

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 34734] - Get.Base64Converter broken

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34734


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-05-11 21:07 ---
*** Bug 34872 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 34871] - sync doesn't document supported attribute "granularity"

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34871


[EMAIL PROTECTED] changed:

   What|Removed |Added

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




--- Additional Comments From [EMAIL PROTECTED]  2005-05-11 21:05 ---
fixed for 1.6.4.  Thanks!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[mbenson]

mbenson 2005/05/11 12:04:18

  Modified:docs/manual/CoreTasks Tag: ANT_16_BRANCH sync.html
  Log:
  Document granularity attribute in 1.6 branch
  PR: 34871
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.3.2.4   +10 -0 ant/docs/manual/CoreTasks/sync.html
  
  Index: sync.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTasks/sync.html,v
  retrieving revision 1.3.2.3
  retrieving revision 1.3.2.4
  diff -u -r1.3.2.3 -r1.3.2.4
  --- sync.html 15 Mar 2005 15:10:28 -  1.3.2.3
  +++ sync.html 11 May 2005 19:04:18 -  1.3.2.4
  @@ -57,6 +57,16 @@
Log the files that are being copied.
No; defaults to false.
 
  +  
  +granularity
  +The number of milliseconds leeway to give before
  +deciding a file is out of date. This is needed because not every
  +file system supports tracking the last modified time to the
  +millisecond level. Default is 0 milliseconds, or 2 seconds on DOS
  +systems.  This can also be useful if source and target files live
  +on separate machines with clocks being out of sync.  since Ant
  +1.6.2.
  +  
   
   
   Parameters specified as nested elements
  
  
  

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

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

[mbenson]

mbenson 2005/05/11 12:03:45

  Modified:docs/manual/CoreTasks sync.html
  Log:
  Correct granularity attribute from 1.6 to 1.6.2
  
  Revision  ChangesPath
  1.10  +1 -1  ant/docs/manual/CoreTasks/sync.html
  
  Index: sync.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTasks/sync.html,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- sync.html 29 Apr 2005 18:58:13 -  1.9
  +++ sync.html 11 May 2005 19:03:45 -  1.10
  @@ -65,7 +65,7 @@
   millisecond level. Default is 0 milliseconds, or 2 seconds on DOS
   systems.  This can also be useful if source and target files live
   on separate machines with clocks being out of sync.  since Ant
  -1.6.
  +1.6.2.
No.
 
   
  
  
  

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

DO NOT REPLY [Bug 34872] New: - Using get task with authentication causes ArrayIndexOutOfBoundsException

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34872

   Summary: Using get task with authentication causes
ArrayIndexOutOfBoundsException
   Product: Ant
   Version: 1.6.3
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: normal
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Using the get task with http authentication causes 
ArrayIndexOutOfBoundsException.

Running the following build file results in the error :
java.lang.ArrayIndexOutOfBoundsException: 24





http://eek:8096/manager/html"; />








-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 34871] New: - sync doesn't document supported attribute "granularity"

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34871

   Summary: sync doesn't document supported attribute "granularity"
   Product: Ant
   Version: 1.6.3
  Platform: All
   URL: http://ant.apache.org/manual/CoreTasks/sync.html
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Documentation
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


It looks like "granularity" was added to the copy task in ant 1.6.2, which
carries through to the sync task - but it was never documented in the sync task.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [VOTE] Ant 1.6.4 release

[Bruce Atherton]

Antoine Levy-Lambert wrote:
Do we want to release ant 1.6.4 on Thursday, May 19th
(this would at least suit Eclipse)
+1.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Jose Alberto Fernandez]

If we want to entice people to write antlibs, every little helps.

We could have said the same thing about metainf.mf but we provided 
something in JAR to simplify that. Same argument here.

Jose Alberto

> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED] 
> Sent: 11 May 2005 16:37
> To: 'Ant Developers List'
> Subject: RE: [patch] FTP.java - adding support for new 
> features in commons-net 1.4.0 and performance improvement
> 
> 
> I don't know if this is just me,
> but I don't see the point of .
> 
> Writing the antlib.xml resource manually
> and including it in the jar is trivial.
> 
> We don't need special code for it. What
> we may need is simply a little tutorial
> about writing a basic AntLib, that's all,
> and even that would mostly repeat existing
> sections of the manual. --DD
> 
> > > --- Jose Alberto Fernandez <[EMAIL PROTECTED]>
> > > >  
> > > >
> > > >
> > > >  
> > > >  ...
> > > >
> > > >  
> > > > What do you guys think.
> 
> 
> -
> 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: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Dominique Devienne]

I don't know if this is just me,
but I don't see the point of .

Writing the antlib.xml resource manually
and including it in the jar is trivial.

We don't need special code for it. What
we may need is simply a little tutorial
about writing a basic AntLib, that's all,
and even that would mostly repeat existing
sections of the manual. --DD

> > --- Jose Alberto Fernandez <[EMAIL PROTECTED]>
> > >  
> > >
> > >
> > >  
> > >  ...
> > >
> > >  
> > > What do you guys think.


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

RE: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Jose Alberto Fernandez]

Fine with me, this was just some schetched of thoughts.

It seem to get simpler and simpler to do. We should
also support passing the antlib.xml file location like we do for
manifest.

Jose Alberto

> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED] 
> Sent: 11 May 2005 16:07
> To: Ant Developers List
> Subject: RE: [patch] FTP.java - adding support for new 
> features in commons-net 1.4.0 and performance improvement
> 
> 
> --- Jose Alberto Fernandez <[EMAIL PROTECTED]>
> wrote:
> 
> >  
> >
> >
> >  
> >  ...
> >
> >  
> > 
> > This creates a JAR with the antlib.xml in
> > foo/bar/antlib.xml
> > which contains the antlib content as specified
> > there.
> > 
> > You do not need to have many files is just one
> > target you maintain and
> > everything should
> > be build.
> > 
> > What do you guys think.
> 
> I don't care for the  element name. Couldn't
>  extend jar, the  element being the
> only addition?  Then, 's content would be
> implemented using XMLFragment?
> 
> -Matt
> > 
> > Jose Alberto
> > 
> >
> -
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > 
> > 
> 
> 
>   
> Discover Yahoo! 
> Find restaurants, movies, travel and more fun for the 
> weekend. Check it out! 
> http://discover.yahoo.com/weekend.html 
> 
> 
> -
> 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: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Matt Benson]

--- Steve Loughran <[EMAIL PROTECTED]> wrote:
> Neeme Praks wrote:
> > Very legitimate concern.
> > However, this is a trivial change.
> 
> so are all changes that end up breaking things.
> 
> Ant1.6.4 is really Ant1.6.3a; a late fix for stuff
> that wasnt caught in 
>   the beta test. I am really, really, reluctant to
> do anything that 
> could break stuff. If ant1,6.4 ends up broken, we
> have to release an 
> Ant1.6.5 two weeks later, there is more pressure for
> last minute 
> changes, we introduce new bugs, never stabilise, get
> a bad reputation 
> for release management, etc, etc.

In this case, I tend to agree.  I can be reckless at
times, but considering that 1.6.4 is already an
attempt to get the egg off our collective face from a
couple of (IMO) showstopping bugs in 1.6.3 perhaps we
should leave well enough alone.  I agree these changes
look innocuous but I worry about the timing.

-Matt


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

RE: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Matt Benson]

--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:

>  
>
>
>  
>  ...
>
>  
> 
> This creates a JAR with the antlib.xml in
> foo/bar/antlib.xml
> which contains the antlib content as specified
> there.
> 
> You do not need to have many files is just one
> target you maintain and
> everything should
> be build.
> 
> What do you guys think.

I don't care for the  element name. Couldn't
 extend jar, the  element being the
only addition?  Then, 's content would be
implemented using XMLFragment?

-Matt
> 
> Jose Alberto
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 


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

DO NOT REPLY [Bug 34867] New: - Deploying an ear to weblogic seems to break junitreport only in ant 1.6.3

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34867

   Summary: Deploying an ear to weblogic seems to break junitreport
only in ant 1.6.3
   Product: Ant
   Version: 1.6.3
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: blocker
  Priority: P3
 Component: Optional Tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


We're deploying an ear to weblogic 8.1 (have tried both SP3 and SP4).  We run
some functional tests against that deployment which are driven by junit.  The
results of these tests are generated using junit report.

We can do this using ant 1.6.2 but upgrading to ant 1.6.3 gives us the following
error:

/home/jammin/src/aol/ordermanagement/build2/functional.build.xml:58: Could not
find a valid processor version implementation from
weblogic.xml.jaxp.RegistrySAXTransformerFactory
at
org.apache.tools.ant.taskdefs.optional.junit.Xalan2Executor.getProcVersion(Xalan2Executor.java:67)
at
org.apache.tools.ant.taskdefs.optional.junit.XalanExecutor.newInstance(XalanExecutor.java:88)
at
org.apache.tools.ant.taskdefs.optional.junit.AggregateTransformer.transform(AggregateTransformer.java:144)
at
org.apache.tools.ant.taskdefs.optional.junit.XMLResultAggregator.execute(XMLResultAggregator.java:139)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)

We commented out the WLDeploy part of the deployment task and then this problem
goes away with 1.6.3.

You'll notice that it's suddenly trying to use a weblogic SAX factory. So we
think that something's hanging over from the wldeply task.

That it works in ant 1.6.2 makes us feel this is an ant problem.

No idea whether it will help but we've pasted a few targets after this so that
you can see what we're doing...

Thanks

--




















-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Stefan Bodewig]

On Wed, 11 May 2005, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:

> Think of something like:
> 
>  
>
>
>  
>  ...
>
>  
> 
> This creates a JAR with the antlib.xml in foo/bar/antlib.xml
> which contains the antlib content as specified there.

Works for me.  antliburi instead of anturl, though.

Stefan

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

RE: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Jose Alberto Fernandez]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> 
> On Wed, 11 May 2005, Jose Alberto Fernandez 
> <[EMAIL PROTECTED]> wrote:
> 
> > Maybe people would be less scare about it if we provide a 
> task that is 
> > able to produce a ready to go plugin JAR containing all the pieces 
> > necessary for your antlib to work using an 
> "antlib:" URL. Do 
> > we have such a thing already, if nor it should be quite easy to do.
> 
> I'm not sure what you mean.  A task that creates antlib.xml 
> and puts it into the proper place inside the jar?  I'm having 
> a hard time to come up with a syntax for the task (you still 
> have to tell it which taskname maps to which task) that 
> doesn't look like antlib.xml.

Think of something like:

 
   
   
 
 ...
   
 

This creates a JAR with the antlib.xml in foo/bar/antlib.xml
which contains the antlib content as specified there.

You do not need to have many files is just one target you maintain and
everything should
be build.

What do you guys think.

Jose Alberto

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

RE: Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Jose Alberto Fernandez]

> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Nicola Ken Barozzi
> 
> Stefan Bodewig wrote:
> > On Wed, 11 May 2005, Jose Alberto Fernandez 
> > <[EMAIL PROTECTED]> wrote:
> > 
> >>I do not think we can continue maintaining tasks for every 
> project in 
> >>the world just because they do not want to depend on ANT.
> 
> Likewise, you cannot ask for every project to keep an Ant task just 
> because Ant does not want to depend on them ;-)
> 

We ask exactly that from other projects. We would like the SVN people to
maintain
their SVN tasks. And the ClearCase people to maintain theirs because
then you can upgrade and deliver them in sync with their new versions.

On the other hand we "promise" not to break the API they use so that
they
do not need to worry about forward compatibility with ANT (within
reason).

> > Calm down.  We are talking about an existing Ant task that 
> gets used a 
> > lot.  And so far nobody has asked the commons-net people whether 
> > they'd want to maintain it.
> > 
> > If you ask me, Ant is the owner of the  task and commons-net 
> > "only" a support library.  The javacc, antlr or weblogic tasks (for
> > example) are completely different beasts IMHO.
> 
> Yes.
> 
> Ant tasks - like any piece of code really - should simply 
> reside where 
> people care about them, fix bugs and enhance them. IMHO this usually 
> happens in Ant if the task is generic enough to be used by most 
> committers, and ftp seems to be the case.

Ok, but with that view. Any features of common-net will not be available
until
1.7 is out some six month from now. Or people will have to use nightly
builds.
If you want the new features to be made available, then either
common-net provides
the task or has to coordinate the release cycles.

Not sure who is the winner on this.

I may not have made myself clear on one issue: When I talk about
common-net's 
task, I am not talking about the current task supported within ANT
(which will have to stay
there and get eventually deprecated). I am talking of a "new" 
task, lets call it
 that provides all the features and benefits of using the
common-net libraries.
It will be common-net's new replacement task and it will be under
common-net control. 

That is the whole point of the antlibs.

Jose Alberto

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

AW: [patch] FTP.java - adding support for new features in com mons-net 1.4.0 and performance improvement

[Jan . Materne]

> But everybody will have a different opinion what makes up this core.
> ?  You bet.  ?  For those RPM builders probably yes.
> ?  _I_ don't think so.


Why  - works only on *nix ;-)

Jan

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Stefan Bodewig]

On Wed, 11 May 2005, Steve Cohen <[EMAIL PROTECTED]> wrote:

> I recently spent some time looking over jpackage.org.  Have you guys
> seen this operation?

More than that.  We modified the Ant wrapper script to suit their
needs, so that they could stop distributing their version, for
example.  We've had some fruitful collaboration in the past.

I used to be subscribed to their dev list but had to cut down on
activities, so I dropped out of it.

> They don't like builds that depend on downloading stuff from the
> internet. Etc.  They hate circular dependencies.

Like me ;-)

> They're somewhat annoyed with Ant.  It's hard to talk to them.

I've not seen that, if so, something must have changed over the past
six months.  Anything special?

> In that world, they have a heck of a time building Ant from source
> since Ant (its optional tasks, anyway) depend on things like
> commons-net, which depend on Ant to build.  Chicken-egg again.

Not really.  They have separate RPMs for Ant and for ant with optional
tasks.  You only need the Ant RPM to build commons-net, and you need
Ant and commons-net to build the ant-apache-commons-net RPM.

> It seems to me that Ant is really at least two beasts:
> 
> 1. a tool for running strictly java compiles and packaging into
> jars, wars, etc.

But everybody will have a different opinion what makes up this core.
?  You bet.  ?  For those RPM builders probably yes.
?  _I_ don't think so.

> (this may or may not equate exactly to Ant's core vs. optional tasks
> - e.g. why is cvs core, but other vcs optional?)

historical reasons.   was there before any optional task came
along.  I guess 

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Stefan Bodewig]

On Wed, 11 May 2005, Steve Cohen <[EMAIL PROTECTED]> wrote:

> So commit to head as we see fit

yes.

> and maybe it will be moved to the branch?

call for a vote, and do so in time, usually votes are supposed to run
for a week.  We had a vote on 1.6.4 for the current feature set, we
would have to vote on the release again if the code changed.

Stefan

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

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Steve Cohen]

Stefan Bodewig wrote:
On Wed, 11 May 2005, Steve Cohen <[EMAIL PROTECTED]> wrote:

Other parts of Mr. Praks' patch are less simple (retry handler,
etc.) and I've asked him to remove those for now.  These definitely
belong in CVS_HEAD after the release.

The release comes from a branch, so you can go ahead and commit to
HEAD whenever you see fit.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

So commit to head as we see fit and maybe it will be moved to the branch?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Ant Wiki] Update of "AntTasks" by HontvariJozsef

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ant Wiki" for change 
notification.

The following page has been changed by HontvariJozsef:
http://wiki.apache.org/ant/AntTasks

The comment on the change is:
exec task and double quoted path elements

--
  
  }}}
  
+ == The Exec Task ==
+ 
+ On Windows the Exec task does not find the executable file if its directory 
was double quoted in the PATH environment variable. (Execute failed ... error 
2: which means file not found.)
+ 
  
  CategoryCategory
  

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

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Stefan Bodewig]

On Wed, 11 May 2005, Steve Cohen <[EMAIL PROTECTED]> wrote:

> Other parts of Mr. Praks' patch are less simple (retry handler,
> etc.) and I've asked him to remove those for now.  These definitely
> belong in CVS_HEAD after the release.

The release comes from a branch, so you can go ahead and commit to
HEAD whenever you see fit.

Stefan

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

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Nicola Ken Barozzi]

Stefan Bodewig wrote:
On Wed, 11 May 2005, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
I do not think we can continue maintaining tasks for every project
in the world just because they do not want to depend on ANT.
Likewise, you cannot ask for every project to keep an Ant task just 
because Ant does not want to depend on them ;-)

Calm down.  We are talking about an existing Ant task that gets used a
lot.  And so far nobody has asked the commons-net people whether
they'd want to maintain it.
If you ask me, Ant is the owner of the  task and commons-net
"only" a support library.  The javacc, antlr or weblogic tasks (for
example) are completely different beasts IMHO.
Yes.
Ant tasks - like any piece of code really - should simply reside where 
people care about them, fix bugs and enhance them. IMHO this usually 
happens in Ant if the task is generic enough to be used by most 
committers, and ftp seems to be the case.

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

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Steve Cohen]

Stefan Bodewig wrote:
On Wed, 11 May 2005, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:

I do not think we can continue maintaining tasks for every project
in the world just because they do not want to depend on ANT.

Calm down.  We are talking about an existing Ant task that gets used a
lot.  And so far nobody has asked the commons-net people whether
they'd want to maintain it.
If you ask me, Ant is the owner of the  task and commons-net
"only" a support library.  The javacc, antlr or weblogic tasks (for
example) are completely different beasts IMHO.
Maybe Sun should ship the Javac compiler adapter?  Just kidding.

Maybe people would be less scare about it if we provide a task that
is able to produce a ready to go plugin JAR containing all the
pieces necessary for your antlib to work using an "antlib:"
URL. Do we have such a thing already, if nor it should be quite easy
to do.

I'm not sure what you mean.  A task that creates antlib.xml and puts
it into the proper place inside the jar?  I'm having a hard time to
come up with a syntax for the task (you still have to tell it which
taskname maps to which task) that doesn't look like antlib.xml.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

On decoupling in general:
I recently spent some time looking over jpackage.org.  Have you guys 
seen this operation?  Their basic mission is to convert all of 
open-source java into RPMs.  They don't like builds that depend on 
downloading stuff from the internet.  Etc.  They hate circular 
dependencies.  They're somewhat annoyed with Ant.  It's hard to talk to 
them.  There is a real culture clash between the Java open-source world 
as it has evolved and their world.

I am not convinced that what they are doing is practical (and it's 
certainly a HUGE task they've set for themselves), but I did spend a 
little time looking at what they're doing and it did get me thinking 
about the structure of Ant.  In that world, they have a heck of a time 
building Ant from source since Ant (its optional tasks, anyway) depend 
on things like commons-net, which depend on Ant to build.  Chicken-egg 
again.

It seems to me that Ant is really at least two beasts:
1. a tool for running strictly java compiles and packaging into jars, 
wars, etc.

2. other related tools that are very useful to the typical build-meister
(ftp, support for version control systems, etc.)
I think Ant does somewhat recognize this distinction in the business of 
bootstrap vs. build when building ant.  The bootstrap stuff is core, the 
other stuff is somewhat peripheral.  (this may or may not equate exactly 
to Ant's core vs. optional tasks - e.g. why is cvs core, but other vcs 
optional?)

I don't know what any of this means, going forward, probably nothing, 
but it's food for thought.

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

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Steve Cohen]

Neeme Praks wrote:
Steve Loughran wrote:
I worry about releasing any change to code without giving it time to 
stabilise and beta test. Last minute "this won't break anything" 
patches always break something. Always. At least in my experience.

If commons1.4.0 is incompatible with shipping  then yes, we have 
no choice but to upgrade. But if it is a feature enhancement, then it 
needs
to go into CVS_HEAD

Very legitimate concern.
However, this is a trivial change.
commons-net 1.4.0 added a configuration javabean for FTP client.
It is a simple value-object that has some setters and then it can be 
used to configure a FTP client instance.

All the added code does is expose this javabean on the FTP task through 
delegating setters.

Let me illustrate with some code:
public class FTP extends Task {
[...]
private FTPClientConfig configuration = null;
/**
 * Gets a FTPClientConfig. If the configuration object has not been
 * created yet, it is created also.
 */
private FTPClientConfig getConfiguration() {
if (this.configuration == null) {
this.configuration = new FTPClientConfig();
}
return this.configuration;
}
/**
 * Delegate method for 
FTPClientConfig.setDefaultDateFormatStr(String).
 * @param defaultDateFormatStr
 * @see #getConfiguration()
 * @see FTPClientConfig
 */
public void setDefaultDateFormat(String defaultDateFormatStr) {
getConfiguration()
.setDefaultDateFormatStr(defaultDateFormatStr);
}

[...there are 5 more delegating setters like this, but I'm skipping them 
here for clarity...]

public void execute() throws BuildException {
[...]
ftp = new FTPClient();
if (this.configuration != null) {
ftp.configure(this.configuration);
}
ftp.connect(server, port);
[...]
}
[...]
}
Simple enough, no?
Assuming that commons-net code is bug-free, this code cannot possibly 
break anything. And it is backwards compatible, if there is no 
configuration set, no configuration is used.

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

Well, you're both right.  The new commons-net code is not incompatible 
with Ant.  This is just a new feature of commons-net.

However, it's an extremely simple feature, just passing bean attributes 
around.  I am quite confident that we can add just the support for the 
new commons-net feature and have all the tests pass.

Other parts of Mr. Praks' patch are less simple (retry handler, etc.) 
and I've asked him to remove those for now.  These definitely belong in 
CVS_HEAD after the release.

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

DO NOT REPLY [Bug 34860] New: - Startupscript must not add empty $CLASSPATH to evaluated command

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=34860

   Summary: Startupscript must not add empty $CLASSPATH to evaluated
command
   Product: Ant
   Version: 1.6.3
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P3
 Component: Wrapper scripts
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi ! 
 
I hope this is not a dublicate, but I didn't find one. 
 
When there is no environment variable CLASSPATH then the invoked command must 
not contain -cp "$CLASSPATH" (which is expanded to -cp ""). 
 
The following change it a trivial fix (could probably be improved): 
 
if [ -n "$CLASSPATH" ] ; then 
  ant_exec_command="exec \"$JAVACMD\" $ANT_OPTS -classpath \"$LOCALCLASSPATH\" 
-Dant.home=\"$ANT_HOME\" -Dant.library.dir=\"$ANT_LIB\" $ant_sys_opts 
org.apache.tools.ant.launch.Launcher $ANT_ARGS -cp \"$CLASSPATH\" 
$ant_exec_args" 
else 
  ant_exec_command="exec \"$JAVACMD\" $ANT_OPTS -classpath \"$LOCALCLASSPATH\" 
-Dant.home=\"$ANT_HOME\" -Dant.library.dir=\"$ANT_LIB\" $ant_sys_opts 
org.apache.tools.ant.launch.Launcher $ANT_ARGS $ant_exec_args" 
fi 
 
Best, 
Michael

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Steve Cohen]

Stefan Bodewig wrote:
On Tue, 10 May 2005, Steve Cohen <[EMAIL PROTECTED]> wrote:

As the author of the commons-net code that Mr. Praks is relying on,
and an Ant committer, I would be happy to take a look at his code
and "sponsor" it for the 1.6.4 release.

There is no need to sponsor, you are a committer.  We usually work in
commit-then-review mode, at least for CVS HEAD, so go ahead and commit
it to HEAD.
After you've done that, you could call for a vote for merging the
change over to the 1.6 branch.  Personally I don't think a vote would
be necessary, though.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

I may be a committer but Mr Praks is not.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Steve Loughran]

Neeme Praks wrote:
Steve Loughran wrote:
I worry about releasing any change to code without giving it time to 
stabilise and beta test. Last minute "this won't break anything" 
patches always break something. Always. At least in my experience.

If commons1.4.0 is incompatible with shipping  then yes, we have 
no choice but to upgrade. But if it is a feature enhancement, then it 
needs
to go into CVS_HEAD

Very legitimate concern.
However, this is a trivial change.
so are all changes that end up breaking things.
Ant1.6.4 is really Ant1.6.3a; a late fix for stuff that wasnt caught in 
 the beta test. I am really, really, reluctant to do anything that 
could break stuff. If ant1,6.4 ends up broken, we have to release an 
Ant1.6.5 two weeks later, there is more pressure for last minute 
changes, we introduce new bugs, never stabilise, get a bad reputation 
for release management, etc, etc.

If you look at the commit log, you can see that I tend to avoid 
committing my own changes to the 1.6.x branch either, because I like to 
work with things myself for a bit. Once something is in the public API 
of Ant, we cant remove it. So we need to get it right, And that means 
being strict about last minue commitments. Indeed, there are three 
things I committed that I think might want to go into the 1.6 branch, 
but but I'm not going to do it

 -java1.5 class passthrough changes to JavaEnvUtils
 -java1.5 settings of default rmi compiler options
 -that switch to WeakHashMap.
Why am I not committing them? Because nobody is complaining about them, 
even though they are clearly bugs with trivial fixes.

-Steve
(NB, I'm not the release manager, but note that I'm fairly relaxed about 
changes compared to someone I've worked with. Ruthlessness is a 
wonderful thing when it is time to get something out the door)

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

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Neeme Praks]

Steve Loughran wrote:
I worry about releasing any change to code without giving it time to 
stabilise and beta test. Last minute "this won't break anything" patches 
always break something. Always. At least in my experience.

If commons1.4.0 is incompatible with shipping  then yes, we have no 
choice but to upgrade. But if it is a feature enhancement, then it needs
to go into CVS_HEAD
Very legitimate concern.
However, this is a trivial change.
commons-net 1.4.0 added a configuration javabean for FTP client.
It is a simple value-object that has some setters and then it can be 
used to configure a FTP client instance.

All the added code does is expose this javabean on the FTP task through 
delegating setters.

Let me illustrate with some code:
public class FTP extends Task {
[...]
private FTPClientConfig configuration = null;
/**
 * Gets a FTPClientConfig. If the configuration object has not been
 * created yet, it is created also.
 */
private FTPClientConfig getConfiguration() {
if (this.configuration == null) {
this.configuration = new FTPClientConfig();
}
return this.configuration;
}
/**
 * Delegate method for 
FTPClientConfig.setDefaultDateFormatStr(String).
 * @param defaultDateFormatStr
 * @see #getConfiguration()
 * @see FTPClientConfig
 */
public void setDefaultDateFormat(String defaultDateFormatStr) {
getConfiguration()
.setDefaultDateFormatStr(defaultDateFormatStr);
}

[...there are 5 more delegating setters like this, but I'm skipping them 
here for clarity...]

public void execute() throws BuildException {
[...]
ftp = new FTPClient();
if (this.configuration != null) {
ftp.configure(this.configuration);
}
ftp.connect(server, port);
[...]
}
[...]
}
Simple enough, no?
Assuming that commons-net code is bug-free, this code cannot possibly 
break anything. And it is backwards compatible, if there is no 
configuration set, no configuration is used.

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

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Stefan Bodewig]

On Wed, 11 May 2005, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:

> I do not think we can continue maintaining tasks for every project
> in the world just because they do not want to depend on ANT.

Calm down.  We are talking about an existing Ant task that gets used a
lot.  And so far nobody has asked the commons-net people whether
they'd want to maintain it.

If you ask me, Ant is the owner of the  task and commons-net
"only" a support library.  The javacc, antlr or weblogic tasks (for
example) are completely different beasts IMHO.

Maybe Sun should ship the Javac compiler adapter?  Just kidding.

> Maybe people would be less scare about it if we provide a task that
> is able to produce a ready to go plugin JAR containing all the
> pieces necessary for your antlib to work using an "antlib:"
> URL. Do we have such a thing already, if nor it should be quite easy
> to do.

I'm not sure what you mean.  A task that creates antlib.xml and puts
it into the proper place inside the jar?  I'm having a hard time to
come up with a syntax for the task (you still have to tell it which
taskname maps to which task) that doesn't look like antlib.xml.

Stefan

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

RE: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Jose Alberto Fernandez]

> From: Steve Loughran [mailto:[EMAIL PROTECTED] 
> 
> Steve Cohen wrote:
> 
> > Since there is apparently an Ant 1.6.4 version coming out 
> on May 19th
> > and since Neeme Praks has already submitted a patch to 
> accomodate it, 
> > why not try to get this into that release?  As the author of the 
> > commons-net code that Mr. Praks is relying on, and an Ant 
> committer, I 
> > would be happy to take a look at his code and "sponsor" it 
> for the 1.6.4 
> > release.
> > 
> > I realize that there may be other deadlines here.  What do other Ant
> > committers think?
> 
> I worry about releasing any change to code without giving it time to 
> stabilise and beta test. Last minute "this won't break 
> anything" patches 
> always break something. Always. At least in my experience.
> 
> If commons1.4.0 is incompatible with shipping  then yes, 
> we have no 
> choice but to upgrade. But if it is a feature enhancement, 
> then it needs to go into CVS_HEAD

I agree.

We really need to come up with a decoupling strategy for ANT optional
tasks or its future replacements. If the owners of the code on which
those
tasks depend, refuse to deliver them as part of their project because it
adds
a dependency to ANT for their projects, then we have a chicken and egg
problem here.

I do not think we can continue maintaining tasks for every project in
the world
just because they do not want to depend on ANT. There has to be a middle
ground
that everyone is happy about.

I still think that common-net should be the owner of the future 
replacement task
and that they may release it on a separate JAR if they do not want to
add dependencies
to their main deliverable. Remember, they do not need to bundle ANT,
just the 
"plugin" aka antlib for it.

Maybe people would be less scare about it if we provide a task that is
able to produce
a ready to go plugin JAR containing all the pieces necessary for your
antlib to work
using an "antlib:" URL. Do we have such a thing already, if nor
it should be
quite easy to do.

Jose Alberto

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

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Steve Loughran]

Steve Cohen wrote:
Since there is apparently an Ant 1.6.4 version coming out on May 19th 
and since Neeme Praks has already submitted a patch to accomodate it, 
why not try to get this into that release?  As the author of the 
commons-net code that Mr. Praks is relying on, and an Ant committer, I 
would be happy to take a look at his code and "sponsor" it for the 1.6.4 
release.

I realize that there may be other deadlines here.  What do other Ant 
committers think?
I worry about releasing any change to code without giving it time to 
stabilise and beta test. Last minute "this won't break anything" patches 
always break something. Always. At least in my experience.

If commons1.4.0 is incompatible with shipping  then yes, we have no 
choice but to upgrade. But if it is a feature enhancement, then it needs
to go into CVS_HEAD

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

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[sissonj]

While you are at it, could you please also incorporate my simple patch to 
the FTP task? 

http://issues.apache.org/bugzilla/show_bug.cgi?id=34853

It would be nice if it also could make it into the 1.6.4 release.

Thanks,

John

This e-mail message and any attachments may contain confidential, 
proprietary or non-public information.  This information is intended 
solely for the designated recipient(s).  If an addressing or transmission 
error has misdirected this e-mail, please notify the sender immediately 
and destroy this e-mail.  Any review, dissemination, use or reliance upon 
this information by unintended recipients is prohibited.  Any opinions 
expressed in this e-mail are those of the author personally.

Stefan Bodewig <[EMAIL PROTECTED]> wrote on 11/05/2005 05:45:23 PM:

> On Tue, 10 May 2005, Steve Cohen <[EMAIL PROTECTED]> wrote:
> 
> > As the author of the commons-net code that Mr. Praks is relying on,
> > and an Ant committer, I would be happy to take a look at his code
> > and "sponsor" it for the 1.6.4 release.
> 
> There is no need to sponsor, you are a committer.  We usually work in
> commit-then-review mode, at least for CVS HEAD, so go ahead and commit
> it to HEAD.
> 
> After you've done that, you could call for a vote for merging the
> change over to the 1.6 branch.  Personally I don't think a vote would
> be necessary, though.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement

[Stefan Bodewig]

On Tue, 10 May 2005, Steve Cohen <[EMAIL PROTECTED]> wrote:

> As the author of the commons-net code that Mr. Praks is relying on,
> and an Ant committer, I would be happy to take a look at his code
> and "sponsor" it for the 1.6.4 release.

There is no need to sponsor, you are a committer.  We usually work in
commit-then-review mode, at least for CVS HEAD, so go ahead and commit
it to HEAD.

After you've done that, you could call for a vote for merging the
change over to the 1.6 branch.  Personally I don't think a vote would
be necessary, though.

Stefan

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