refactor: More explicit Provenance Handling

[pepper-jk]

Since RepositoryProvenance and ArtifactProvenance are both KnownProvenance, ORT's code base widely assumes the interface is synonymous with the classes.

This however might change in light of the proposed provenance interface/class hierarchy.

To ensure Code, which expects KnownProvenance to be either RepositoryProvenance or ArtifactProvenance, will still function as expected during refactoring, this PR aims to remove some of the ambiguity regarding KnownProvenance, especially in conditional statements.

Signed-off-by: Jens Keim [email protected]

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 10 lines in your changes missing coverage. Please review.

Project coverage is 65.68%. Comparing base (e841910) to head (f58c38d).
Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
...el/src/main/kotlin/licenses/LicenseInfoResolver.kt	0.00%	2 Missing and 1 partial ⚠️
...del/src/main/kotlin/config/PackageConfiguration.kt	0.00%	1 Missing ⚠️
...src/main/kotlin/utils/FileProvenanceFileStorage.kt	0.00%	1 Missing ⚠️
...main/kotlin/utils/PostgresProvenanceFileStorage.kt	0.00%	1 Missing ⚠️
model/src/main/kotlin/utils/PurlExtensions.kt	0.00%	1 Missing ⚠️
...main/kotlin/provenance/NestedProvenanceResolver.kt	0.00%	1 Missing ⚠️
...main/kotlin/storages/ProvenanceBasedFileStorage.kt	0.00%	1 Missing ⚠️
.../kotlin/storages/ProvenanceBasedPostgresStorage.kt	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #9421      +/-   ##
============================================
- Coverage     68.09%   65.68%   -2.41%     
- Complexity     1291     1303      +12     
============================================
  Files           250      250              
  Lines          8814     9218     +404     
  Branches        916     1022     +106     
============================================
+ Hits           6002     6055      +53     
- Misses         2427     2767     +340     
- Partials        385      396      +11     

Flag	Coverage Δ
test	35.85% <0.00%> (-0.02%)	⬇️

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.

[sschuberth]

Is this is not ready yet, you can convert the PR back to draft state:

[sschuberth]

Since RepositoryProvenance and ArtifactProvenance are both KnownProvenance, ORT's code base widely assumes the interface is synonymous with the classes.

This however might change in light of the proposed provenance interface/class hierarchy.

To ensure Code, which expects KnownProvenance to be either RepositoryProvenance or ArtifactProvenance, will still function as expected during refactoring, this PR aims to remove some of the ambiguity regarding KnownProvenance, especially in conditional statements.

I'm having a general problem with the argumentation here, as you seem to assume that whatever new entity may get added to KnownProvenance cannot be handled in the same way as RepositoryProvenance and ArtifactProvenance. But this might not be the case. Maybe in a good chunk of code we actually do not care what kind of KnownProvenance a thing is. As we cannot really tell before adding that new kind of KnownProvenance, I'd approach the whole topic in the other order: First change the Provenance hierarchy to what you envision it to be, and then make any necessary changes (maybe even in the same commit, just from a coding perspective I'd adjust the hierarchy first).

[pepper-jk]

I'm having a general problem with the argumentation here, as you seem to assume that whatever new entity may get added to KnownProvenance cannot be handled in the same way as RepositoryProvenance and ArtifactProvenance. But this might not be the case. Maybe in a good chunk of code we actually do not care what kind of KnownProvenance a thing is.

The point of this PR is mainly to avoid touching the same conditional statement over and over again during the refactoring and keeping the PRs small and incremental.

As we cannot really tell before adding that new kind of KnownProvenance, I'd approach the whole topic in the other order: First change the Provenance hierarchy to what you envision it to be, and then make any necessary changes (maybe even in the same commit, just from a coding perspective I'd adjust the hierarchy first).

Once I change the hierarchy I have to handle it. This PR attempts to front load some of this work.

I know it is hard to review changes without the hierarchy and the later new classes present, but we talked about it enough and defined the hierarchy in theory that it should be possible.

However, I see your reasoning to start with the hierarchy, if this first PR is not at all to your liking. But I would prefer stopping there and implementing the DiretoryProvenance class and their handling later.

I would just like to avoid creating a large PR with all the changes over the course of 2 month only to start from scratch this time.