You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Nested cyclonedx.model.dependency.Dependency not serialized to JSON #941
I stumbled upon this when trying to process external BOMs for further analysis with only looking at the type hints, while I have not been able to build a BOM myself which would actually trigger this after serialization.
changed the title [-]cyclonedx.model.dependency.Dependency claims to be nestable, although not serialized[/-][+]Nested cyclonedx.model.dependency.Dependency not serialized to JSON[/+]on Mar 4, 2026
could you elaborate on the topic? what is the question/issue here? what is your exact use case?
I have a BOM importer and wrote some tests where I used the XML-only Python-structure for JSON by mostly looking at the attributes exposed by the different classes. This worked without any warning and can lead to data loss. I would (at least) have expected to receive a warning or error on serialization about this being not supported for JSON.
could you elaborate on the topic? what is the question/issue here? what is your exact use case?
I have a BOM importer and wrote some tests where I used the XML-only Python-structure for JSON by mostly looking at the attributes exposed by the different classes. This worked without any warning and can lead to data loss. I would (at least) have expected to receive a warning or error on serialization about this being not supported for JSON.
Ah, i see. the topic is not modeling, but conversion.
Possible solutions I see:
have a 'contrib' module that flattens a dependency graph's data models
or have this flattening as part of JSON serialization transparently.
I did not yet have any further thoughts about the best solution for this case, as my testing (luckily) showed this rather quickly, although it took me some time to further debug this.
The problem I see with a contrib module possibly being required to be called for flattening wouldn't be obvious for me. Thus I would rather see this being flattened automatically or detected automatically with a hint to the contrib function, preventing unexpected data loss in the first place due to "conflicting" serializiation options.
Activity
jkowalleck commentedon Mar 4, 2026
have you tried it? could you pull-request a test setup that has any issues?
tests go here: https://github.com/CycloneDX/cyclonedx-python-lib/blob/main/tests/_data/models.py
stefan6419846 commentedon Mar 4, 2026
I will have a look at possibly preparing a PR for this tomorrow. For now, this is some reproducing code based upon
complex_serialize.py:JSON output is this, with nothing depending on
some-library:{ "components": [ { "bom-ref": "myComponent@1.33.7-beta.1", "group": "acme", "name": "some-component", "type": "library", "version": "1.33.7-beta.1" }, { "bom-ref": "some-library", "name": "some-library", "type": "library" } ], "dependencies": [ { "dependsOn": [ "myComponent@1.33.7-beta.1" ], "ref": "myApp" }, { "ref": "myComponent@1.33.7-beta.1" }, { "ref": "some-library" } ], "metadata": { "component": { "bom-ref": "myApp", "name": "myApp", "type": "application" }, "timestamp": "2026-03-04T17:33:26.085743+00:00" }, "serialNumber": "urn:uuid:9c7da534-f964-4d74-a09e-9c5770262989", "version": 1, "$schema": "http://cyclonedx.org/schema/bom-1.7.schema.json", "bomFormat": "CycloneDX", "specVersion": "1.7" }The XML looks correct (
myComponent@1.33.7-beta.1referencingsome-library):[-]cyclonedx.model.dependency.Dependency claims to be nestable, although not serialized[/-][+]Nested cyclonedx.model.dependency.Dependency not serialized to JSON[/+]jkowalleck commentedon Jun 8, 2026
looking at #942
i can not see any issues.
The test data looks about right:
this means:
you are correctly able to model the dependency graph according to CycloneDX XML and JSON implementation/schema.
@stefan6419846 , could you elaborate on the topic? what is the question/issue here? what is your exact use case?
stefan6419846 commentedon Jun 8, 2026
I have a BOM importer and wrote some tests where I used the XML-only Python-structure for JSON by mostly looking at the attributes exposed by the different classes. This worked without any warning and can lead to data loss. I would (at least) have expected to receive a warning or error on serialization about this being not supported for JSON.
jkowalleck commentedon Jun 8, 2026
Ah, i see. the topic is not modeling, but conversion.
Possible solutions I see:
have a 'contrib' module that flattens a dependency graph's data models
or have this flattening as part of JSON serialization transparently.
did you have a solution in mind already?
stefan6419846 commentedon Jun 8, 2026
I did not yet have any further thoughts about the best solution for this case, as my testing (luckily) showed this rather quickly, although it took me some time to further debug this.
The problem I see with a
contribmodule possibly being required to be called for flattening wouldn't be obvious for me. Thus I would rather see this being flattened automatically or detected automatically with a hint to thecontribfunction, preventing unexpected data loss in the first place due to "conflicting" serializiation options.jkowalleck commentedon Jun 8, 2026
understood.
will work on a fix .