I think I did that because of the increased build time, but I can't remember exactly.
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... - Les 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> >
