ci: streamline enforcer job and update version requirements

[lqiu96]

Summary

Reduces the CI enforcer job runtime from ~20+ minutes down to ~15 seconds by removing the banDuplicateClasses rule and eliminating the full-repo mvn install step.

Key Changes

• Remove banDuplicateClasses rule: The banDuplicateClasses rule in java-shared-config required compiled dependency .jar files to exist on disk to inspect bytecode, which forced CI to compile and install all 285+ modules before checking enforcer rules. Removing it allows mvn enforcer:enforce to run purely on POM dependencies in memory.
• Streamline CI enforcer workflow: In .github/workflows/ci.yaml, removed the Install Maven modules to local Maven repository (JOB_TYPE: install) step, invoking mvn -B -ntp enforcer:enforce@enforce -T 1C directly.
• Update required versions: Updated requireMavenVersion to [3.9.0,) and requireJavaVersion to [1.8,) in java-shared-config.
• Skip enforcer on java-samples: Added <enforcer.skip>true</enforcer.skip> to java-samples/pom.xml to match other non-released sample module configurations.

Verification

• mvn -B -ntp enforcer:enforce@enforce -T 1C executed across all 285 modules cleanly in ~6–15 seconds without requiring any prior installation.

With strict dependency governance policies inside the Java SDK, we ensure that we do not introduce duplicate dependencies or dependencies with overlapping package names. Running banDuplicateClasses with a full mvn install locally is overkill given that we rarely introduce new dependencies.

[gemini-code-assist]

Code Review

This pull request configures java-samples to skip the enforcer plugin, updates the minimum Maven and Java version requirements in the shared configuration, and removes the banDuplicateClasses rule. The reviewer noted that removing the banDuplicateClasses rule completely exposes downstream projects to classpath conflicts and suggested instead moving it to a separate profile or execution phase to maintain protection without slowing down PR checks.

I am having trouble creating individual review comments. Click here to see my feedback.

java-shared-config/java-shared-config/pom.xml (257-264)

Removing the banDuplicateClasses rule entirely from the shared configuration eliminates protection against classpath conflicts (JAR hell) for all downstream projects inheriting this configuration. While this significantly speeds up the CI enforcer job by avoiding bytecode inspection of compiled dependencies, completely disabling this check increases the risk of duplicate classes causing runtime issues (such as LinkageError or NoSuchMethodError).

Consider keeping this rule but binding it to a separate execution or a profile (e.g., activated only during release or packaging phases) so that it doesn't block fast PR checks but still runs before releases.