Clarify CLIXML support path vs existing CLIParser contract

[agastya-kataria]

Context

I am working on a GSoC proposal around CLIXML support / visualization and wanted to first validate how CLIXML is expected to integrate into the current SW360 license-info pipeline before proposing implementation details.

Rather than starting with assumptions, I traced the existing backend flow and verified the parser module locally.

---

Verified backend path

From attachment ingestion to REST exposure, the relevant flow appears to be:

• AttachmentHandler
• LicenseInfoHandler
• CLIParser / AbstractCLIParser / CombinedCLIParser
• Sw360LicenseInfoService
• ReleaseController

Parser selection is handled via isApplicableTo(...), and XML attachments are routed through the existing license-info infrastructure.

---

Parser contract (current behavior)

From reviewing the parser implementations:

• CLIParser accepts XML where the root element is ComponentLicenseInformation
• CombinedCLIParser accepts XML where the root element is CombinedCLI
• LicenseInfoHandler selects parsers based on applicability and attachment type

---

CLIXML signal in the repository

I found a reference to a CLIXML-named attachment in:

• ProjectSpecTest (attachment: CLIXML_core-js.xml, typed as COMPONENT_LICENSE_INFO_XML)

However:

• I could not locate an actual CLIXML payload under test resources in this checkout
• So I could not yet validate whether CLIXML structure matches the existing parser contract

---

Environment verification

To ensure this wasn’t just a setup limitation:

• I verified the parser module builds successfully using Java 21 + Maven + Thrift
• Ran CLIParserTest successfully:
  • Tests run: 6, Failures: 0, Errors: 0

So the parser path itself is reproducible and ready for extension once a valid input is available.

---

Why this matters

Before implementing anything, the key question seems to be:

Does CLIXML structurally fit the existing CLI parser contract, or does it require a dedicated parser?

Without a representative CLIXML sample, it’s unclear whether:

• this is primarily a frontend/viewer problem, or
• a backend parsing extension problem

---

Clarification requested

1. Is CLIXML expected to extend the existing CLIParser / CombinedCLIParser path if the structure is compatible?

2. Or should CLIXML support be implemented as a separate parser from the beginning?

3. Is there a representative CLIXML sample file or fixture that contributors should use to validate parser compatibility?

4. Is the intended viewer/UI for this feature located in this repository or in a separate frontend project?

---

Goal

I want to scope the proposal correctly (backend vs viewer vs both) and avoid proposing unnecessary or misaligned changes.

Happy to proceed with a concrete spike (parser test or implementation) once the intended direction is clarified.

[iAbhiNaV2005]

Can you assign it to me

[agastya-kataria]

I am working on it