Search Results

Search found 8 results on 1 pages for 'doclet'.

Page 1/1 | 1 

  • Java XHTML Doclet: fatal exception

    - by Cheeso
    Has anyone used XHTML Doclet, and can you provide some hints as to how to get it to work successfully? I run it like this: \sunjdk\bin\javadoc -doclet net.sourceforge.xhtmldoclet.Doclet -docletpath c:\sw\java\XHTML_Doclet_0.4.jar -d <output> [class files here] (all on one line) When I run it I get this: javadoc: error - In doclet class net.sourceforge.xhtmldoclet.Doclet, method validOptions has thrown an exception java.lang.reflect.InvocationTargetException java.lang.Error: Fatal: Resource (net.sourceforge.xhtmldoclet.resources.doclet) for javadoc doclets is missing. at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:110) at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:92) at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:81) at com.sun.tools.doclets.internal.toolkit.Configuration.getText(Configuration.java:634) at com.sun.tools.doclets.internal.toolkit.Configuration.generalValidOptions(Configuration.java:515) at net.sourceforge.xhtmldoclet.Config.validOptions(Unknown Source) at net.sourceforge.xhtmldoclet.Doclet.validOptions(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) at com.sun.tools.javadoc.DocletInvoker.validOptions(DocletInvoker.java:198) at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:317) at com.sun.tools.javadoc.Start.begin(Start.java:128) at com.sun.tools.javadoc.Main.execute(Main.java:41) at com.sun.tools.javadoc.Main.main(Main.java:31) 1 error It seems like it ought to just work. What am I doing wrong?

    Read the article

  • JavaDoc to (Doku)Wiki conversion / doclet

    - by gamma
    Our company has a very large public Java API which is currently being released standalone and online using (of course) JavaDoc. It is surrounded by product documentation which links into the API. We are moving our static documentation to DokuWiki - which works pretty good - and want to keep the links. Now it would be good to have a method (or doclet) that exports the JavaDoc directly into DokuWiki - or a very near alternative. Question: Is there something like this or do you know a method to do just that?

    Read the article

  • Java: How can I create good looking class docs with Javadoc?

    - by Cheeso
    I'd like to create HTNML documentation for a Java class library that includes programming guide information - beyond just a class reference code examples in the reference doc collapsible regions I want it to look well-styled. Something like this: I think that Javadoc exposes a doclet API that allows other parties to provide doc generation integrated in Javadoc. Is there a doclet option that I can use (for free) that does something a little nicer than the standard javadoc output? I tried googling for this but no luck. Suggestions?

    Read the article

  • How to generate android styled javadocs ?

    - by Kaillash
    Hi, Is it possible to generate android styled javadocs for my android project (like http://developer.android.com/reference/java/lang/String.html, instead of http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html) Is it something regarding using of some custom doclet instead of standard doclet? If yes, then which one I have to use?

    Read the article

  • Warning on missing custom javadoc tags

    - by flumins
    We create a custom Doclet for our projet to generate a specific documentation for our client. We define some specific tags that are parsed by the doclet when we generate the documentation. Do you know how to ask eclipse to add warning when those special tags are missing in our javadoc comments ? Example of well formed javadoc: /** * @dialogName TECK-01-E-608 * @useVO ServiceVO * @useVO AgentVO */ public class MyDialog extends BaseDialogImpl { ... If @dialogName is missing, the developper should have a warning in eclipse... I look checkstyle a little bit, but I don't understand how to configure it to do such a thing. Thanks in advance for your help.

    Read the article

  • Java source code generation frameworks

    - by Superfilin
    I have a set of Java 5 source files with old-style Doclet tags, comments and annotations. And based on that I would like to write a generator for another set of Java classes. What is the best way to do that? And are there any good standalone libraries for code analysis/generation in Java? Any shared exprience in this field is appreciated. So, far I have found these: JaxME's Java Source Reflection - seems good, but it does not seem to support annotations. Also it had no release since 2006. Annogen - uses JDK's Doclet generator, which has some bugs under 1.5 JDK. Also it had no releases for a long time. Javaparser - seems good as well and pretty recent, but only supports Visitor pattern for a single class i.e. no query mechanism like in the 2 above packages.

    Read the article

  • JDK bug migration: components and subcomponents

    - by darcy
    One subtask of the JDK migration from the legacy bug tracking system to JIRA was reclassifying bugs from a three-level taxonomy in the legacy system, (product, category, subcategory), to a fundamentally two-level scheme in our customized JIRA instance, (component, subcomponent). In the JDK JIRA system, there is technically a third project-level classification, but by design a large majority of JDK-related bugs were migrated into a single "JDK" project. In the end, over 450 legacy subcategories were simplified into about 120 subcomponents in JIRA. The 120 subcomponents are distributed among 17 components. A rule of thumb used was that a subcategory had to have at least 50 bugs in it for it to be retained. Below is a listing the component / subcomponent classification of the JDK JIRA project along with some notes and guidance on which OpenJDK email addresses cover different areas. Eventually, a separate incidents project to host new issues filed at bugs.sun.com will use a slightly simplified version of this scheme. The preponderance of bugs and subcomponents for the JDK are in library-related areas, with components named foo-libs and subcomponents primarily named after packages. While there was an overall condensation of subcomponents in the migration, in some cases long-standing informal divisions in core libraries based on naming conventions in the description were promoted to formal subcomponents. For example, hundreds of bugs in the java.util subcomponent whose descriptions started with "(coll)" were moved into java.util:collections. Likewise, java.lang bugs starting with "(reflect)" and "(proxy)" were moved into java.lang:reflect. client-libs (Predominantly discussed on 2d-dev and awt-dev and swing-dev.) 2d demo java.awt java.awt:i18n java.beans (See beans-dev.) javax.accessibility javax.imageio javax.sound (See sound-dev.) javax.swing core-libs (See core-libs-dev.) java.io java.io:serialization java.lang java.lang.invoke java.lang:class_loading java.lang:reflect java.math java.net java.nio (Discussed on nio-dev.) java.nio.charsets java.rmi java.sql java.sql:bridge java.text java.util java.util.concurrent java.util.jar java.util.logging java.util.regex java.util:collections java.util:i18n javax.annotation.processing javax.lang.model javax.naming (JNDI) javax.script javax.script:javascript javax.sql org.openjdk.jigsaw (See jigsaw-dev.) security-libs (See security-dev.) java.security javax.crypto (JCE: includes SunJCE/MSCAPI/UCRYPTO/ECC) javax.crypto:pkcs11 (JCE: PKCS11 only) javax.net.ssl (JSSE, includes javax.security.cert) javax.security javax.smartcardio javax.xml.crypto org.ietf.jgss org.ietf.jgss:krb5 other-libs corba corba:idl corba:orb corba:rmi-iiop javadb other (When no other subcomponent is more appropriate; use judiciously.) Most of the subcomponents in the xml component are related to jaxp. xml jax-ws jaxb javax.xml.parsers (JAXP) javax.xml.stream (JAXP) javax.xml.transform (JAXP) javax.xml.validation (JAXP) javax.xml.xpath (JAXP) jaxp (JAXP) org.w3c.dom (JAXP) org.xml.sax (JAXP) For OpenJDK, most JVM-related bugs are connected to the HotSpot Java virtual machine. hotspot (See hotspot-dev.) build compiler (See hotspot-compiler-dev.) gc (garbage collection, see hotspot-gc-dev.) jfr (Java Flight Recorder) jni (Java Native Interface) jvmti (JVM Tool Interface) mvm (Multi-Tasking Virtual Machine) runtime (See hotspot-runtime-dev.) svc (Servicability) test core-svc (See serviceability-dev.) debugger java.lang.instrument java.lang.management javax.management tools The full JDK bug database contains entries related to legacy virtual machines that predate HotSpot as well as retired APIs. vm-legacy jit (Sun Exact VM) jit_symantec (Symantec VM, before Exact VM) jvmdi (JVM Debug Interface ) jvmpi (JVM Profiler Interface ) runtime (Exact VM Runtime) Notable command line tools in the $JDK/bin directory have corresponding subcomponents. tools appletviewer apt (See compiler-dev.) hprof jar javac (See compiler-dev.) javadoc(tool) (See compiler-dev.) javah (See compiler-dev.) javap (See compiler-dev.) jconsole launcher updaters (Timezone updaters, etc.) visualvm Some aspects of JDK infrastructure directly affect JDK Hg repositories, but other do not. infrastructure build (See build-dev and build-infra-dev.) licensing (Covers updates to the third party readme, licenses, and similar files.) release_eng (Release engineering) staging (Staging of web pages related to JDK releases.) The specification subcomponent encompasses the formal language and virtual machine specifications. specification language (The Java Language Specification) vm (The Java Virtual Machine Specification) The code for the deploy and install areas is not currently included in OpenJDK. deploy deployment_toolkit plugin webstart install auto_update install servicetags In the JDK, there are a number of cross-cutting concerns whose organization is essentially orthogonal to other areas. Since these areas generally have dedicated teams working on them, it is easier to find bugs of interest if these bugs are grouped first by their cross-cutting component rather than by the affected technology. docs doclet guides hotspot release_notes tools tutorial embedded build hotspot libraries globalization locale-data translation performance hotspot libraries The list of subcomponents will no doubt grow over time, but my inclination is to resist that growth since the addition of each subcomponent makes the system as a whole more complicated and harder to use. When the system gets closer to being externalized, I plan to post more blog entries describing recommended use of various custom fields in the JDK project.

    Read the article

1