Creating aggregated javadoc for such a big project like AS is a few-step process, during which various issues appear: Maven bugs, wrong data in pom.xml's and jars (mostly 3rd party outside our scope), javadoc generator bugs.

For all of these, we have some kind of workaround, mostly blacklisting the offending jars / artifacts.

This process (including workarounds) was automated in the form of a Jenkins job.

All this was done for AS 7.

 

For EAP 6, the same process was not applicable at the time of developing, as even more problems emerged - not all artifacts had -source.jar's.

I've tried to replace these with fake ones.

That worked, but then, for some reason, the javadoc tool, when run, doesn't provide any output. It runs as with AS 7, downloads the source packages, but after that, it quits with no error, and simply doesn't create the javadoc dir nor .jar.

 

We decided to go with the hybrid approach of generating Javadoc from AS tag which EAP is based on, and apply EAP's module.xml's which determine what modules the public API consists of.

This approach worked until current release, EAP 6.1.0 for which we have an upstream code base.

But for 6.1.next, we need to be able to generate javadoc purely from EAP sources, without relying on AS upstream.

This will need an analysis why the javadoc tool or maven javadoc plugin fails to create any output, and possibly ask an expert (John Casey?) to help with fixing.