fix(model): Keep the root project under all circumstances

[wkl3nk]

If a repository has monorepo-like structures, possibly with sub-projects declaring dependencies to the root-project, it may happen that the root-project is removed when generating the SPDX report, as it is a dependency of a sub-project and one does not want to include it.

[wkl3nk]

@sschuberth @fviernau @mnonnenmacher I don't know how to continue here, what is the best way to solve it.
Generation of SPDX report fails with the error message above.

In the web app report, I see the following dependencies:
The look kind of strange, with a project pointing back to itself as a dependency

The debug output that I added looks as follows:

org.ossreviewtoolkit.model.OrtResultKt - wklenk --- sub-project it=Identifier(type=Gradle, namespace=rd-management, name=domain, version=)
org.ossreviewtoolkit.model.OrtResultKt - wklenk --- sub-project it=Identifier(type=Gradle, namespace=rd-management, name=protobuf, version=)
org.ossreviewtoolkit.model.OrtResultKt - wklenk --- sub-project it=Identifier(type=Gradle, namespace=, name=rd-management, version=)
org.ossreviewtoolkit.model.OrtResultKt - wklenk --- sub-project it=Identifier(type=Gradle, namespace=rd-management, name=agent-adapter, version=)
org.ossreviewtoolkit.model.OrtResultKt - wklenk --- sub-project it=Identifier(type=Gradle, namespace=rd-management, name=amqp-adapter, version=)
org.ossreviewtoolkit.model.OrtResultKt - wklenk --- sub-project it=Identifier(type=Gradle, namespace=rd-management, name=application, version=)
org.ossreviewtoolkit.model.OrtResultKt - wklenk --- sub-project it=Identifier(type=Gradle, namespace=rd-management, name=kafka-adapter, version=)
org.ossreviewtoolkit.model.OrtResultKt - wklenk --- sub-project it=Identifier(type=Gradle, namespace=rd-management, name=rest-adapter, version=)
org.ossreviewtoolkit.plugins.reporters.spdx.SpdxDocumentModelMapper - wklenk --- Found 0 projects
org.ossreviewtoolkit.plugins.reporters.spdx.SpdxDocumentModelMapper - wklenk --- Generated SPDX document describing 0 projects, 558 packages, and 26691 files.
org.ossreviewtoolkit.utils.spdxdocument.model.SpdxDocument - wklenk --- Document describes relationships: false
org.ossreviewtoolkit.utils.spdxdocument.model.SpdxDocument - wklenk --- document.describes: []
Exception in thread "main" java.lang.IllegalArgumentException: The document must either have at least one relationship of type 'DESCRIBES' or contain the 'documentDescribes' field.
        at org.ossreviewtoolkit.utils.spdxdocument.model.SpdxDocument.validate(SpdxDocument.kt:180)
        at org.ossreviewtoolkit.utils.spdxdocument.model.SpdxDocument.<init>(SpdxDocument.kt:139

Looking at the debug output, the item with name=rd-management and namespace="" should not be interpreted as sub-project and deleted, because it is the root-project.

Can you advise what could be done, either a code change - or tell the customer to fix the dependencies?
I need support here.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.42%. Comparing base (7f4f6c5) to head (b764a6e).

Additional details and impacted files

@@            Coverage Diff            @@
##               main   #11042   +/-   ##
=========================================
  Coverage     57.42%   57.42%           
- Complexity     1701     1703    +2     
=========================================
  Files           346      346           
  Lines         12835    12835           
  Branches       1215     1215           
=========================================
  Hits           7370     7370           
  Misses         4998     4998           
  Partials        467      467           

Flag	Coverage Δ
funTest-external-tools	13.50% <ø> (ø)
funTest-no-external-tools	31.20% <ø> (+0.10%)	⬆️
test-ubuntu-24.04	42.35% <ø> (ø)
test-windows-2025	42.33% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[fviernau]

Do I understand correctly that Gradle::rd-management: has a dependency on itself in scope combinedGraphClasspass?

Also, is combinedGraphClasspass defined in Gradle, or is it some artificial scope ORT creates?

[wkl3nk]

Do I understand correctly that Gradle::rd-management: has a dependency on itself in scope combinedGraphClasspass?

Yes, looks like, doesn't it. I currently think this is the source of evil, because of this the algorithm thinks this Gradle::rd-management: is a dependency, although it is the root project

Also, is combinedGraphClasspass defined in Gradle, or is it some artificial scope ORT creates?

Defined in Gradle. You can see it in the output of ./gradlew dependencies

Ahh ... maybe there is a way to exclude every scope except runtimeClasspath and the problems will go away?

[fviernau]

Yes, looks like, doesn't it. I currently think this is the source of evil, because of this the algorithm thinks this Gradle::rd-management: is a dependency, although it is the root project

It may not be the most appropriate solution to this problem and also only fix a (this) special case:
But would it make sense to filter out any direct dependency between a project and itself (its identity)?

A more general solution could be, to reconsider whether this function which removes "sub-projects" actually has a bug.
(I'm not sure if there is a unambiguous definition of "subproject" as a basis)
But primarily, I wonder where this combined scope and dependency actually comes from?

Defined in Gradle. You can see it in the output of ./gradlew dependencies

Is the scope created by some Gradle plugin or how exactly? And what does it contain? (The union of all other scopes?)