They are already there http://maven.apache.org/ref/current/index.html
Note the new Reference link in the left menu On 3/7/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] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
