Automated javadoc generation



Since the early days that i adopted iDempiere, I was using some scripts and command line tool to achieve that.

Talking with , this is the same he does as we can see here

With maven & tycho i found an easier and automated way to do that:

1 - org.idempiere.javadoc
this new project uses tycho-document-bundle and basically we need only two files to configure:

  • pom.xml: javadoc related options and details

  • MANIFEST.MF: plugins selection for generation

2 - enable/disable javadoc generation on main pom.xml
by default i think that is important and that at each build we have a new version of javadoc generated/published.
Note: if you don't want you just need to comment the line below

With this simple changes every time that you run "mvn verify" you will have inside org.idempiere.javadoc/API a fresh version of your documentation.




Carlos Ruiz
July 12, 2019, 9:40 AM

Thanks , I integrated this into 6.2

I noticed some core classes are not indexed, for example:


Carlos Ruiz

Carlos Ruiz
July 12, 2019, 10:04 AM

Not sure why in jenkins is showing wrongly if I push F5
and there are warnings about “JAVASCRIPT IS DISABLED ON YOUR BROWSER.”

Maybe a post step there would be to upload (rsync) to a static website.

Murilo Habermann Torquato
January 13, 2020, 9:17 PM

Hi ,

I found this documentation related to “javascript is disabled on your browser”:

we can modify this on jenkins or configure a static website to solve this


Carlos Ruiz
January 13, 2020, 9:29 PM

Right , following that I installed this plugin:

And then you can define a project to be a javadoc and it allows javascript there.

Apparently maven projects could not be defined as javadoc, so I created a separate javadoc project and copied there the javadoc files after compilation.

But still it doesn’t work - I guess something still pending to configure.

Carlos Ruiz
June 15, 2020, 6:54 PM

I think this finally worked correctly in jenkins, the URLs are:

The trick in jenkins was explained at:

The most expedient approach is to use Jenkins 2.200+ and set up a second domain pointing to the same Jenkins instance (Jenkins URL:; Resource Root URL: This will result in resources being served from the resource root URL instead of the Jenkins URL. The advantage of this is that there are no cookies associated with this domain, and file paths are hopefully sufficiently non predictable that people won't be able to exfiltrate content.


Murilo Habermann Torquato


Murilo Habermann Torquato


Tested By


Fix versions