I'm looking for a way to convert the javadocs from my open source project (generated in Eclipse) to GitHub MarkDown, or come up with some other simple solution to display my documentation on GitHub (shy of simply adding a docs
directory). Is there a simple solution for this? Can I simply point the GitHub README.md
to my docs
directory? Is there something more elegant? I have been striking out on Google.

- 35,852
- 23
- 123
- 164
-
1I guess you can do it using maven site also. http://stackoverflow.com/questions/3939595/making-javadocs-available-with-github-sonatype-maven-repo might help you. – Jeevan Patil Mar 12 '13 at 09:21
-
In the past, I've used [GitHub Pages](http://pages.github.com/) for publishing JavaDocs. It was ugly, but it worked. – Fred Foo Mar 12 '13 at 13:44
4 Answers
I don't think it's possible to make a usable Javadoc with MarkDown. The best solution is probably to commit the Javadoc you generated on the gh-pages
branch (or in the docs/
directory depending on the settings of your GitHub project). It will be available at :
http://username.github.io/projectname
Here is an example from one of my projects:
http://ebourg.github.io/jsign/apidocs/
I used to do this but nowadays I just rely on javadoc.io to host the Javadoc:
https://javadoc.io/doc/net.jsign/jsign/
The documentation is picked automatically from Maven Central, this saves the extra step of commiting the files into the Git repository when preparing a new release.

- 9,601
- 3
- 48
- 76
-
3This is so close to being useful, but not quite! My overview documentation is in Asciidoc documents which contains cross-references to the API documentation, which is auto-generated from the source code, and both contain cross-references to the actual source lines. But of course the source and documentation evolve over time as the project grows, so the API documentation needs to be versioned and live on the same branch as the source and other docs. There is no way to do that with gh-pages, which is its own separate branch. – James Elliott Jan 19 '16 at 16:13
-
-
@EmmanuelBourg can you elaborate on how that would work? What I have ended up doing is creating subdirectories within gh-pages/api-doc for each release, and using a shell script with sed to update the asciidoc cross-references to the appropriate gh-pages/api-doc/version when cutting the release. – James Elliott Jan 25 '16 at 16:38
-
@JamesElliott It's now possible to host the pages of the project's site on the same branch as the code under the `docs/` directory. This can be enabled from the project settings. – Emmanuel Bourg Jan 18 '17 at 16:15
-
1Hmm, all I can see is the option to host GitHub pages from the master branch /docs folder as shown in the Oct 19, 2016 answer. Maybe I am looking in the wrong place? My current solution of using shell scripts to edit my documentation to link to version-specific releases that I self-host on AWS is working well enough for now, but self-contained in the branch would be nicer. – James Elliott Jan 19 '17 at 20:00
-
your javadoc is generate on your computer and you commit the new javadoc on docs folder? or your travis ci do it automatically? – Stéphane GRILLON Jul 13 '17 at 12:24
-
@sgrillon I generate and commit the javadoc manually every time I publish a new release. – Emmanuel Bourg Jul 16 '17 at 22:11
Currently you can also host your Javadoc with Github Pages from not only a gh-pages
branch, but directly from the /docs
folder within your master
branch. You can check the help section on this topic, here (also check attached image below).
Also, there's a project on Github that targets some conversion of Javadoc to Markdown (have not tried it yet, just leaving the reference).

- 1,549
- 14
- 19
-
This, plus rsync-ing my maven target/site/apidocs/ directory to docs/, works perfectly for me. Thanks! – awwsmm Mar 05 '18 at 11:26
-
I downvoted this answer after I tried checking javadocs into the /docs folder in the master branch of several projects for a year. It made it too difficult to review diffs. I even made a script to update less of the Javadoc, but it still was a mess. – GlenPeterson Feb 13 '19 at 14:51
Do NOT check Javadocs into the source control for your project
Especially not into the master
branch! I followed the other answers to this question for about a year before deciding it was a really bad idea. Why?
It made it too difficult to review diffs. I even made a script (see below) to update only the Javadoc pages that substantially changed, but it still was a mess.
It fooled IntelliJ's refactoring tools. I just tried to change .x() to .getX() and had to approve/reject every "x" in the Javadocs. Maybe I forgot to exclude the folder in IntelliJ, but if you ever use sed/grep/find on your project, you have to remember to exclude it every time.
It adds a bunch of data in git that just shouldn't be there, potentially making
pull
andclone
commands take longer... FOREVER! Even if you later "remove" the folder, it's still stored in git.
Where should javadocs go?
It's probably best to post them on https://javadoc.io/, your web site, or AWS or heroku. If you must check javadoc into source control, make a separate project just for Javadocs so you'll never need to look at the diff. You can follow other people's answers for how to do this.
"I read your post, but I'm doing it anyway"
Here's my script to update fewer javadocs. It only copies files with substantial changes from the target/apidocs
folder to the docs/apidocs
folder. It also adds new files and deletes no longer used ones. I think I used poor names, newfile
and oldfile
, but it works. I mean, it wasn't enough to justify checking javadoc into my project's source control, but it helps.
#!/usr/bin/env bash
# -I means ignore lines matching a regular expression
# -q means "quiet" - only tell whether files differ or not
# -r means "recursive" - explore subdirectories
# -N means "treat absent files as empty" which makes absent files show up in Quiet mode.
diff -I '<!-- Generated by javadoc ' \
-I '<meta name="date" content="' \
-I '<title>' \
-I 'parent.document.title=' \
-N \
-qr \
docs/apidocs/ target/apidocs/ > target/javadocPatch.txt
# Now read in the output file created by the previous command and
# Update only files that have substantial changes.
while read ignore1 oldfile ignore2 newfile ignore3
do
if [ ! -f "$oldfile" ]
then
echo "Added $oldfile"
echo -n >$oldfile
cp -fu $newfile $oldfile
elif [ ! -f "$newfile" ]
then
echo "Deleted $newfile"
rm $newfile
else
echo "cp -fu $newfile $oldfile"
cp -fu $newfile $oldfile
fi
done < "target/javadocPatch.txt"

- 4,866
- 5
- 41
- 49
-
3I think the problem with sync changes in Javadoc is that you shouldn't changes your javadoc under the doc/ folder, instead, you have to store each release in a different version like with any professional library, eg. docs/1.0.0/ will contain the Javadocs for the version 1.0.0 and so on. Moreover, if a developer need helps with an older version of your library, it will be able to consult older documentation versions – Mariano Ruiz Apr 14 '20 at 12:20
-
That said, the only concern is not duplicate the assets generated by the javadoc engine that are always the same: CSS, JS and maybe some images, that may require a manual edition or a script to edit the content each time you release a new version – Mariano Ruiz Apr 14 '20 at 12:22
It might be a bit off topic but I believe what OP is looking for is a mechanism to automatically make javadoc available as a new version of the project is published.
If this is the case, then you can try: http://javadoc.io
It's a free service hosting javadocs for open source project, currently supporting maven central and bintray (jcenter).
You can generate a link to the latest version of your project. For example, this link https://javadoc.io/doc/org.springframework/spring-core always point to the latest version of spring-core, which is 5.2.0.RELEASE at the time I write this answer.
Declaimer: I run javadoc.io

- 2,065
- 24
- 20
-
1Awesome! I added javadoc.io to the front of my list of places to post javadoc and plan to add your buttons to the home pages of my projects momentarily. Yours is the best answer to this question. Thank you for doing the world a great service! – GlenPeterson Apr 06 '20 at 14:52