Enable Gradle module metadata for test-fixtures modules

[dushyantk1509]

Summary

GenerateModuleMetadata is disabled globally to prevent shadow jar modules from exposing unshaded dependencies via .module files. However, this also prevents .module files from being published for modules with test fixtures. Without the .module file, Gradle has no way to discover the test-fixtures variant. Consumers that depend on testFixtures(common) fail with:

---

Unable to find a variant of com.linkedin.openhouse:common:0.5.364-SNAPSHOT
providing the requested capability com.linkedin.openhouse:common-test-fixtures:
- Variant compile provides com.linkedin.openhouse:common:0.5.364-SNAPSHOT
- Variant runtime provides com.linkedin.openhouse:common:0.5.364-SNAPSHOT
- Variant sources provides com.linkedin.openhouse:common:0.5.364-SNAPSHOT
- Variant javadoc provides com.linkedin.openhouse:common:0.5.364-SNAPSHOT
- Variant platform-compile provides com.linkedin.openhouse:common-derived-platform:0.5.364-SNAPSHOT
- Variant platform-runtime provides com.linkedin.openhouse:common-derived-platform:0.5.364-SNAPSHOT
- Variant enforced-platform-compile provides com.linkedin.openhouse:common-derived-enforced-platform:0.5.364-SNAPSHOT
- Variant enforced-platform-runtime provides com.linkedin.openhouse:common-derived-enforced-platform:0.5.364-SNAPSHOT

---

This blocks local development workflows where developers publish to mavenLocal via publishToMavenLocal and consume from downstream projects. Developers need to add this code block.

After the global disable, add an afterEvaluate block that re-enables GenerateModuleMetadata for modules with the java-test-fixtures plugin. This is safe because:

• Only two modules are affected: common and internalcatalog
• Neither is a shadow jar module — their .module metadata accurately describes their dependencies
• The .module file provides the same dependency information as the POM (PR Use java-library plugin and api configuration for correct POM scopes #470 already aligned scopes via implementation → api), plus the
  test-fixtures variant that the POM cannot express
• Shadow jar modules are unaffected — they don't apply java-test-fixtures

Changes

• Client-facing API Changes
• Internal API Changes
• Bug Fixes
• New Features
• Performance Improvements
• Code Style
• Refactoring
• Documentation
• Tests - Local testing.

For all the boxes checked, please include additional details of the changes made in this pull request.

Testing Done

• Manually Tested on local docker setup. Please include commands ran, and their output.
• Added new tests for the changes made.
• Updated existing tests to reflect the changes made.
• No tests added or updated. Please explain why. If unsure, please feel free to ask for help.
• Some other form of testing like staging or soak time in production. Please explain. - publishToMavenLocal produces .module files for common and internalcatalog && Downstream consumer successfully resolves testFixtures(common) from mavenLocal.

For all the boxes checked, include a detailed description of the testing done for the changes made in this pull request.

Additional Information

• Breaking Changes
• Deprecations
• Large PR broken into smaller PRs, and PR plan linked in the description.

For all the boxes checked, include additional details of the changes made in this pull request.

[cbb330]

Thanks for this change, really happy to see improvements to the dev experience ❤️

Instead of the global disable + selective re-enable for test-fixtures, consider targeting only shadow jar modules:

pluginManager.withPlugin('com.github.johnrengelman.shadow') {
  tasks.withType(GenerateModuleMetadata) {
    enabled = false
  }
}

This replaces both the existing global disable and the new afterEvaluate block. Module metadata stays enabled by default (as Gradle intends), and only gets suppressed where it's actually problematic. Then, test fixtures just work without needing to remember to add them to the special exception.

The impliciation is that non-shadow, non-test-fixture modules (like services/tables, cluster/storage, etc.) would now gain a .module file where they didn't have one before. But... should be harmless since their metadata is accurate, and Gradle falls back gracefully between .module and POM