Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org Received: (qmail 64650 invoked by uid 500); 6 Aug 2001 07:35:54 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: ant-dev@jakarta.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 64622 invoked from network); 6 Aug 2001 07:35:53 -0000 X-Authentication-Warning: bodewig.bost.de: bodewig set sender to bodewig@bost.de using -f To: ant-dev@jakarta.apache.org Subject: Re: Patch Audit References: <0ea701c11dc8$c8bba550$48e2223f@cognetnt> From: Stefan Bodewig Date: 06 Aug 2001 09:36:00 +0200 Message-ID: Lines: 311 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Thanks for that big effort Conor. Let me go through the list from top to bottom: * with if/unless I first had to look up the reason why I did not commit it. OK, it was consistency and I pointed to the more general task level if/unless attribute vote that has been going on at that time. Task level if/unless attributes have been rejected (because nobody wanted them, not because anybody had given it a -1). I mentioned the task which is now there. Peter now talks about an if task instead of task level if/unless attributes, well, that's almost trivial to do now, just combine ConditionBase and TaskContainer. Seems like Peter has mad up his mind about certain control-flow features that have been rejected for Ant2 as much as I have about certain other parts of it (I'd be willing to accept a task based on TaskContainer). Let's sort that out once again, but don't hold up the release for this. Promise to write shorter answers for the rest 8-) * Single File in FileSet Does work today, doesn't it? * Callback in I have some problems to see the motivation, at least after you've introduced filtersets. * Regex Replace task Yes, I agree we should have one - but I wanted to base it on the regex interface I had built for the regex-mapper stuff to make the task work with ORO, jakarta-regexp or JDK 1.4. Call it a pet project of mine. As I've never found the time to adapt the stuff, I could live with one of the tasks being committed and work on it later. Question remains whether we wanted to extend or make it a completely new task. Could wait until after the release IMHO, but I wouldn't veto it either. * Concatenate task I would consider this the prime example of "learn to write your own Ant task, lesson 1". No real opinion. * Unix utilities Very specific - given that Ant cannot detect symlinks when deleting stuff, making it create them could get us in serious trouble. Let's wait with this, especially since Martin his pulled back his tasks. * Ask for properties We need a more general solution than simply reading from System.in, I'd rather wait with this. * Weblogic JSPC No opinion * FTP Updates Either they are bugfixes, in which case they should be applied or have already been addressed. * wait No - terminating tasks should be the responsibility of the container, so I'd rather see that added to . * making DirectoryScanner statics public -1 I'd like to rework the whole FileSet/DirectoryScanner interaction after the release of 1.4 (taking ideas from the culler proposal and other stuff accepted for Ant2) - making stuff public now, that we may remove sooner or later is a bad thing IMHO. * Weblogic RMIC -1, I think all we need is there behind the facade. * Exec with detach +1 - but could wait until after the release. We'll have to see whether a set of patches can make and consistent or whether we need to role our own for one part of it. * Case sensitivity in filesets Actually, I think it should apply to patternset, not fileset. +0 but after the release. * OS/2 scripts Must have missed them, +1 and now. * doc updates for antlr +1 on all documentation updates - now. * with working dirs Already addressed? * Alternative s kjc is in (I committed the bugzilla version, that also contained gjc support). sj support looks trivial, commit now IMHO (I'll do it). * jni c I'd rather wait for the stuff, after the release. * equal task is there via . * Ant shell (oh my, is this list long) Should be a separate frontend, I see serious problems with statics and missing cleanups and all that - to dangerous to commit before the beta build as it will need very extensive testing. * Precompile couldn't find it, sorry. * internal targets -1 - next would be targets that may be invoked from other build files but not from the command line, then ... * FTP tests If you look at the patch, you'll see it it incomplete. David promised to hand them over after reworking some of them, i.e. I tried to commit it a few months ago ;-) * Cullers rethink and rework after the release * Bean generator too specific IMHO. * DDCreator bug Bugs should be fixed 8-) * uptodate Superseded by condition * improvements revoked by Steve * Diff task Make that a condition - after the release. * enhanced propertyfile +1 but could wait. * command line arguments -1 - Ant shouldn't be a shell script replacement, give names to your properties. * foreach has been -1ed several times. * cvs news I considered that superseded by the changelog task in Alexandria. * File contents as a replace value prpertyFile attribute of can be used to do that, even if in an unconvenient way - low priority IMHO. * iPlanet AppServer No real opinion. * fileset and not-existing dirs part (1) has been addressed, I don't think I like part (2). * IONA idl Sounds very specific, but could be a starting point for a more generic task, just like ejbjar started as a very specific thing. No real opinion. * JUnitReport encoding supposed to be addressed. * Unix man pages Who wants to keep them up to date? Not me, I'd rather point to the Debian package. * Ejbjar patches Bugs should be fixed. * Attrib task equal rights to chmod, I simply cannot test it. * test skeleton generator I have some problems with the motivation, as you write tests first, don't you? OK, not before the release. * propagation of filters and references Need to get our concept clear, big backwards compatibility problems -1. * New clearcase tasks As with most stuff I cannot test myself - I wait for feedback of other users and haven't seen any. Not before the release. * C/C++ still to be submitted in combined form * lightweight antcall couldn't find that patch * J2EE deploy No real opinion. * User input to property Hasn't that been there way above? * fixcrlf warn mode Could wait, but is OK. * OS specific properties There are several other ways to do that. -1 * Jikes on MacOS X I've already committed that one. * Multiple targets in mapper Part of - not much value as an independent patch. * Jasper compiler Would love to combine one of the submissions with wljspc to a single one, after the release. * lazy classloading I'm fine with the changes to project, but not with the changes to , as they will lose class loader information for custom taskdefs. * stream pumper input Didn't really test it, and needs to be reconsidered for the multithreading stuff, delay to after the release. * thread safe XML logger +1 and now. * missing file in filterfile cannot find that patch * Additional PVCS ops No real opinion, see my comments on the clearcase tasks. * dependset +1 Seems to be simple and straight forward, so it could go in before the release IMHO. * description element +1 and almost trivial, so could go in now. Stefan