Generating project/component SBoM data corresponding SPDX

[KoukiHama]

Description

Now SW360 can import SPDX, but can not export. For realizing it, we need to consider some points like following quotes and comments. If anyone have any concern or advice or comment, please let me know, it would be helpful.

Maybe, at first, we need to compare SW360 items with SPDX items, and consider output format

864

I think regarding the multiple formats, this maybe need input how this can be done. My personal preference would be to use SPDX (with multiple formats) and then use comments in SPDX to add clearing information Originally posted by @mcjaeger in https://github.com/eclipse/sw360/issues/1073#issuecomment-745120203

Comments in slack
generation of the sdpx for BOM is not supported so far, so were looking for contributions to this regard

cf. SPDX one page, and SPDX 2.2

By the way, spdx importing has issue #108.

Steps followed and expected result

Project -> License clearing -> SPDX export

Screenshots

[KoukiHama]

Memo: Other SPDX SBOM generator which we can refer. https://sbom.democert.org/sbom/ https://github.com/CERTCC/SBOM/tree/master/sbom-demo

[mcjaeger]

maybe that would be the opportunity to do the export of SPDX BOM right with the new library from the SPDX project and then we could phase out the classic one: https://github.com/spdx/tools I think it could be good to be with YAML and JSON on the long run instead of RDF: https://github.com/spdx/Spdx-Java-Library

[mcjaeger]

The generator at https://sbom.democert.org/sbom/ seem to be on package level and not on file level. however, I find that that would be a super good first step and maybe the file level description shall be separate files for each package so the handling would be better (instead of attempting to generate one large file)

[KoukiHama]

There are variety of spdx format and these example exist in

https://github.com/spdx/spdx-spec/tree/development/v2.2.1/examples

https://github.com/spdx/tools-java/tree/master/testResources

I agree export json format / yaml format is best in the long run. And, as a first step, I think export tag format or spread sheet format is also good, because it may be easy to develop.

309 mention about export format

[KoukiHama]

Need to consider SPDX Attribution comatibility #864

cf: https://github.com/spdx/spdx-spec/issues/163 https://github.com/fossology/fossology/issues/1603

[dineshr93]

@KoukiHama @mcjaeger One note on Yaml that i observed I downloaded a fossology generated rdf file for one of big component release boost from the sw360 & performed the rdf to yaml conversion using the spdx-tools-java

using command

rdf to yml: java -jar tools-java-0.0.6-jar-with-dependencies.jar Convert SPDX2_boost_1_59_0.zip_1611659988-spdx.rdf boost.yaml

rdf to json: java -jar tools-java-0.0.6-jar-with-dependencies.jar Convert SPDX2_boost_1_59_0.zip_1611659988-spdx.rdf bosst.json

both are spdx-2.2

The conversion was successful. Check the size difference below. I guess Yaml is very memory efficient & puts very less load on the tool as well while processing the data. SW360 struggles to generate the notice file for us from rdf file currently issues/1011. May be yaml processing could be a solution on its efficiency (saves almost 50 mb in terms of storage definitely there will be increase in processing speed as it is a dictionary format)

[KoukiHama]

I compared SW360 relationship with SPDX relationship.

SPDX relationship definition is complicated … But their definition is clearer than sw360's ones.

https://github.com/eclipse/sw360/wiki/User-Data-Model-Enumerations#release-relationship

https://spdx.github.io/spdx-spec/7-relationships-between-SPDX-elements/

[dineshr93]

@KoukiHama Also if you noticed, Currently There is disconnect between the data it fetches from spreadsheet & from its License info .

this "Export BOM" should get data both from rdf(copright & licenses) and from component release UI elements(name, version , homepage url, download url etc) project ui elements (linkage, comments. File path etc..)..

[dineshr93]

just sharing this for future proof the sw360 w.r.t sbom creation https://www.zdnet.com/article/linux-and-open-source-communities-rise-to-bidens-cybersecurity-challenge/ from https://www.ntia.gov/files/ntia/publications/sbom_options_and_decision_points_20210427-1.pdf It seems 3 SBOM Formats are approved for use: SPDX, CycloneDx, SWID

