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: Batchtest filesets and classes/classpaths
Date Thu, 23 Sep 2004 07:51:40 GMT
Your master buildfile can call all module tests, so running the tests should

not be the pain. More reading the report.

<junit> can generate one xml logfile for each test. <junitreport> collects
them
and creates one single xml file and then the html output. Why dont let
<junitreport>
do the merge job? Havent tried that, but 
    <junitreport>
        <fileset dir="." includes="plugins/*/build/report/*.xml"/>
(or where your files are) should work.


Jan


> -----Urspr√ľngliche Nachricht-----
> Von: Greg Irvine [mailto:greg.irvine@thalesatm.com]
> Gesendet am: Donnerstag, 23. September 2004 09:43
> An: 'Ant Users List'
> Betreff: Batchtest filesets and classes/classpaths
> 
> Hi ant users.
> 
>  
> 
> I'm having a little trouble with creating a fileset to suite 
> my needs.  In
> fact, I have a couple of issues which have led to this point, 
> so I'll see if
> I can explain simply.  :-)
> 
>  
> 
> While you're reading this, think about how Eclipse works, and 
> you'll not go
> far wrong.
> 
>  
> 
> Normally a java package matches the directory structure from 
> the root of the
> "project".
> 
> e.g. org.apache.ant.Ant lives in org/apache/ant/Ant.java
> 
>  
> 
> If I had 2 separate application "components" that shared 
> mostly the same
> package name:
> 
> e.g. org.apache.ant.Jakarta and org.apache.jakarta.Jakarta.
> 
> If they lived together in the same repository structure, it 
> would look like
> so:
> 
> org /
> 
>     apache /
> 
>         ant /
> 
>             Main.java
> 
>         jakarta /
> 
>             Main.java
> 
>  
> 
> The problem with this is that you can't work on Jakarta, 
> without checking it
> out at the "org" level, which means you also check out the 
> Ant code too.
> 
>  
> 
> Because the application I'm working on is based on an 
> independent plugin
> style architecture I've structured the repository to allow me 
> to check out
> functionality independently.  It's meant duplication of 
> directory names etc
> and a deeper tree than above, but I don't mind.
> 
> e.g.
> 
>     myproject /
> 
>        build.xml
> 
>         core /
> 
>             build.xml
> 
>             Main.java
> 
>         plugins /
> 
>             build.xml
> 
>             plugin1 /
> 
>                 com /
> 
>                     mycompany /
> 
>                          plugin1 /
> 
>                              build.xml
> 
>                              Plugin1.java
> 
>             plugin2 /
> 
>                 com /
> 
>                     mycompany /
> 
>                          plugin2 /
> 
>                              build.xml
> 
>                              Plugin2.java
> 
>  
> 
> This allows me (via Eclipse) to check out my project from the 
> repository at
> the first "plugin1" directory for example and just checkout 
> the code for
> plugin1 (e.g. com/mycompany/plugin1/*) and retain the desired 
> package naming
> while separating the plugins' source code.
> 
>  
> 
> This is where it gets a little complicated.
> 
> I'm using Ant to build all my components, by (using the 
> ant-contrib) looping
> through each subdirectory and calling it's build.xml (which 
> in turn my have
> subdirectories).  
> 
> i.e.  myproject/build.xml calls core/build.xml and plugins.xml, and
> plugins/build.xml will itself look through and call 
> plugin1/build.xml and
> plugin2/build.xml.
> 
>  
> 
> Are you still with me? :-)
> 
>  
> 
> Next, I have the need that each component exists in it's own jar file.
> 
>  
> 
> To do this, I was placing the .class files from each projects 
> build into
> build/<project> (therefore,
> build/plugin1/com/mycompany/plugin/Plugin1.class), and then I 
> jar up each
> one from build/pluginX,   etc.
> 
>  
> 
> Here's where the problem is.  I was also originally running 
> the unit tests
> individually in each build file.  This however produced 
> individual test
> results output, which was a pain, so I'm now trying to 
> consolidated it all
> into 1 place but running the unit test task as a global task 
> in the root
> build.xml instead of individually in each subproject/plugin's 
> build file.
> 
>  
> 
> The problem actually is, when the <batchtest> is called with:
> 
>             <batchtest todir="testresults/test-out">
> 
>                 <fileset dir="build" includes="**/*Test.class" />
> 
>             </batchtest>
> 
>  
> 
> I get the error:
> 
> [junit] Exception in thread "main" java.lang.NoClassDefFoundError:
> plugin1/com/mycompany/plugin1/Plugin1Test (wrong name:
> com/mycompany/plugin1/Plugin1Test)
> 
>  
> 
> I THINK this is because the <batchtest> "root dir" is build, 
> instead of
> build/*/.  I can't seem to find a way to get the <batchtest> 
> to run in all
> subdirectories under build without it retaining the 
> subdirectory name at the
> start of the expected class file it's looking for.
> 
>  
> 
> This gets even more complex as I'm introducing coverage testing with
> GroboUtils and postcompiling classes into another directory, etc.
> 
>  
> 
> So, does anyone have an ideas or suggestions on what I can do 
> to solve, or
> even completely change my approach?
> 
>  
> 
> Thanks, regards, and apologies for the long email.
> 
>  
> 
> Greg.
> 
> 

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