Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow project-specific customization #90

Open
raboof opened this issue Nov 14, 2024 · 2 comments
Open

Allow project-specific customization #90

raboof opened this issue Nov 14, 2024 · 2 comments

Comments

@raboof
Copy link
Contributor

raboof commented Nov 14, 2024

It would be good to provide projects with a way to make project-specific customizations to the Bom object, so we allow them to express facts about the software that are not picked up automatically yet (such as embedded/shaded artifacts).

Maybe we can refactor things so that creating the Bom object is a separate sbt task, that can then be overridden in the project, so the customized Bom object is picked up by the configuration that adds it to the published artifacts.

raboof added a commit to raboof/sbt-bom that referenced this issue Nov 14, 2024
We'll likely want to refactor the task structure when we
implement sbt#90 or sbt#91, it might be nice to explicitly set
expectations around this without making it a blocker for
doing earlier releases.
raboof added a commit to raboof/sbt-bom that referenced this issue Nov 14, 2024
We'll likely want to refactor the task structure when we
implement sbt#89, sbt#90 or sbt#91, it might be nice to explicitly
set expectations around this without making it a blocker
for doing earlier releases.
raboof added a commit to raboof/sbt-bom that referenced this issue Dec 12, 2024
We'll likely want to refactor the task structure when we
implement sbt#89, sbt#90 or sbt#91, it might be nice to explicitly
set expectations around this without making it a blocker
for doing earlier releases.
@lhns
Copy link
Contributor

lhns commented Jan 8, 2025

Do you think of modelling our own Bom object or exposing the cyclonedx Bom object to the user?
The first option would pobably make it format-agnostic and it would be easier to support spdx in the future.

@raboof
Copy link
Contributor Author

raboof commented Jan 8, 2025

Good question. I could see value in either: indeed having our own Bom object is useful when making changes that should apply to both CycloneDX and (later) SPDX, but hooking into the upstream data structures would allow more fine-grained format-specific tweaks. If we end up implementing SPDX support (#89) with https://github.com/spdx/cdx2spdx then updates to the CycloneDX might also affect SPDX.

As this is a poweruser feature I'd be OK with not committing to any particular API yet and just doing 'the simplest thing that could possibly work', knowing we can refactor it later.

raboof added a commit that referenced this issue Jan 8, 2025
We'll likely want to refactor the task structure when we
implement #89, #90 or #91, it might be nice to explicitly
set expectations around this without making it a blocker
for doing earlier releases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants