struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hus...@apache.org
Subject svn commit: r376838 [5/6] - in /struts/site/trunk/xdocs: announce.xml bylaws.xml download.xml downloads.xml faqs.xml helping.xml index.xml javadoc.xml kickstart.xml mail.xml navigation.xml release-checklist.xml releases.xml struts.css volunteers.xml
Date Fri, 10 Feb 2006 20:58:36 GMT
Modified: struts/site/trunk/xdocs/release-checklist.xml
URL: http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/release-checklist.xml?rev=376838&r1=376837&r2=376838&view=diff
==============================================================================
--- struts/site/trunk/xdocs/release-checklist.xml (original)
+++ struts/site/trunk/xdocs/release-checklist.xml Fri Feb 10 12:58:33 2006
@@ -1,114 +1,129 @@
 <?xml version="1.0"?>
 <document url="./release-checlist.xml">
-  <!--
-  // ======================================================================== 78
-  -->
-  <properties>
-    <title>Release Checklist - Apache Struts Project</title>
-  </properties>
-  <body>
-  <pre>
-      = Struts x.x.x Release =
-
-      == Info ==
-
-       1. Struts [http://struts.apache.org/releases.html#Releases 
-          Release Guidelines]
-       
-       2. [http://wiki.apache.org/incubator/SigningReleases 
-          Signing Releases]
- 
-       3. Apache [http://apache.org/dev/mirrors.html Mirroring Guidelines]
-       
-      == Release Manager ==
-
-      The release manager is '''${RELEASE_MANAGER}'''
-
-      == Special Issues ==
-
-       1. ${ISSUES}
-
-      == Outstanding Bug Review ==
-
-      || '''ID''' || '''Summary''' || '''Component''' || '''Status''' ||
-      || ${ID} || ${SUMMARY} || $COMPONENT} || ${STATUS} ||
-
-      == Preparation Checklist ==
-
-      || '''#''' || '''Description''' || '''Status''' ||
-      || 1. || ${DESCRIPTION} || ${STATUS} ||
-      
-      The Commons [http://jakarta.apache.org/commons/releases/prepare.html 
-      Preparation Guide] is a helpful preparation backgrounder, but Commons
-      uses the "beta/release-candidate/final" process.
-
-      Likewise, the [http://httpd.apache.org/dev/release.html 
-      HTTPD Release Guidelines] is a helpful "overall process" backgrounder,
-      but HTTPD does not use a test-build stage.
-
-      Dependency versions for this release:
-
-      || '''Dependency''' || '''Version''' || '''Status''' ||
-      || ${DEPENDENCY} || ${VERSION} || ${STATUS} ||
-
-      == Testing Checklist ==
-
-      === Testing Summary ===
-
-      || '''#''' || '''Description''' || '''Completed''' ||
-      || 1. || Run Unit Test targets  || ${STATUS} ||
-      || 2. || Run Cactus Tests (see below) || ${STATUS} ||
-      || 3. || Play test bundled applications (TC 4.x) || ${STATUS} ||
-      
-      TODO: A Canoo WebTest for the applications would be great!
-
-      === Cactus Tests ===
-
-      || '''#''' || '''J2SE Version''' || '''Tomcat Version''' ||  '''Status''' ||
-      || 1. || J2SE 1.3.x || Tomcat 4.x || ${STATUS} ||
-      || 2. || J2SE 1.4.x || Tomcat 4.x || ${STATUS} ||
-      || 3. || J2SE 1.3.x || Tomcat 5.x || ${STATUS} ||
-      || 4. || J2SE 1.4.x || Tomcat 5.x || ${STATUS} ||
-
-      == Test Build Checklist (A) ==
-
-      See also Commons [http://jakarta.apache.org/commons/releases/release.html 
-      Step-by-Step Guide]
-
-      || '''#''' || '''Description''' || '''Completed''' ||
-      || A1. || Tag release in cvs: ${STRUTS_x_x_x} || ${STATUS} ||
-      || A2. || Run Distribution Target || ${STATUS} ||
-      || A3. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/x.x.x
|| ${STATUS} ||
-      || A4. || Post release-quality vote on dev@ and user@ lists || ${STATUS ||
+    <!--
+    // ======================================================================== 78
+    -->
+    <properties>
+        <title>Release Checklist - Apache Struts Project</title>
+    </properties>
+    <body>
+        <pre>
+            = Struts x.x.x Release =
 
-      == Vote (A) ==
+            == Info ==
 
-      || ${PMC_MEMBER} || ${GRADE} ||
-      
-      If release vote fails, including for a lack of quorum, remove from dist 
-      folder.      
+            1. Struts [http://struts.apache.org/releases.html#Releases
+            Release Guidelines]
+
+            2. [http://wiki.apache.org/incubator/SigningReleases
+            Signing Releases]
+
+            3. Apache [http://apache.org/dev/mirrors.html Mirroring
+            Guidelines]
+
+            == Release Manager ==
+
+            The release manager is '''${RELEASE_MANAGER}'''
+
+            == Special Issues ==
+
+            1. ${ISSUES}
+
+            == Outstanding Bug Review ==
+
+            || '''ID''' || '''Summary''' || '''Component''' || '''Status''' ||
+            || ${ID} || ${SUMMARY} || $COMPONENT} || ${STATUS} ||
+
+            == Preparation Checklist ==
+
+            || '''#''' || '''Description''' || '''Status''' ||
+            || 1. || ${DESCRIPTION} || ${STATUS} ||
+
+            The Commons
+            [http://jakarta.apache.org/commons/releases/prepare.html
+            Preparation Guide] is a helpful preparation backgrounder, but
+            Commons
+            uses the "beta/release-candidate/final" process.
 
