Better documentation output for calls to java libraries

[GoogleCodeExporter]

As a test writer 
I would like to see documentation of java library calls in the output log
So that I can understand what the call is doing without searching and reading 
the javadocs in an external library javadoc file.

I would like to see at least the first sentence of a javadoc comment to a 
called keyword displayed in a "Documentation" row below the keyword.

This may require access for the log generator to either the javadoc jar or the 
source jar of the library in question.

Original issue reported on code.google.com by kai.hack...@gmail.com on 19 Jul 2010 at 4:30

[GoogleCodeExporter]

Accessing the docs requires access to the source code. There is, AFAIK, no 
standard location for source code so implementing anything generic is hard. The 
core development team has discussed this earlier and concluded the task is too 
big compared to the benefits. Are you Kai interested in looking at this 
yourself?

Original comment by pekka.klarck on 19 Jul 2010 at 6:41

[GoogleCodeExporter]

I could do this, if I would have a bit more plan about Python. The way would be 
to search within the classpath for a file with the same name of the library 
that ends on .java instead of .class. Having that I could develop some 
javadoc-extractor for the methods. Have to think about that a bit.

Original comment by kai.hack...@gmail.com on 19 Jul 2010 at 11:02

[GoogleCodeExporter]

How about this idea: Instead of javadoc java libraries expose a map of the 
method name to a string that contains the documentation as a static final field 
with a name like METHOD_DOCUMENTATION? No access to the sourcecode required, 
just can RIDE access that map field of a java class then?

Original comment by kai.hack...@gmail.com on 21 Jul 2010 at 4:35

[GoogleCodeExporter]

Why wouldn't you use dynamic libraries instead? They already support 
documentation via getKeywordDocumentation method. See JavaLibCore project for 
an easy way to use the dynamic API: 
http://code.google.com/p/robotframework-javatools/wiki/JavalibCore

Original comment by pekka.klarck on 21 Jul 2010 at 6:13

[GoogleCodeExporter]

Ok, somehow I have missed that option before. Now investigating.

Original comment by kai.hack...@gmail.com on 21 Jul 2010 at 8:32

[GoogleCodeExporter]

1) Trying to locate source code is too big a task, compared to benefits, for 
the core development team.

2) Adding special documentation mechanism for the static Java library API 
doesn't really make sense when we already have that support in the dynamic API.

=> WontFix. If Kai or someone else is interested to work with 1) this can be 
reopened.

Original comment by pekka.klarck on 30 Aug 2010 at 3:15

• Changed state: WontFix