It would be great if maven had the ability to specify a snapshot site url similar to how the repositories work. Then a snapshot rev gets its site deployed some where different than the release version.
-----Original Message----- From: Brian K. Wallace [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 9:01 PM To: Maven Developers List Subject: Re: Making the current web site suck less -----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]