ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan.Mate...@rzf.fin-nrw.de
Subject AW: Aggregating filesets dynamically
Date Mon, 20 Sep 2004 05:55:14 GMT
If the modules have a common parent directory that should be possible:
Instead of 
     <fileset dir="${common.dir}/test">
         <include name="**/*.java"/>
     </fileset>
use
     <fileset dir=".">
         <include name="${common.dir}/test/**/*.java"/>
     </fileset>

Jan




> -----Urspr√ľngliche Nachricht-----
> Von: Tim McNerney [mailto:mcnerney@navis.com]
> Gesendet am: Samstag, 18. September 2004 00:48
> An: user@ant.apache.org
> Betreff: Aggregating filesets dynamically 
> 
> 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
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message