We know that the documentation, specially the javadoc, is not perfect, present or uptodate.
Well, I feared that ;-) My primary goal was to stress that it would be worth the pain to maintain the javadoc right from the beginning (instead of fixing bugs afterwards). From my personal experience, writing doc in parallel as one writes code is less painful than having to write it all at once for an entire API. If the API is not stable but frequently changes during development, fine, update the javadoc, too, such that others always know what it does right now. In the end, it's just a matter of good habits.
Do you have special ideas to improve the doc?
As I said, some javadocs for those classes that plugin developers tend to use would be nice.
I writed in the past some Plugins Cookbook. Maybe we could add more.
"More" doc is always good but I think there are two different kinds of documentation to keep in mind. A cookbook is usually something that answers questions like "How do I...?" whereas the other part of questions starts like "What does Maven...?". At the end of the day, when a plugin developer starts his IDE to go coding, he will appreciate a proper javadoc attachment for all his dependencies such that he can properly fulfill his part of the contract with the Maven APIs. Of couse, one needs as well a description of the big picture (where cookbooks can help) but javadocs are the basis to build upon (a picture without details is quite uninteresting).
agree and patches are always welcome :)
I think I got it ;-) Nevertheless, I still believe that there are code parts that are best documented by the responsible developers because what kind of documentation could I contribute by just looking at the source for say MavenProject.getArtifact() without having an in-depth understanding of Maven's guts?
Regards, Benjamin Bentmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
