Expose non-pretty printed XML generation#873
Conversation
BomXmlGenerator has the ability to generate non pretty printed XML on a package private method but this was not exposed on the public API as it was for BomJsonGenerator. The non pretty printed code path for JSON generation was not actually exercised in tests so modified some existing generator tests to verify that non pretty printed output is smaller. When modifying the equivalent XML generation tests found that the equivalent test case wasn't actually exercising XML generation so fixed that which exposed a bug in how the XML generator serialized properties which was leading to JsonMappingException's from Jackson. That bug is also fixed with this commit. Signed-off-by: Rob Vesse <rob.vesse@telicent.io>
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
🟢 Coverage 100.00% diff coverage · +0.10% coverage variation
Metric Results Coverage variation ✅ +0.10% coverage variation Diff coverage ✅ 100.00% diff coverage Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (39ce872) 7675 5731 74.67% Head commit (f6267da) 7675 (+0) 5739 (+8) 74.78% (+0.10%) Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#873) 4 4 100.00% Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
| // NB - In this context Jackson already knows we're producing <property> elements so no need to explicitly try and | ||
| // write the property field name otherwise we end up with malformed XML with double wrapped <property> elements | ||
| for (Property property : properties) { | ||
| SerializerUtils.serializeProperty("property", property, xmlGenerator); | ||
| SerializerUtils.serializeProperty(null, property, xmlGenerator); | ||
| } | ||
| xmlGenerator.writeEndArray(); |
There was a problem hiding this comment.
Can we separate this into another PR please? Glad you found this, but making it a drive-by fix in a feature PR makes it hard for others to understand changes in the next version.
2 participants
Context
CycloneDX SBOMs contain a lot of information (by design) which for small modules with large dependency trees can actually lead to the SBOM being the largest artefact in a module by some margin. With Maven Central planning to bring in publishing limits we've been deep auditing what our open source releases produce to reduce unnecessary publishing and try to keep within the proposed size limit (80MB/month) as much as possible.
Once we eliminate the more obvious things that we shouldn't be publishing to Maven Central (e.g. fat JARs for local dev testing/tools,
testsJARs for modules with no reusable test harnesses etc.) the SBOMs remain the largest contributor to release size. For example on one large multi-module repository the SBOMs are the biggest artefact for over half of our modules and represent approximately 1/3 of total released bytes.If we were able to generate non-pretty printed versions of the SBOMs (since ultimately SBOMs are for machine/tool consumption anyway) then some basic testing with tools like
jqshows we could save up to 150 kilobytes per SBOM. For a large multi-module project that adds up to megabytes of savings, which when we're talking about an 80MB/month publishing limit is not insignificant. We use the Cyclone DX Maven Plugin, which in turns uses the library from this repository so the first step in exposing this capability in the plugin is to expose it in the library. See related PR CycloneDX/cyclonedx-maven-plugin#668This PR exposes that capability in the API where it wasn't previously exposed and ensures that there are more tests exercising the non-pretty printing code path.
Code Changes
BomXmlGeneratorhas the ability to generate non pretty printed XML on a package private method but this was not exposed on the public API as it was forBomJsonGenerator.BomXmlGeneratorgains atoXmlString(boolean prettyPrint)method to expose this.In investigating noted that the non-pretty printed code path for JSON generation was not actually exercised in tests so modified some existing JSON generator tests to verify that non-pretty printed output is smaller.
When modifying the equivalent XML generation tests found that the equivalent test case wasn't actually exercising XML generation at all so fixed that which exposed a bug in how the XML generator serialized properties which was leading to
JsonMappingException's from Jackson. That bug is also fixed with this commit.