refactor: refactor the NPEFix pipeline

[andre15silva]

• Moves logic to pipeline
• Introduces abstract NPEFix step
• Introduces MavenInspector

[andre15silva]

Needs to be rebased after #1171 is merged.

[andre15silva]

Ready for review.

Note, had to change Jenkins config because the junit command wouldn't run if previous stages failed.
I can open a separate PR for this if it makes sense.

[monperrus]

Hi Andre,

Nice.

We need to further split it into atomic PRs. The advantage of baby PRs is that 1) it easier to explain, understand and review 2) it enables us to write and run tests in isolation in CI. 3) since we squash PRs, we have a nicer and finer-grain commit history.

By doing baby PRs, you'll become a great developer and master branch-by-abstraction.

Here is a proposal of baby PRs from this one:

• Jenkinsfile
• Feature: Add RunInspector4Maven + Test case for the new class
• Refactor: refactor GatherTestInformation + related changes
• Refactor: introduce AbstractNPERepairStep
• Refactor: refactor FailureLocation and related changes
• Feature: add new method addNextSteps + test case for the new method

Plus, when you change an assertion, add a comment to explain why there is a change

WDYT?

[andre15silva]

Here is a proposal of baby PRs from this one:

* Jenkinsfile

* Feature: Add RunInspector4Maven + Test case for the new class

* Refactor: refactor GatherTestInformation + related changes

* Refactor: introduce AbstractNPERepairStep

* Refactor: refactor FailureLocation and related changes

* Feature: add new method addNextSteps + test case for the new method

Plus, when you change an assertion, add a comment to explain why there is a change

WDYT?

Sounds very good. The order needs to be different tho, because there are some dependencies.

• Jenkinsfile
• Feature: add new method addNextSteps + test case for the new method
• Feature: Add RunInspector4Maven + Test case for the new class
• Refactor: refactor FailureLocation and related changes
• Refactor: refactor GatherTestInformation + related changes
• Refactor: introduce AbstractNPERepairStep

I'll open these PRs today.

[monperrus]

Perfect!

[andre15silva]

This will be ready after #1183

[monperrus]

we're making progress

[andre15silva]

Should be ready for review after CI.

Note: the parameters for NPEFix initialization in the AbstractNPERepairStep constructor is temporary and can be changed after #1184 and after changing TestNPERepairStep to include a parameter definition.

[monperrus]

Overall this refactoring looks really good.

Could you elaborate on the meaning of each new configuration option? We can have a few sentences, maybe a paragraph.

Thanks!

[andre15silva]

Introduces 4 new config options for NPERepair:

• npeSelection: Strategy for selecting repair strategies. Possible values: dom, exploration, mono, greedy, random, safe-mono. Default value: exploration
• npeNbIteration: Number of laps executed during the multiple runs.
• npeScope: Scope of the sources.
  • class includes only classes where NPE's occur
  • package all classes of the packages of classes where NPE's occur
  • stack all classes present in the stack trace of a NPE
  • project includes all project classes. Default value: class
• npeRepairStrategy: Repair strategy to be used during the multiple runs. Possible values: default, tryCatch. Default value: default

[andre15silva]

Now, there is a problem with this. Seems like I misunderstood what the option scope meant, and didn't refactor this properly.

To include all the functionality described above for this option, I have add functionality to FailureLocation and GatherTestInformation again, to include information about the classes where the errors occur (not just the test classes), as well as all the classes present in the stack trace of an error.

I propose #1185, which would enable this.

[andre15silva]

Sorald's version that was on the repository is no longer available. CI is failing because of that.

I'm adapting surli/failingProject to have NPEs that are fixable at the different levels of the scope, so we can have tests for them.

Apart from that it's ready.

[monperrus]

I'm adapting surli/failingProject to have NPEs that are fixable at the different levels of the scope, so we can have tests for them.

great. ping me back when it's done.

[andre15silva]

I'm having some issues with having NPEFix produce patches that change code that is outside the class where the error occurs (on a class that is in the stacktrace or a class that is in the same package).

My adaptation is here https://github.com/andre15silva/failingProject/tree/npefix-scope, and it has test cases that could be fixed by changing those files.

I traced this option back to Spirals-Team/maven-repair@44f2a2d.

@tdurieux, would it be possible for you to briefly explain/show an example where this would happen?

Thank you!

[tdurieux]

It could happen with silent NPE (catched NPE that NPEfix still try to fix) also the textual patch generation of NPEFix is not the most robust.
NPEfix is not designed to generate patches, it was meant to generate runtime patches and therefore the textual representation does not exist.

[andre15silva]

Issue opened.

Ready for review.

[monperrus]

Thanks a lot @andre15silva ! That's a big milestone, and we can now continue with Java 11 support.