[KoukiHama]

I've been reviewing Nita's pdf files as well.

Next week at telco, a colleague of mine will be sharing his thoughts on how SPDX output can be achieved with SW360.

[KoukiHama]

Comparing SW360 (Component/release) and SPDX 3.1 - 3.23

cf. SPDX 2.2

Compare_SPDX_SW360.md

SPDX Packages	SPDX Mandatory	SPDX Lite	SW360 component	SW360 release
3.1 Package Name	X	X	Component name
3.2 Package SPDX Identifier Id	X	X	id?	id?
3.3 Package Version		X		version
3.4 Package File Name		X		source code attachment file name
3.5 Package Supplier		vendor short name
3.6 Package Originator
3.7 Package Download Location	X	X		source code download URL (opposed to binary download URL)
3.8 Files Analyzed		X
3.9 Package Verification Code	X
3.10 Package Checksum				sha1 of source code attachment
3.11 Package Home Page		X	homepage
3.12 Source Information
3.13 Concluded License	X	X	Main license	Main license
3.14 All Licenses Information from Package	X			Other license
3.15 Declared License	X	X
3.16 Comments on License		X
3.17 Copyright Text	X	X		from SPDX attachment
3.18 Package Summary Description			description
3.19 Package Detailed Description
3.20 Package Comment		X
3.21 External Reference
3.22 External Reference Comment
3.23 Package Attribution Text

---

SW360 have field but SPDX have not ?

• CPE ID
• Release Date of this Release
• Created on
• Created by
• Contributors
• Moderators
• Subscribers
• Additional Roles
• Source Code Download URL
• Binary Download URL
• Clearing State
• Release Mainline State
• Programming Languages
• Operating Systems
• External ids
• Additional Data
• Full Name
• Short Name
• URL

[shi9qiu]

I am considering should the SPDX format be treated as an entirety. Because the SPDX is a "standard", which means only when the required fields are recorded, it can be called "SPDX". But in industry, some fields may not be satisfied easily such as "File information".

To balance this problem, SPDX provides a simple version called SPDX Lite. Apart from the Package Information, only a few fields are needed to satisfy the requirements of SPDX Lite, and all these fields can be generated automatically based on the previous set rules in my opinion.

So I wonder maybe SPDX Lite could be a good choice here?

Here is a simple ui for example.

[KoukiHama]

1143 is related with this issue.

After adding items to sw360 for SPDX, all SPDX data should be imported.

[KoukiHama]

@shi9qiu Creating "SPDX format" tab in release pages like your image is good idea, but this issue should focus on generating SPDX file. Therefore, I made new issue #1240 with enhancement label for clearance.

[mcjaeger]

I think SPDX lite is a good idea to generate, but maybe the SPDX lite support would be ideal placed in the SPDX lib for SPDX support so it gets more popularity also in other tools.

[KoukiHama]

I think SPDX lite is a good idea to generate, but maybe the SPDX lite support would be ideal placed in the SPDX lib for SPDX support so it gets more popularity also in other tools.

I think so too. Now only few tools (include commercial tools) support SPDX lite.

[shi9qiu]

I think SPDX lite is a good idea to generate, but maybe the SPDX lite support would be ideal placed in the SPDX lib for SPDX support so it gets more popularity also in other tools.

I agree with this idea as well. What's more, since we have put our hand to implement the SPDX function of the release, maybe we could begin considering the SPDX function of the project as well. For example, a new SPDX tag firstly.

[KoukiHama]

FYI : Proposal Slide about New SPDX function design in here.

https://github.com/eclipse/sw360/issues/1240#issuecomment-874488919

[KoukiHama]

108 is related to this issue.

[arunazhakesan]

