docs: Fix all links in Docusaurus

Fix all markdown links and configure the Docusaurus build to fail on
broken links.

Compared to before there are two main differences for links within
Docusuaurus:
* Links between URL links need to be URL links to be resolved. This will
  be fixed in Docusaurus 3 [1].
* Links that point to files outside the "docusaurus" directory need to
  be absolute links to be resolvable in the final website. This could
  mabye be improved by adding support for variables [2].

[1]: facebook/docusaurus#6370
[2]: facebook/docusaurus#395

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.io>

docusaurus/docs/configuration/copyright-garbage.md

@@ -2,8 +2,7 @@
 
 The `copyright-garbage.yml` file allows to define which Copyright statements are to be considered as garbage, like any
 invalid findings from a scanner. This can be done by literal strings or regular expression patterns. The *evaluator* and
-*reporter* take the file as optional input. See the [copyright-garbage.yml example](../examples/copyright-garbage.yml)
-as a base to get started.
+*reporter* take the file as optional input. See the [example](#example) as a base to get started.
 
 ## Command Line
 

docusaurus/docs/configuration/evaluator-rules.md

@@ -6,10 +6,9 @@ findings. Rules are written in a Kotlin-based DSL.
 For each policy rule violation, you can define 'How to fix' follow-up actions to help users resolve policy rules
 violations by themselves.
 
-You can use the [example rules](../../examples/example.rules.kts) as the base script file for your policy rules. Note
+You can use the [example rules](#example) as the base script file for your policy rules. Note
 that this example depends on the license categorizations defined in the
-[license-classifications example](../../examples/license-classifications.yml), see the
-[license-classifications docs](../config-file-license-classifications-yml.md).
+[license-classifications example](license-classifications.md#example).
 
 ## Command Line
 

docusaurus/docs/configuration/license-classifications.md

@@ -2,7 +2,7 @@
 
 The `license-classifications.yml` file holds a user-defined categorization of licenses.
 
-You can use the [license-classifications.yml example] as the base configuration
+You can use the [example](#example) as the base configuration
 file for your scans.
 
 The file consists of two sections: The first one, *categories*, allows defining arbitrary categories for grouping
@@ -26,7 +26,7 @@ The information from the `license-classifications.yml` is evaluated by the follo
   decide, which licenses to include into the generated notice file.
 
 The [license-classifications.yml example] demonstrates the intended use cases. It defines some categories that specify
-whether licenses are applicable to development projects. The [example.rules.kts] checks ORT results against these
+whether licenses are applicable to development projects. The [example](#example) checks ORT results against these
 categories and generates issues if the rules detect a misuse.
 
 In addition, there are some other categories to be evaluated by the templates for the notice file: The
@@ -52,12 +52,10 @@ cli/build/install/ort/bin/ort evaluate
   --rules-file $ORT_CONFIG_DIR/evaluator.rules.kts
 ```
 
-[license-classifications.yml example]: ../examples/license-classifications.yml
 [generated license-classifications.yml]: https://github.com/maxhbr/LDBcollector/blob/generated/ort/license-classifications.yml
 [LDBcollector]: https://github.com/maxhbr/LDBcollector
-[Rules]: scripts/rules-kts.md
-[Plain text templates]: reporters/plain-text-templates.md
-[example.rules.kts]: ../examples/example.rules.kts
+[Rules]: evaluator-rules.md
+[Plain text templates]: reporter-templates.md#plain-text-templates
 
 ## Example
 

docusaurus/docs/configuration/license-texts.md

@@ -3,7 +3,7 @@
 ORT does provide the license texts for all [SPDX licenses](https://spdx.org/licenses/) and for all license references
 from [ScanCode](https://github.com/nexB/scancode-toolkit/tree/develop/src/licensedcode/data/licenses). These license
 texts will be used when generating open source notices using the
-[PlainTextTemplateReporter](reporters/plain-text-templates.md).
+[PlainTextTemplateReporter](reporter-templates.md#plain-text-templates).
 
 If you need a license text that is not provided by ORT you can put it in the custom license texts directory. By default,
 it is located at `$ORT_CONFIG_DIR/custom-license-texts`. Alternatively, you can pass a different location to the

docusaurus/docs/configuration/ort-yml.md

@@ -10,8 +10,8 @@ increased degree of automation and local configurations should only be done if t
 * [resolutions](#resolutions) - Resolve any issues or policy rule violations.
 * [license choices](#license-choices) - Select a license for packages which offer a license choice.
 
-The sections below explain each in further detail. Prefer to learn by example? See the [.ort.yml](../.ort.yml) for the
-OSS Review Toolkit itself.
+The sections below explain each in further detail. Prefer to learn by example? See the
+[.ort.yml](https://github.com/oss-review-toolkit/ort/blob/main/.ort.yml) for the OSS Review Toolkit itself.
 
 ## Excludes
 
@@ -75,15 +75,15 @@ excludes:
 ```
 
 Where the list of available options for `reason` is defined in
-[PathExcludeReason.kt](../model/src/main/kotlin/config/PathExcludeReason.kt). For how to write a glob pattern, please
+[PathExcludeReason.kt](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/config/PathExcludeReason.kt). For how to write a glob pattern, please
 see the
 [AntPathMatcher documentation](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/util/AntPathMatcher.html).
 
 The path exclude above has the following effects:
 
 * All projects found below the `test-data` directory are marked as excluded.
 * License findings in files below the `test-data` directory are marked as excluded. This can be used in
-  [evaluator rules](getting-started.md#6-running-the-evaluator) to for instance change the severity from error to
+  [evaluator rules](../../tutorial/intro#6-running-the-evaluator) to for instance change the severity from error to
   warning.
 
 ```yaml
@@ -118,7 +118,7 @@ The above example excludes all the following scopes for all projects: `testAnnot
 `testRuntimeOnly`.
 
 Where the list of available options for scopes is defined in
-[ScopeExcludeReason.kt](../model/src/main/kotlin/config/ScopeExcludeReason.kt).
+[ScopeExcludeReason.kt](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/config/ScopeExcludeReason.kt).
 
 See the examples below for typical scope excludes for the supported package managers. Note that you must verify that the
 scopes defined in the examples below match the scopes in your project.
@@ -164,7 +164,7 @@ import Yarn from '!!raw-loader!@site/../examples/yarn.ort.yml'
 
 License finding curations should be used when you want to correct the licenses detected in the source code of the
 project. To define curations on global level for third-party packages, please use
-[curations](config-file-curations-yml.md) or [package configurations](config-file-package-configuration-yml.md).
+[curations](package-curations.md) or [package configurations](package-configurations.md).
 
 ### Curating Project License Findings
 
@@ -189,7 +189,7 @@ curations:
 
 To correct identified licenses in a dependency you can use a package configuration to overwrite scanner findings. Note
 that this feature requires `enableRepositoryPackageConfigurations` to be enabled in the
-[config.yml](../README.md#ort-configuration-file).
+[config.yml](../getting-started/usage.md#ort-configuration-file).
 
 ```yaml
 package_configurations:
@@ -206,17 +206,17 @@ package_configurations:
 ```
 
 For details of the specification, see
-[LicenseFindingCuration.kt](../model/src/main/kotlin/config/LicenseFindingCuration.kt).
+[LicenseFindingCuration.kt](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/config/LicenseFindingCuration.kt).
 The list of available options for `reason` are defined in
-[LicenseFindingCurationReason.kt](../model/src/main/kotlin/config/LicenseFindingCurationReason.kt).
+[LicenseFindingCurationReason.kt](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/config/LicenseFindingCurationReason.kt).
 
 ### Curating Metadata
 
 Package curations can be added if you want to correct metadata of third-party dependencies.
 
 The following example corrects the source-artifact URL of the package with the id `Maven:com.example:dummy:0.0.1`.  Note
 that this feature requires `enableRepositoryPackageCurations` to be enabled in the
-[config.yml](../README.md#ort-configuration-file).
+[config.yml](../getting-started/usage.md#ort-configuration-file).
 
 ```yaml
 curations:
@@ -229,7 +229,7 @@ curations:
 ```
 
 For more information about package curations see
-[the documentation for the curations.yml file](config-file-curations-yml.md).
+[the documentation for the curations.yml file](package-curations.md).
 
 ### Example
 
@@ -245,7 +245,7 @@ import Curations from '!!raw-loader!@site/../examples/curations.ort.yml'
 
 Resolutions should be used if you are unable to solve an issue by other means.
 
-If a resolution is not project-specific than add it to [resolutions.yml](./config-file-resolutions-yml.md) so that it is
+If a resolution is not project-specific than add it to [resolutions.yml](resolutions.md) so that it is
 applied to each scan.
 
 ### Resolution Basics
@@ -280,7 +280,7 @@ resolutions:
 ```
 
 Where the list of available options for `reason` is defined in
-[IssueResolutionReason.kt](../model/src/main/kotlin/config/IssueResolutionReason.kt)
+[IssueResolutionReason.kt](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/config/IssueResolutionReason.kt)
 
 For example, to ignore an issue related to a build tool problem, your `.ort.yml` could include:
 
@@ -297,7 +297,7 @@ resolutions:
 Resolutions should not be used to resolve license policy rule violations as they do not change the generated open
 source notices. To resolve a license policy rule violation either add a [license finding curation](#curations) to the
 .ort.yml file if the finding is in your code repository or add a curation to the
-[curations.yml](config-file-curations-yml.md) if the violation occurs in a third-party dependency.
+[curations.yml](package-curations.md) if the violation occurs in a third-party dependency.
 
 The code below shows the structure of a policy rule violation resolution in the `.ort.yml` file:
 
@@ -310,7 +310,7 @@ resolutions:
 ```
 
 Where the list of available options for `reason` is defined in
-[RuleViolationResolutionReason.kt](../model/src/main/kotlin/config/RuleViolationResolutionReason.kt).
+[RuleViolationResolutionReason.kt](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/config/RuleViolationResolutionReason.kt).
 
 For example, to confirm you acquired a commercial Qt license for your project, your `.ort.yml` could include:
 
@@ -335,7 +335,7 @@ resolutions:
 ```
 
 Where the list of available options for `reason` is defined in
-[VulnerabilityResolutionReason.kt](../model/src/main/kotlin/config/VulnerabilityResolutionReason.kt).
+[VulnerabilityResolutionReason.kt](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/config/VulnerabilityResolutionReason.kt).
 
 For example, to ignore a vulnerability that is ineffective, because it is not invoked in your project, your `.ort.yml`
 could include:
@@ -363,7 +363,7 @@ import Resolutions from '!!raw-loader!@site/../examples/resolutions.ort.yml'
 For multi-licensed dependencies a specific license can be selected. The license choice can be applied to a package or
 globally to an SPDX expression in the project. A choice is only valid for licenses combined with the SPDX operator `OR`.
 The choices are applied in the evaluator, and the reporter to the effective license of a package, which is calculated by
-the chosen [LicenseView](../model/src/main/kotlin/licenses/LicenseView.kt).
+the chosen [LicenseView](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/licenses/LicenseView.kt).
 
 ### License Choice by Package
 

docusaurus/docs/configuration/package-configurations.md

@@ -2,7 +2,7 @@
 
 A package configuration file allows you to define path excludes and license finding curations for a specific package
 (dependency) and provenance. Conceptually, the file is similar to
-[.ort.yml](https://github.com/oss-review-toolkit/ort/blob/main/docs/config-file-ort-yml.md), but it is used only for
+[.ort.yml](ort-yml.md), but it is used only for
 packages included via a package manager as project dependencies, and not for the project's own source code repository to
 be scanned.
 
@@ -44,8 +44,8 @@ in the source repository but only used for building, documenting or testing the
 to fix incorrect scan results, for example if a wrong license was detected, or if a finding is a false positive.
 
 The entries for path excludes and license finding curations have the same syntax and semantics as in the `ort.yml` file,
-see [excluding paths](config-file-ort-yml.md#excluding-paths) and
-[curating license findings](config-file-ort-yml.md#curating-project-license-findings) for details.
+see [excluding paths](ort-yml.md#excluding-paths) and
+[curating license findings](ort-yml.md#curating-project-license-findings) for details.
 
 ```yaml
 id: "Pip::example-package:0.0.1"

docusaurus/docs/configuration/package-curations.md

@@ -2,7 +2,7 @@
 
 Curations correct invalid or missing package metadata and set the concluded license for packages.
 
-You can use the [curations.yml example](../examples/curations.yml) as the base configuration file for your scans.
+You can use the [curations.yml example](#example) as the base configuration file for your scans.
 
 ## When to Use Curations
 
@@ -33,7 +33,7 @@ Curations can be used to:
 The sections below explain how to create curations in the `curations.yml` file which,
 if passed to the *analyzer*, is applied to all package metadata found in the analysis.
 If a license detected in the source code of a package needs to be corrected, add
-a license finding curation in the [.ort.yml](config-file-ort-yml.md#curations) file for the project.
+a license finding curation in the [.ort.yml](ort-yml.md#curations) file for the project.
 
 ## Curations Basics
 
@@ -48,7 +48,7 @@ location of source artifacts.
 
 Hint: If the `concluded_license` *and* the `authors` are curated, this package will be skipped during the `scan` step,
 as no more information from the scanner is required. This requires the `skipConcluded` scanner option to be enabled in
-the [config.yml](../README.md#ort-configuration-file).
+the [config.yml](../getting-started/usage.md#ort-configuration-file).
 
 The structure of the curations file consist of one or more `id` entries:
 
@@ -83,7 +83,7 @@ The structure of the curations file consist of one or more `id` entries:
 ```
 
 Where the list of available options for curations is defined in
-[PackageCurationData.kt](../model/src/main/kotlin/PackageCurationData.kt).
+[PackageCurationData.kt](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/PackageCurationData.kt).
 
 ## Command Line
 
@@ -98,10 +98,11 @@ cli/build/install/ort/bin/ort analyze
 
 Alternatively to a single file, curations may also be split across multiple files below a directory, by default
 `$ORT_CONFIG_DIR/curations`. File and directory package curation providers may also be configured as
-[FilePackageCurationProviders](../plugins/package-curation-providers/file/src/main/kotlin/FilePackageCurationProvider.kt)
+[FilePackageCurationProviders](https://github.com/oss-review-toolkit/ort/blob/main/plugins/package-curation-providers/file/src/main/kotlin/FilePackageCurationProvider.kt)
 in `$ORT_CONFIG_DIR/config.yml`. Similarly, ORT can use [ClearlyDefined](https://clearlydefined.io/) and
 [SW360](https://www.eclipse.org/sw360/) as sources for curated metadata. See the
-[reference configuration file](../model/src/main/resources/reference.yml) for examples.
+[reference configuration file](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/resources/reference.yml)
+for examples.
 
 To override curations, e.g. for testing them locally, you can also pass a `curations.yml` file or a curations directory
 via the `--package-curations-file` / `--package-curations-dir` options of the *evaluator*:

docusaurus/docs/configuration/resolutions.md

@@ -3,15 +3,15 @@
 Resolutions allow you to *resolve* issues, policy rule violations or vulnerabilities by providing a reason why they are
 acceptable and can be ignored.
 
-You can use the [resolutions.yml example](../examples/resolutions.yml) as the base configuration file for your scans.
+You can use the [resolutions.yml example](#example) as the base configuration file for your scans.
 
 ## When to Use Resolutions
 
 Resolutions should be used when it is impossible to solve an issue or a fix is planned for a later time.
 
 The sections below explain how to create resolutions in the `resolutions.yml` file which, if passed as an argument to
 the *reporter*, applies to each scan made. If a resolution is project-specific, then add it in the
-[.ort.yml](config-file-ort-yml.md) file for the project.
+[.ort.yml](ort-yml.md) file for the project.
 
 Resolutions are only taken into account by the *reporter*, while the *analyzer* and *scanner* ignore them.
 
@@ -45,7 +45,7 @@ issues:
 ```
 
 Where the list of available options for `reason` is defined in
-[IssueResolutionReason.kt](../model/src/main/kotlin/config/IssueResolutionReason.kt).
+[IssueResolutionReason.kt](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/config/IssueResolutionReason.kt).
 
 For example, to ignore an issue related to a build tool problem, your `resolutions.yml` could include:
 
@@ -60,8 +60,8 @@ issues:
 
 Resolutions should not be used to resolve license policy rule violations as they do not the change generated open source
 notices. To resolve a license policy rule violation either add a local `license_findings` curation to the
-[.ort.yml file](./config-file-ort-yml.md) if the finding is in your code repository or add a curation to the
-[curations.yml](config-file-curations-yml.md) if the violation occurs in a third-party dependency.
+[.ort.yml file](./ort-yml.md) if the finding is in your code repository or add a curation to the
+[curations.yml](package-curations.md) if the violation occurs in a third-party dependency.
 
 The code below shows the structure of a policy rule violation resolution in the `resolutions.yml` file:
 
@@ -73,7 +73,7 @@ rule_violations:
 ```
 
 Where the list of available options for `reason` is defined in
-[RuleViolationResolutionReason.kt](../model/src/main/kotlin/config/RuleViolationResolutionReason.kt).
+[RuleViolationResolutionReason.kt](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/config/RuleViolationResolutionReason.kt).
 
 For example, to confirm your organization has acquired an org-wide Qt commercial license, your `resolutions.yml` could
 include:
@@ -97,7 +97,7 @@ vulnerabilities:
 ```
 
 Where the list of available options for `reason` is defined in
-[VulnerabilityResolutionReason.kt](../model/src/main/kotlin/config/VulnerabilityResolutionReason.kt).
+[VulnerabilityResolutionReason.kt](https://github.com/oss-review-toolkit/ort/blob/main/model/src/main/kotlin/config/VulnerabilityResolutionReason.kt).
 
 For example, to ignore a vulnerability that is ineffective, because it is not invoked in your project, your
 `resolutions.yml` could include:

docusaurus/docs/getting-started/installation.md

@@ -51,7 +51,7 @@ Depending on how ORT was installed, it can be run in the following ways:
   docker run ort --help
   ```
 
-  You can find further hints for using ORT with Docker in the [documentation](./docs/hints-for-use-with-docker.md).
+  You can find further hints for using ORT with Docker in the [documentation](../guides/docker.md).
 
 * If the ORT distribution was built from sources, use