You are viewing a plain text version of this content. The canonical link for it is here.
Posted to zeta-commits@incubator.apache.org by ko...@apache.org on 2010/08/03 08:25:19 UTC
[zeta-commits] svn commit: r981774 [2/38] - in /incubator/zetacomponents/website: ./ build/
config/ config/content/ config/display/ content/ content/community/
content/community/ressources/ content/documentation/
content/documentation/trunk/ content/documentation/tru...
Added: incubator/zetacomponents/website/Makefile
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/Makefile?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/Makefile (added)
+++ incubator/zetacomponents/website/Makefile Tue Aug 3 08:23:50 2010
@@ -0,0 +1,191 @@
+
+# Set proper default for zeta components base path
+ZETA_BASE=`pwd`"/../trunk"
+BUILDDIR="build/"
+
+# Paths and zeta components required for the website building process
+WCV_PATHS=classes scripts templates
+WCV_ZETA_COMPONENTS=Base Configuration ConsoleTools Database Feed Mail Template
+
+# Evaluated build name - extract from path
+BUILDNAME=$$(basename $(ZETA_BASE))
+
+# Checks out the required external bits required to re-build the website.
+#
+# If a valid copy of Zeta Components is specified in the ZETA_BASE environment
+# variable those libraries are used from there. They are checkout out
+# otherwise.
+checkout-wcv :
+ for SUBDIR in $(WCV_PATHS) ; \
+ do \
+ if [ ! -d "$$SUBDIR" ]; then \
+ svn checkout --ignore-externals "svn://web-content-viewer.org/wcv/trunk/$$SUBDIR" $$SUBDIR ; \
+ else \
+ svn update --ignore-externals $$SUBDIR ; \
+ fi; \
+ done
+ for COMPONENT in $(WCV_ZETA_COMPONENTS) ; \
+ do \
+ if [ ! -d "classes/ezc/$$COMPONENT/src" ]; then \
+ if [ -d "$(ZETA_BASE)/$$COMPONENT" ]; then \
+ ln -s "$(ZETA_BASE)/$$COMPONENT/src" "classes/ezc/$$COMPONENT/src" ; \
+ else \
+ svn checkout "http://svn.ez.no/svn/ezcomponents/trunk/$$COMPONENT/src" "classes/ezc/$$COMPONENT/src" ; \
+ fi; \
+ fi; \
+ done
+
+# Sets up and cleans the build directory
+builddir :
+ if [ ! -d $(BUILDDIR) ]; then \
+ mkdir $(BUILDDIR) ; \
+ else \
+ rm -rf "$(BUILDDIR)/*" ; \
+ fi; \
+
+# Creates the API documentation.
+#
+# Requires an installation of PHPDocumentor and 2.5GB of free memory. To
+# install PHPDocumentor use:
+# pear install phpDocumentor
+#
+# The release is specified by the ZETA_BASE environment variable and defaults
+# to trunk.
+phpdoc : builddir
+ echo $(BUILDNAME)
+ env php -d "memory_limit=2500M" `whereis phpdoc | awk '{print $$2}'` \
+ --directory $(ZETA_BASE) \
+ --templatebase "phpdoc/" \
+ --target "$(BUILDDIR)/phpdoc/$(BUILDNAME)/phpdoc" \
+ --ignore "autoload/,*autoload.php,tests/,docs/,design/" \
+ --hidden false \
+ --undocumentedelements off \
+ --title "Apache Zeta Components Manual" \
+ --parseprivate off \
+ --defaultpackagename "NoPackageName" \
+ --defaultcategoryname "NoCategoryName" \
+ --output "HTML:Arbit:arbit" \
+ --sourcecode off \
+ --javadocdesc off \
+ --pear off
+ for FILE in $$(find $(BUILDDIR)/phpdoc/$(BUILDNAME)/phpdoc/ -name 'classtrees_*.html' -or -name 'elementindex_*.html'); \
+ do \
+ TARGET=$$(echo $$FILE | sed -e 's/\(classtrees\|elementindex\)_\([A-Za-z]*\)\.html/\2\/\1.html/') ; \
+ COMPONENT=$$(basename $$FILE .html | sed -e 's/\(classtrees\|elementindex\)_//') ; \
+ mv "$$FILE" "$$TARGET" ; \
+ sed -i -e "s/$$COMPONENT\///g" "$$TARGET" ; \
+ done
+ cd "$(BUILDDIR)/phpdoc/$(BUILDNAME)" && tar -cjf "$(BUILDNAME).tar.bz2" "phpdoc/"
+ cd ../
+ # rm -rf "$(BUILDNAME)"
+ cd ../../
+ if [ ! -d "content/documentation/$(BUILDNAME)" ]; then \
+ mkdir -p "content/documentation/$(BUILDNAME)" ; \
+ fi;
+ cp "$(BUILDDIR)/phpdoc/$(BUILDNAME)/$(BUILDNAME).tar.bz2" "content/documentation/$(BUILDNAME)/phpdoc.tar.bz2"
+ rm -rf "$(BUILDDIR)/phpdoc/$(BUILDNAME)"
+
+# Copies tutorials for a given release to the website directory.
+#
+# The release is specified by the ZETA_BASE environment variable and defaults
+# to trunk.
+tutorials :
+ for DOCS in $$(find $(ZETA_BASE) -name 'docs' -type d | grep -v tests) ; \
+ do \
+ LOCAL_PATH=$$(echo "$$DOCS" | sed -e "s#^$(ZETA_BASE)/\?##") ; \
+ COMPONENT=$$(echo "$$LOCAL_PATH" | sed -e "s#/.*\$$##") ; \
+ TARGET="content/documentation/$(BUILDNAME)/$$COMPONENT/" ; \
+ if [ ! -d "$$TARGET" ]; then \
+ mkdir -p "$$TARGET" ; \
+ fi; \
+ cp -r "$$DOCS/"* "$$TARGET" ; \
+ find $$TARGET -name ".svn" -print0 | xargs -0 -n 1 rm -rf ; \
+ done
+ echo "Generating index filesâ¦"
+ for COMPONENT in $$(find "content/documentation/$(BUILDNAME)/" -mindepth 1 -maxdepth 1 -type d | grep -v "\\.svn" | grep -v design) ; \
+ do \
+ INDEX_FILE="$$COMPONENT/.index.xml" ; \
+ echo '<?xml version="1.0" encoding="utf-8"?>' > $$INDEX_FILE ; \
+ echo '<index>' >> $$INDEX_FILE ; \
+ if [ -f "$$COMPONENT/tutorial.txt" ]; then \
+ echo ' <site index="true"><name>Tutorial</name><path>tutorial.txt</path></site>' >> $$INDEX_FILE ; \
+ fi; \
+ echo ' <directory><name>API</name><path>phpdoc/</path></directory>' >> $$INDEX_FILE ; \
+ for FILE in $$(find "$$COMPONENT" -mindepth 1 -maxdepth 1 -name '*.txt' | grep -v tutorial) ; \
+ do \
+ LOCALFILENAME=`basename "$$FILE"` ; \
+ NAME=$$(basename $$FILE .txt | perl -ane ' foreach $$word ( @F ) { print ucfirst($$word)." "; } print "\n" ; ') ; \
+ echo " <site><name>$$NAME</name><path>$$LOCALFILENAME</path></site>" >> $$INDEX_FILE ; \
+ done ; \
+ for FILE in $$(find "$$COMPONENT" -mindepth 1 -maxdepth 1 -type d | grep -v "\\.svn" | grep -v design | grep -v phpdoc | grep -v tutorial | grep -v functions) ; \
+ do \
+ LOCALFILENAME=`basename "$$FILE"` ; \
+ echo " <directory display=\"false\"><name>$$LOCALFILENAME</name><path>$$LOCALFILENAME/</path></directory>" >> $$INDEX_FILE ; \
+ done ; \
+ echo '</index>' >> $$INDEX_FILE ; \
+ done
+
+# Extract API documentation from archive and copy it to teh correct location in
+# the content tree.
+extract-phpdoc :
+ ARCHIVE="content/documentation/$(BUILDNAME)/phpdoc.tar.bz2" ; \
+ tar xjf "$$ARCHIVE" -C $$(dirname "$$ARCHIVE") ; \
+ DOC_PATH="content/documentation/$(BUILDNAME)/phpdoc/" ; \
+ for COMPONENT in $$(find "content/documentation/$(BUILDNAME)/" -mindepth 1 -maxdepth 1 -type d | grep -v "\\.svn" | grep -v phpdoc | grep -v design | grep -v Framework | sort) ; \
+ do \
+ NAME=$$(basename "$$COMPONENT") ; \
+ echo "Copy API docs for $$NAME" ; \
+ if [ -d "$$COMPONENT/phpdoc" ]; then \
+ rm -rf "$$COMPONENT/phpdoc/*" ; \
+ else \
+ mkdir -p "$$COMPONENT/phpdoc" ; \
+ fi ; \
+ cp "content/documentation/$(BUILDNAME)/phpdoc/$$NAME/"* "$$COMPONENT/phpdoc/" ; \
+ sed -i -e "s#\.\./$$NAME/##g" "$$COMPONENT/phpdoc/"*.html ; \
+ sed -i -e "s#\"\(\.\./\)\?\([a-zA-Z]*\)/#\"/documentation/$(BUILDNAME)/\2/phpdoc/#g" "$$COMPONENT/phpdoc/"*.html ; \
+ INDEX_FILE="$$COMPONENT/phpdoc/.index.xml" ; \
+ echo '<?xml version="1.0" encoding="utf-8"?>' > $$INDEX_FILE ; \
+ echo '<index>' >> $$INDEX_FILE ; \
+ echo ' <site index="true"><name>Class tree</name><path>classtrees.html</path></site>' >> $$INDEX_FILE ; \
+ for FILE in $$(find "$$COMPONENT/phpdoc/" -name "*.html" | grep -v classtrees) ; \
+ do \
+ NAME=$$(basename $$FILE) ; \
+ echo " <site display=\"false\"><name>$$NAME</name><path>$$NAME</path></site>" >> $$INDEX_FILE ; \
+ done ; \
+ echo '</index>' >> $$INDEX_FILE ; \
+ done ; \
+ rm -rf "content/documentation/$(BUILDNAME)/phpdoc"
+
+# Build all docs for the release specified by the environment variable
+# ZETA_BASE
+docs : tutorials extract-phpdoc
+ INDEX_FILE="content/documentation/$(BUILDNAME)/.index.xml" ; \
+ echo '<?xml version="1.0" encoding="utf-8"?>' > $$INDEX_FILE ; \
+ echo '<index>' >> $$INDEX_FILE ; \
+ echo ' <site index="true"><name>Overview</name><path>overview.txt</path></site>' >> $$INDEX_FILE ; \
+ for DIR in $$(find "content/documentation/$(BUILDNAME)/" -mindepth 1 -maxdepth 1 -type d | grep -v "\\.svn" | grep -v phpdoc | grep -v design | sort) ; \
+ do \
+ NAME=`basename "$$DIR"` ; \
+ echo " <directory><name>$$NAME</name><path>$$NAME/</path></directory>" >> $$INDEX_FILE ; \
+ done ; \
+ echo '</index>' >> $$INDEX_FILE
+ OVERVIEW="content/documentation/$(BUILDNAME)/overview.txt" ; \
+ cat content/documentation/teaser.txt > "$$OVERVIEW" ; \
+ for DIR in $$(find "content/documentation/$(BUILDNAME)/" -mindepth 1 -maxdepth 1 -type d | grep -v "\\.svn" | grep -v phpdoc | grep -v design | sort) ; \
+ do \
+ NAME=`basename "$$DIR"` ; \
+ echo "- $${NAME}__" >> $$OVERVIEW ; \
+ done ; \
+ echo '' >> $$OVERVIEW ; \
+ for DIR in $$(find "content/documentation/$(BUILDNAME)/" -mindepth 1 -maxdepth 1 -type d | grep -v "\\.svn" | grep -v phpdoc | grep -v design | sort) ; \
+ do \
+ NAME=`basename "$$DIR"` ; \
+ echo "__ /documentation/$(BUILDNAME)/$$NAME/tutorial.html" >> $$OVERVIEW ; \
+ done
+
+# Build the website
+#
+# Requires about 250MB of memory.
+website : checkout-wcv
+ env php scripts/updateCache.php
+
Added: incubator/zetacomponents/website/config/authors.ini
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/config/authors.ini?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/config/authors.ini (added)
+++ incubator/zetacomponents/website/config/authors.ini Tue Aug 3 08:23:50 2010
@@ -0,0 +1,14 @@
+[mapping]
+
+# The metadata handlers may provide different author names why mean the same
+# author. For this you may define a mapping of author names.
+name[wcv] = Kore Nordmann
+name[kore] = Kore Nordmann
+name[kore_web] = Kore Nordmann
+
+# It is possible to assiciate a mail address to the author name which may be
+# used by some display handlers.
+mail[wcv] = wcv@kore-nordmann.de
+mail[kore] = wcv@kore-nordmann.de
+mail[kore_web] = wcv@kore-nordmann.de
+
Added: incubator/zetacomponents/website/config/binaries.ini
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/config/binaries.ini?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/config/binaries.ini (added)
+++ incubator/zetacomponents/website/config/binaries.ini Tue Aug 3 08:23:50 2010
@@ -0,0 +1,43 @@
+# Location definitions for all binaries, required by WCV. Normally the default
+# should just work fine, which means, that the binary with the requested name
+# is available in your $PATH. If the binary is only available at another
+# location, or even has another name, you may specify an option for this here.
+#
+# You may of course specify the full absolute path to the binary, isntead of
+# just its name, if it is not in $PATH.
+
+[core]
+
+# The SVN binary is required by the SVN metadata handler
+#svn=/usr/bin/svn
+
+# The RST content handler for now uses the python docutils package to transform
+# the RST documents into XML for further processing inside of WCV. These
+# binaries may differ in name on some systems like fedora, or ubuntu, where the
+# file extension is removed.
+rst2xml=rst2xml
+rst2newlatex=rst2newlatex
+
+# For all XSLT modifications for now we use the binary xsltproc from the
+# libxml2 distribution..
+#xsltproc=xsltproc
+
+[search]
+
+# The default search uses glimspe as an indexer and search tool. Nearly each
+# distribution offers glimpse as a package, and you need two binaries from this
+# package.
+#glimpse=glimpse
+#glimpseindex=glimpseindex
+
+[gallery]
+
+# For the resizing and image manipulation the pecl/iMagick is used, which does
+# not ofer support for all maker specific relevant image information (which are
+# not all available as EXIF headers). To extract those and similar data the
+# perl software exiftool is used, which should also be available as apackage in
+# most distribvutions.
+#exiftool=exiftool
+
+[pdf]
+#rubber=rubber
Added: incubator/zetacomponents/website/config/content/blog.ini
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/config/content/blog.ini?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/config/content/blog.ini (added)
+++ incubator/zetacomponents/website/config/content/blog.ini Tue Aug 3 08:23:50 2010
@@ -0,0 +1,27 @@
+[blog]
+
+# Blog post handlers
+handler[] = wcvIndexerFileBlogPostRst
+
+# Number of entries per page
+entries=10
+
+# Akisment key for comment spam checking
+# You may get one signing up on wordpress.com
+akismet_key=
+
+# Absolut path to page notifying the user, that his comment has been rated as
+# spam
+spamUrl=/spam.html
+
+# Optionally you may provide an URL (including auth information) to some xmlrpc
+# spam collecting service, which understands the XMLRPC protocol specification
+# supported by WCV and defined at: !URL!
+#xmlrpc=http://norro.de/Spam/Pot1
+
+# Absolut path to page containing XML repsonse for trackback spammers
+trackbackSpamUrl=/trackback_spam.xml
+# Absolut path to page containing XML repsonse for trackback spammers
+trackbackErrorUrl=/trackback_error.xml
+# Absolut path to page containing XML repsonse for trackback spammers
+trackbackSuccessUrl=/trackback_success.xml
Added: incubator/zetacomponents/website/config/display/sitemap.ini
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/config/display/sitemap.ini?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/config/display/sitemap.ini (added)
+++ incubator/zetacomponents/website/config/display/sitemap.ini Tue Aug 3 08:23:50 2010
@@ -0,0 +1,37 @@
+[generator]
+
+# Calculate change frequency from log in versioning handler. When versioning
+# metadata handler takes some time to fetch the log (like svn does) this may
+# result in a very slow sitemap generation.
+changefreq=false
+
+[priorities]
+
+# Flag wheather to include priority flags in the generated sitemap. Either
+# "true" or "false". Defaults to "false".
+include=true
+
+# Format priorities.
+#
+# Defines an additional factor (float value between 0 and 1) for each format to
+# modify the ranking of a site. Defaults to .5 if not set.
+format[html]=1
+format[pdf]=.6
+format[rss]=.6
+format[txt]=.3
+format[rdf]=.1
+format[sitemap]=0
+
+# Node priorities
+#
+# You may specify a higher priority for some spcial nodes, which should gain
+# more importance. You may use factors bigger then 1 here.
+node[/description]=2
+node[/spam]=0
+
+[pingback]
+
+# Searchengines to ping with regenerated sitemap
+#searchengine[]=http://google.com/webmasters/sitemaps/ping
+#searchengine[]=http://search.yahooapis.com/SiteExplorerService/V1/ping
+searchengine[]=http://webmaster.live.com/ping.aspx
Added: incubator/zetacomponents/website/config/handlers.ini
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/config/handlers.ini?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/config/handlers.ini (added)
+++ incubator/zetacomponents/website/config/handlers.ini Tue Aug 3 08:23:50 2010
@@ -0,0 +1,50 @@
+[indexers]
+
+# The indexer handlers define the mechanism used to handle the content of a
+# directory. The top most handler has the highest priority.
+
+handler[]=wcvIndexerGallery
+handler[]=wcvIndexerBlog
+handler[]=wcvIndexerSearch
+handler[]=wcvIndexerXml
+handler[]=wcvIndexerDirectory
+
+[file]
+
+# The file handlers describe how to handle a file. The top most handler has
+# the highest priotity.
+
+handler[]=wcvIndexerFileHtml
+handler[]=wcvIndexerFileRst
+handler[]=wcvIndexerFileStatic
+
+[metadata]
+
+# The metadata handlers describe how to receive metadata associated with
+# files. The top most handler has the highest priotity.
+
+handler[]=wcvMetadataSvn
+handler[]=wcvMetadataFilesystem
+
+[display]
+
+# The list of display handlers define a decorator used to fulfill the users
+# request for a file. The default decorator is used as a fallback when no
+# other handler was defined for the requested file extension.
+
+#handler[rdf]=wcvDisplayRdf
+handler[html]=wcvDisplayHtml
+#handler[txt]=wcvDisplayText
+#handler[pdf]=wcvDisplayPdf
+handler[rss]=wcvDisplayRss
+#handler[sitemap]=wcvDisplaySitemap
+
+# Pseudo handler to force dynamic contents. Will issue a redirect to static
+# content and not display anything.
+
+handler[dyn]=wcvDisplayRedirect
+
+# Deafult to binary handeler which will just passthru the content with setting
+# the correct mime type.
+
+default=wcvDisplayBinary
Added: incubator/zetacomponents/website/config/metadata.ini
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/config/metadata.ini?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/config/metadata.ini (added)
+++ incubator/zetacomponents/website/config/metadata.ini Tue Aug 3 08:23:50 2010
@@ -0,0 +1,19 @@
+[base]
+
+# Title of the webpage
+title=Apache Zeta Components - high quality PHP components
+
+# Website description
+description=Apache Zeta Components - reusable set of high quality PHP components to fasten your development.
+
+# Website tags, sperated by commas
+tags=PHP, apache, components, framework, quality
+
+# Basic language of website.
+# Maybe could be ovirwritten by content handlers later
+language=en
+
+# Default license of the displayed content. May be overwritten by the content
+# handler with more appropriate values
+license=Copyright
+
Added: incubator/zetacomponents/website/config/site.ini
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/config/site.ini?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/config/site.ini (added)
+++ incubator/zetacomponents/website/config/site.ini Tue Aug 3 08:23:50 2010
@@ -0,0 +1,84 @@
+[base]
+
+# Base path to content repository
+#
+# If you want to use a relative URL, this is evaluated relative from the
+# position of the index.php in your directory tree.
+content=../content
+
+# Default display handler
+# Which display handler to use if none was specified - also affects the
+# display handler used to display a request to /
+default=html
+
+# Base URL for webpage
+#
+# This one is autodetected from your server variables, of not set. The
+# autodetection does not work with https for now, and also does not work, when
+# the caches are regenerated from CLI.
+url=http://zeta/
+
+# Classes to notify with a static call to ::postUpdate() after cache
+# regeneration
+# The class should implement the interface wcvContentPostUpdate
+# class[]=wcvContentSitemap
+
+# Optional template override paths to use custom templates
+override[]=override/
+
+# To switch on the debug mode set this to 1
+debug = 1
+
+# List of files, which are included after the base initialization.
+#
+# This may be used to add custom modules / classes to WCV. You may want to add
+# a autoload function in this init script, or just include your required
+# classes.
+#
+# All pathes must be given relative to the WCV installation base
+#scripts[]=external/myModule/init.php
+
+[cache]
+
+# Cache settings
+#
+# The cache setting is a bitmask of the single cache entries below. -1 will
+# always cache everything. To explicitely cache tree and content you may use 3:
+# 1 | 2 = 3
+#
+# 1 = Cache content tree
+# 2 = Cache generated content
+# types = -1
+types = -1
+
+# When deleting files in the htdocs/ folder exclude the directories listed here
+# from deletion. Ensure you add directories here, when uploading some stuff
+# into you htdocs/ folder.
+exclude[]=.svn
+exclude[]=index.php
+exclude[]=styles
+exclude[]=scripts
+exclude[]=images
+exclude[]=robots.txt
+exclude[]=.htaccess
+
+[mail]
+
+# General flag indicating wheather to send mail. May be ignored by modules of
+# course.
+# send=yes
+send=no
+
+# Sender address for mails from WCV
+sender=no-response@fzc
+
+# Receiver, who should receive mails
+reporting=tobias@schlitt.info
+
+# Subject for mails
+subject=[fzc] - %s
+
+[trackback]
+
+# Time in seconds after which a connection atempt will be aborted.
+timeout=3
Added: incubator/zetacomponents/website/content/.index.xml
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/content/.index.xml?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/content/.index.xml (added)
+++ incubator/zetacomponents/website/content/.index.xml Tue Aug 3 08:23:50 2010
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="utf-8"?>
+<index>
+ <directory index="true">
+ <name>About</name>
+ <path>news/</path>
+ </directory>
+ <directory>
+ <name>Community</name>
+ <path>community/</path>
+ </directory>
+ <directory>
+ <name>Documentation</name>
+ <path>documentation/</path>
+ </directory>
+ <directory>
+ <name>Download</name>
+ <path>download/</path>
+ </directory>
+ <site>
+ <name>Support</name>
+ <path>support.txt</path>
+ </site>
+
+ <!-- Static pages -->
+ <site display="false">
+ <name>404</name>
+ <path>404.txt</path>
+ </site>
+ <site display="false">
+ <name>Spam</name>
+ <path>spam.html</path>
+ </site>
+ <site display="false">
+ <name>Trackback Spam</name>
+ <path>trackback_spam.xml</path>
+ </site>
+ <site display="false">
+ <name>Trackback Error</name>
+ <path>trackback_error.xml</path>
+ </site>
+ <site display="false">
+ <name>Trackback Success</name>
+ <path>trackback_success.xml</path>
+ </site>
+</index>
Added: incubator/zetacomponents/website/content/404.txt
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/content/404.txt?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/content/404.txt (added)
+++ incubator/zetacomponents/website/content/404.txt Tue Aug 3 08:23:50 2010
@@ -0,0 +1,14 @@
+===============
+Site note found
+===============
+
+The site you tried to access does not exist (any more). We are sorry for this.
+Please try to relocate the requested site using the site navigation.
+
+
+..
+ Local Variables:
+ mode: rst
+ fill-column: 79
+ End:
+ vim: et syn=rst tw=79
Added: incubator/zetacomponents/website/content/community/.index.xml
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/content/community/.index.xml?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/content/community/.index.xml (added)
+++ incubator/zetacomponents/website/content/community/.index.xml Tue Aug 3 08:23:50 2010
@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="utf-8"?>
+<index>
+ <site index="true">
+ <name>Overview</name>
+ <path>index.txt</path>
+ </site>
+ <site>
+ <name>Development process</name>
+ <path>dev_process.txt</path>
+ </site>
+ <site>
+ <name>Guidelines</name>
+ <path>implementation.txt</path>
+ </site>
+</index>
Added: incubator/zetacomponents/website/content/community/dev_process.txt
URL: http://svn.apache.org/viewvc/incubator/zetacomponents/website/content/community/dev_process.txt?rev=981774&view=auto
==============================================================================
--- incubator/zetacomponents/website/content/community/dev_process.txt (added)
+++ incubator/zetacomponents/website/content/community/dev_process.txt Tue Aug 3 08:23:50 2010
@@ -0,0 +1,411 @@
+===================
+Development Process
+===================
+
+.. contents:: Table of Contents
+ :depth: 2
+
+
+Introduction
+============
+
+In order to streamline our development we have a specific set of guidelines
+that need to be followed. This document summarizes the steps and provides
+pointers to the relevant guidelines where that is relevant. This document
+is ultimately meant for the Apache Zeta Components developers.
+
+Our development process consists of a set of seven steps; transitions between
+the different states can be done when the criteria are matched that describe
+the finalization of each step. Depending on the situation not all seven steps
+are necessary (for example for bug fixes you don't need to write a Requirements
+Document or Design Specification as a bug is simply a feature that doesn't
+adhere to those documents).
+
+The Seven Steps
+===============
+
+1. `Present the Idea`_.
+2. `Write Requirements Document`_.
+3. Write `Design Specifications`_.
+4. `Time and Cost Estimates`_.
+5. `Implementation`_.
+6. `Testing`_.
+7. `Release`_.
+
+
+Detailed Information about the Steps
+------------------------------------
+
+1. _`Present the Idea`
+~~~~~~~~~~~~~~~~~~~~~~
+
+1.1. New Feature
+````````````````
+
+Before the requirements documents and design specifications are written an
+idea for a *new* feature should be announced on the `components mailing list`_.
+This is to make sure that only features are developed which fit into
+our global idea of "high quality components for web application development".
+Based on the ideas that are outlined on the list we will make a decision
+whether we are interested in making a new feature part of the Apache Zeta
+Components
+library.
+
+1.2. Enhancement
+````````````````
+
+Feature requests should go to the `issue tracker`_.
+
+1.3. Bug
+````````
+
+Bug reports should go to the `issue tracker`_.
+
+
+Transition
+``````````
+
+While introducing a new feature or an enhancement the following information
+should be present:
+
+- What is the feature about?
+- Which features will it provide?
+- A rationale why it should be part of the product.
+
+Those three elements will be checked against our policies of what features we
+are interested it. *This document does not yet exist.*
+
+For bug reports the information in the `issue tracker`_ should be filled in.
+
+.. _`components mailing list`: http://lists.ez.no/mailman/listinfo/components
+
+
+2. _`Write Requirements Document`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After a new feature or enhancement has been announced, discussed and approved
+it is time to start writing the requirements document. At this point we will
+create a directory in the experimental directory in SVN where the documents can
+be stored while waiting for feedback
+(http://svn.ez.no/svn/ezcomponents/experimental/<component>/design). At this
+same time *some* prototyping can be done as well there.
+
+There is also more information on how to structure an `requirements
+document`_.
+
+Discussions
+```````````
+
+The requirements document is most likely going to attract feedback.
+This is supposed to be a creative and iterative process which means that
+proceeding to the next phase should not commence before the documents have been
+approved as well.
+
+Discussions about the requirements should be done on the `components mailing
+list`_.
+
+Transition
+``````````
+
+When the Requirements Document contains all the required information, and it
+has been approved by the product manager, the next step can start where a
+Design Document is written.
+
+.. _`Requirements Document`: http://svn.ez.no/svn/ezcomponents/docs/guidelines/requirements_doc.txt
+
+3. _`Design specifications`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+At this point we assign a mentor to the component. This mentor
+makes sure all the necessary steps and reviews are done correctly and keeps an
+eye on the design, working closely with the developer that makes the design.
+
+The design specification describes how the feature is going to be implemented
+with the requirements document in mind. The design specification is there to
+see whether something can be implemented, and also explores the different
+implementation approaches. The different approaches can then be assessed in the
+next step (`Time and Cost Estimates`_).
+
+Only after the design specification has been approved can be started with the
+implementation of the feature. There are guidelines on how to create such an
+`design specification`_.
+
+Discussions
+```````````
+
+The design specification is most likely going to attract feedback in
+the form of different implementation approaches or just general comments.
+
+Discussions about the design should be done on the `components mailing
+list`_, or where possible in face-to-face meetings with a summary to the
+mailing list.
+
+Transition
+``````````
+
+The design specification is checked against the guidelines on how to write such
+a document. There is also an assessment whether the feature can be implemented
+at all. The design specification should be vetted by the product manager before
+the next step can be taken.
+
+.. _`Design Specification`: http://svn.ez.no/svn/ezcomponents/docs/guidelines/design_doc.txt
+
+
+4. _`Time and Cost Estimates`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Once the requirement specifications have been written and the design has been
+made, it is possible to estimate how much time the implementation of a specific
+item will take. During the two previous phases all possible ways of
+implementation are researched and there is knowledge about what the
+implementation of a new feature exactly will entail.
+
+There are a couple of things that need to be taken into account, for example
+which part of the software is to be touched. Standalone small parts are easier
+to estimate then larger parts that touch many different corners of the
+software.
+
+
+5. _`Implementation`
+~~~~~~~~~~~~~~~~~~~~
+
+In the implementation step the feature is implemented according to the design
+specifications. When this step is reached for a new feature, the appropriate
+directory structures can be moved from "`experimental`_" to "`trunk`_".
+
+There are several sub-items in this step:
+
+5.1. _`Write API stubs with parameter documentation and descriptions`
+`````````````````````````````````````````````````````````````````````
+
+This should serve as some prototyping to see how the design could work. As part
+of the API stubs you should already create the files with the classes and methods
+that you think your API needs, following the design that is outlined in the
+design document. To complete this phase there should
+be an example in the main classes` doc blocks and API documentation for
+each constant, variable, property and method. Of course during development
+some things might change. This first initial implementation of the stubs just
+serves as a little playground. It is important that *no* implementation code
+is written during this phase. Documentation of classes
+is done with the `phpDocumentor`_ syntax. A `small introduction`_ on how to
+use it for the Apache Zeta Components is available as well.
+
+Transition
+##########
+
+After the API stubs are written and committed to SVN a mail should be send to
+the `components mailing list`_ to ask for feedback.
+
+.. _`experimental`: http://svn.ez.no/svn/ezcomponents/experimental/
+.. _`trunk`: http://svn.ez.no/svn/ezcomponents/trunk/
+.. _`phpDocumentor`: http://phpdoc.org
+.. _`small introduction`: http://svn.ez.no/svn/ezcomponents/docs/guidelines/implementation.txt
+
+5.2. Write test cases
+`````````````````````
+
+Test cases are written for PHPUnit, see the documentation on how to `set-up the test environment`_.
+
+.. _`set-up the test environment`: http://svn.ez.no/svn/ezcomponents/docs/test_environment.txt
+
+5.3. Initial Implementation
+```````````````````````````
+
+There are many guidelines for implementing classes and methods. Please refer to
+the `guidelines`_.
+
+.. _`guidelines`: http://svn.ez.no/svn/ezcomponents/docs/guidelines/implementation.txt
+
+Transition
+##########
+
+After the first implementation has been done, alpha1 is released.
+
+5.4. _`Initial Implementation Review`
+`````````````````````````````````````
+
+After the implementation of the classes there is a review required of the
+implementation. The review should be done by at least two people that where
+*not* part in writing the code. The original author is of course free to do a
+review as well. During the review the implementation should be matched against
+the requirements specification and design document. On top of there a few extra
+things should be taken care of, which are described in the `review`_ document.
+
+.. _`review`: http://svn.ez.no/svn/ezcomponents/docs/guidelines/review.txt
+
+5.5. Updating Implementation according to review
+````````````````````````````````````````````````
+
+After the `Initial Implementation Review`_ has been done, the original
+developer updates the implementation according to provided feedback. In case
+conflicting opinions exist the issues need to be discussed on the list, in all
+other cases it is suggested to discuss all found issues on the list as well.
+
+Transition
+##########
+
+Release a beta version of the component.
+
+5.6. Implementation Review
+``````````````````````````
+
+The updated code is reviewed once again according to the `review`_ guidelines.
+If more issues arise go back to step 5.5.
+
+Transition
+``````````
+
+Once the implementation has been reviewed and all the comments of the reviewers
+have been integrated into the implementation a Release Candidate can be
+released.
+
+
+6. _`Testing`
+~~~~~~~~~~~~~
+
+In the testing phase we run all the Apache Zeta Components tests as one big bunch, using
+all the different permutations of parameters that we support. At the moment
+this is a multitude of PHP versions and supported Databases, but other input
+variables might be defined later as well.
+
+Transition
+``````````
+
+Before we can do the release, we run a couple of scripts that validate a few
+basic things:
+
+- whether we have uncommitted changes
+- whether all tests pass
+- whether line endings are correct
+- whether the ChangeLog parses correctly as reST file
+- code style guidelines are checked with a script
+
+7. _`Release`
+~~~~~~~~~~~~~
+
+A document that describes how to make releases of the Apache Zeta Components can be
+found in svn__.
+
+__ http://svn.ez.no/svn/ezcomponents/docs/releasing.txt
+
+
+
+Applicability
+-------------
+
+New Features
+~~~~~~~~~~~~
+
+Should follow all of `The Seven Steps`_.
+
+
+Bugs
+~~~~
+
+Bugs should should always be reported in the `issue tracker`_. Bugs
+should also be reported here by ourselves if we are not in the first
+development cycle of a component (e.g. before version 1.0) or during an active
+development face for a new .y release. This allows easier tracking of issues.
+While committing a bug fix the bug number should be mentioned.
+
+For bugs from non-`maintainers`_ that come with a patch, the patch should be
+reviewed by one of the maintainers of the specific area. The patch should
+be attached to the bug report and when updates of the patch are requested
+through the `issue tracker`_ the non-`maintainer`_ should update his patch there.
+All patches for bug reports have to include test cases that show that before the
+fix the bug failed, and afterwards it was fixed. Of course a bug fix should not
+break other tests (unless they were incorrect of course). A patch by a
+non-`maintainer`_ can only be committed when the CLA_ has been signed.
+
+From the `The Seven Steps`_, step 2 (`Write Requirements Document`_) and step 3
+(Write `Design Specifications`_) can be omitted because a bug is in violation
+with either one of those documents. Step 5.1 (`Write API stubs with parameter
+documentation and descriptions`_) and step 5.4/5.6 (`Initial Implementation
+Review`_) are also not required, although the latter might be a good idea
+to do for very large fixes.
+
+
+.. _CLA: http://ez.no/ezpublish/contributing/cla
+
+Enhancements
+~~~~~~~~~~~~
+
+Should just like bugs always be filed into the `issue tracker`_, also if it comes
+from `maintainers`_. The development process is handled in the same way as new
+features. When an enhancement is filed, the specs of the feature/change are
+attached to the report in the issue tracker. Once the specification is approved
+by one or more of the current `maintainers`_ and the product manager, it can be
+moved into the requirements and design documents. The development can be done
+in SVN directly, but is not required to be done there for non-`maintainers`_.
+Once a contributer has shown enough knowledge about a specific area he can be
+marked as a `maintainer`_ for that specific area. Discussion about whether
+enhancements are wanted are always required to be done on the components
+mailing list. We can only allow code coming from external contributers into the
+repository when the CLA_ has been signed.
+
+
+Justifications
+==============
+
+The process outlined above solves the basic requirement of accepting
+contributions while defining a clear process. The Components are self contained
+building blocks and therefore changes are often very small and contained.
+Because of this nature it is not required that every little issue is reviewed
+by at least one other person. By allowing direct commit access to SVN we allow
+quicker development while still maintaining quality (as every addition and bug
+fix is required to have a test case). Because the components have a quick
+release cycle we would hardly have conflicts between bug fixes and new features
+so we do not have to create many branches. A component would usually have one
+branch, or perhaps two concurrent ones if we go for a version 2 of a component.
+We are reluctant to bump the version number to 2 though as this would only be
+done on a backward compatibility breaking change.
+
+
+Version States
+==============
+
+pre-alpha
+ Development state, everything can change.
+
+alpha 1
+ First release of a component up for initial review.
+
+beta 1
+ First release of a component after the implementation of review comments.
+ The API is still subject to change, but the general workings of the
+ component should not change anymore.
+
+beta n
+ Releases of a component after implementation of more reviews. The API is
+ still allowed to change, but doing so is discouraged.
+
+rc 1
+ Release candidate, the API can not change anymore unless there is an
+ extremely compelling reason to do so.
+
+final
+ The component is now released, BC can *not* be broken anymore.
+
+
+Glossary
+========
+
+maintainer
+----------
+ A person from the Apache Zeta Components development team or an external contributer
+ that has shown enough knowledge about a specific component, or contributes
+ a whole new component. Maintainers can commit directly to SVN.
+
+maintainers
+-----------
+ More than one `maintainer`_.
+
+.. _`tutorial`: http://svn.ez.no/svn/ezcomponents/docs/guidelines/tutorial.txt
+.. _`issue tracker`: http://issues.ez.no
+
+
+.. Local Variables:
+.. mode: rst
+.. fill-column: 79
+.. End:
+.. vim: et syn=rst tw=79