I am considering should the SPDX format be treated as an entirety. Because the SPDX is a "standard", which means only when the required fields are recorded, it can be called "SPDX". But in industry, some fields may not be satisfied easily such as "File information".

To balance this problem, SPDX provides a simple version called SPDX Lite. Apart from the Package Information, only a few fields are needed to satisfy the requirements of SPDX Lite, and all these fields can be generated automatically based on the previous set rules in my opinion.

So I wonder maybe SPDX Lite could be a good choice here?

Here is a simple ui for example.

In the Package Information, why is PURL not listed or is it same as Package Download Location. Let me know if my understanding is correct or not.

[KoukiHama]

@arunazhakesan

Package Download Location in this image is stems from and same with SPDX v2.2 (3.7) and it is defined in https://spdx.github.io/spdx-spec/3-package-information/#37-package-download-location

And you can find many example in the link. However, Unfortunately, P-URL is not in these example.

In my opinion, P -URL is worth to use in SPDX, but now SPDX doesn't seem to be designed to handle PURLs.

[KoukiHama]

So if sw360 user want to register purl, they need to use external-id like this document

https://github.com/eclipse/sw360/blob/8229b03a82d1ec623a224c3de8c58914046aed1a/frontend/sw360-portlet/src/documentation/sw360docs/user-guide/component-and-releases/component-and-releases.md#external-ids

Or

Maybe, use spdx 2.2 (3-21) package external reference instead of package download location. (Example image don't include external reference, because it is a just example )

https://spdx.github.io/spdx-spec/3-package-information/#321-external-reference

[KoukiHama]

PURL issue https://github.com/eclipse/sw360/issues/1033

[KoukiHama]

I had got important reply in sw360Slack' :

In SPDX there is already a well defined place for PURLs.

https://github.com/spdx/spdx-spec/blob/development/v2.2/chapters/appendix-VI-external-repository-identifiers.md#purl-

Locator Format:

scheme:type/namespace/name@version?qualifiers#subpath

Contextual Example:

pkg:docker/debian@sha256:2f04d3d33b6027bb74ecc81397abe780649ec89f1a2af18d7022737d0482cefe

So this @arunazhakesan 's question's

In the Package Information, why is PURL not listed or is it same as Package Download Location. Let me know if my understanding is correct or not.

Answer is that

This image is consists of SPDX lite' fields and they don't have field for purl. So both purl itself and "external-repository-identifiers", which is field for purl, are not listed in the image.

In addition, If sw360 need to prepare for field for purl, sw360 should be corresponding not only spdx lite but also spdx itself. Then SPDX have field of "external-repository-identifiers" and sw360 user can register purl in the field.

What do you think? @shi9qiu

[shi9qiu]

Yes. I agree with @KoukiHama . As the definition of SPDX:

Added support for PURL and container images to External Repository Identifiers. So It should be implemented in "External Repository Identifiers". We may have it included in the future development plan. PS: The image here is a very early version to show how the page looks like. The real one is quite different from this. I think we will show the new one within this month if everything goes well.

[quan-tv]

Dear @arunazhakesan , @KoukiHama , @shi9qiu and all,

I and my colleagues are working functions of Import, View and Edit SPDX files.

Import function support RDF/XML and JSON.

I hope that the PR for these functions could be created within October.

Actually, we are also working with Export SPDX file, but we are stuck at creating the file. The library is being used: https://github.com/spdx/tools I'm not sure that this issue is from the library or not, we will need more time for investigating.

Below are some screen designs: spdx_import.pdf spdx_view.pdf spdx_edit.pdf

[shi9qiu]

org.apache.thrift.transport.TTransportException: HTTP Response code: 500 at org.apache.thrift.transport.THttpClient.flush(THttpClient.java:352) ~[bundleFile:?] at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:73) ~[bundleFile:?] at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:62) ~[bundleFile:?] at org.eclipse.sw360.datahandler.thrift.components.ComponentService$Client.send_exportSPDX(ComponentService.java:2386) ~[bundleFile:?] at org.eclipse.sw360.datahandler.thrift.components.ComponentService$Client.exportSPDX(ComponentService.java:2376) ~[bundleFile:?] at org.eclipse.sw360.portal.portlets.components.ComponentPortlet.exportSPDX(ComponentPortlet.java:306) ~[bundleFile:?] at org.eclipse.sw360.portal.portlets.components.ComponentPortlet.serveResource(ComponentPortlet.java:250) ~[bundleFile:?]

