On 2026-08-07, Stefan Bodewig wrote:

> Some differences are easy to explain and I'm fine with them:

> * jackson-core's SBOM lists a dependency on fastdoubleparser that is
>   actually shaded away by Maven and not visible in the POM (and thus not
>   visible to Ivy)

> * Ivy's own SBOM contains all optional dependencies - since
>   ant-antlibs-cyclondedx doesn't depend on the optional dependencies
>   they don't appear in the "new" SBOM.

> * the Maven generated SBOMs contain publisher fields and external
>   references that are (currently not available) from Ivy files.

> * licenses uses names instead of SPDX ids

> But there are differences I'm not happy with and which must be related
> to the way I identify dependencies.

> In the Ivy generated SBOM ivy doesn't seem to depend on Ant and
> commons-collections doesn't seem to depend on commons-codec anymore. I
> believe this is because the Antlib directly depends on them.

In the case of commons-collections this is because commons-collections'
dependency on commons-codec is optional in 4.5.0.

The same is true for Ivy's dependency on Ant which is also optional - at
least as far as the POM is concerned, I'm not sure this is true in
reality.

So these are the second cases of the "I'm fine with" list and I now
believe the code does what it is supposed to do. I still need to write
tests and document it.

I'd be grateful if people who know more about Ivy than I do could look
over
https://github.com/apache/ant-antlibs-cyclonedx/blob/support-ivy-as-component-source/src/main/org/apache/ant/cyclonedx/IvyModuleComponentResolver.java
and tell me what could be done better or what just works because the
only thing I have tested it on so far has been something simple.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to