| <?xml version="1.0" encoding="UTF-8"?> |
| <document> |
| <properties> |
| <author email="akarasulu@apache.org">Alex Karasulu</author> |
| <title>Apache Directory Project: </title> |
| </properties> |
| |
| <body> |
| <section name="Deploying Site and Subprojects"> |
| <subsection name="Incubator Site"> |
| <p> |
| The entire Apache Incubator site is kept within CVS. This includes |
| generated files. There has to be a good Apache Incubator resource |
| for this in existance that explains how it is all organized. Until |
| I figure that out just follow along. |
| </p> |
| |
| <p> |
| Currently as a podling the Directory Project's resources are managed |
| under the Apache Incubator. The website is no exception. The |
| specific incubator module used is the <b>incubator-directory</b> CVS |
| module. I check it out like so: |
| </p> |
| |
| <source> |
| cvs -d :ext:akarasulu@cvs.apache.org:/home/cvs co incubator-directory |
| </source> |
| |
| <p> |
| This module contains a content directory: <b>www</b>. The final |
| content under <b>www</b> is served up by the Apache servers. The |
| module's <b>www</b> folder is checked out daily into the following |
| directory on minotaur.apache.org: |
| <b>/www/incubator.apache.org/directory</b> |
| </p> |
| |
| <p> |
| So all we have to do is generate the site out of our subversion |
| working directory and copy the Maven generated content into the |
| <b>www</b> folder of the CVS working copy for the incubator-directory |
| CVS module. That's a mouth full. |
| </p> |
| |
| <p> |
| Once the generated content is copied, the changes are committed. Then |
| deployers should ssh into minotaur and cd to the |
| <b>/www/incubator.apache.org/directory</b> to do an update like so: |
| </p> |
| |
| <source> |
| cd /www/incubator.apache.org/directory |
| cvs update -d |
| </source> |
| |
| <p> |
| Everyone within our team has access to this area. Anyone can deploy |
| the entire site or just a part of it this way. It's a pretty neat |
| setup and works well. |
| </p> |
| |
| </subsection> |
| |
| <subsection name="Building Top Level Project Site"> |
| <p> |
| Keep in mind that the subprojects contain their own documentation. |
| They hook into the TLP Site. The sitedocs project manages the TLP |
| site shell. Any documentation that is not specific to a subproject |
| goes here. |
| </p> |
| |
| <p> |
| Building the top level project site is really simple. You checkout |
| the sitedocs trunk form the subversion repository. Add, delete or |
| make changes to the xdocs that reside under the <b>xdocs</b> folder. |
| Once the changes are made run: |
| </p> |
| |
| <source> |
| maven site |
| </source> |
| |
| <p> |
| This will generate the TLP site right under <b>target/docs</b>. |
| This does not generate the subproject content. To do this you'll |
| have to build the subproject documentation by using the same command |
| on the respective subproject. If all subprojects are configured as |
| documented here in the subproject integration section above then the |
| subproject build should copy the generated subproject documents over |
| to the respective <b>target/docs/subprojects/[subproject]</b> output |
| folder of the sitedocs module. |
| </p> |
| |
| <p> |
| If you're changes are to the TLP only without changes to the |
| subprojects then there is no need to build any subproject sites. If |
| you want to deploy one or more subproject site changes then go ahead |
| and build the subproject site for every subproject module. All the |
| results collect under the <b>sitedocs/target/docs</b> folder. |
| </p> |
| |
| <p> |
| The contents of the <b>sitedocs/target/docs</b> folder is what is |
| copied over into the <b>incubator-directory/www</b> folder and |
| committed into CVS. |
| </p> |
| </subsection> |
| </section> |
| </body> |
| </document> |