-      == Point Release Checklist (B) ==
+            Likewise, the [http://httpd.apache.org/dev/release.html
+            HTTPD Release Guidelines] is a helpful "overall process"
+            backgrounder,
+            but HTTPD does not use a test-build stage.
 
-      || B1. || Create Sums and Sign Distributions [2] || ${STATUS} ||
-      || B2. || Request new Bugzilla version level (x.x.x) || ${STATUS} ||
-      || B3. || Update "Acquiring" page on website and Test Downloads || ${STATUS} ||
+            Dependency versions for this release:
 
-      == Vote (B) ==
+            || '''Dependency''' || '''Version''' || '''Status''' ||
+            || ${DEPENDENCY} || ${VERSION} || ${STATUS} ||
+
+            == Testing Checklist ==
+
+            === Testing Summary ===
+
+            || '''#''' || '''Description''' || '''Completed''' ||
+            || 1. || Run Unit Test targets || ${STATUS} ||
+            || 2. || Run Cactus Tests (see below) || ${STATUS} ||
+            || 3. || Play test bundled applications (TC 4.x) || ${STATUS} ||
+
+            TODO: A Canoo WebTest for the applications would be great!
+
+            === Cactus Tests ===
+
+            || '''#''' || '''J2SE Version''' || '''Tomcat Version''' ||
+            '''Status''' ||
+            || 1. || J2SE 1.3.x || Tomcat 4.x || ${STATUS} ||
+            || 2. || J2SE 1.4.x || Tomcat 4.x || ${STATUS} ||
+            || 3. || J2SE 1.3.x || Tomcat 5.x || ${STATUS} ||
+            || 4. || J2SE 1.4.x || Tomcat 5.x || ${STATUS} ||
+
+            == Test Build Checklist (A) ==
+
+            See also Commons
+            [http://jakarta.apache.org/commons/releases/release.html
+            Step-by-Step Guide]
+
+            || '''#''' || '''Description''' || '''Completed''' ||
+            || A1. || Tag release in cvs: ${STRUTS_x_x_x} || ${STATUS} ||
+            || A2. || Run Distribution Target || ${STATUS} ||
+            || A3. || Upload Distribution to
+            cvs.apache.org:/www/cvs.apache.org/dist/struts/x.x.x || ${STATUS}
+            ||
+            || A4. || Post release-quality vote on dev@ and user@ lists || ${STATUS ||
+
+      == Vote (A) ==
 
       || ${PMC_MEMBER} || ${GRADE} ||
-      
-      Voting continues until a GA or "withdraw" vote passes, or there is a
-      subsequent release.
-
-      == General Availability Checklist (C) ==
-
-      || '''#''' || '''Description''' || '''Completed''' ||
-      || C1. || Copy Distribution to Mirrored Directories [3] || ${STATUS} ||
-      || C2. || Deploy JAR to Apache Java-Repository || ${STATUS} ||
-      || C3. || After 24 hours, update "Acquiring" page on website || ${STATUS} ||
-      || C4. || Post an announcement to lists and website || ${STATUS} ||
-      ----
-  </pre>
-  </body>
-  </document>
\ No newline at end of file
+
+            If release vote fails, including for a lack of quorum, remove from
+            dist
+            folder.
+
+            == Point Release Checklist (B) ==
+
+            || B1. || Create Sums and Sign Distributions [2] || ${STATUS} ||
+            || B2. || Request new Bugzilla version level (x.x.x) || ${STATUS}
+            ||
+            || B3. || Update "Acquiring" page on website and Test Downloads ||
+            ${STATUS} ||
+
+            == Vote (B) ==
+
+            || ${PMC_MEMBER} || ${GRADE} ||
+
+            Voting continues until a GA or "withdraw" vote passes, or there is
+            a
+            subsequent release.
+
+            == General Availability Checklist (C) ==
+
+            || '''#''' || '''Description''' || '''Completed''' ||
+            || C1. || Copy Distribution to Mirrored Directories [3] ||
+            ${STATUS} ||
+            || C2. || Deploy JAR to Apache Java-Repository || ${STATUS} ||
+            || C3. || After 24 hours, update "Acquiring" page on website ||
+            ${STATUS} ||
+            || C4. || Post an announcement to lists and website || ${STATUS}
+            ||
+            ----
+        </pre>
+    </body>
+</document>
\ No newline at end of file

Modified: struts/site/trunk/xdocs/releases.xml
URL: http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/releases.xml?rev=376838&r1=376837&r2=376838&view=diff
==============================================================================
--- struts/site/trunk/xdocs/releases.xml (original)
+++ struts/site/trunk/xdocs/releases.xml Fri Feb 10 12:58:33 2006
@@ -18,119 +18,299 @@
 -->
 <document>
 
-  <properties>
-    <title>Release Guidelines</title>
-  </properties>
-  <body>
+    <properties>
+        <title>Release Guidelines</title>
+    </properties>
+    <body>
 
-    <a name="status"/>
-    <section name="Release Guidelines">
-    <p>This document describes the Apache Struts
-      <a href="#Releases">release process</a> and our
-      <a href="#Coding">coding conventions</a>,
-      which are applicable to all subprojects.
-      Both stable and development releases are
-      <a href="downloads.html">available for download</a>.</p>
+        <a name="status"/>
+        <section name="Release Guidelines">
+            <p>This document describes the Apache Struts
+                <a href="#Releases">release process</a>
+                and our
+                <a href="#Coding">coding conventions</a>
+                ,
+                which are applicable to all subprojects.
+                Both stable and development releases are
+                <a href="downloads.html">available for download</a>
+                .
+            </p>
 
-    <a name="Releasing"/>
-    <subsection name="Release Process">
-      <p>A
-      <a href="http://jakarta.apache.org/commons/releases/versioning.html">point release</a>
should be made before and after any product change that is not a "fully-compatible change"
(see link). This includes moving a dependency from an internal package to an external product,
including products distributed through the Jakarta Commons. We should place any fully-compatible
changes in the hands of the community before starting on a change that is only "interface"
or "external-interface" compatible.</p>
-      <p>
-      Any release should follow the same general process used by the
-      <a href="http://jakarta.apache.org/site/decisions.html">Jakarta Tomcat</a>
team
-      and must observe the <a href="http://apache.org/dev/mirrors.html">Apache Mirroring
guidelines</a>.
-      See also <a href="http://wiki.apache.org/incubator/SigningReleases">Signing Releases</a>.
-      </p>
-      <p>Additional remarks:</p>
-      <ul>
-        <li>Every committer is encouraged to participate in the release process, either
as the release manager or a helper. Committers may also share the release manager role.</li>
-        <li>The release process can seem daunting when you review it for the first
time. But, essentially, it breaks down into four phases of just a few steps each:
-        <ul>
-          <li><strong>Rolling</strong> - Bugzilla, dependencies, release
notes, JAR manifest, licenses, copyrights, and build (using the release target).</li>
-          <li><strong>Testing</strong> - JUnit, Cactus, web apps (for all
"supported" containers).</li>
-          <li><strong>Voting</strong> - Upload test build to internal directory,
post majority vote on DEV list as to release grade: Alpha, Beta, General Availability.</li>
-          <li><strong>Distributing</strong> - Checksum, sign, mirror, update
download page, announce.</li>
-        </ul></li>
-        <li>Committers are <b>required</b> to post a release plan before
tagging the repository and should wait the traditional 72 hours before proceeding.</li>
-        <li>A checklist format can be used for the <a href="http://wiki.apache.org/struts/StrutsReleasePlans">release
plan</a>, to help step through the process. The plan may be maintained in the repository
or on the <a href="http://wiki.apache.org/struts/">Struts wiki</a>.</li>
-        <li>Our dependencies on external JARs (including Commons JARs) should be in
line with our own release status. Our nightly build can be dependant on another nightly build.
Our beta can be dependant on another beta (or "release candidate"), but should avoid a dependance
on a nightly build.
-        Our General Availability release may only have dependencies on other GA, final, or
stable releases.</li>
-        <li>Use your own discretion as to detail needed by the Release Notes. A high-level
description of the changes is more important than providing uninterpreted detail. At a minimum,
new features and deprecations should be summarized, since these are commonly asked questions.
Ideally, the release notes should be maintained continuously for the nightly build so that
we they do not need to be assembled at the last minute.</li>
-        <li>Try building the distribution under prior version of J2SE, if possible,
to ensure that we are still backwardly-compatible. But, our distributions should be built
using the
-        <strong>latest production release of J2SE</strong>, to take advantage
of all available compiler enhancements.</li>
-        <li>If you have multiple J2SE versions configured, run the JUnit and Cactus
tests using the same configuration that will be used to build the distribution.</li>
-        <li>There is a "release" target in the buildfile that will zip and tar the
distribution. Before uploading the distribution, extract the sample web applications and deploy
the WARs under each of the "supported" containers (if you can). Play test each application
under each container to be sure they operate nominally.</li>
-        <li>The test build can be posted to the internal distribution directory (svn.apache.org/struts/)
and announced to the Struts DEV and PMC lists (only!). Do not announce a test build on any
other Apache lists or link to it from an Apache website.</li>
-        <li>If the test build is voted to Alpha, Beta, or GA status, the release can
announced to the User list and linked from the website.</li>
-        <li>Any formal release may be submitted for mirroring. All GA releases <b>must</b>
be mirrored.</li>
-        <li>After announcing a release, remember to update the Acquiring and Announcements
pages. If the release is to be mirrored, wait at least 24 hours after submittal before making
public announcements (as stated in the <a href="http://apache.org/dev/mirrors.html">Apache
Mirroring guidelines</a>).</li>
-        <li>If a serious flaw if found in a test build or release, it may be withdrawn
by a majority vote of the PMC and removed from ASF distribution channels.</li>
-      </ul>
-    </subsection>
-    <a name="Coding"/>
-    <subsection name="Coding Conventions and Guidelines">
-      <p>Source code and documentation contributed to the Struts repositories should
observe the:</p>
-      <ul>
-        <li>
-            The
-            "<a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">
-            Code Conventions for the Java Programming Language</a>",
-            as published by Sun.
-        </li>
-        <li>
-        <a href="http://www.ambysoft.com/elementsJavaStyle.html">Elements of Java Style</a>,
and</li>
-        <li>
-          <a href="http://java.sun.com/j2se/javadoc/writingdoccomments/">How to write
Doc Comments</a>
-        </li>
-      </ul>
-      <p>as core references regarding the formatting of code and documentation.</p>
-      <p>
-        <strong>Clarifications</strong>
-      </p>
-      <ul>
-        <li>First, "Observe the style of the original". Resist the temptation to make
stylistic changes for their own sake. But, if you must reformat code, commit style changes
separately from code changes. Either change the style, commit, and then change the code, or
vice- versa.</li>
-        <li>Set editors to replace tabs with spaces and do not trim trailing spaces.
Tabs confound the version control alerts. Trimming trailing spaces creates unnecessary changes.</li>
-        <li>Specify imported classes (do not use 
-        <code>.*</code>).</li>
-        <li>Write all if/else statements as full blocks with each clause within braces,
unless the entire statement fits on the same line.</li>
-        <li>Use 
-        <code>FIXME:</code>and
-        <code>TODO:</code>tokens to mark follow up notes in code. You may also
include your Apache username and the date.</li>
-        <li>Omit 
-        <code>@author</code>tags.</li>
-        <li>Use 
-        <code>@since</code>to document changes between Struts versions, as in

-        <code>@since Struts 1.1</code>.</li>
-        <li>Wrap lines of code and JavaDoc at column 78. You can include a "comment
rule" in the source to help with this.
-        <br />
-        <small>// ------------------------------------------------------------------------
78</small></li>
-        <li>Please do your best to provide high-quality Javadocs for all source code
elements. Package overviews (aka "Developer Guides") are also encouraged.</li>
-        <li>When working on a bugfix, please first write a 
-        <a href="http://www.junit.org">JUnit</a> test that proves the bug exists,
and then use the test to prove the bug is fixed. =:0)</li>
-        <li>When working on an enhancement, please feel free to use test-driven design
and write the test first &lt;head-slap/&gt;. For more about TDD, see the 
-        <a href="http://sourceforge.net/projects/mockobjects">MockObjects project</a>.</li>
-        <li>As files are updated from year to year, the copyright on each file should
be extended to include the current year. 
-        <b>You do not need to change the copyright year unless you change the file.</b>Every
source file should include the ASF copyright notice and current Apache License and copyright.</li>
-        <li>Provide high-level API compatibility for any changes made within the same
major release series (#.x.x). Changes which adversely affect compatibility should be slotted
for the next major release series (++#.x.x).</li>
-        <li>Our favorite books about programming are 
-        <a href="http://www.amazon.com/exec/obidos/ISBN=0201633612/apachesoftwar-20/">Design
Patterns</a>,
-        <a href="http://www.amazon.com/exec/obidos/ISBN=0201485672/apachesoftwar-20/">Refactoring</a>,
and
-        <a href="http://www.amazon.com/exec/obidos/ISBN=0735619670/apachesoftwar-20/">Code
Complete</a> (2d).</li>
-        <li>Our favorite book about open source development is the 
-        <a href="http://www.amazon.com/exec/obidos/ISBN=1565927249/apachesoftwar-20/">The
Cathedral and the Bazaar</a>.</li>
-        <li>Our favorite science fiction author is 
-        <a href="http://www.nitrosyncretic.com/rah/">Robert Heinlein</a>. 
-        <a href="http://jargon.net/jargonfile/t/TANSTAAFL.html">TANSTAAFL</a>.
-        <br />(Except on Friday, when we favor 
-        <a href="http://news.bbc.co.uk/1/hi/uk/1326657.stm">Douglas Adams</a>).
-        </li>
-      </ul>
-    </subsection>
-  </section>
-    <section>
-      <p class="right">Next: 
-      <a href="javadoc.html">Javadoc Index</a></p>
-    </section>
-  </body>
+            <a name="Releasing"/>
+            <subsection name="Release Process">
+                <p>A
+                    <a href="http://jakarta.apache.org/commons/releases/versioning.html">
+                        point release</a>
+                    should be made before and after any product change that is
+                    not a "fully-compatible change" (see link). This includes
+                    moving a dependency from an internal package to an
+                    external product, including products distributed through
+                    the Jakarta Commons. We should place any fully-compatible
+                    changes in the hands of the community before starting on a
+                    change that is only "interface" or "external-interface"
+                    compatible.
+                </p>
+                <p>
+                    Any release should follow the same general process used by
+                    the
+                    <a href="http://jakarta.apache.org/site/decisions.html">
+                        Jakarta Tomcat</a>
+                    team
+                    and must observe the
+                    <a href="http://apache.org/dev/mirrors.html">Apache
+                        Mirroring guidelines</a>
+                    .
+                    See also
+                    <a href="http://wiki.apache.org/incubator/SigningReleases">
+                        Signing Releases</a>
+                    .
+                </p>
+                <p>Additional remarks:</p>
+                <ul>
+                    <li>Every committer is encouraged to participate in the
+                        release process, either as the release manager or a
+                        helper. Committers may also share the release manager
+                        role.</li>
+                    <li>The release process can seem daunting when you review
+                        it for the first time. But, essentially, it breaks
+                        down into four phases of just a few steps each:
+                        <ul>
+                            <li>
+                                <strong>Rolling</strong>
+                                - Bugzilla, dependencies, release notes, JAR
+                                manifest, licenses, copyrights, and build
+                                (using the release target).
+                            </li>
+                            <li>
+                                <strong>Testing</strong>
+                                - JUnit, Cactus, web apps (for all "supported"
+                                containers).
+                            </li>
+                            <li>
+                                <strong>Voting</strong>
+                                - Upload test build to internal directory,
+                                post majority vote on DEV list as to release
+                                grade: Alpha, Beta, General Availability.
+                            </li>
+                            <li>
+                                <strong>Distributing</strong>
+                                - Checksum, sign, mirror, update download
+                                page, announce.
+                            </li>
+                        </ul>
+                    </li>
+                    <li>Committers are
+                        <b>required</b>
+                        to post a release plan before tagging the repository
+                        and should wait the traditional 72 hours before
+                        proceeding.
+                    </li>
+                    <li>A checklist format can be used for the
+                        <a href="http://wiki.apache.org/struts/StrutsReleasePlans">
+                            release plan</a>
+                        , to help step through the process. The plan may be
+                        maintained in the repository or on the
+                        <a href="http://wiki.apache.org/struts/">Struts
+                            wiki</a>
+                        .
+                    </li>
+                    <li>Our dependencies on external JARs (including Commons
+                        JARs) should be in line with our own release status.
+                        Our nightly build can be dependant on another nightly
+                        build. Our beta can be dependant on another beta (or
+                        "release candidate"), but should avoid a dependance on
+                        a nightly build.
+                        Our General Availability release may only have
+                        dependencies on other GA, final, or stable
+                        releases.</li>
+                    <li>Use your own discretion as to detail needed by the
+                        Release Notes. A high-level description of the changes
+                        is more important than providing uninterpreted detail.
+                        At a minimum, new features and deprecations should be
+                        summarized, since these are commonly asked questions.
+                        Ideally, the release notes should be maintained
+                        continuously for the nightly build so that we they do
+                        not need to be assembled at the last minute.</li>
+                    <li>Try building the distribution under prior version of
+                        J2SE, if possible, to ensure that we are still
+                        backwardly-compatible. But, our distributions should
+                        be built using the
+                        <strong>latest production release of J2SE</strong>
+                        , to take advantage of all available compiler
+                        enhancements.
+                    </li>
+                    <li>If you have multiple J2SE versions configured, run the
+                        JUnit and Cactus tests using the same configuration
+                        that will be used to build the distribution.</li>
+                    <li>There is a "release" target in the buildfile that will
+                        zip and tar the distribution. Before uploading the
+                        distribution, extract the sample web applications and
+                        deploy the WARs under each of the "supported"
+                        containers (if you can). Play test each application
+                        under each container to be sure they operate
+                        nominally.</li>
+                    <li>The test build can be posted to the internal
+                        distribution directory (svn.apache.org/struts/) and
+                        announced to the Struts DEV and PMC lists (only!). Do
+                        not announce a test build on any other Apache lists or
+                        link to it from an Apache website.</li>
+                    <li>If the test build is voted to Alpha, Beta, or GA
+                        status, the release can announced to the User list and
+                        linked from the website.</li>
+                    <li>Any formal release may be submitted for mirroring. All
+                        GA releases
+                        <b>must</b>
+                        be mirrored.
+                    </li>
+                    <li>After announcing a release, remember to update the
+                        Acquiring and Announcements pages. If the release is
+                        to be mirrored, wait at least 24 hours after submittal
+                        before making public announcements (as stated in the
+                        <a href="http://apache.org/dev/mirrors.html">Apache
+                            Mirroring guidelines</a>
+                        ).
+                    </li>
+                    <li>If a serious flaw if found in a test build or release,
+                        it may be withdrawn by a majority vote of the PMC and
+                        removed from ASF distribution channels.</li>
+                </ul>
+            </subsection>
+            <a name="Coding"/>
+            <subsection name="Coding Conventions and Guidelines">
+                <p>Source code and documentation contributed to the Struts
+                    repositories should observe the:</p>
+                <ul>
+                    <li>
+                        The
+                        "
+                        <a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">
+                            Code Conventions for the Java Programming
+                            Language</a>
+                        ",
+                        as published by Sun.
+                    </li>
+                    <li>
+                        <a href="http://www.ambysoft.com/elementsJavaStyle.html">
+                            Elements of Java Style</a>
+                        , and
+                    </li>
+                    <li>
+                        <a href="http://java.sun.com/j2se/javadoc/writingdoccomments/">
+                            How to write Doc Comments</a>
+                    </li>
+                </ul>
+                <p>as core references regarding the formatting of code and
+                    documentation.</p>
+                <p>
+                    <strong>Clarifications</strong>
+                </p>
+                <ul>
+                    <li>First, "Observe the style of the original". Resist the
+                        temptation to make stylistic changes for their own
+                        sake. But, if you must reformat code, commit style
+                        changes separately from code changes. Either change
+                        the style, commit, and then change the code, or vice-
+                        versa.</li>
+                    <li>Set editors to replace tabs with spaces and do not
+                        trim trailing spaces. Tabs confound the version
+                        control alerts. Trimming trailing spaces creates
+                        unnecessary changes.</li>
+                    <li>Specify imported classes (do not use
+                        <code>.*</code>
+                        ).
+                    </li>
+                    <li>Write all if/else statements as full blocks with each
+                        clause within braces, unless the entire statement fits
+                        on the same line.</li>
+                    <li>Use
+                        <code>FIXME:</code>
+                        and
+                        <code>TODO:</code>
+                        tokens to mark follow up notes in code. You may also
+                        include your Apache username and the date.
+                    </li>
+                    <li>Omit
+                        <code>@author</code>
+                        tags.
+                    </li>
+                    <li>Use
+                        <code>@since</code>
+                        to document changes between Struts versions, as in
+                        <code>@since Struts 1.1</code>
+                        .
+                    </li>
+                    <li>Wrap lines of code and JavaDoc at column 78. You can
+                        include a "comment rule" in the source to help with
+                        this.
+                        <br/>
+                        <small>//
+                            ------------------------------------------------------------------------
+                            78</small>
+                    </li>
+                    <li>Please do your best to provide high-quality Javadocs
+                        for all source code elements. Package overviews (aka
+                        "Developer Guides") are also encouraged.</li>
+                    <li>When working on a bugfix, please first write a
+                        <a href="http://www.junit.org">JUnit</a>
+                        test that proves the bug exists, and then use the test
+                        to prove the bug is fixed. =:0)
+                    </li>
+                    <li>When working on an enhancement, please feel free to
+                        use test-driven design and write the test first &lt;head-slap/&gt;.
+                        For more about TDD, see the
+                        <a href="http://sourceforge.net/projects/mockobjects">
+                            MockObjects project</a>
+                        .
+                    </li>
+                    <li>As files are updated from year to year, the copyright
+                        on each file should be extended to include the current
+                        year.
+                        <b>You do not need to change the copyright year unless
+                            you change the file.</b>
+                        Every source file should include the ASF copyright
+                        notice and current Apache License and copyright.
+                    </li>
+                    <li>Provide high-level API compatibility for any changes
+                        made within the same major release series (#.x.x).
+                        Changes which adversely affect compatibility should be
+                        slotted for the next major release series
+                        (++#.x.x).</li>
+                    <li>Our favorite books about programming are
+                        <a href="http://www.amazon.com/exec/obidos/ISBN=0201633612/apachesoftwar-20/">
+                            Design Patterns</a>
+                        ,
+                        <a href="http://www.amazon.com/exec/obidos/ISBN=0201485672/apachesoftwar-20/">
+                            Refactoring</a>
+                        , and
+                        <a href="http://www.amazon.com/exec/obidos/ISBN=0735619670/apachesoftwar-20/">
+                            Code Complete</a>
+                        (2d).
+                    </li>
+                    <li>Our favorite book about open source development is the
+                        <a href="http://www.amazon.com/exec/obidos/ISBN=1565927249/apachesoftwar-20/">
+                            The Cathedral and the Bazaar</a>
+                        .
+                    </li>
+                    <li>Our favorite science fiction author is
+                        <a href="http://www.nitrosyncretic.com/rah/">Robert
+                            Heinlein</a>
+                        .
+                        <a href="http://jargon.net/jargonfile/t/TANSTAAFL.html">
+                            TANSTAAFL</a>
+                        .
+                        <br/>
+                        (Except on Friday, when we favor
+                        <a href="http://news.bbc.co.uk/1/hi/uk/1326657.stm">
+                            Douglas Adams</a>
+                        ).
+                    </li>
+                </ul>
+            </subsection>
+        </section>
+        <section>
+            <p class="right">Next:
+                <a href="javadoc.html">Javadoc Index</a>
+            </p>
+        </section>
+    </body>
 </document>

Modified: struts/site/trunk/xdocs/struts.css
URL: http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/struts.css?rev=376838&r1=376837&r2=376838&view=diff
==============================================================================
--- struts/site/trunk/xdocs/struts.css (original)
+++ struts/site/trunk/xdocs/struts.css Fri Feb 10 12:58:33 2006
@@ -1,266 +1,267 @@
 a {
-	color: #023264;
+    color: #023264;
 }
 
 body {
-	background: #FFFFFF;
-	color: #000000;
-	margin: 0;
-	padding: 20px 15px;
+    background: #FFFFFF;
+    color: #000000;
+    margin: 0;
+    padding: 20px 15px;
 }
 
-div.authors{
-	width: 150px;
-	background: #EEEEFF;
-	border: 1px solid #CCCCFF;
-	color: #333333;
-	margin: 2em 0 0;
-	padding-bottom: 0.5em;
+div.authors {
+    width: 150px;
+    background: #EEEEFF;
+    border: 1px solid #CCCCFF;
+    color: #333333;
+    margin: 2em 0 0;
+    padding-bottom: 0.5em;
 }
 
 div.authors li {
-	color: #023264;
-	line-height: 1;
-	margin: 0;
-	padding: 0;
+    color: #023264;
+    line-height: 1;
+    margin: 0;
+    padding: 0;
 }
 
 div.authors ul {
-	list-style: none;
-	margin: 0;
-	padding: 0;
+    list-style: none;
+    margin: 0;
+    padding: 0;
 }
 
 div.indent {
-	padding: 0 4%;
+    padding: 0 4%;
 }
 
 div.notice {
-	background: #00FFFF;
-	border: 1px solid #000000;
-	margin-left: 8%;
-	padding: 0 2%;
-	width: 80%;
+    background: #00FFFF;
+    border: 1px solid #000000;
+    margin-left: 8%;
+    padding: 0 2%;
+    width: 80%;
 }
 
-
-h1, h2 , h3 {
-	color: #FFFFFF;
-	font-family: Arial, Helvetica, sans-serif;
-	margin: 1em 0;
+h1, h2, h3 {
+    color: #FFFFFF;
+    font-family: Arial, Helvetica, sans-serif;
+    margin: 1em 0;
 }
 
 h1 a, h2 a, h3 a {
-	color: #FFFFFF;
+    color: #FFFFFF;
 }
 
 h1 {
-	background: #023264;
-	font-size: 1.2em;
-	font-weight: bold;
-	padding: 5px;
+    background: #023264;
+    font-size: 1.2em;
+    font-weight: bold;
+    padding: 5px;
 }
 
 h2 {
-	background: #023264;
-	font-size: 1.1em;
-	font-weight: normal;
-	padding: 3px 5px;
+    background: #023264;
+    font-size: 1.1em;
+    font-weight: normal;
+    padding: 3px 5px;
 }
 
 h3 {
-	background: #023264;
-	font-size: 1em;
-	font-weight: normal;
-	padding: 2px 5px;
+    background: #023264;
+    font-size: 1em;
+    font-weight: normal;
+    padding: 2px 5px;
 }
 
 h4 {
-	font-size: 1.1em;
+    font-size: 1.1em;
 }
 
 hr {
-	background: #CCCCCC;
-	border: none;
-	height: 1px;
+    background: #CCCCCC;
+    border: none;
+    height: 1px;
 }
 
 hr.section {
-	background: #023264;
-	border: none;
-	height: 1px;
+    background: #023264;
+    border: none;
+    height: 1px;
 }
 
 img {
-	border: none;
+    border: none;
 }
 
 img.book {
-	margin: 10px;
+    margin: 10px;
 }
 
 q {
-	font-family: Arial, Helvetica, sans-serif;
+    font-family: Arial, Helvetica, sans-serif;
 }
 
 table {
-	border: 2px solid #CCCCCC;
-	border-collapse: collapse;
+    border: 2px solid #CCCCCC;
+    border-collapse: collapse;
 }
 
 table.noborder, table.noborder td, table.noborder td th {
-	border: none;
+    border: none;
 }
 
-table.tag-attributes{
-	width: 100%;
+table.tag-attributes {
+    width: 100%;
 }
 
 table.taglib-summary {
-	width: 100%;
+    width: 100%;
 }
 
 table.task-list {
-	width: 100%;
+    width: 100%;
 }
 
-td,th {
-	border: 1px solid #CCCCCC;
-	padding: 3px;
+td, th {
+    border: 1px solid #CCCCCC;
+    padding: 3px;
 }
 
 th.attribute {
-	width: 15%;
+    width: 15%;
 }
 
 thead {
-	border: 2px solid #CCCCCC;
-	background: #DDDDDD;
-	color: #333333;
-	font-family: Arial, Helvetica, sans-serif;
+    border: 2px solid #CCCCCC;
+    background: #DDDDDD;
+    color: #333333;
+    font-family: Arial, Helvetica, sans-serif;
 }
 
 tr.evenRow {
-	background: #F6F6F6;
+    background: #F6F6F6;
 }
 
 .center {
-	text-align: center;
+    text-align: center;
 }
 
-.clear{
-	clear: both;
+.clear {
+    clear: both;
 }
 
 .deprecated {
-	color: #FF0000;
+    color: #FF0000;
 }
 
 .float-left {
-	float: left;
+    float: left;
 }
 
 .float-right {
-	float: right;
+    float: right;
 }
 
 .left {
-	text-align: left;
+    text-align: left;
 }
 
-.right{
-	text-align: right;
+.right {
+    text-align: right;
 }
 
 .since {
-	font-style: italic;
+    font-style: italic;
 }
 
 .version {
-	color: #999999;
-	font: 0.7em Arial, Helvetica, sans-serif;
-	margin: 0;
+    color: #999999;
+    font: 0.7em Arial, Helvetica, sans-serif;
+    margin: 0;
 }
 
 .warning {
-	color: #FF0000;
-	font-weight: bold;
+    color: #FF0000;
+    font-weight: bold;
 }
 
 #footer {
-	border-top: 1px solid #333333;
-	clear: both;
-	color: #023264;
-	font-size: 0.83em;
-	font-style: italic;
-	padding-top: 10px;
-	text-align: center;
+    border-top: 1px solid #333333;
+    clear: both;
+    color: #023264;
+    font-size: 0.83em;
+    font-style: italic;
+    padding-top: 10px;
+    text-align: center;
 }
 
 #heading {
-	border-bottom: 1px solid #333333;
-	height: 100px;
-	margin-bottom: 0.5em;
-	position: relative;
+    border-bottom: 1px solid #333333;
+    height: 100px;
+    margin-bottom: 0.5em;
+    position: relative;
 }
 
 #jakarta-logo {
-	left: 0;
-	position: absolute;
-	top: 0;
+    left: 0;
+    position: absolute;
+    top: 0;
 }
 
 #main {
-	margin-left: 22%;
+    margin-left: 22%;
 }
 
 #menu {
-	width: 21%;
-	float: left;
+    width: 21%;
+    float: left;
 }
 
 #menu li {
-	font-size: 0.84em;
-	font-weight: normal;
-	margin: 0 0 0.5em 2em;
+    font-size: 0.84em;
+    font-weight: normal;
+    margin: 0 0 0.5em 2em;
 }
 
 #menu p {
-	color: #023264;
-	font-weight: bold;
-	margin: 0.5em;
+    color: #023264;
+    font-weight: bold;
+    margin: 0.5em;
 }
 
 #menu ul {
-	list-style: none;
-	margin: 0 0 1em;
-	padding: 0;
+    list-style: none;
+    margin: 0 0 1em;
+    padding: 0;
 }
 
 #powered-logo {
-	float: right;
-	margin-bottom: 20px;
+    float: right;
+    margin-bottom: 20px;
 }
 
 #struts-logo {
-	position: absolute;
-	right: 0;
-	top: 0;
+    position: absolute;
+    right: 0;
+    top: 0;
 }
 
-@media print {
+@media
+print
+{
 .noprint, #menu, #jakarta-logo {
-	display: none;
+    display: none;
 }
+
 #main {
-	margin-left: 0;
+    margin-left: 0;
 }
 
 h1, h2, h3 {
-	background: #fff;
-	color: #000;
-	font-weight: bold;
+    background: #fff;
+    color: #000;
+    font-weight: bold;
 }
-
 
 }



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message