The problem will be also with reports. Do we need all reports for all releases ? Documentation reports like javadoc, jxr, are needed for each release. But is it useful for quality reports (pmd, simian, linkcheck, ...) ? These reports are useful for the development team to improve their code. But for the end user ???
Arnaud On 3/8/06, Tim O'Brien <[EMAIL PROTECTED]> wrote: > > Sorry, gmail confused me and I sent that last one by mistake John. > > I don't think you'll be trading look and feel here. I think you'd just be > doing something like making the site.xml for trunk point to a logo or > banner > GIF that just added a "trunk", "draft", or "development" stamp. If this > was > done correctly, i think you could add it to the banner graphic in an > attractive way. > > But, it brings up some questions: > > 1. Would every minor release get a separate site? Or are we just talking > about major releases? In other words, is there a 2.x site, or is there a > 2.0.2 site? (My vote is for a 2.x site.) > > 2. What would the first page look like? What would Maven's home page look > like? Would it even be managed by Maven? > > Something to think about is maybe not having the initial Maven page be a > Maven site. ASF sites in general seems to be more Developer focused than > user focused. What if the initial Maven site were more like the front > pages > of Mozilla or Rails. An attractive logo, links to resources and > materials, > an introduction. The home page should be user focused, Maven developers > are > a minority of the audience here. > > > On 3/8/06, John Casey <[EMAIL PROTECTED]> wrote: > > > > +1 > > > > Maybe we can put a banner at the top of each page that marks the version > > it refers to or something. If we styled the reference doco as a manual, > > it could be part of the page layout that ties it together. I'd be > > willing to trade a bit of the look&feel for that sort of information, as > > it seems to me that it would reduce confusion. > > > > -john > > > > Tim O'Brien wrote: > > > Having to choose between publishing the latest and greatest docs and > > only > > > the released version is a problem that Maven seems to have created for > > > itself. Same issue comes up in other projects frequently - Commons > has > > a > > > problem because some of the sites only publish on a release. Latest > and > > > greatest are almost never there. > > > > > > What about publishing the latest and greatest docs to another > directory? > > > The Maven site gets pushed to a directory that has a version of a > > > label. http://maven.apache.org/version/1.0 > > > , http://maven.apache.org/version/2.0.2, and > > > http://maven.apache.org/version/trunk. This way the Maven site can > have > > a > > > nightly publish of the most current Maven site to Trunk every single > > day, > > > but still keep legacy docs around intact for people using older > versions > > of > > > the product. The "consumer" site can point to the latest release, and > > the > > > "developer" site can point to "trunk". The Maven site plugin would > need > > > some mechanism for adding a skin to a site to clearly identify it as > > > "Development". > > > > > > > > > > > > On 3/7/06, Wendy Smoak <[EMAIL PROTECTED]> 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 > > >> > > >> --------------------------------------------------------------------- > > >> 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] > > > > > >
