RE: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On 18 Feb 2005, [EMAIL PROTECTED] wrote:
I'm tempted to retrofit Task.bindToOwner back to the 1.6.x
codebase, for the benefit of third party tasks; same for the extra
constructors for exec and java. Thoughts?
If you only port bindToOwner and the new constructors, but not all the
points of invocation then you can't do much harm.
FWIW, just one nit about bindToOwner(), but a bit late since I saw the
commit like everyone else.
I would have reversed Steve's bindee.bindToOwner(owner) logic into
owner.configureHelper(helper), which then allows configureHelper to be
protected. It's basically the same, but avoids the public method which
then anyone can call on any task, and it's closer to the code I posted a
few times, and that I'll post again below.
Note also that my code init()s the helper task too, and that I was
always calling configureTask() in the parent task own init(). --DD
/**
* Configures a helper task to be used within another task.
*
* @param parent the parent (custom) task using the helper task.
* @param helper the helper task to configure for use.
* @return the configured helper task for call chaining.
*/
public static Task configureTask(Task parent, Task helper) {
// Make helper share attributes of the parent
helper.setProject(parent.getProject());
helper.setTaskName(parent.getTaskName());
helper.setOwningTarget(parent.getOwningTarget());
// Copy location for better troubleshooting of subtask
Location location = parent.getLocation();
if (location == null) {
location = Location.UNKNOWN_LOCATION;
}
helper.setLocation(location);
// Initialize (and return) the helper
helper.init();
return helper;
}
-
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
Dominique Devienne wrote:
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On 18 Feb 2005, [EMAIL PROTECTED] wrote:
I'm tempted to retrofit Task.bindToOwner back to the 1.6.x
codebase, for the benefit of third party tasks; same for the extra
constructors for exec and java. Thoughts?
If you only port bindToOwner and the new constructors, but not all the
points of invocation then you can't do much harm.
FWIW, just one nit about bindToOwner(), but a bit late since I saw the
commit like everyone else.
sorry, I did it while I was offline for a week.
I would have reversed Steve's bindee.bindToOwner(owner) logic into
owner.configureHelper(helper), which then allows configureHelper to be
protected. It's basically the same, but avoids the public method which
then anyone can call on any task, and it's closer to the code I posted a
few times, and that I'll post again below.
I hadnt see that; like your location fixup though.
the reason I stuck in the task, is it lets a task add its own
bindToOwner implementation, to do extra binding. If you put it in the
parent, then the bound task doesnt get a look in.
Make sense?
Note also that my code init()s the helper task too, and that I was
always calling configureTask() in the parent task own init(). --DD
/**
* Configures a helper task to be used within another task.
*
* @param parent the parent (custom) task using the helper task.
* @param helper the helper task to configure for use.
* @return the configured helper task for call chaining.
*/
public static Task configureTask(Task parent, Task helper) {
// Make helper share attributes of the parent
helper.setProject(parent.getProject());
helper.setTaskName(parent.getTaskName());
helper.setOwningTarget(parent.getOwningTarget());
// Copy location for better troubleshooting of subtask
Location location = parent.getLocation();
if (location == null) {
location = Location.UNKNOWN_LOCATION;
}
helper.setLocation(location);
// Initialize (and return) the helper
helper.init();
return helper;
}
-
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
From: Steve Loughran [mailto:[EMAIL PROTECTED] the reason I stuck in the task, is it lets a task add its own bindToOwner implementation, to do extra binding. If you put it in the parent, then the bound task doesnt get a look in. Make sense? Not really ;-) Do you have any example of such a thing? Sounds like me like it breaks encapsulation, no? A task should not have to know whether it's used directly or not in my view. Then again I tend to button things down tight as a habit. It always easier to loosen things a bit later, than the reverse, especially with Ant's BC requirements. All that said, thanks for doing this. You're new bindToOwner() does help encapsulation. We can now easily copy more attributes in just one place in the future. --DD - 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
On 18 Feb 2005, [EMAIL PROTECTED] wrote: I'm tempted to retrofit Task.bindToOwner back to the 1.6.x codebase, for the benefit of third party tasks; same for the extra constructors for exec and java. Thoughts? If you only port bindToOwner and the new constructors, but not all the points of invocation then you can't do much harm. Stefan - 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, 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 ftp 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
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 ftp 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
- 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. *** GUS 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. /GUS ANTOINE 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 /ANTOINE 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 AFAIK ANT 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 /ANT WINDOWS .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 /WINDOWS UNIX the area where symbolic links support should be least problematic, except for possible exceptions due to media not accepting symbolic links /UNIX /AFAIK Apart from copy/, 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: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
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 :) snip 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. *** GUS 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. /GUS ANTOINE 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 /ANTOINE /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 AFAIK ANT 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 /ANT agree WINDOWS .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 /WINDOWS 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). UNIX the area where symbolic links support should be least problematic, except for possible exceptions due to media not accepting symbolic links /UNIX /AFAIK Apart from copy/, packaging tasks are good candidates for having the option of copying/preserving symbolic links. They
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
I have introduced two changes in the behavior of the FTP.FTPDirectoryScanner to make it behave like the normal DirectoryScanner : - possibility of following symbolic links which are directories, governed by the followSymlinks property, - including (root directory of the fileset) in the includedDirectories, as long as it matches include patterns These 2 changes are introducing behavior changes with ant 1.5.3 The impact of the changes : - symbolic links : if you are doing a get operation and there is a symbolic link pointing to a directory in the fileset, then you are going to download from the link too, whereas you previously would not have - the inclusion of in includedDirectories impacts only the action RM_DIR. I need to check whether it works anyway. The aim of the exercise was to make FTP.FTPDirectoryScanner pass the same tests as DirectoryScanner. My thoughts : 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 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 ? What are your thoughts ? Cheers, Antoine - 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
On Tue, 5 Aug 2003, Steve Loughran wrote: That is interesting. Exec() hanging. It is not like chmod is doing much. No obvious causes spring to mind, but then I dont use freebsd much. (though I could bring it up under vmware, I suppose) I've had similar problems with JDK 1.4.1 on RedHat 7.2, and better luck with 1.4.0_03. 11011011 - 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
Thanks for the comments Stefan, will do so this evening. Cheers, Antoine - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 9:28 AM Subject: Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java 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 ftp 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
Antoine Levy-Lambert wrote: Steve, I am trying to test on cvs.apache.org (FreeBsd and java version 1.4.1-p3 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-p3-brian_28_jul_2003_12_35) Java HotSpot(TM) Client VM (build 1.4.1-p3-brian_28_jul_2003_12_35, mixed mode) The exec task is hanging out there it seems; at least chmod/ and symlink/ hang out there. I wonder whether the JVM which I am using there is worth something ? Maybe I will try with a JDK 1.3 or 1.2 That is interesting. Exec() hanging. It is not like chmod is doing much. No obvious causes spring to mind, but then I dont use freebsd much. (though I could bring it up under vmware, I suppose) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
