Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 88992 invoked from network); 17 Jan 2002 13:20:42 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 17 Jan 2002 13:20:42 -0000 Received: (qmail 3836 invoked by uid 97); 17 Jan 2002 13:20:38 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 3806 invoked by uid 97); 17 Jan 2002 13:20:37 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 3795 invoked from network); 17 Jan 2002 13:20:37 -0000 Message-ID: <37B2E6BFD50BD411970000B0D021D9C09B8E97@intranet.tel.cril.net> From: =?iso-8859-1?Q?MOUSSAUD_Beno=EEt?= To: 'Ant Developers List' Subject: RE: Ant2 VFS Proposal Date: Thu, 17 Jan 2002 14:17:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi=20 I am very interrested to follow your work about VFS and if i can help you ! I have tried to make such thing but i am not completly happy with=20 my design (JNDI+EJB+WebServer). Can you send me the other java file to better understand you design ? Benoit -------------------------------------------- Benoit Moussaud - Software Team Leader benoit.moussaud@criltelecom.com CTS - Cril Telecom Software http://www.criltelecom.com 8 rue danjou 92517 Boulogne Billancourt - France Tel: (33) 1 58 17 04 78 -----Message d'origine----- De : Adam Murdoch [mailto:adammurdoch_ml@yahoo.com] Envoy=E9 : jeudi 17 janvier 2002 12:07 =C0 : ant-dev@jakarta.apache.org Objet : Ant2 VFS Proposal Hi, I've done up a proposal for an Ant 2 VFS layer. It's a first cut, so there's plenty of stuff missing from the API, and the implementation = is, well, "experimental" at best. The API currently allows the following: * Locating a file by absolute URI, a local file name, or relative to = another file. * Traversing the structure of a file system. For example, listing the children of a file. * Creation and deletion of files. Includes recursive deletion, and = implicit creation of parent. * Reading and writing the content of files. * Some name parsing. * Getting and setting of some file attributes, such as last-modified = time. In short, everything that java.io.File gives you (along with = FileReader, FileInputStream, etc). The implementation currently supports: * Local file systems. * Zip/Jar file systems. Read-only, and only for local files. * FTP file systems. Uses NetComponents. * CIFS (Samba, Windows shares, etc). Uses jCFIS (from Samba). * Caching of structural info. No caching of content or content = meta-info. * Plenty of validation. For example, you can't create file if its = parent aleady exists and is not a directory, you can't list the children of a regular file, etc. * Some concurrency detection. Can't read and write a file at the same = time, for example. The goal for this first cut was to do up a proof-of-concept. I'd love = to get some feedback from ant-dev. The javadoc for the API interfaces is attached (I've left out the provider API, cause it's just noise at this stage). Please have a read - comments most welcome. Just keep in mind = it ain't finished yet. If it looks ok, I'll tidy-up the code (license, = package names, etc) and send it in. The next step would be to try it out. I'd like to do this in Myrmidon, = if possible. The plan would be something like: * Do up a FileSystemManager impl that wires into myrmidon. * Expose the FileSystemManager to the tasks via TaskContext as = (ultimately) a replacement for getBaseDirectory() and resolveFile(). Could be done = via ComponentManager + AbstractTask too, I suppose. * Add a String -> FileObject converter. * Port FileSet and Path to use FileObject and friends, rather than java.io.File. Would involve pushing some of this stuff behind the API. * Port , , , and . Again, some of = this stuff would end up behind the API. * Look at getting rid of , , , . Longer term maybe things like , , , etc. * Port some of the tasks that need local files, such as , = , , etc. * Look at things like configuring file systems in the build file, = getting user name and password from the user, etc. As far as the VFS layer itself goes, there's a few things that would be = good to do soon-ish: * Implement a bunch of new providers: HTTP, WebDAV, CVS, writable Zip/Jar/Tar, etc. * Get the FS providers involved in searching, deleting, moving, and = copying. Do as much as possible of this remotely. * Convertion to/from local files, and java.net.URL. * More naming stuff, dealing with things like case sensitivity, and = (maybe) canonical names, and links/aliases. * Layered FS, compound FS, filtering, a concurrency model, etc. Adam -- To unsubscribe, e-mail: For additional commands, e-mail: