Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 94770 invoked from network); 10 Apr 2002 09:14:40 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 10 Apr 2002 09:14:40 -0000 Received: (qmail 5890 invoked by uid 97); 10 Apr 2002 09:14:50 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 5833 invoked by uid 97); 10 Apr 2002 09:14:50 -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 5822 invoked from network); 10 Apr 2002 09:14:49 -0000 X-Epoch: 1018430083 X-Sasl-enc: iH1jQ8BxajFfSqhp2Zg38g Message-ID: <01ba01c1e070$27346a30$2ff1f682@har.mrc.ac.uk> From: "Rob Oxspring" To: "Ant Developers List" References: <134401c1e027$0c71b750$1219570f@ranier> Subject: Re: [SUBMIT] FileOrder element for ordering of filesets Date: Wed, 10 Apr 2002 10:14:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Steve Loughran" To: "Ant Developers List" Sent: Wednesday, April 10, 2002 1:31 AM Subject: Re: [SUBMIT] FileOrder element for ordering of filesets > > ----- Original Message ----- > From: "Rob Oxspring" > To: "Ant Developers List" > Sent: Tuesday, April 09, 2002 3:57 PM > Subject: [SUBMIT] FileOrder element for ordering of filesets > > > > Background: > > IIRC at least one of the problems with submitted concatenation tasks in > the > > past was that ant does not guarentee the order of files within the > > concatenated file. Instead of patching one of the concat tasks > (admittedly > > where I started) this submission is just a utility to allow file order to > be > > specified by the user and applied by the task. I'm sure this is useful for > > concatenation, it may also be handy for the tar/zip family of tasks and it > > might also add an extra aesthetic bonus to the mail task. > > > > User perspective: > > The idea is that tasks can be enhanced with a fileorder element that takes > > an order attribute defining the order to be used when processing files. > > Implementation using an attribute would involve creating an implicit > > fileorder object to hold the value. Various attributes of a file can be > > used to specify the order, can be reversed with a '-' prefix, and combined > > with ',' symbols. Currently the supported attributes are > > name|basename|extension|path|size|length|date. > > > > E.g. > > - group by directory and then > > file extension > > - decreasing date order > > ok, to be an XML pedant we should really have somethign verbose like > > > > > > > > I know it is harder to use, but it is better than encoding magic in literals > and makes XSLT rework that much easier. The reason for the encoded magic was just so that it could be added to tasks such as mail as a single attribute order="x,y,z" rather than having to add an extra element. That said am more than happy to recode it in the more verbose form. > > > How it works: > > The Java2 Comparator is reimplemented and various implementations are used > > to supply the ordering information. A merge sort is performed by the > sort() > > method, thus avoiding the Java2 dependancies of Collections.sort() or > > Arrays.sort(). These should probably be revised when the move to Java2 is > > made. > > So it works on java1.1 fine? Nice. One caveat - the testcase for date ordering won't compile or run under 1.1 since it used file.setLastModified(long) to prep the sample files. I suppose I could recode using reflection - but should the test pass or fail with 1.1? > > > > > Whats included: > > o.a.t.a.util.FileOrder - the class doing the work. > > o.a.t.a.util.compare.* - the classes doing the comparisons > > > > o.a.t.a.util.FileOrderTest - tests the attribute validation and general > > sorting > > o.a.t.a.util.compare.ComparatorTest - tests each comparator individually > > > So, anyone think that this is useful? is it worth me writing the docs? > > I think this is a nice feature, +1 on sticking it in the system with the > appopriate docs and tests, though I am minded towards a more rigorous > approach because it is more xml-ish, and may give more flexibilityin future. > > Which apps should have it? Mail, clearly; but which others? Concat? IIRC Peter and Adam were concerned that ant & myrmidon produce archive files with files in different orders making it harder to check that myrmidon was producing the correct output. My gut feeling is that at least using FileOrder from code (ie not necessarily exposing it in XML) within the archive tasks would make this comparison easier. To be honest, concat is the only situation I can think of that *needs* this, but it may be an aesthetic bonus to other tasks. Rob > > What do others think? > > > > -steve > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: