On Tue, Feb 9, 2010 at 2:34 PM, Kalle Korhonen <[email protected]> wrote: > On Tue, Feb 9, 2010 at 2:30 PM, Les Hazlewood <[email protected]> wrote: >> 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.
FYI: http://incubator.apache.org/shiro/site/ (but I'll change it to deploy to /${project.version} and /latest for snapshots). 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
