Incompatibility of multi-module Bears bugs.

[zhenyudg]

Some multi-module projects are removed because they are not compatible with the automation tools used in this paper. Which tools do you refer to?

[zhenyudg]

We had previously written internal software tools that operate on single-module Maven projects.

[zhenyudg]

For an ICSE resubmission, how difficult would it be to support multi-module projects? I believe that @lvyiwei1 made the decision to exclude multi-module bugs, so he may have some insights here.

[lvyiwei1]

Um, I can only give some insight about the fitness experiment: the whole experiment pipeline is designed based on standard single-module maven project structure, so including multi-module bugs would require some serious re-working. Also, since I actually use Genprog4java's testing functionality combined with Fake-JUnit to do count passing test classes/methods/assertions, I have to figure out how to make GP4J work with multi-module projects too (the script I use to run GP4J on Bears was an adaptation of the GenProgScripts repo written by Mau years ago for D4j, which has no mult-module projects).

[lvyiwei1]

To include the multi-module bugs, we have 2 options: 1. make the current code work for multi-module bugs (most likely that means). This will require some serious dev work and debugging, since the current experiment pipeline contains a LOT of code and scripts reused from older repos that fits to D4J-style single-module projects. 2. Maybe we can ditch the additional modules and only do experiment on the module that contains the bug? that will also require some engineering too since the bug info that comes with the Bears Dataset applies to the whole project instead of specific modules. Also, that's assuming modules are completely independent from each other -- which may not always be the case

[zhenyudg]

Okay, perhaps this language might work:

We reused code from genprog4java's text execution harness, which assumes a single-module project structure.