feat(scanner): Store detected and effective license in database by Joelp03 · Pull Request #4791 · eclipse-apoapsis/ort-server

Joelp03 · 2026-04-02T14:55:59Z

Hi there.
This implementation resolves the issue of storing detected and effective licenses for packages and projects in the database during the scanning process, making them readily available for API routes without needing to iterate through all scan results.

Resolve #4607

mnonnenmacher · 2026-04-02T15:30:27Z

@Joelp03 Thank you for the contribution!

I don't have time to review this now and I won't be available for review for the next week, so some hints for anyone who picks up the review:

Make sure that package curations and package configurations are applied before storing the licenses, otherwise wrong data could be shown.
I think we should store the concluded license as well to have the full picture. Could be done separately, but this would also be a chance to do all of them together.
Filtering by license will be important for the UI, this should be considered when designing the storage model.

Etsija · 2026-04-14T03:39:33Z

Thanks @Etsija I’ve reverted the merge and rebased the branch. I’m standing by for any further changes or feedback.

For starters, you should run ./gradlew detekt detektMain detektTest to fix all linting issues, as the action is failing. Then, I believe it would be needed to address the points @mnonnenmacher is giving in his comment.

sschuberth · 2026-04-14T05:47:14Z

you should run ./gradlew detekt detektMain detektTest

FYI, we have the ./gradlew detektAll shorthand for that.

The merge commit was removed.

sschuberth · 2026-04-20T16:06:25Z

Make sure that package curations and package configurations are applied before storing the licenses, otherwise wrong data could be shown.

@Joelp03, can you confirm that esp. this first point from @mnonnenmacher has been addressed?

Joelp03 · 2026-04-20T19:02:04Z

Make sure that package curations and package configurations are applied before storing the licenses, otherwise wrong data could be shown.

@Joelp03, can you confirm that esp. this first point from @mnonnenmacher has been addressed?

It is not yet implemented. This latest commit contains the implementation.

Store detected licenses and effective license for packages and projects during the scanner phase to make them easily available via API routes without having to traverse all license findings from scan results. - Add detectedLicenses and effectiveLicense columns to packages and projects tables (Flyway V139 migration) - Add fields to Package and Project models - Add DAO support for new columns with comma-separated serialization - Create LicenseComputation.kt with functions to compute licenses - Integrate license computation in ScannerWorker - Expose new fields in API v1 Package and Project responses - Add unit tests for DAO and LicenseComputation Signed-off-by: Joel Pimentel <joelpimentel1995@gmail.com> Resolves eclipse-apoapsis#4607.

Detected licenses must have PackageCuration and PackageConfiguration applied before storing, otherwise wrong data could be shown. - Change computeDetectedLicenses to use LicenseInfoResolver which applies LicenseFindingCuration and PathExclude from PackageConfiguration - Remove scannerRun parameter from computeAndStoreLicenses since it's no longer needed after using LicenseInfoResolver Signed-off-by: Joelp03 <joelpimentel1995@gmail.com>

Joelp03 · 2026-04-20T19:47:54Z

I would appreciate a thorough review of this request to ensure it fully aligns with the project's requirements and standards. Please let me know if any adjustments

Etsija · 2026-04-21T04:50:59Z

Some comments:

Commit structure

See Contributing Guide / Atomic Commits: each commit should be atomic and buildable. The first commit is pretty hard to follow, as it touches four software layers (model, DAO, workers, API) in a single commit.

I would consider splitting the commit into smaller, more manageable and reviewable commits with their respective tests, and making sure each commit builds and tests pass. However I will not block this PR because it, as other reviewers may have easier time reading it than me as a non-back-end guy.

API layer

Do I understand correctly that no API endpoints are affected yet, ie. no detected/effective license data can yet be retrieved from packages/projects endpoints? I am asking because if the data is already available and meant to be provided by the API in this PR and not a follow-up, the PR should probably also touch routes and apiDocs for the corresponding endpoints. But if not, maybe just make it clear that the API changes will come in a follow-up.

Some code smell issues

There's a lot of splitting by ",", then joining by "," in the code, which to me is a bit suspicious.

oheger-bosch · 2026-04-21T06:02:19Z

Similar to point 3 from @Etsija : Wouldn't it be preferable to have a normalized data model for the detected licenses, i.e., storing them in a separate table and having a relation to the packages and projects tables? Just asking.

Etsija · 2026-04-21T08:23:59Z

Similar to point 3 from @Etsija : Wouldn't it be preferable to have a normalized data model for the detected licenses, i.e., storing them in a separate table and having a relation to the packages and projects tables? Just asking.

True, and as I am not exactly loving the fact that my license-findings service currently needs something like a 10-way join to fetch detected licenses of a package found from an ORT run, it could potentially be greatly simplified with your suggestion.

Joelp03 requested review from MarcelBochtler, bs-ondem, mnonnenmacher, nnobelis, oheger-bosch, sschuberth and wkl3nk as code owners April 2, 2026 14:56