Aggregating filesets dynamically

[Tim McNerney <mc...@navis.com>]

Each of our applications can contain an arbitrary number of modules, 
each which may have their own tests. To include modules within an 
application, one need only add a single reference in the application 
build.xml, in the form of an entry in a comma-separated list of modules 
within a property:

       <property name="modules.list" value="common,mod1,mod2"/>

To build these individual modules, we use ant-contrib.sf.net and have a 
target that looks like:

     <target name="build-modules">
         <for list="${modules.list}" param="module">
             <sequential>
                 <moduleDist moduleDir="../@{module}"/>
             </sequential>
         </for>
     </target>

where moduleDist is a macrodef we have written. This will iterate over 
each of the modules and build them.

Each of these modules has unit tests. We'd like to run these tests en 
masse from the context of the application rather than within their 
individual module contexts (they are often also run that way in 
different builds). So rather than have them handled in the moduleDist 
macro, we'd like a single <junit> task to run them all. There are a 
number of reasons for this, as well as a number of other similar tasks 
which we want to run thusly, so alternate methods for running the tests 
aren't useful.

So when we get to the <junit> task, we'd want something like:

	<junit>
		<batchtest todir="${test-results.dir}">
                 <fileset refid="test.all"/>
             </batchtest>
         </junit>

where test.all is an aggregate fileset which would look like:

     <fileset dir="${common.dir}/test">
         <include name="**/*.java"/>
     </fileset>
     <fileset dir="${mod1.dir}/test">
         <include name="**/*.java"/>
     </fileset>
     <fileset dir="${mod2.dir}/test">
         <include name="**/*.java"/>
     </fileset>
     <fileset dir="${app.dir}/test">
         <include name="**/*.java"/>
     </fileset>

if written in longhand. We'd love to avoid having to enumerate the 
fileset individually, as it simply duplicates information contained in 
the modules.list property.

So the question is, is there some way to dynamically create a fileset, 
containing the aggregate of other filesets, each with a differing base 
dir and the number of which is not known beforehand? Basically, we'd 
like something where adding a module to an application involves simply 
adding an entry to the modules.list property?

Ideally, the solution would be within ant. Another possible solution 
might be an external list which transforms a template build.xml into 
one with references to all the modules in multiple locations/forms, 
though this would be much less ideal as these build.xmls vary 
substantially from application to application. Extending ant would be 
another possibility, though I'm unfamiliar with the practice and any 
pointers or suggestions how to go about it (new task, patternset, 
filter, etc) would be greatly appreciated.

Thanks.

--Tim


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

Re: Aggregating filesets dynamically

[Stefan Bodewig <bo...@apache.org>]

On Fri, 17 Sep 2004, Tim McNerney <mc...@navis.com> wrote:

> So the question is, is there some way to dynamically create a
> fileset, containing the aggregate of other filesets, each with a
> differing base dir and the number of which is not known beforehand? 

No, unfortunately there isn't.

The main reason is that a <fileset> has a single base directory by
defintion, so whatever the result of the joined <fileset>s would be,
it would not be a <fileset>.

Our generic file collection ATM is <path>, even though it hasn't been
designed for this purpose.  But even if <batchtest> supported a nested
<path> (which should be rather simple), I don't see how to dynamically
create a <path> from a comma separated list of directory names - at
least not without writing a custom task that does it.

The "real" solution would be support for arbitrary file collections
inside of Ant - and inside of all Ant tasks.  So far the goal has been
stated more than once but the way to get there is so long and made
more and more difficult by backwards compatibility that nobody has
really tackled it yet.

Stefan

-- 
http://stefanbodewig.blogger.de/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org