KEMBAR78
Allow package exclusions and inclusions in javadocs by vinnybod · Pull Request #1293 · bazel-contrib/rules_jvm_external · GitHub
Skip to content

Conversation

@vinnybod
Copy link
Contributor

@vinnybod vinnybod commented Dec 5, 2024

There are times where developers want to exclude specific packages from being generated in the javadocs such as internal code. This is commonly offered as a feature of javadoc generation in both maven and gradle.

An exact package can be provided to remove the first level of files, or a .* to remove all subpackages under it.

java_export(
  ...
  doc_excluded_packages = [
    "com.example.internal.*"
  ]
)
java_export(
  ...
  doc_included_packages = [
    "com.example.processor.*"
  ],
  doc_excluded_packages = [
    "com.example.processor.internal.*"
  ]
)

updated_deploy_env = deploy_env + [KOTLIN_STDLIB]
else:
updated_deploy_env = deploy_env
updated_excluded_workspaces = {name: None for name in excluded_workspaces}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

deploy_env gets added back into the docs so we were generating docs for kotlin stdlib which seems wrong. Changed to excluded_workspace to keep it out of the docs, which seems like what was actually intended.
This is also how we handle scala_export in confluent's fork of rules_jvm_external.

@vinnybod
Copy link
Contributor Author

vinnybod commented Dec 6, 2024

Hm, only windows is failing. not sure why

Copy link
Collaborator

@shs96c shs96c left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm slightly worried by the sheer number of parameters appearing on java_export, but I can see why this is needed. Thank you for the PR!

@shs96c shs96c merged commit aa82071 into bazel-contrib:master Jun 26, 2025
7 checks passed
shs96c added a commit to jin/rules_jvm_external that referenced this pull request Jul 4, 2025
* master: (39 commits)
  Fix resolution of Android/AAR artifacts with Gradle resolver (bazel-contrib#1395)
  fail_if_repin_required is now True by default and minor improvement to failure message (bazel-contrib#1397)
  Housekeeping before we release 6.8 (bazel-contrib#1384)
  Add dll, dylib and so types to maven package mappings (bazel-contrib#1392)
  [bzlmod] Allow suppressing warning about multiple contributing modules. (bazel-contrib#1393)
  Use the artifact default values when adding them to a struct and add tests for coursier artifacts that have empty versions provided by BOMs and don't inlcude them in outdated (bazel-contrib#1390)
  Allow package exclusions and inclusions in javadocs (bazel-contrib#1293)
  Document well-known issues with `bzlmod` (bazel-contrib#1388)
  Begin documenting the gradle resolver (bazel-contrib#1389)
  Run gradle regression tests in CI (bazel-contrib#1385)
  Modify maven_export to allow exporting zip archives (bazel-contrib#1368)
  Allow root module's override tags to take precedence over the overridees from transitive deps. (bazel-contrib#1381)
  Ensure root module artifacts and boms take precedence with warnings (bazel-contrib#1373)
  Update maven-metadata.xml when publishing locally (bazel-contrib#1369)
  Add support for gradle resolver (bazel-contrib#1357)
  Prepare for 6.8 release (bazel-contrib#1380)
  Remove the Windows `kt_jvm_export` example (bazel-contrib#1383)
  Avoid spurious warnings about poorly formatted artifact coordinates (bazel-contrib#1374)
  Flip `fail_if_repin_required` to `True` by default (bazel-contrib#1371)
  Allow the same coordinate to be overridden in different repos (bazel-contrib#1378)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants