Spike: investigate the use of BOMs

[paullatzelsperger]

Feature Request

For the convenience of downstream projects we want to explore the possibilites that BOMs (Bills of material) would give us.
This issue really is about figuring out, what BOMs make sense at all.

Which Areas Would Be Affected?

build

Why Is the Feature Desired?

Developers, who embed EDC in their java application, or who simply want to create a launcher, now have to list all dependencies explicitly, which may be a bit cumbersome at times.

Instead, it would be nice if only a few dependencies were needed.

Solution Proposal

As a starting point, we should look into

• a core BOM
• a Postgres BOM
• a CosmosDB BOM
• an IDS BOM (partly exists already)
• a Federated Catalog BOM (partly exists already)

Acceptance Criteria

a decision-record must be created to reflect the investigation and the outcome.

Type of Issue

spike

Checklist

• assigned appropriate label?
• Do NOT select a milestone or an assignee!

[ndr-brt]

I'd suggest to tackle this after the project structure review (#1596), since we're gonna to divide modules by "components", the BOMs could be related to the components themselves.

[paullatzelsperger]

moved to Milestone 6.

[ndr-brt]

With the last project structure review I think this became more clear.
There should be a base BOM for every component, currently they are: control-plane-core, data-plane-core, data-plane-selector-core and federated-catalog-core.

On these, the component can be customized adding the needed extensions.

Other kind of BOMs could be to provide a set of extensions based on some common "type", e.g. control-plane-sql and control-plane-cosmos.

Maybe to complete this issue I could provide a piece of markdown that describes the components and show how to use the BOM to build them.

[paullatzelsperger]

@ndr-brt sorry I completely overlooked this issue. The BOMs you describe sound reasonable to me, absolutely.