fix: [OData] Name mapping bug in NamingUtils

[rpanackal]

Context

• https://github.com/SAP/cloud-sdk-java-backlog/issues/498#issue-3698922103
• Service-Mapping.properties changed after generation a second time #1024

NamingUtils currently makes unintentional changes to the mappings in serviceNameMappings.properties
If the file name is API MATERIAL DOCUMENT SRV.edmx

First run:

• Input: "API_MATERIAL_DOCUMENT_SRV" (from .edmx filename)
• After transformations: "APIMaterialDocumentSrv"
• .replace("Api", ""): No match (looking for "Api", found "API")
• Resulting className: "APIMATERIALDOCUMENTSRV"
• Resulting packageName: "APIMATERIALDOCUMENTSRV".toLowerCase() = "apimaterialdocumentsrv"

Second run (re-processing stored value):

• Input: APIMATERIALDOCUMENTSRV for className and "apimaterialdocumentsrv" for packageName (from mapping)
• For packageName:
  • After transformations: "Apimaterialdocumentsrv"
  • .replace("Api", ""): MATCHES! Removes "Api"
  • Resulting packageName: "materialdocumentsrv" ❌
• For className, the same flow as first run -> no change

Even though the className stays consistent across runs, the result is semantically flawed since prefix "Api" is not removed.

Feature scope:

• Stay consistent across runs
• Remove "Api" case insensitively on both packageName and className
• Fix other prefixes as well which has the same issue

Definition of Done

• Functionality scope stated & covered
• Tests cover the scope above
• Error handling created / updated & covered by the tests above
• Documentation updated
• Release notes updated

[newtork]

(Major)

Wouldn't this match edge-cases like "SapInvoice"?
I would probably rather go with something like "A(pi|PI)" or straight up two lines.

Edit: I realize you changed the replacement from "anywhere in the string" to "only in the beginning". Therefore potentially bringing a breaking change for existing users that rely on "Api" being removed from their service name(?).

Which would be fine if we had a major release or sth.

[rpanackal]

Yes, It is breaking change.

My rational was, to be consistent across regeneration, we have three options

1. Always remove "Api"
   • breaking to users relying on Api
2. Always keep "Api"
   • breaking to users who have been regenerating with .edmx file updates.
3. Don't apply any transformations to mappings that are read from serviceNameMappings.properties
   • I didn't feel confident about removing this additional transformation as it might be a safety measure (?). But, it would be non-breaking.

What do you think about Option 3?

[rpanackal]

I didnt get your comment the first time. I have updated the regex.

[rpanackal]

It still is not edge-case free. Eg: "Apiary" would be matched. But this is unavoidable