When we build the source code in another environment, we failed and get some error messages. We are very confused about this. I wonder does anyone see a similar error message before? What is the reason behind this?

[KoukiHama]

We asked question about new SPDX library here. https://github.com/spdx/Spdx-Java-Library/issues/66

and We continue to survey about large files.

[shi9qiu]

Done:

• Toshiba only implement the SPDX export function for component (not for project yet).
• The moderation request based on the role.
• The function supports RDF/XML/JSON/XLS/TAG formats.
• The clause of file information (Clause 8) is not included.
• The function supports SPDX Full and SPDX Lite.
• We added the validation for the fields which belong to SPDX Lite.
• The user can also import the analysis report, in SPDX format, generated by FOSSology into the system, and then export it.

In progress:

• We are extending the support formats: RDF/XML, JSON, TAG, XLS -> RDF/XML, JSON, TAG, XLS, XLSX, YAML.
• We are trying to make it possible that the function could export SPDX file of large scale. The plan is replace the old library with a new one (https://github.com/spdx/Spdx-Java-Library), but it seems work not well. We are trying to develop a new library for this goal.

Possible collaboration (include some features we have no plan for now):

• API for SPDX function (get, update, import, and export function).
• The implement of the SPDX function for project level (also API).
• The implement of the SPDX function for the clause of file information (Clause 8).
• The merge and split function for SPDX.

[sschuberth]

We are trying to develop a new library for this goal.

Does it maybe make sense to collaborate on ORT's SPDX library? We were looking to find the time to extract this as a stand-alone library for quite some time, and a collaboration would be a good reason to do so.

[quan-tv]

Dear all,

I noticed an important point that, in one SPDX file, the most data is File Information.

For example:

1. File SPDX2_linux-4.18.tar.xz_1535128294-spdx.rdf ~ 82MB After removing File Information: ~ 84KB

2. File spdx_e2fsprogs1.44.5-1+deb10u3.rdf ~ 229MB After removing File Information: ~ 149KB

It will be a good approach if we separate SPDX file into 2 parts and handle them in different ways.

So, I would like to propose solution for Importing/Exporting SPDX SBOM as attached files:

SPDX Import.pdf SPDX Export.pdf

Best regards,

[KoukiHama]

New spdx library was updated, we ought to try to new one. @shi9qiu https://github.com/spdx/Spdx-Java-Library/issues/66#issuecomment-989030156

[dineshr93]

Just a thought check section "designing executive order compliant sbom" in this link https://devblogs.microsoft.com/engineering-at-microsoft/generating-software-bills-of-materials-sboms-with-spdx-at-microsoft/

[KoukiHama]

We tired and it is the result of new library trial. (thank you @akapti ) https://github.com/spdx/Spdx-Java-Library/issues/66#issuecomment-989030156

tried tools-java 1.0.2 which is using java-spdx-library 1.0.7 and also tried with tools-java 1.0.3 which is using java-spdx-library 1.0.9.

But both are having some issues..

Error logs with tools-java version 1.0.2 when I call SpdxConverter.convert(sourceFileName, targetFileName); :

09-Dec-2021 22:19:48.281 SEVERE [http-nio-8080-exec-8] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [ComponentService] in context with path [/components] threw exception [Servlet execution threw an exception] with root cause
    java.lang.NoSuchMethodError: 'void org.spdx.tag.BuildDocument.<init>(org.spdx.storage.IModelStore, java.util.Properties, java.util.List)'
        at org.spdx.tagvaluestore.TagValueStore.deSerialize(TagValueStore.java:86)
        at org.spdx.tools.SpdxConverter.convert(SpdxConverter.java:151)
        at org.spdx.tools.SpdxConverter.convert(SpdxConverter.java:124)
        at org.eclipse.sw360.spdx.SpdxBOMExporter.exportSPDXFile(SpdxBOMExporter.java:170)
        at org.eclipse.sw360.datahandler.db.ComponentDatabaseHandler.exportSPDX(ComponentDatabaseHandler.java:2232)
        at org.eclipse.sw360.components.ComponentHandler.exportSPDX(ComponentHandler.java:522)
        at org.eclipse.sw360.datahandler.thrift.components.ComponentService$Processor$exportSPDX.getResult(ComponentService.java:6554)
        at org.eclipse.sw360.datahandler.thrift.components.ComponentService$Processor$exportSPDX.getResult(ComponentService.java:6534)
        at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:38)
        at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:38)
        at org.apache.thrift.server.TServlet.doPost(TServlet.java:83)
        at org.eclipse.sw360.projects.Sw360ThriftServlet.doPost(Sw360ThriftServlet.java:40)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
        at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
        at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
        at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1594)
        at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.base/java.lang.Thread.run(Thread.java:829)

