Re: Dynamic Table of Contents of all system Javadoc
Hello !
On 08/04/11 00:09, Ludovic Claude wrote:
> This proposal is for Eclipse, so the documentation in question is
> Java-specific, but it could also include Groovy doc, and any other
> languages providing structured HTML documentation.
>
> It probaly will be implemented as an Eclipse plugin.
> I think that is a great idea, as it would provide a good use-case for
> those documentation packages which are quite under-used.
> In the same way, we could provide automatically Eclipse libraries for
> system-installed jars.
I too think it is a good idea, and that would probably be a good
occasion to enforce the policy on javadoc. I'm currently improving
lintian with a little more knowledge of java (see #620829). I haven't
started to work on javadoc, but it's somewhere on my TODO-list.
That raises a question I have in mind, and for which the policy is
currently unclear. Several of the packages I maintain are both programs
and libraries (and used as such). One of the examples that come to my
mind is statcvs, which is used by statsvn. For now, the package is
simply called statcvs, and it contains the javadoc (which is bad).
However, if we consider it a library, I should split that into three
packages:
statcvs, that would still contain the wrapper and the manual page.
libstatcvs-java, containing the jar
libstatcvs-java-doc, containing the javadoc.
Is that correct ? Should this be enforced ? (it is simple enough: if
javadoc is built for a program, then most probably it is used as a
library too).
Cheers,
Vincent
--
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
Some pirates achieved immortality by great deeds of cruelty
and derring-do. Some achieved immortality by amassing great
wealth. But the captain had long ago decided that he would,
on the whole, prefer to achieve immortality by not dying.
-- Terry Pratchet, the Colour of Magic
Vincent, listening to Frank Sinatra (CAKE)
Reply to: