Thanks Jon. It is a pity there is so little flexibility around the standard doclet (or its HTML producer) because rewriting everything from scratch is out of question. I'll take a look at getting it to work via tool provider - thank you for the hint!
D. On Thu, May 7, 2020 at 4:33 PM Jonathan Gibbons <jonathan.gibb...@oracle.com> wrote: > > Dawid, > > The issue about being difficult to subtype the StandardDoclet is a > known issue. > > You should be able to provide your own file manager if you invoke > javadoc via the API available in javax.tools. > > https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/tools/ToolProvider.html#getSystemDocumentationTool() > > -- Jon > > > On 5/7/20 1:29 AM, Dawid Weiss wrote: > > Hello everyone, > > > > I had a somewhat wild idea of trying to modify the behavior of the > > StandardDoclet to write directly to a ZIP file (instead of the file > > system). All the pieces fall into place relatively easily: > > > > 1) Create a custom Doclet that extends (public) StandardDoclet and > > overrides the run method with: > > > > public boolean run(DocletEnvironment docEnv) { > > return super.run(new CustomEnvironment(docEnv)); > > } > > > > 2) CustomEnvironment delegates everything to docEnv except it returns > > a ForwardingJavaFileManager over the docEnv.getJavaFileManager with a > > bunch of "get*Input" methods substituted. > > > > > > The only problem is - it doesn't work. :) Internally WorkArounds has a > > cast to an internal implementation type: > > > > public WorkArounds(BaseConfiguration configuration) { > > [...] > > this.toolEnv = ((DocEnvImpl)this.configuration.docEnv).toolEnv; > > } > > > > And it's a showstopper (maybe there are others but I didn't have a > > chance to try). > > > > Is there any way forward out of this (or an alternative take I can try)? > > > > Dawid
