WIP Refactor: Unify encapsulation of Nopol

[andre15silva]

Will close #1137 .

[monperrus]

Looks good overall @andre15silva ! Let's now have a green CI :)

[andre15silva]

@monperrus After evaluating several options and trying to understand how this refactor can be designed in a good way, I came up with the following solution:

• Create a MavenProjectInspector and RunInspector4Maven.
• Have each maven-repair Mojo call the above classes, triggering the corresponding tools. This way all Mojos are the same, apart from parameters and repair tool names.

The other options considered were having each Mojo call each respective Step (whether a static method for the tool itself or the actual execute method) , but that doesn't provide a very clean approach to handling configuration options IMO.

WDYT about this design path?

[andre15silva]

I've been following the path I proposed on the comment above, but I'm now stuck on a weird bug when running Nopol through maven-repair.

[ERROR] [Compilation errors]
StringUtils.java:11: error: package instrumenting does not exist
instrumenting._Instrumenting.isPassedThrough("org.apache.commons.lang.StringUtils", 168);
^
StringUtils.java:15: error: package instrumenting does not exist
instrumenting._Instrumenting.isPassedThrough("org.apache.commons.lang.StringUtils", 192);

This happens when executing the step NopolRepair, more specifically when calling nopol.build(). I do not get this error when running Nopol through repairnator-pipeline.

Do you have any clue what might be causing this?

To reproduce the bug:

$ cd repairnator
$ mvn clean install -DskipTests
$ mvn install:install-file -Dfile=<path-to-maven-repair-jar> -DgroupId=fr.inria.gforge.
spirals -DartifactId=repair-maven-plugin -Dversion=1.6-SNAPSHOT -Dpackaging=jar -DpomFile=<path-to-maven-repair-pom>
$ cd ../nopol-experiments/dataset/cl5
$ mvn fr.inria.gforge.spirals:repair-maven-plugin:1.6-SNAPSHOT:nopol -X

[andre15silva]

Also, due to Nopol being loaded through a profile in repairnator-pipeline there is no transitivity for this dependency to maven-repair, hence the duplication of the profiles in this module. See MNG-1338

[monperrus]

Good progress, this design is good.

Do you have any clue what might be causing this?

A classpath problem. AFAIR, this is due to using the "Cocospoon" fault localization mode in Nopol. What happens if we use the GZoltar mode?

[andre15silva]

A classpath problem. AFAIR, this is due to using the "Cocospoon" fault localization mode in Nopol. What happens if we use the GZoltar mode?

I get this error trace

[ERROR] Got runtime exception while running Nopol
java.lang.NullPointerException
at com.gzoltar.core.GZoltar.run (GZoltar.java:51)
at fr.inria.lille.localization.GZoltarFaultLocalizer.run (GZoltarFaultLocalizer.java:163)
at fr.inria.lille.localization.GZoltarFaultLocalizer. (GZoltarFaultLocalizer.java:94)
at fr.inria.lille.localization.GZoltarFaultLocalizer. (GZoltarFaultLocalizer.java:68)
at fr.inria.lille.localization.GZoltarFaultLocalizer.createInstance (GZoltarFaultLocalizer.java:60)
at fr.inria.lille.repair.nopol.NoPol.createLocalizer (NoPol.java:178)
at fr.inria.lille.repair.nopol.NoPol.build (NoPol.java:130)
at fr.inria.spirals.repairnator.process.step.repair.nopol.NopolRepair$1.call (NopolRepair.java:188)
at fr.inria.spirals.repairnator.process.step.repair.nopol.NopolRepair$1.call (NopolRepair.java:183)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:624)
at java.lang.Thread.run (Thread.java:748)

I have the dependency gzoltar loaded, so I don't know why this is happening.

[monperrus]

I see. Also a classpath problem.

Debugging classpath and fault localization in Nopol is out of the scope of this PR ('Unify repair tools encapsulations').

What about about having a first working and merged POC with the other repair tools (SequenceR/NpeFix)?

[andre15silva]

I see. Also a classpath problem.

Debugging classpath and fault localization in Nopol is out of the scope of this PR ('Unify repair tools encapsulations').

What about about having a first working and merged POC with the other repair tools (SequenceR/NpeFix)?

Ok, sounds good! I'll work on NPEFix first and then SequenceR.

[monperrus]

Very good. Let's do the unification one repair tool at a time. NpeFix is a great one to start with.

[andre15silva]

I encountered another problem, now with NPEFix. I already moved all of the logic to repairnator-pipeline but I'm not being able to get NPEFix to produce a patch.
The partial unification is in https://github.com/andre15silva/repairnator/tree/unify-npefix.
I'm testing with https://github.com/Spirals-Team/npe-dataset/tree/master/lang-304. To reproduce the bug use the same commands as above in Nopol replacing nopol by npefix.

I then ran maven-repair by itself, the version on https://github.com/eclipse/repairnator/tree/master, and the same problem occurs. Trace below:

(...)
org.apache.commons.lang.LocaleUtilsTest#testCountriesByLanguage
Status: Ko
org.apache.commons.lang.LocaleUtilsTest#testConstructor
Status: Ok
org.apache.commons.lang.LocaleUtilsTest#testToLocale_1Part
Status: Ok
org.apache.commons.lang.LocaleUtilsTest#testToLocale_2Part
Status: Ok
org.apache.commons.lang.LocaleUtilsTest#testToLocale_3Part
Status: Ok
org.apache.commons.lang.LocaleUtilsTest#testLocaleLookupList_Locale
Status: Ok
org.apache.commons.lang.LocaleUtilsTest#testAvailableLocaleList
Status: Ok
Multirun 100/100 100%
/home/andre/Repos/npe-dataset/lang-304/target/test-classes/:/home/andre/Repos/npe-dataset/lang-304/target/classes/:/home/andre/.m2/repository/junit/junit/4.7/junit-4.7.jar:/home/andre/Repos/npe-dataset/lang-304/target/npefix/npefix-bin/:/home/andre/.m2/repository/fr/inria/gforge/spirals/npefix/0.7/npefix-0.7.jar
/home/andre/Repos/npe-dataset/lang-304/target/npefix
org.json.JSONException: JSONObject["executions"] not found.Since we have surefire plugin configure to true, to automatically trigger NPEFixWe don't break the build for errors during the build, continue.

Now, when I try to use maven-repair 1.5.1 it works and generates a patch. Do you have any idea why 1.5.1 works but the current version in https://github.com/eclipse/repairnator/tree/master does not?

[monperrus]

Renamed this PR and moving the conversation to #1153

[eclipse-repairnator-bot]

Can one of the admins verify this patch?