Question

I would like to be able to generate javadoc for my maven projects even when running under a JRE instead of a JDK, where the javadoc command invoked by maven is found. In other words, not relying on anything but what is in the JRE and what Maven can download and use as artifacts.

Is there any easy way to generate javadocs at all with Maven without needing to use code only found in the JDK?


EDIT: Apparently it is important to understand why I want to do this. We are a small team in a larger organization with yearly releases of our product suite, which our customers then upgrade when it is convenient for them (due to the sheer scale of the deployments this is expensive and time demanding, so it is common to skip one or several releases) and we make a living of being able to provide bugfixes and new functionality on short notice for existing deployments on whatever version the customer in question is running. As an example I recently did a bugfix for a component I wrote five years ago which had been largely untouched since.

Hence long term stability of our build process is very important to us as well as being able to use new versions of Java as they become available. We have migrated our complete build environment to Maven - which buys us permanently frozen artifacts in Maven Central - and have now started to look at what else we need to do.

With the recent announcement that future versions of javac will not support old targets (http://openjdk.java.net/jeps/182) we have concluded that our long term goal is to minimize our dependencies on the underlying Java environment, preferably to just the plain JRE. We are in the process of completely replacing javac from the JDK with the Eclipse compiler which is available from Maven Central, and now we look at javadoc generation.

Was it helpful?

Solution

Get the source of the JavaDoc from the OpenJDK, and build your own JAR from it with all the relevant JavaDoc classes. Write a maven plugin that relies on your JAR, and call com.sun.tools.javadoc.Main.main from it.

It does not look like you need to open up your sources when using OpenJDK's classes, you should be OK to distribute the resultant plug-in without harsh restrictions.

Even if the terms do not cover the tools, you could write an Open Source GPL-2 plugin for maven, and make it a separate product that you distribute under GPL-2. Your product would then download and install the plugin using maven plugin:download, thus separating out your JavaDoc plugin from the rest of your code.

Of course you should run this suggestion by your legal department before following this advice.

OTHER TIPS

  1. An aside (not answering your Q directly):

    The Eclipse Development Guide recommends using both the Eclipse compiler and the JDK tool (for the javadoc menu option).

    http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-export-javadoc.htm

    Eclipse Generate Javadoc Wizard: what is "Javadoc Command"?

    From your comments, it's clear you don't want to go this way, which is your right :)

  2. Answer to your Q. There a few open source / free javadoc tools that you can invoke from your build tool:

    Pros: Work outside of JDK. Some have richer documentation than javadoc.
    Cons: Might have some non-standard behaviour compared to javadoc (might not be an issue for you).

You can use a product called doxygen. It is typically used to create documentation for C++ or other languages that don't have a javadoc product built-in.

You can set up doxygen to read the javadoc annotations and product similar output to javadoc.

The command that generates the java docs is actually called javadoc and it is only available with the JDK.

From the Javadoc FAQ :

String[] javadocargs = { "-d", "docs",
                         "-sourcepath", "/home/user/src",
                         "java.applet" };
com.sun.tools.javadoc.Main.main(javadocargs);

tools.jar needs to be in your classpath.

We offer a tool called DocFlex/Javadoc, which is already mentioned here by Glen Best (although a little bit incorrectly).

But before going deep into this, I would like to provide some intro to what this is all about.

Basically, Javadoc (that is provided by JDK) is a caller of two things:

  1. The Java parser
  2. A doclet

Javadoc starts by calling the Java parser to collect information about Java sources, from which it builds a DOM-like structure represented in the form of Doclet API. Then, it calls a doclet. This is a Javadoc plug-in that uses Doclet API as a data-source to generate by it any kind of output.

What you see as the standard JavaDoc is generate by the Standard Doclet. So, you can imagine that doclet is the largest part of the whole Javadoc implementation.

Now, about our DocFlex/Javadoc software. Essentially, it is a tool for fast development of special doclets, which utilizes our much more general technology for template-driven documentation generators. (Actually, our focus is rather away from Javadoc stuff. So, it is more a by-product of the main thing).

In our interpretation, the doclets themselves (as documentation generators) are programmed in the form of special template sets. Those templates are more akin to XSLT scripts, but conceptualy only (we do not use XSLT somewhere in background). The DOM-like organization of the Doclet API allowed us to utilize an XSLT/XPath-like approach general to our technology. So, each doclet consists of two things:

  1. The template interpretor
  2. A template set

Here, the template set is an interchangable part (which is actually the focus of our tool).

Currently, we provide a ready-to-use JavadocPro template set, which generates HTML output equivalent to the standard JavaDocs (with some important extra-features not available in the Standard Doclet). Here, you can see a demo JavaDoc generated with it:

enter image description here

The whole DocFlex/Javadoc is a commercial product. But we also provide a light edition of it called DocFlex/Doclet, which is free. It includes only template interpreter and some ready template sets (including JavadocPro). So, you can use it to generate JavaDoc very similar to the standard one (in HTML) as well as RTF documentation.


Now, concerning the main question. Can our tool be used without JDK?

No. Because, as being a Javadoc plug-in (the doclet part of our tool), it still needs Javadoc.

On the other hand, what is missing to make it fully JDK independent is a Java parser, and we don't need a full-blown Java parser at that, because we are not generating an executable code. What we need is something lightweight, able to build a structure like Doclet API.

If we knew what a demand for such a thing might be, we could consider developing one. Any further questions? Let us know by email (found on our website)!

why don't you download javadoc source at http://docs.oracle.com/javase/6/docs/technotes/guides/javadoc/standard-doclet.html#source

and rebuild it to suit you needs in maven

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top