improve: integration test for corner case for activation condition

[csviri]

Signed-off-by: Attila Mészáros a_meszaros@apple.com

[Copilot]

Pull request overview

This PR updates the onedependentactivationcondition integration-test scenario to exercise a corner case where a dependent resource type is “not available” (via a custom resource type) while its activation condition prevents it from being reconciled.

Changes:

• Switch the workflow dependent in OneDependentActivationConditionReconciler from a ConfigMap-based dependent to NotAvailableDependentResource.
• Update the dependent resource implementation to target a new NotAvailableCustomResource type.
• Add NotAvailableCustomResource test CRD type.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
operator-framework/src/test/java/io/javaoperatorsdk/operator/workflow/onedependentactivationcondition/OneDependentActivationConditionReconciler.java	Switches workflow dependent type to NotAvailableDependentResource to test the “not available dependent” corner case.
operator-framework/src/test/java/io/javaoperatorsdk/operator/workflow/onedependentactivationcondition/NotAvailableDependentResource.java	Updates dependent to produce NotAvailableCustomResource instead of a ConfigMap.
operator-framework/src/test/java/io/javaoperatorsdk/operator/workflow/onedependentactivationcondition/NotAvailableCustomResource.java	Introduces a new test CustomResource type used by the dependent.

[Copilot]

The dependent type was switched to NotAvailableDependentResource, but the rest of this test scenario still appears to be based on a ConfigMap dependent (e.g., FalseActivationCondition is parameterized with ConfigMap and the IT checks that no ConfigMap is created). As-is, the integration test likely no longer validates the intended corner case; update the activation condition and assertions to align with the new dependent resource type (or otherwise assert the new failure mode you intend to cover).

[Copilot]

This new NotAvailableCustomResource has the same Kind/name-derived CRD (same group sample.javaoperatorsdk and same class name → same plural) as the existing io.javaoperatorsdk.operator.workflow.preconditionandactivation.NotAvailableCustomResource. Because the crd-generator-maven-plugin scans the entire test output directory, this can result in duplicate/overwritten generated CRD YAML (same META-INF/fabric8/notavailablecustomresources.sample.javaoperatorsdk-v1.yml), making builds/tests flaky. Use a unique class name and/or @Group/@Plural to ensure a distinct CRD name, or reuse the existing test custom resource type instead of introducing a duplicate.

Suggested change

	import io.fabric8.kubernetes.model.annotation.Group;
	import io.fabric8.kubernetes.model.annotation.ShortNames;
	import io.fabric8.kubernetes.model.annotation.Version;
	@Group("sample.javaoperatorsdk")
	@Version("v1")
	import io.fabric8.kubernetes.model.annotation.Group;
	import io.fabric8.kubernetes.model.annotation.Plural;
	import io.fabric8.kubernetes.model.annotation.ShortNames;
	import io.fabric8.kubernetes.model.annotation.Version;
	@Group("sample.javaoperatorsdk")
	@Version("v1")
	@Plural("onedependentactivationconditionnotavailablecustomresources")