fix: update docFX config #744
Conversation
| <outputpath>${project.build.directory}/docfx-yml</outputpath> | ||
| <projectname>${project.artifactId}</projectname> | ||
| <excludeclasses></excludeclasses> | ||
| <excludePackages></excludePackages> |
There was a problem hiding this comment.
Are there repos that depend on overwriting this value to get the behavior they want out of the plugin? Does removing it from additionalOptions thus break them?
There was a problem hiding this comment.
Yes, some of the handwritten repos have a custom DocFx profile, like java-bigtable: https://github.com/googleapis/java-bigtable/blob/main/pom.xml#L322
However, their profiles are configured to include any excluded classes and packages which should overwrite the entire default profile, so I don't think removing these additional options here will affect them.
| <properties> | ||
| <!-- default config values --> | ||
| <docletName>java-docfx-doclet-1.9.0</docletName> | ||
| <docletPath>${env.KOKORO_GFILE_DIR}/${docletName}.jar</docletPath> |
There was a problem hiding this comment.
I thought this docletPath specifies the JAR file that has implementation of java-docfx-doclet. Don't we still need this?
There was a problem hiding this comment.
We're setting the docletPath directly in the script that publishes the Cloud RAD tarballs here: https://source.corp.google.com/piper///depot/google3/cloud/sdk/client_libraries/kokoro/java/googleapis/java-cloud-bom/release/publish_javadoc17.sh;l=45
so I don't think this is needed.
3 participants
This should fix #680
The issue is that starting with maven-javadoc-plugin v3.6.0, passing in null parameters into caused javadoc generation to fail. This PR removes that parameter and also updates the javadoc source to use Java 17 source as that is what we're publishing javadocs with now.