You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far, for local scanners, ORT has the specific version it supports hard-coded; if a different version of the scanner is installed on the system, it is not accepted, but ORT tries to bootstrap this exact version (see
This behaviour is rather strict, and it complicates updates to newer scanner versions (e.g. refer to #4296). To be more flexible, ORT could support setting the accepted scanner version (or even a version range) in the scanner configuration. For instance, for ScanCode, this could look as follows:
Note: The properties minVersion and maxVersion are currently already used to configure the accepted versions when loading results from the scan result storage; so they would have to be renamed.
The expectedVersion hard-coded in ORT could be kept and used as default value if no version is configured for a scanner; this would also be the version that gets bootstrapped.
The text was updated successfully, but these errors were encountered:
Closing this in favor of the even more relaxed approach in #4669, which accepts any scanner version already installed on the host, but informs about a version mismatch.
So far, for local scanners, ORT has the specific version it supports hard-coded; if a different version of the scanner is installed on the system, it is not accepted, but ORT tries to bootstrap this exact version (see
ort/scanner/src/main/kotlin/LocalScanner.kt
Line 119 in 4ab3679
This behaviour is rather strict, and it complicates updates to newer scanner versions (e.g. refer to #4296). To be more flexible, ORT could support setting the accepted scanner version (or even a version range) in the scanner configuration. For instance, for ScanCode, this could look as follows:
Note: The properties minVersion and maxVersion are currently already used to configure the accepted versions when loading results from the scan result storage; so they would have to be renamed.
The
expectedVersion
hard-coded in ORT could be kept and used as default value if no version is configured for a scanner; this would also be the version that gets bootstrapped.The text was updated successfully, but these errors were encountered: