[Anthill-pro] Re: Can AHP3 slurp up junit tests?

[Eric Minick]

Diving back into the code here, it's obvious that what you're describing 
is exactly right. The limitation for now (and probably for 3.1) is that 
reports must be consolidated into a single directory.

-- Eric

Jason Dillon wrote:

> On Nov 29, 2006, at 8:02 AM, Eric Minick wrote:
>
>> As for the slurping, the report is working both locally and in my  
>> test environment.
>
>
> Are each of your TEST-*.xml files in the same directory?  As in:
>
>     /TEST-a.xml
>     /TEST-b.xml
>
> or in different directories, as in:
>
>     /foo/target/surefire-reports/TEST-a.xml
>     /bar/target/surefire-reports/TEST-b.xml
>
> I am quite sure the later will not work with an inclusion pattern  
> like "**/target/surefire-reports/TEST-*.xml"... as I have tried it a  
> few times and it won't work.
>
> I had to add another post-process to basically:
>
>         ant.copy(todir: "reports/surefire", flatten: true) {
>             fileset(dir: ".") {
>                 include(name: "**/target/surefire-reports/TEST-*.xml")
>             }
>         }
>
> Then use an include pattern like "TEST-*.xml" in the "reports/ 
> surefire" directory.  This tells me that however you are finding the  
> XML inputs for the report generation is only working off of a single  
> directory, not an entire tree (which is why the "flatten: true" works.
>
> NOTE: This pattern "**/target/surefire-reports/TEST-*.xml" does  
> appear to pick up all of the report files to be delivered to the  
> server... as I do see the right number of files added to the zip  
> (from the logs, have not actually peeped at the zip itself, but I  
> assume your logs are reporting the correct numbers).
>
>
>> Would it be possible for you to zip up the test results directory  
>> structure of your and shoot it over to me? I'd be happy to set up a  
>> little test project that just tries to load them and see where  
>> things are tripping up.
>
>
> You can see the exact set of files, by using that above pattern, with:
>
> svn co http://svn.apache.org/repos/asf/geronimo/specs/trunk specs
> cd specs
> mvn install
>
>
>> We're actually doing an XML parse rather than XSLT. The report  
>> generation would be better as XSLT but that's a distraction anyway.  
>> The real nifty part is that the data is decently exposed to the  API. 
>> While you can include test information in notifications, that  might 
>> also be XSLTable. What isn't is making decisions based on the  data. 
>> There's a little example at the bottom of the Integrating  JUnit 
>> tutorial in the docs that shows how to send out seperate  
>> notifications for failing tests or tests that are not running  
>> quickly enough (indicating functional rather than unit).
>
>
> Okay, how does your XML parse find the files it is going to process  
> for the report?  I hope its not a simple java.io.File.listFiles() off  
> of a directory.  I had expected it to re-use that pattern I had given  
> the report configuration, using an ant-like FileScanner or something.
>
> --jason
>
>
> _______________________________________________
> Anthill-pro mailing list
> Anthill-pro at lists.urbancode.com
> http://lists.urbancode.com/mailman/listinfo/anthill-pro