Problem found in File#1 the fix needs to occur in File#2: - Example JDK 8->17: ejb-security - SecuredEJB.java - Analysis Hint is triggered on import from Java file and Hint suggests fix via pom.xml update

[jwmatthews]

Below is an example that may be interesting for us to consider.

As we ran the openjdk11 target against ejb-security, we saw one violation that has some trouble for us to address with our current approach. Namely the rule removed-javaee-modules-00020 is written to look for the presence of an import in the java code, then it recommends to fix via a pom.xml change.

Below is my understanding of how we will act as of 0.0.10:

• We will attempt to fix the incident from removed-javaee-modules-00020 in SecuredEJB.java
• We will ask the LLM to update SecuredEJB.java with the analysis info that essentially says be sure to update the pom.xml. As there are no changes required from analysis to SecuredEJB.java there is no work to do (in theory, sometimes we get confused and we get back a diff to trash SecuredEJB.java content and replace with a snippet of pom.xml)
• We will ignore any additional info the LLM returns about updates needed for pom.xml. (Could have some relation to Ability to consume and incorporate additional information from LLM that go beyond the immediate file being updated #131)

Ideally we would have a means to take this extra information into advisement and act on it.

Sample App:
https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.2.0.GA/ejb-security

Specific Rule:
https://github.com/konveyor/rulesets/blob/main/default/generated/openjdk11/192-removed-javaee-modules.windup.yaml#L53-L76

message: |-
    Add the `jakarta.annotation` dependency to your application's `pom.xml`.

     `<groupId>jakarta.annotation</groupId>`

     `<artifactId>jakarta.annotation-api</artifactId>`
  ruleID: removed-javaee-modules-00020
  when:
    java.referenced:
      location: IMPORT
      pattern: javax.annotation*