that becomes an epic adventure, close to none of the methods/classes have a usable javadoc (most have none). the same applies to plugin parameters, I always go to the plugin doc first, but then realize it's useless and try finding stuff in the other site documentation. Also please consider removing the "Discovered" parameters that just don't add value but confuse (unless I missed the point entirely)
+1 on that. Milos On 3/8/06, Rinku <[EMAIL PROTECTED]> wrote: > Since we talk about 'latest and greatest', I wonder why javadocs > published online cannot serve as 'latest and greatest' docs? > > I am +1 to Carlos' idea about documenting almost all methods. If we were > to publish API docs for Maven and Plugins on the website (some separate > URL) with every Maven release build or every nightly build, at least > they would always reflect the 'latest and greatest' for the code. > > Cheers, > > Rahul > > > > Brian K. Wallace wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Wendy Smoak wrote: > > > >> On 3/7/06, Brett Porter <[EMAIL PROTECTED]> wrote: > >> > >> > >>> * I'm still a little torn on where plugin docs go. No hurry on this, but > >>> something to ponder. We definitely need to make the references for those > >>> integrate better. Site/skin inheritance will help > >>> > >> No matter where they go, I think they need to be updated more often. > >> Random example... the assembly plugin docs are wrong, and have been > >> that way for months. (it's descriptorId, not > >> maven.assembly.descriptorId.) > >> * http://maven.apache.org/plugins/maven-assembly-plugin/howto.html > >> > >> I would like to see the "latest and greatest" docs on the main site. > >> Yes, they'll be ahead of the released version, but not by much, and > >> (hopefully) not for long.When the answer to a lot of "X doesn't work" > >> questions is "It's fixed in the trunk, use a snapshot," it would be > >> nice to have the snapshot docs available in a centralized place. > >> > >> This also makes it more fun to contribute to the documentation, > >> because you get to see your work "in print" right away. > >> > >> Thanks for updating the main site. :) > >> > >> -- > >> Wendy > >> > > > > While I agree that it would be nice to have the 'latest and greatest' > > docs on the main site, I don't believe having them as the only > > documentation is a good idea at all. The documentation should be able to > > evolve after a release to make them better, but having documentation > > online that applies to "trunk" code and not released code tends to > > equate "bad documentation" (the docs say I can do X. "oh, that's in the > > trunk, use a snapshot"). If you aren't going to have two sets - one for > > released code and one for trunk code, only go with released code. If > > there are changes that can be made to make the released code's > > documentation better between releases, by all means - make it live as > > soon as practical. > > > > My .02 > > > > Brian > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.5 (MingW32) > > > > iD8DBQFEDjrpaCoPKRow/gARAiGlAJ98kZI0ItEEusrpmgIAT/jaQBaLXgCfbUhi > > 8iPFWc+Loyp9VtbXHxd6eqY= > > =cs6U > > -----END PGP SIGNATURE----- > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
