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 >>>>>> >>>>> >>>> >>> >> >
