Description
Currently, library stakeholders are using ocm v1 transfer. If we want to migrate those library stakeholders to ocm v2, we need to offer them equivalent functionality.

To offer the transfer functionality as a library function, we need to:

• Introduce a new module (eventually called transfer).
  • We do not want to put the transfer behaviour into the transform module, as the transfer behaviour eventually needs to know (and therefore import) all the ocm repository and artifact storage technologies.
• Factor out and move the functionality of the cli function TransferComponentVersion into the new module. That includes
  • the functionality for pre-fetching the component version
  • the functionality for building the TGD (BuildGraphDefinition) based on the pre-fetched component version
  • the functionality for statically evaluating the TGD (BuildAndCheck())
  • the functionality for processing the graph (Process())

The transform module should offer a function with roughly the following interface

func TranferComponentVersion(component, version string, transferOpts ...Option)

Since we do not have our transfer configuration in place yet, this API is likely to be subject to significant change. We should cautious about exposing low level primitives (such as the graph building) as public API for now. We might even want to consider labelling this API as experimental for now.

Optional Questions

• What do we need to support compared to v1?
  • Similar to what we need for cli transfer compared to v1

Done Criteria

• Code has been reviewed by other team members
• Analysis of existing tests (Unit and Integration)
• Unit Tests created for new code or existing Unit Tests updated
• Integration Test Suite updated (includes deletion of existing unnecessary Integration Test and/or creation of new ones if required)
• Enduser Documentation updated (if applicable)
• Internal technical Documentation created/updated (if applicable)
• Successful demonstration in Review