Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 75411 invoked from network); 10 Aug 2005 05:01:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Aug 2005 05:01:06 -0000 Received: (qmail 32501 invoked by uid 500); 10 Aug 2005 05:01:05 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 32006 invoked by uid 500); 10 Aug 2005 05:01:02 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 31989 invoked by uid 99); 10 Aug 2005 05:01:02 -0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Aug 2005 22:01:01 -0700 Received: by ajax.apache.org (Postfix, from userid 99) id 30061E0; Wed, 10 Aug 2005 07:00:59 +0200 (CEST) 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 X-Bugzilla-Reason: AssignedTo Message-Id: <20050810050059.30061E0@ajax.apache.org> Date: Wed, 10 Aug 2005 07:00:59 +0200 (CEST) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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=34942 hoju@visi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From hoju@visi.com 2005-08-10 07:00 ------- I found yet another reason to bite the bullet and depend on Ant-1.6.2+ instead of 1.5.x. I made some changes to my build so that as optional VFS dependencies are downloaded, I redefine the VFS tasks so that the next optional dependency to download can take advantage of the most recent downloaded optional dependency. For instance, if I download commons-collections, I can then re-define the task with commons-collections now in the classpath so that the next dependency can take advantage of the LRU cache, and so on.... So, I tried this and I got (partial stack track after doing ant -debug)... java.lang.ClassCastException: org.apache.commons.vfs.tasks.VfsTask$VfsRef at org.apache.commons.vfs.tasks.VfsTask.resolveFile(VfsTask.java:64) at org.apache.commons.vfs.tasks.AbstractSyncTask.handleSingleFile(AbstractSyncTask.java:339) at org.apache.commons.vfs.tasks.AbstractSyncTask.execute(AbstractSyncTask.java:182) 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.taskdefs.Sequential.execute(Sequential.java:64) However, when I revert back to the previous version of VfsTask.java and apply my patch, everything works like clockwork. No errors or anything. Can we, pretty please, just require Ant-1.6.2. The patch is deadpan simple, it actually works in all cases (try it if you have doubts), and if people are still using Ant-1.5, they are living in the dark ages anyway. The current solution is brittle. BTW, is commons-httpclient now *not* an optional dependency? I used to be able to only need commons-logging and commons-vfs in the classpath in order to have basic rudimentary downloading capability using simple http to grab a file. Now, if I don't have commons-httpclient in the classpath before using , I get this... java.lang.NoClassDefFoundError: org/apache/commons/httpclient/util/URIUtil at org.apache.commons.vfs.provider.URLFileName.getPathQueryEncoded(URLFileName.java:65) at org.apache.commons.vfs.provider.URLFileName.getURIEncoded(URLFileName.java:119) at org.apache.commons.vfs.provider.url.UrlFileObject.createURL(UrlFileObject.java:74) at org.apache.commons.vfs.provider.url.UrlFileObject.doAttach(UrlFileObject.java:63) at org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1215) at org.apache.commons.vfs.provider.AbstractFileObject.getType(AbstractFileObject.java:400) at org.apache.commons.vfs.tasks.AbstractSyncTask.handleSingleFile(AbstractSyncTask.java:341) at org.apache.commons.vfs.tasks.AbstractSyncTask.execute(AbstractSyncTask.java:183) 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.taskdefs.Sequential.execute(Sequential.java:64) Can we move back to making it optional? At a minimum, the optional dependencies page needs updating, but I'd much rather simply keep httpclient optional. Thanks, Jake -- 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