Any software developer will tell you that when using APIs the most important help you can have is documentation. When talking about Java, the typical type of documentation for APIs is Javadoc. Often when we produce the jars for our APIs we don’t build them with the Javadoc included in order to keep the size down. Typically you would produce two sets of jars, one for production and one for development which has the Javadoc and sometimes the source. However this model can break down. For example, with Notes and our Client UI APIs we can’t distribute a version of Notes with jars that have the Javadoc included. Therefore our Notes plugin developers have two options. Use the Javadoc in the Help or use the documentation published online. The first option is not always possible since most developers don’t have Notes open when developing plugins. The second option is therefore the next best option.
However our plugin developers mostly use Eclipse and as we all know Eclipse has this great feature which will give you the Javadoc for the methods and classes you are using as you develope. But as I said before you would need the plugin to be build with the Javadoc, which IBM does not do to keep the size of the plugins smaller. Eclipse has a solution for this problem in the form of an extension point. Essentially this allows you to create a plugin containing the Javadoc and then use the extension point to connect the Javadoc with specific plugins. In theory then one would just have to install this plugin into Notes and then it would be in the target platform, and therefore provide the Javadoc for our Notes developers inside Eclipse without having Notes or a browser open. We are going to be investigating providing this type of plugin at least for the Client UI APIs but maybe other APIs as well.