Mmm...spoken like someone with an emotional attachment to SubAnt due to your involvement with it. Let's be constructive and stick with the merits of my proposal because you've got some good points. BTW, this is my first submittal to any open source project so let's approach this from a "today's my first day" kind of way. :-) I don't care which one people like and/or use, but I implemented it anyway so I thought I'd put it out there.
My new ant task supports ordering of build files by default. Just line them up in the includes="" attribute. I have never seen the <loadproperties> task before your reference to it but yes, looking at it for a minute I think it may have been a better fit in the <property> task, but it's fine the way it is. This new ant task has no support for running several targets, forking, child->parent props,refs (except the default handling of props/ref provided by the original ant). This was outside of my scope. I don't see why these features couldn't be added though. <java> and <javac> have a fork attribute - why couldn't <ant>? Based on *your* reasoning we should have created a <subjavac> if <javac> wasn't meeting our needs. This is why I extended <ant>. I knew of the existence of SubAnt task but it hadn't been released (or even committed) when I got started on the new Ant task and I thought my implementation was cleaner for the end user. It's early enough for the Ant committers and the other developers to decide which they like, or decide to keep both ways like the Properties and LoadProperties tasks. So, to say that I should have used an *existing* task is a bit of a stretch. And, on the subtleties, I think it work pretty intuitively: dir & antFile = dir\antFile dir & <dirset> = error <dirset> & antFile = dir[i]\antFile <fileset> = path\to\antFile Andy >>> [EMAIL PROTECTED] 3/13/2003 9:55:03 AM >>> But where does it stop? <subant> also supports automatic ordering of the projects called based on the declared dependencies of the projects in an XML file... Should that go into <ant> as well? (granted, I didn't submit that, it's only in my sandbox...) According to your reasoning, <loadproperties> features should have gone into <property file="">. And what about running several targets instead of one, or forking the sub-builds, or exporting back up properties/references from the child to the parent? Should that go in <ant> as well? This is why <subant> and orther <ant> derivatives exist, and do a good job at what they do. Have you considered the subtleties of what basedir gets used for the sub-projects when mixing build filesets and dirsets? Instead of modifying Ant to get your chances, you might as well have used something that already exists and works. But that's just me. --DD -----Original Message----- From: Andrew Goodnough [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 9:27 AM To: [EMAIL PROTECTED] Subject: [PATCH] Ant Task - Proposed Enhancement The current ant task runs an ant process for a specified build file in a specified directory. I wanted to be able to give it more than one directory, and execute the build file found in each directory specified, or give it a set of build files to execute. This can be really useful for building projects on which this project depends (could be sub-projects but doesn't have to be). I understand that this enhancement overlaps with the proposed SubAnt task but I feel that this function is really the domain of the existing Ant task, so rather than adding another task, the Ant task should be enhanced - especially when it only involves adding a couple contained types that users already know how to use in other contexts. This enhancement adds the ability to specify multiple directories with the addition of a contained <dirset> type or multiple files with the addition of a contained <fileset> type. One can also specify both DirSets and FileSets together, as well. This allows the task to run ant processes on the directories specified (by appending the default "antFile" to them), or on the set of files specified. {see ANT_HOME\src\etc\testcases\taskdefs\ant.xml for examples in the attached zip file} I've run all of the current and new tests on the task and all passed. Most of the original logic flow is unchanged (although it doesn't seem that way due to refactoring). In a nutshell, I added a for loop to the execute method to loop through the each directory and each file specifed, and execute the target on each. {see "diff.txt" in the attached zip file} Tell me what you think. Andy Using directory structure ************************* /sub1 build.xml /sub2 build.xml /sub3 build.xml A typical build file could use the new task like this: <!-- excerpt from Project3/build.xml which depends on Project1 and Project2 --> <!-- in order to build correctly --> <property name="subproject.dirs" value="Project1,Project2"/> <target name="compile-subprojects" if="subproject.dirs"> <taskdef name="antnew" classname="org.apache.tools.ant.taskdefs.AntNew"/> <antnew inheritAll="false" target="compile"> <dirset dir=".." includes="${subproject.dirs}"/> <!-- NEW FEATURE --> </antnew> </target> <target name="compile" depends="compile-subprojects"> ... </target> more examples pasted from testcases: <target name="test-dirset-inline-includes"> <ant inheritAll="false" target="printMessage"> <dirset dir="ant" includes="sub1,sub2,sub3"/> </ant> </target> <target name="test-dirset-contained-includes"> <ant inheritAll="false" target="printMessage"> <dirset dir="ant"> <include name="sub*"/> </dirset> </ant> </target> <target name="test-fileset-inline-includes"> <ant inheritAll="false" target="printMessage"> <fileset dir="ant" includes="sub1/build.xml,sub2/build.xml,sub3/build.xml"/> </ant> </target> <target name="test-fileset-contained-includes"> <ant inheritAll="false" target="printMessage"> <fileset dir="ant"> <include name="sub*/build.xml"/> </fileset> </ant> </target> <target name="test-fileset-and-dirset"> <ant inheritAll="false" target="printMessage"> <fileset dir="ant"> <include name="sub1/build.xml"/> </fileset> <dirset dir="ant" includes="sub2,sub3"/> </ant> </target> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
