docs: Fix broken links (#2903)

Signed-off-by: Michael Koepf <[email protected]>

Author: michaelkoepf

docs/content/en/docs/documentation/dependent-resource-and-workflows/dependent-resources.md

@@ -177,7 +177,7 @@ usually limited to status handling based on the state of the secondary resources
 resources are not dependent on each other. As an alternative, you can also invoke reconciliation explicitly, 
 event for managed workflows.
 
-See [Workflows](https://javaoperatorsdk.io/docs/workflows) for more details on how the dependent
+See [Workflows](https://javaoperatorsdk.io/docs/documentation/dependent-resource-and-workflows/workflows/) for more details on how the dependent
 resources are reconciled.
 
 This behavior and automated handling is referred to as "managed" because the `DependentResource`
@@ -220,7 +220,7 @@ It is also possible to wire dependent resources programmatically. In practice th
 developer is responsible for initializing and managing the dependent resources as well as calling
 their `reconcile` method. However, this makes it possible for developers to fully customize the
 reconciliation process. Standalone dependent resources should be used in cases when the managed use
-case does not fit. You can, of course, also use [Workflows](https://javaoperatorsdk.io/docs/workflows) when managing
+case does not fit. You can, of course, also use [Workflows](https://javaoperatorsdk.io/docs/documentation/dependent-resource-and-workflows/workflows/) when managing
 resources programmatically.
 
 You can see a commented example of how to do

docs/content/en/docs/documentation/dependent-resource-and-workflows/workflows.md

@@ -12,12 +12,12 @@ depends on the state of other resources or cannot be processed until these other
 a given state or some condition holds true for them. Dealing with such scenarios are therefore
 rather common for operators and the purpose of the workflow feature of the Java Operator SDK
 (JOSDK) is to simplify supporting such cases in a declarative way. Workflows build on top of the
-[dependent resources](https://javaoperatorsdk.io/docs/dependent-resources) feature.
+[dependent resources](https://javaoperatorsdk.io/docs/documentation/dependent-resource-and-workflows/dependent-resources/) feature.
 While dependent resources focus on how a given secondary resource should be reconciled,
 workflows focus on orchestrating how these dependent resources should be reconciled.
 
 Workflows describe how as a set of
-[dependent resources](https://javaoperatorsdk.io/docs/dependent-resources) (DR) depend on one
+[dependent resources](https://javaoperatorsdk.io/docs/documentation/dependent-resource-and-workflows/dependent-resources/) (DR) depend on one
 another, along with the conditions that need to hold true at certain stages of the
 reconciliation process.
 
@@ -135,7 +135,7 @@ public class SampleWorkflowReconciler implements Reconciler<WorkflowAllFeatureCu
 ### Standalone
 
 In this mode workflow is built manually
-using [standalone dependent resources](https://javaoperatorsdk.io/docs/dependent-resources#standalone-dependent-resources)
+using [standalone dependent resources](https://javaoperatorsdk.io/docs/documentation/dependent-resource-and-workflows/dependent-resources/#standalone-dependent-resources)
 . The workflow is created using a builder, that is explicitly called in the reconciler (from web
 page sample):
 
@@ -194,7 +194,7 @@ public class WebPageDependentsWorkflowReconciler
 This section describes how a workflow is executed in details, how the ordering is determined and
 how conditions and errors affect the behavior. The workflow execution is divided in two parts
 similarly to how `Reconciler` and `Cleaner` behavior are separated.
-[Cleanup](https://javaoperatorsdk.io/docs/features#the-reconcile-and-cleanup) is
+[Cleanup](https://javaoperatorsdk.io/docs/documentation/reconciler/#implementing-a-reconciler-and-cleaner-interfaces) is
 executed if a resource is marked for deletion.
 
 ## Common Principles

docs/content/en/docs/documentation/reconciler.md

@@ -138,7 +138,7 @@ Kubernetes [garbage collection](https://kubernetes.io/docs/concepts/architecture
 mechanism as much as possible by setting owner references for your secondary resources so that
 the cluster can automatically delete them for you whenever the associated primary resource is
 deleted. Note that setting owner references is the responsibility of the `Reconciler`
-implementation, though [dependent resources](https://javaoperatorsdk.io/docs/dependent-resources)
+implementation, though [dependent resources](https://javaoperatorsdk.io/docs/documentation/dependent-resource-and-workflows/dependent-resources/)
 make that process easier.
 
 If you do need to clean such a state, you need to use finalizers so that their

docs/content/en/docs/migration/v3-1-migration.md

@@ -13,7 +13,7 @@ renamed accordingly.
 
 Version 3.1 comes with a workflow engine that replaces the previous behavior of managed dependent
 resources.
-See [Workflows documentation](https://javaoperatorsdk.io/docs/workflows) for further details.
+See [Workflows documentation](https://javaoperatorsdk.io/docs/documentation/dependent-resource-and-workflows/workflows/) for further details.
 The primary impact after upgrade is a change of the order in which managed dependent resources
 are reconciled. They are now reconciled in parallel with optional ordering defined using the
 ['depends_on'](https://github.com/java-operator-sdk/java-operator-sdk/blob/df44917ef81725c10bbcb772ab7b434d511b13b9/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/reconciler/dependent/Dependent.java#L23-L23)

docs/content/en/docs/migration/v4-4-migration.md

@@ -55,7 +55,7 @@ explicitly to the Operator constructor, it is now recommended to provide that va
 ## Using Server-Side Apply in Dependent Resources
 
 From this version by
-default [Dependent Resources](https://javaoperatorsdk.io/docs/dependent-resources) use
+default [Dependent Resources](https://javaoperatorsdk.io/docs/documentation/dependent-resource-and-workflows/dependent-resources/) use
 [Server Side Apply (SSA)](https://kubernetes.io/docs/reference/using-api/server-side-apply/) to
 create and
 update Kubernetes resources. A

docs/content/en/docs/migration/v4-5-migration.md

@@ -5,7 +5,7 @@ permalink: /docs/v4-5-migration
 ---
 
 Version 4.5 introduces improvements related to event handling for Dependent Resources, more precisely the
-[caching and event handling](https://javaoperatorsdk.io/docs/dependent-resources#caching-and-event-handling-in-kubernetesdependentresource)
+[caching and event handling](https://javaoperatorsdk.io/docs/documentation/dependent-resource-and-workflows/dependent-resources/#caching-and-event-handling-in-kubernetesdependentresource)
 features. As a result the Kubernetes resources managed using
 [KubernetesDependentResource](https://github.com/java-operator-sdk/java-operator-sdk/blob/73b1d8db926a24502c3a70da34f6bcac4f66b4eb/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/InformerEventSource.java#L72-L72)
 or its subclasses, will add an annotation recording the resource's version whenever JOSDK updates or creates such