Analysis of samples with modules appears to be bugged

[JonahSussman]

I think something in Kantra or something related to analyzing Java apps with multiple modules is currently bugged.

I was checking out the ejb-remote sample recently, trying to make headway in incident pattern recognition. I manually looked through the initial and final analysis runs and saw the following:

• cloud-readiness had some matches, but they all appeared to be simple textual matches looking for variants of http://localhost/. These were even present in the Quarkus version. Not sure how useful these are.
• quarkus/springboot had a ton of matches. However, all of them were for the pom.xml, and most of them remained unsolved after the migration to Quarkus. Again, unsure of usefulness.
• Most rules in the rule sets came back unmatched or skipped. Not surprising.
• Unfortunately, this also applied to kai/quarkus. It looks like at least remote-ejb-to-quarkus-00000 should have triggered, but it didn't

This is quite strange because there's another version of this file in the notebooks directory that has a bunch of matches for kai/quarkus. I tried manually running Kantra on the ejb-remote project again, thinking it was an issue with the generated report, but still none of the kai/quarkus rules matched.

I think this has something to do with Java rules and there being multiple modules in the ejb-remote project. Looking at the other examples, similar-looking Java rules trigger just fine. In fact, I modified the cmt project to try and trigger this rule, and it indeed did.

The strangest thing is that the analysis used to work and now doesn't. Thoughts?

---

GitHub isn't allowing me to attach .yaml or .patch files, so here they are as .txt files.
patch-to-cmt.patch
cmt-new-output.yaml

[JonahSussman]

Something to be aware of is that it seems Kantra generates URIs with the prefix file:///opt/input/source/, not file:///tmp/source-code/ like it used to. Thus, if we generate the reports again, we'll probably need to update how we ingest it. Additionally, it would be good if we added --skip-static-report to the analyze_apps.py script.

[JonahSussman]

This was the report result from back then, and this is the ejb-remote app

[shawn-hurley]

After testing this, I have found a couple of things:

1. That the repo as is (ejb-remote) expects to have a parent pom in a specific location, probably because we copied it out of a directory where the parent pom was at the level above. if you update the pom to:

    <parent>
        <groupId>org.jboss.eap.quickstarts</groupId>
        <artifactId>quickstart-parent</artifactId>
        <!--
        Maintain separation between the artifact id and the version to help prevent
        merge conflicts between commits changing the GA and those changing the V.
        -->
        <version>7.4.0.GA</version>
        <!--<relativePath>../pom.xml</relativePath>-->
    </parent>

and create in the directory and files in the .m2 repo pulling from here all the files.

Then when you run analysis, things work correctly.

when the parent poms are failing to resolve the language server is unable to create search scopes for the modules and therefore is unable to find anything.

I am going to close this bug, but wanted to lay out where the issue was and what we would need to do to solve.

If we think that we should leave this up, and add checks around this scenario so that we can expose these issues to the end user, we can re-open, reprioritize and re-name/change the text of the issue.