Error with tools-java version 1.0.3 when I call new SpdxDocumentContainer() constructor:

09-Dec-2021 21:39:50.719 SEVERE [http-nio-8080-exec-2] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [ComponentService] in context with path [/components] threw exception [Servlet execution threw an exception] with root cause
    java.lang.IncompatibleClassChangeError: Method 'org.apache.jena.util.FileManager org.apache.jena.util.FileManager.get()' must be InterfaceMethodref constant
        at org.spdx.rdfparser.license.ListedLicenses.getLicenseModel(ListedLicenses.java:331)
        at org.spdx.rdfparser.license.ListedLicenses.getLicenseFromUri(ListedLicenses.java:207)
        at org.spdx.rdfparser.license.ListedLicenses.getListedLicenseById(ListedLicenses.java:555)
        at org.spdx.rdfparser.license.LicenseInfoFactory.getListedLicenseById(LicenseInfoFactory.java:108)
        at org.spdx.rdfparser.license.LicenseExpressionParser.parseSimpleLicenseToken(LicenseExpressionParser.java:228)
        at org.spdx.rdfparser.license.LicenseExpressionParser.parseLicenseExpression(LicenseExpressionParser.java:144)
        at org.spdx.rdfparser.license.LicenseExpressionParser.parseLicenseExpression(LicenseExpressionParser.java:74)
        at org.spdx.rdfparser.license.LicenseInfoFactory.parseSPDXLicenseString(LicenseInfoFactory.java:208)
        at org.spdx.rdfparser.SpdxDocumentContainer.<init>(SpdxDocumentContainer.java:228)
        at org.eclipse.sw360.spdx.SpdxBOMExporter.createSpdxDocumentCreationInfoFromSw360DocumentCreationInfo(SpdxBOMExporter.java:608)
        at org.eclipse.sw360.spdx.SpdxBOMExporter.createSpdxDocumentFromSw360Spdx(SpdxBOMExporter.java:425)
        at org.eclipse.sw360.spdx.SpdxBOMExporter.exportSPDXFile(SpdxBOMExporter.java:139)
        at org.eclipse.sw360.datahandler.db.ComponentDatabaseHandler.exportSPDX(ComponentDatabaseHandler.java:2232)
        at org.eclipse.sw360.components.ComponentHandler.exportSPDX(ComponentHandler.java:522)
        at org.eclipse.sw360.datahandler.thrift.components.ComponentService$Processor$exportSPDX.getResult(ComponentService.java:6554)
        at org.eclipse.sw360.datahandler.thrift.components.ComponentService$Processor$exportSPDX.getResult(ComponentService.java:6534)
        at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:38)
        at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:38)
        at org.apache.thrift.server.TServlet.doPost(TServlet.java:83)
        at org.eclipse.sw360.projects.Sw360ThriftServlet.doPost(Sw360ThriftServlet.java:40)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
        at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
        at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
        at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1594)
        at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.base/java.lang.Thread.run(Thread.java:829)

