stevedlawrence commented on code in PR #1237:
URL: https://github.com/apache/daffodil/pull/1237#discussion_r1601493507
##########
build.sbt:
##########
@@ -53,6 +54,8 @@ lazy val daffodil = project
udf
)
.settings(commonSettings, nopublish, ratSettings, unidocSettings,
genCExamplesSettings)
+ .settings(javadocSettings: _*) // for genjavadoc to create javadoc from
scala code
Review Comment:
I've just pushed a change that I think fixes the CI, looks like the CI is
passing so far.
This fixes it by disabling publishing of -doc jar artifacts, including
genjavadoc artifacts. We don't really need these and people probably shouldn't
reference them anyways. They should use the public API published on our
website. The reason this works:
There is no way to filter out what GenJavadoc generates. When SBT compiles a
scala file with the genjavadoc compiler plugin enabled it is going to generate
a java file for it, no matter what. For complex scala files like in runtime1,
this can sometimes generate invalid java files that cause scala/javadoc to
fail. And when scaladoc/javadoc is run it's going to cause a failure.
However, we use unidoc which runs on a subset of files (thanks to the new
filtering) so these invalid files should be ignored. However, when publishing
jars (which a number a tasks can trigger like publishLocal, daffodil-cli/stage,
etc.), it also publishes -doc artifacts for each project. These doc artifacts
do not use the same filtering as unidoc, so they end up using these invalid
files and cause the failure.
Removing the PublishJavaDocPlugin is probably sufficient to cause it to
ignore these invalid java files when publishing -doc artifacts, but really we
don't need to be publishing any docs.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
