Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 34942]  -
    [VFS] no vfs_cache cleanup after ant task completed
Message-Id: <20050811073106.EC7F7E5@ajax.apache.org>
Date: Thu, 11 Aug 2005 09:31:06 +0200 (CEST)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34942>.
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=34942


------- Additional Comments From mario@ops.co.at  2005-08-11 09:30 -------
> One issue with the downloads page.  It says commons-httpclient-2.0 and later. 
> Except that commons-vfs won't compile with commons-httpclient-3.0....
After some testing during upgrade webdav & httpclient to their latest versions
showed us some problems with the webdav communication. It was no longer
possible to list directories with webdav.

> After all, someone might want to use 3.0 along with VFS in a
> project and run into jar hell.
Once it works VFS will support it. But you are right. A project with such a
dependency list has the potential to drive the user into a jar hell.
But surf on the latest version wont make it better.

> Also, you build against commons-net-1.4.0 according to project.xml.
Same story. Its often better to use more recent versions but we should
take care not to break backward compatibility too fast.
Now that commons-net has a new parsing engine there are arguments to 
break it, so we can go that way. Yes please file a new bugzilla ticket with your
patch - as enhancement - we can apply it after release 1.0

> Anyway, the point is, it seems to me that you should keep the dependency
> versions defined in download.xml in sync with those in project.xml.
> Otherwise you might end up fooling yourself and users by breaking backward
compatibility
> with asserted library versions without realizing it.  Thoughts?  
Thats true, thanks for pointing out. In the future I'll take more care NOT
to upgrade the project.xml. Without any reason.
For now I'll sync dowload.xml with it.

> Now, one more thing.  I'd like to add Ant-1.6+ antlib functionality.
Sure, we can to it.
Isnt the main advantage of it to have a namespace? So we could name your vfs
tasks simply copy, move, ...
In ant one can use 
xmlns:vfs="antlib:org.apache.commons.vfs.tasks" and then
<vfs:copy ..

Or am I wrong?


-- 
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org