[KoukiHama]

Those issues are due to overriding 3rd party libraries. namely Apache jena

Here is the hierarchy. One is using 3.12.0 and another using 4.2.0 tools-java is using Apache jena version4.2.0

[INFO] +- org.spdx:tools-java:jar:1.0.3:compile
[INFO] |  +- org.spdx:java-spdx-library:jar:1.0.9:compile
[INFO] |  |  \- com.google.code.findbugs:jsr305:jar:3.0.2:compile
[INFO] |  +- org.spdx:spdx-rdf-store:jar:1.0.3:compile
[INFO] |  |  +- org.apache.jena:jena-core:jar:4.2.0:compile
[INFO] |  |  |  \- commons-cli:commons-cli:jar:1.4:compile
[INFO] |  |  +- org.apache.jena:jena-arq:jar:4.2.0:compile
[INFO] |  |  |  +- com.github.jsonld-java:jsonld-java:jar:0.13.3:compile
[INFO] |  |  |  +- com.apicatalog:titanium-json-ld:jar:1.1.0:compile
[INFO] |  |  |  \- org.glassfish:jakarta.json:jar:2.0.1:compile
[INFO] |  |  \- org.apache.jena:jena-base:jar:4.2.0:compile
[INFO] |  |     +- org.apache.jena:jena-shaded-guava:jar:4.2.0:compile
[INFO] |  |     \- com.github.andrewoma.dexx:collection:jar:0.7:compile

where as spdx-tools is using Apache jena version 3.12.0 which is creating all the above issues..

[INFO] +- org.spdx:spdx-tools:jar:2.2.5:compile
[INFO] |  +- com.fasterxml.jackson.core:jackson-databind:jar:2.11.3:compile
[INFO] |  +- org.apache.commons:commons-compress:jar:1.19:compile
[INFO] |  +- org.apache.jena:apache-jena-libs:pom:3.12.0:compile
[INFO] |  |  +- org.apache.jena:jena-tdb:jar:3.12.0:compile
[INFO] |  |  +- org.apache.jena:jena-tdb2:jar:3.12.0:compile
[INFO] |  |  |  \- org.apache.jena:jena-dboe-trans-data:jar:3.12.0:compile
[INFO] |  |  |     +- org.apache.jena:jena-dboe-transaction:jar:3.12.0:compile
[INFO] |  |  |     |  \- org.apache.jena:jena-dboe-base:jar:3.12.0:compile
[INFO] |  |  |     \- org.apache.jena:jena-dboe-index:jar:3.12.0:compile
[INFO] |  |  \- org.apache.jena:jena-rdfconnection:jar:3.12.0:compile
[INFO] |  +- org.apache.jena:jena-iri:jar:3.12.0:compile

[KoukiHama]

From our survey, we got the root cause: spdx-tools 2.2.5 is pointing to Apache Jena version 3.12.0, in version 3.12.0 the file org.apache.jena.util.FileManager was defined as Class. where as tools-java 1.0.3 is dependent on spdx-java-tools 1.0.9 which is in-turn dependent on Apache Jena version 4.2.0, in version 4.2.0 the file org.apache.jena.util.FileManager is defined as Interface.

The conflict between Class and Interface is causing that error: java.lang.IncompatibleClassChangeError.

For solving problem, spdx-tools should change the Apache Jena version to latest one in spdx-tools 2.2.5, or else we should completely remove the old SPDX library (spdx-tools 2.2.5) & migrate to new SPDX library (tools-java 1.0.3)

[goneall]

@KoukiHama The SPDX tools updated the Jena library version to resolve a known security vulnerability in Jena. I would recommend migrating to the new SPDX library version 1.0.3 or later.

Let me know if would like any help in the migration.