When you have built the F!F and there is an error with the Frank!Doc, you do not have the trace logs. The build of the Frank!Doc hard-codes log-level INFO. You have to rebuild the Frank!Doc on your development PC with a temporary change of log4j2.xml. After that, you have to rebuild the F!F to get the trace logs.
Two improvements are possible:
The F!F build should provide an option to adjust the log level applied by the Frank!Doc doclet.
The F!F should have the doclet produce trace logs by default, but these trace logs should not clutter the console output. If you see from the console output that there is a Frank!Doc issue, it should not be necessary to repeat the build to have the traces. It would also be useful if the GitHub tests save the Frank!Doc trace logs as artifacts. This allows for quick analysis of failed builds, without needing an additional build on a developer computer.
The second option may be complicated, because the default output directory of the Frank!Doc is target/frankdoc as is configured in the F!F pom.xml. The frank-doc-plugin takes care of attaching the contents of target/frankdoc to the JAR of the core subproject. This logic has to change, because the Frank!Doc logs appear in target/frankdoc but should not be attached to the JAR.
@nielsm5 and @gvanbrakel, what do you think most useful and efficient?
When you have built the F!F and there is an error with the Frank!Doc, you do not have the trace logs. The build of the Frank!Doc hard-codes log-level INFO. You have to rebuild the Frank!Doc on your development PC with a temporary change of
log4j2.xml. After that, you have to rebuild the F!F to get the trace logs.Two improvements are possible:
The second option may be complicated, because the default output directory of the Frank!Doc is
target/frankdocas is configured in the F!Fpom.xml. The frank-doc-plugin takes care of attaching the contents oftarget/frankdocto the JAR of the core subproject. This logic has to change, because the Frank!Doc logs appear intarget/frankdocbut should not be attached to the JAR.@nielsm5 and @gvanbrakel, what do you think most useful and efficient?