You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by di...@incubator.apache.org on 2004/11/25 16:02:07 UTC

[Apache Directory Project Wiki] Updated: ProjectWebSite

   Date: 2004-11-25T07:02:07
   Editor: VincentTence <vt...@apache.org>
   Wiki: Apache Directory Project Wiki
   Page: ProjectWebSite
   URL: http://wiki.apache.org/directory/ProjectWebSite

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -6,24 +6,24 @@
 
 For some time we have had problems distributing work among our selves and
 attracting new developers.  The learning curve is massive and there is no
-beacon to guide new comers so developer retention problems exist.  We need 
-tools to help overcome these barriers.  A home page or site for the project 
+beacon to guide new comers so developer retention problems exist.  We need
+tools to help overcome these barriers.  A home page or site for the project
 was one of the main tools we agreed would aid in solving these problems.
 
-We came to a rapid conclusion that we need to build a website with various 
-developer resources before continuing with any further development.  We need 
+We came to a rapid conclusion that we need to build a website with various
+developer resources before continuing with any further development.  We need
 to state who we are, what we wish to achieve and provide a clear roadmap with
 milestones and guides for developers interested in contributing to the development
 of various subprojects.  This is absolutely paramount to our success.
 
 Next we need to better utilize the resources available to us here in the incubator.
-This includes the wiki, JIRA, subversion and other tools to better manage the 
+This includes the wiki, JIRA, subversion and other tools to better manage the
 project in general.  We would like to make it easier for developers to find things
 to do for the project without worries about duplicating efforts.  We need to find
 a better means to divide labor.  This mostly entails agreeing upon a design, carving
 out interfaces and coding to those interfaces after developers have chosen their
 niches hence the parts of development they would like to take on.  We would like to
-maximize collaboration and peer review to capitalize on the entire community's 
+maximize collaboration and peer review to capitalize on the entire community's
 knowledge without holding back individuals that would like to grok the code at their
 own pace with a minimum of coordination overhead.  Integrating these tools together
 in one contiguous site increases the chance off using these tools.  Everything then
@@ -34,7 +34,7 @@
 
 == Site Sections ==
 
-The site's breakdown will naturally follow the subproject structure.  At this point 
+The site's breakdown will naturally follow the subproject structure.  At this point
 we have a few major categories and a few subcatagories:
 
    * sitedocs
@@ -73,13 +73,43 @@
    * Site structure and code used to build it
    * Any custom tools used for generating documentation are described and documented here.
 
+==== Howto build the site ====
+
+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 '''incubator-directory'''
+CVS module.  Check it out like so:
+
+{{{
+cvs -d :ext:username@cvs.apache.org:/home/cvs co incubator-directory
+}}}
+
+This module contains a content directory: '''www'''.  The final content under '''www''' is served
+up by the Apache servers.  The module's '''www''' folder is checked out daily into the following
+directory on cvs.apache.org:
+
+/www/incubator.apache.org/directory
+
+So all we have to do is generate the site out of our subversion
+working directory and copy the Maven generated content into the
+'''www''' folder of the CVS working copy for the incubator-directory
+CVS module.  That's a mouth full.
+
+Once the generated content is copied, the changes are committed.  Then
+deployers should ssh into cvs.apache.org and cd to the
+'''/www/incubator.apache.org/directory''' to do an update like so:
+
+{{{
+cd /www/incubator.apache.org/directory
+cvs update -d
+}}}
+
 === resources ===
 
-Describes the various resources for this TLP to be.  Things like JIRA, wiki and other 
+Describes the various resources for this TLP to be.  Things like JIRA, wiki and other
 resources as well as various top level guides can go under here like coding standards
 and agreed upon development methodologies.
 
-Each subsection may have its own specific resources like, FAQs, HOWTOs, and 
+Each subsection may have its own specific resources like, FAQs, HOWTOs, and
 user/developer guides.
 
    * Cover all repository issues with a subversion repo faq/howto
@@ -120,7 +150,7 @@
 
 What are we going to use to get us there?  Obviously we're going to leverage Maven
 to build the site using markup like xdocs and sdocbook to build out the site navigation
-and content.  
+and content.
 
 === Maven ===
 We use maven but how? Perhaps we need to do some jelly customization or write a plugin.
@@ -130,13 +160,13 @@
 === Jelly ===
 Need to customize maven with jelly.  Code to build the project site and subproject sites
 in a project to subproject dependency tree and gather the generated sites will require some
-custom code. 
+custom code.
 
 Any new maven plugins will require some jelly.
 
 === XSLT ===
 
-We can use XSLT to transform lots of xml we have into a presentable form.  
+We can use XSLT to transform lots of xml we have into a presentable form.
 
 == Patterns and/or Approach ==
 
@@ -156,4 +186,3 @@
    * use a custom maven plugin to build component subproject documentation from the Maven POM and the Merlin descriptors
    * use subversion properties on various directories and or files to effect the manner in which documentation is generated.  We can flag components as components and differentiate projects that way or we could use the project.properties etc.
    * between subversion properties and project.properties we can define plugin specific properties that effect the way the site is generated by our plugin.
-