Made possible scan for files in subdirectories

[velo]

Hi,

I have a huge project, with integration tests. The integration tests are on project C but they to test code from projects A and B, so I needed a way to scan for source files, so I do not had to add all source folder to my pom.

[coveralls]

Coverage decreased (-3.8%) to 93.54% when pulling 9e7992124fd7aa799b41fd2dc8ac2cbcc1de0c4c on velo:file_scan into aa395baf0720822d563779163883e1b4db23a99e on trautonen:master.

[coveralls]

Coverage increased (+0.11%) to 97.44% when pulling e604328a2cf009de9af7c9a191eed7831804b0e3 on velo:file_scan into aa395baf0720822d563779163883e1b4db23a99e on trautonen:master.

[trautonen]

@velo are you using this modification so that you add one custom root directory to configuration, which is the parent of the actual source modules, and when the scanloader kicks in it picks up the sources? Do you use cobertura or jacoco as the coverage tool, because I was wondering if the cross module coverage gets calculated correctly in your case?

[velo]

Yes, I do.

I'm using jacoco.

After my build finished, I run org.jacoco:jacoco-maven-plugin:0.7.x:merge to aggregate all reports and later coveralls-maven-plugin to create coveralls.

Based on the numbers I have per module, feels it is calculating correctly. I never put it under a rigorous check, but when I look into the numbers they do feel solid.

[trautonen]

Ok nice to know. One thing I'm still wondering... the plugin scans all reactor maven projects (submodules and their submodules and so on), this should make sources visible for all modules that are part of the root project. I guess in your case the test project is not in same project hierarchy than the modules under test, is that correct? Just making sure the use case is solid and I can create correct documentation.

[trautonen]

And one more thing... there's issue #64 with quite similar use case. I've never used the jacoco's merge goal so if you could give a small example there how to put all that together with the coveralls plugin that would be awesome.

[velo]

the module that aggregates and write cobertura reports is not on reactor.

Cause I need it to run after all other, and there is no way to say this module depends on all other (unless I add the dependencies, but then project evolve, new modules come to life and would need to remember to update this dependency list)

            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>0.7.1.201405082137</version>
                <executions>
                    <execution>
                        <id>merge-tests</id>
                        <phase>compile</phase>
                        <goals>
                            <goal>merge</goal>
                        </goals>
                        <configuration>
                            <fileSets>
                                <fileSet>
                                    <directory>${project.build.directory}/../..</directory>
                                    <includes>
                                        <include>**/*.exec</include>
                                    </includes>
                                </fileSet>
                            </fileSets>
                            <destFile>${project.build.directory}/jacoco.exec</destFile>
                        </configuration>
                    </execution>

[trautonen]

Great! That's what I thought. And thanks for all the help. The pull request looked quite nice and I'll try to get time to go through it once more and release it along with 3.1.0.

[velo]

Thanks =D

[velo]

hi @trautonen any update?

[trautonen]

@velo sorry for the delay, been dead busy lately. Now everything should be up to date in Sonatype's repo. Could you verify that your builds are working with the latest 3.1.0-SNAPSHOT. I can then release if everything is fine.

[velo]

No problem, I made an internal release with this and I'm using for quite a while.