Nice! Glad to see this finally up :) Thanks Kalle!
- Les On Wed, Feb 10, 2010 at 1:18 AM, Kalle Korhonen <[email protected]> wrote: > 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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
