xml-doclet
xml-doclet copied to clipboard
Rewrite using new Javadoc API
In Java 13 old doclet API (com.sun.javadoc
) is removed and only new doclet API (jdk.javadoc.doclet
) should be used.
This PR is rewrite using new API. It is a prototype which contains both old and new doclets and can be built using Java 11. To support Java 13 old doclet needs to be removed. New doclet passes all 55 tests and I also tested it (and compared with old doclet) on real project.
I am interested in this doclet because I am using its XML format in https://github.com/vojtechhabarta/typescript-generator. Please let me know if you have any plans with this project so I can decide how to make typescript-generator work on Java 13.
Thanks
[WARNING] Error injecting: org.codehaus.plexus.archiver.jar.JarArchiver
java.lang.ExceptionInInitializerError
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:86)
at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
at com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
at com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:89)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87)
at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at org.eclipse.sisu.inject.Guice4$1.get(Guice4.java:162)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:263)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:243)
at org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getArchiver(DefaultArchiverManager.java:63)
at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchiver(DefaultAssemblyArchiver.java:302)
at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:170)
at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1
at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.
Upping the version of the asembly plugin appears to resolve that issue
Also looks like it ignores
<additionalparam>-d ${project.build.directory} -filename javadoc.xml</additionalparam>
@red61wjt thanks for trying this PR.
Parameters -d
and -filename
are implemented.
When I pass those parameters in the following way it works:
<additionalOptions>-d ${project.build.directory} -filename test-javadoc.xml</additionalOptions>
Yup, that appears to fix it. Was that an intentional change to move from additionalparam to additionalOptions or was it undocumented feature that additionalparam worked before?
I think this was a change in javadoc itself.
When I used cyrillic in comments, these changes generated UTF-16 symbols, for example <comment>\u0418\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0440</comment>
I resolved it, added dependency org.apache.commons:commons-text, and wrapped "fullBody" with StringEscapeUtils.unescapeeEcmaScript(fullBody), and got the right format, for example <comment>идентификатор</comment>
, and it works right for latin comments.
Maybe this change is ugly hack, but I didn't find another resolution.
@russo595 thanks for sharing your solution. I think proper way to output unicode characters would be to create subclass of com.sun.tools.javac.tree.DocPretty
, override void print(Object s)
method to not escape unicode characters and use it in JavadocTransformer.transformJavadoc()
method. But unfortunately DocPretty
class is not accessible so I cannot use it and I didn't want to copy&paste this big chunk of code.
@vojtechhabarta Hi, any chance you would consider repackaging your version of the xmldoclet under your own Maven coordinates and posting to central please? I have a really tough job trying to get our students Javadocs reformatted into Word for their project write-ups. Having JavaDoc -> XML -> XSLT -> Lots would provide a workable solution for us and a lot of others. If not, would you object if I did?
any chance you would consider repackaging your version of the xmldoclet under your own Maven coordinates and posting to central please?
Greetings. I have done exactly that: https://github.com/manticore-projects/xml-doclet
<docletArtifact>
<groupId>com.manticore-projects.tools</groupId>
<artifactId>xml-doclet</artifactId>
<version>1.1.3</version>
</docletArtifact>