On Fri, 21 Nov 2025 at 12:39, Stefan Bodewig <[email protected]> wrote:
> On 2025-11-16, Gintautas Grigelionis wrote: > > > Sorry for being unclear. I mean going back to PR 54 and taking another > look > > at it. > > Right now I am really only concerned with creating SBOMs and the changes > to ivy.xml made in your PR would help if Ivy could create SBOMs. As long > as Ivy doesn't (and as long as we don't enable it to) the change doesn't > help getting there. > > > Then, Ivy needs a task that uses cyclonedx-core-java and/or > > spdx-java-library. > > Right. Personally I'm not sure I have the time to create that and I'm > pretty sure I don't won't have the time maintaining it to keep up with > changes to CycloneDX or SPDX. > The changes to SBOM standards are handled in respective libraries (e.g. there seem to be different libraries for SPDX 2 and 3). Their APIs seem stable, though. It looks like IvyDependencyTree could be a suitable starting point. > I'd be very happy to defer dealing with the latest CISA policy changes > to the people who are actively involved in following the formats and > evolving the libraries we'd use. > It rather looks like there will be a push for harmonisation, in part thanks to CRA. We need to understand what the new minimum requirements will be, though. > > If that's too much of a hassle, Maven can easily provide another > > cop-out. But I'd argue that dependency management ought to be done > > properly in order to produce a proper SBOM. > > No argument with that, that's why all options I listed either dependend > on our existing Maven POMs which provide that or state we need to extend > the ivy.xml or come up with a one-off solution based on > libraries.properties. That latter would be completely sufficient for our > traditional tarball/zip releases as the artifact we'd be talking about > is "all of Ant". The smaller things we push to the maven central are > more complex IMHO. PR 54 in its current form aims to eliminate fetch.xml (except maybe for special logic around the ancient netrexx if that artifact can no longer be resolved -- pity JFrog sunset their repository service; it would bite us in the back, though, if we cannot represent it as pURL which is a requirement by SBOM ;-). Can we drop netrexx or try a newer version? Pity I have no access to a mainframe anymore :-( I'd like to have a look at the release/upload part, there may be extra work. Agreed on SBOM targeting "all of Ant". Gintas
