Split the project into separate crates to support reuse

[amy-keibler]

Right now, the project is published under a single crate cyclonedx-sbom. The dependencies required for the full functionality of the CLI result in a very large dependency tree and large compile times (mostly due to the dependency on cargo due to some things not being available via cargo_metadata).

We should split the project into two crates:

• cyclonedx-sbom: A lightweight library that implements the specification and provides small utilities (e.g. proposed merge algorithm implementations would live here)
• cargo-cyclonedx: The current functionality, but structured in a way that makes the library easy to integrate with other rust applications and makes the binary as the first-party implementation on top.

Proposed Approach

• Preparation
  • Reserve the cargo-cyclonedx crate
  • Set up the cdx-automation user with publish access to that crate
• Restructuring
  • Create a workspace and move the existing code to cargo-cyclonedx/
  • Update CI and publishing to work
• Library-ification
  • Implement the specification library
    • Create an internal model that will be the public API for use by cargo-cyclonedx and other Rust applications
    • Create a private model of every version of the specification that supports serialization and deserialization (can this be auto-generated?)
    • Create the mapping between the public and private models
    • Create utility functions to deserialize from any version of the specification, serialize as the latest version, and serialize as a specific version
    • Support validation (perhaps via something like Keats/validator
  • Set up CI
    • Ensure the tests run on PRs and pushes
    • Set up the publish GitHub actions to handle releasing the library (this should Just Work with the publish crates action we currently use, but more research needs to be done to determine specifying major / minor / patch versions.
• Documentation
  • README.md for each crate
  • Top level readme
  • Rustdoc

Concerns

• This will change the cargo install command and might cause problems with users who have already installed the CLI tool
• This will break anyone using our code as a library. This is permissible under SemVer (reference) and we have zero public reverse dependencies, but might not be appreciate
  • We should look into ways to mitigate this in general by having a public channel for comments that our users can watch for updates
  • This would definitely be at least a minor version increase, but we could also consider releasing a 1.0.0 version

[amy-keibler]

Work on this is underway in the library-ification branch for anyone who would like to follow along

[lfrancke]

I know this is an old issue but do you happen to remember what's not available via cargo_metadata?

[lfrancke]

I think this can be closed as it's been done. Any objections?

@Shnatsel opinions?