Add design for fetching maven artifacts

[kosciCZ]

Hey folks, this is an followup to #652, which extends generic fetching with the support for maven artifacts. I've tried to roughly outline how this will work and how it will integrate with other cachi2 features. Let me know what you think.

Maintainers will complete the following section

• Commit messages are descriptive enough
• Code coverage from testing does not decrease and new code is covered
• Docs updated (if applicable)
• Docs links in the code are still valid (if docs were updated)

Note: if the contribution is external (not from an organization member), the CI
pipeline will not run automatically. After verifying that the CI is safe to run:

• approve GitHub Actions workflows by clicking a button
• approve the Red Hat Trusted App Pipeline container build by commenting /ok-to-test
  (as is the standard for Pipelines as Code)

[a-ovchinnikov]

Thank you for the example! There is no mention of a lock file here. Does this mean that a lock file will always reside in same location? Is there an agreement on where to put it and who would do that?

[kosciCZ]

At this time, yes. The generic lockfile is assumed to be present in the root of the cloned input repository. Here's a link to the code

[a-ovchinnikov]

Who will put it there?

[kosciCZ]

Not sure I understand where this question is going. It should be commited directly in the repository. An user that wants to use cachi2's maven artifact feature would do that

[brunoapimentel]

Maybe we need to add a 3rd option here (or change the 2nd): have a separate lockfile, even if it follows the same format as the generic one. That was what I envisioned at first, and the reason is that I don't think we want folks extending the generic fetcher to cover specific use cases.

So I think the bulk of the discussion here is: how extensible we want generic to be? If we are fine with some special cases (we can't be sure maven will be the only one), then I'd say option 1 is fine. Otherwise, we might want a fully separate package manager.

[kosciCZ]

In my opinion, the part that changes is:

• how you compute the download url (meaning, the list of accepted purl types might be expanded later)
• what the output SBOM component is (depends on the above)

So I'd argue that since the underlying mechanism does not change, it should stay as one package manager.