On Tue, Feb 9, 2010 at 2:30 PM, Les Hazlewood <[email protected]> wrote: > I think I did that because of the increased build time, but I can't > remember exactly.
Yea it takes a long time but only if you build the site. > I'm very much in favor of aggregate JavaDocs - as an end-user, I would > hate to have to go to multiple locations to view core JavaDoc vs web > JavaDoc vs Spring-support JavaDoc, etc... Agree. I'm going to put it back and try deploying the site. Kalle > On Tue, Feb 9, 2010 at 5:15 PM, Kalle Korhonen > <[email protected]> wrote: >> Aggregate javadocs or not for the site? Les, at r788750 you had >> commented out the reporting section including aggregate javadoc >> configuration with comment: >> "Ugraded to apache parent pom version 6. Removed retroweaver >> dependencies as Shiro 1.0+ will use JDK 1.5 as its base requirement >> per email thread..." >> >> Was that on purpose? >> >> Kalle >> >> >> On Tue, Feb 9, 2010 at 10:01 AM, Les Hazlewood <[email protected]> wrote: >>> I'm not sure exactly - I assumed it was useful only because it is >>> incredibly useful for me :) >>> >>> For example, I find this very useful: >>> >>> http://www.springsource.org/documentation >>> >>> Based on that page, I know exactly where to go for documentation >>> related to the particular version of Spring I'm using. >>> >>> My .02, >>> >>> Les >>> >>> On Tue, Feb 9, 2010 at 12:57 PM, Kalle Korhonen >>> <[email protected]> wrote: >>>> On Tue, Feb 9, 2010 at 9:49 AM, Les Hazlewood <[email protected]> >>>> wrote: >>>>> The way we did this for JSecurity was to publish each release's >>>>> documentation to its own version specific directory. Then I'd use a >>>>> symlink to point to the 'current' version and/or snapshot. I.E.: >>>>> >>>>> http://shiro.apache.org/site/current/api >>>>> >>>>> and in the site directory, you'd have the following directories: >>>>> >>>>> 0.9.2 >>>>> 1.0.0 >>>>> 1.0.3 >>>>> 1.0.4-SNAPSHOT >>>>> >>>>> and each time we published something important, we changed 'current' >>>>> symlink to point to the latest release - it was really nice. Can we >>>>> still do this? Maybe not, but I'm just checking. Will this work? >>>> >>>> Yeah, we could. The symlink probably needs to be created manually (as >>>> opposed to as part of site-deploy.. though with sufficient coding, >>>> anything's possible). Do you have any idea how the users felt about - >>>> were the older docs used at all, was there confusion about which docs >>>> they are browsing etc? >>>> >>>> Kalle >>>> >>>> >>>>> On Tue, Feb 9, 2010 at 12:36 PM, Kalle Korhonen >>>>> <[email protected]> wrote: >>>>>> Thanks to Brian for detailed instructions. I'm familiar with staged >>>>>> releases and Nexus so we should be able to get this done. I assume I'm >>>>>> going to cut the release when the time comes unless somebody else >>>>>> steps up :) >>>>>> >>>>>> Les, as Brian noted site's somewhat separate from the release but by >>>>>> default it's published at release time. Basically we have two options, >>>>>> either we publish just snapshots of the site (i.e. exactly one site >>>>>> url) or a site per release (i.e. site/1.0.0) and single url for >>>>>> snapshots, the latter can be achieved with profiles. Multiple archived >>>>>> and released sites could be useful (but also confusing) for users when >>>>>> we have multiple releases available, but just for simplicity's sake >>>>>> I'd go with a single site url at first. The javadocs are in any case >>>>>> deployed per released version. >>>>>> >>>>>> Kalle >>>>>> >>>>>> >>>>>> On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <[email protected]> >>>>>> wrote: >>>>>>> Hey Les, >>>>>>> >>>>>>> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> Hi Brian, >>>>>>>> >>>>>>>> > To get everything setup for a staging repository >>>>>>>> > Create a sub task under: >>>>>>>> https://issues.apache.org/jira/browse/INFRA-1896 >>>>>>>> >>>>>>>> Done: >>>>>>>> >>>>>>>> https://issues.apache.org/jira/browse/INFRA-2488 >>>>>>>> >>>>>>>> > After the deploy you need to close the staging repo, and promote it >>>>>>>> >>>>>>>> What do you mean by close the staging repo? Just ensure that the team >>>>>>>> does not deploy to staging to prevent overwrites? >>>>>>>> >>>>>>> >>>>>>> A single maven deploy is a bunch of stateless deploys so there is no >>>>>>> way to >>>>>>> know when maven is done deploying all the artifacts. So after you do a >>>>>>> deploy you need to tell Nexus you are finished. This puts the >>>>>>> repository in >>>>>>> a read-only mode >>>>>>> >>>>>>> You could do this all from a maven plugin (but personally I like the UI >>>>>>> for >>>>>>> this): >>>>>>> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Also, once the artifacts are in staging, how is promotion done in >>>>>>>> Nexus? I mean, let's say that the community votes to approve the >>>>>>>> release. How do you propagate those voted-upon artifacts from staging >>>>>>>> to the release repo? >>>>>>>> >>>>>>> >>>>>>> The actual promoting is also just a couple clicks (or the plugin listed >>>>>>> above) >>>>>>> Upon promotion all the artifacts are moved into the release repository. >>>>>>> (and >>>>>>> corresponding metadata is merged i.e. maven-metadata.xml) >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks for the pointers! >>>>>>>> >>>>>>>> - Les >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
