ant-dev mailing list archives

Site index · List index
Message view
Top
From "Andrew Goodnough" <Andrew.Goodno...@wicourts.gov>
Subject RE: [PATCH] Ant Task - Proposed Enhancement
Date Thu, 13 Mar 2003 16:54:42 GMT
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.

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

>>> DDevienne@lgc.com 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...)

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:Andrew.Goodnough@wicourts.gov]
Sent: Thursday, March 13, 2003 9:27 AM
To: dev@ant.apache.org
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
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
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">
<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: dev-unsubscribe@ant.apache.org