husted 2003/08/29 09:49:40 Modified: doc status.xml Log: + Add draft of 1.x.x whiteboard Revision Changes Path 1.35 +21 -256 jakarta-struts/doc/status.xml Index: status.xml =================================================================== RCS file: /home/cvs/jakarta-struts/doc/status.xml,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- status.xml 29 Aug 2003 14:27:09 -0000 1.34 +++ status.xml 29 Aug 2003 16:49:40 -0000 1.35 @@ -142,17 +142,35 @@ <ul> <li>Move to Commons Resources</li> <li>Move taglibs into separate JARs</li> - <li>Consider new Request Processor, if available</li> + <li>Enhance all configs to extend one configuration element from another, + as is done with Tiles Definitions</li> </ul> </li> <li>Struts 1.4.x - More substantial enhancements to product base <ul> + <li>Consider new Request Processor, if available</li> <li>Consider migration to an Action context</li> </ul> </li> + <li>Other potential enhancements for the 1.x.x series + <ul> + <li>Move to <a href="http://xml.apache.org/forrest/">Forrest</a> or <a href="http://maven.apache.org/">Maven</a> for project management</li> + <li>Consider adopting several popular extensions, including: + <ul> + <li><a href="http://sslext.sourceforge.net/">SSL Ext</a></li> + <li><a href="http://strutstestcase.sourceforge.net/">TestCase</a></li> + <li><a href="http://stxx.sourceforge.net">Stxx</a> (XLST)</li> + <li><a href="http://www.livinglogic.de/Struts/">Workflow</a></li> + <li><a href="http://struts.sf.net">Cocoon Plugin</a></li> + <li><a href="http://struts.sf.net">Scriptable Actions using BSF</a> (Bean Scripting Framework)</li> + </ul> + </li> + </ul> + </li> + </ul> <!-- @@ -185,16 +203,6 @@ </li> <li> - Better support for XLST technology (e.g. stxx) - </li> - - <li> - Better support for unit testing within the framework (e.g. - <a href="http://sourceforge.net/projects/strutstestcase/">Struts TestCase</a>) - or perhaps even a distinct unit testing framework. - </li> - - <li> Encouraging the use of <a href="http://sourceforge.net/projects/xdoclet/">XDoclet</a> and other code generation technologies to streamline development. </li> @@ -295,252 +303,9 @@ </section> - <section href="releases" name="Release Guidelines"> - - <p> - A <a href="http://jakarta.apache.org/commons/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> - A fully-compatible point release does not always need a "preview" beta or milestone release. - If appropriate, a Release Candidate can be cut, uploaded to the Release Manager's home directory - on cvs.apache.org (~/public_html), and voted to be released to the general public from there. - </p> - - <p> - Any release should follow the same general process used by the Jakarta Commons - and the Apache HTTP Server project. - </p> - - <ul> - <li> - <a href="http://jakarta.apache.org/commons/releases/">Releasing Common Components</a> - </li> - <li> - <a href="http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases">Signing a release version</a> - <ul> - <li> - <small>The MD5 tool is installed on daedalus, and you can create the digests for Struts releases there.</small> - </li> - </ul> - </li> - <li> - <a href="http://httpd.apache.org/dev/release.html">Apache HTTPD Server Release Guidelines</a> - </li> - </ul> - - <p> - Additional remarks: - </p> - - <ul> - <li> - Remember to update the <a href="news/index.html">Status section of the News page</a> when cutting any milestone. - For a final release, also update the /doc/project.xml with the current release number. - </li> - <li> - The release process can seem daunting when you review it for the first time. - But, essentially, it breaks down into three phases of just a few steps each: - <ul> - <li>Building - Bugzilla, dependencies, release notes, JAR manifest, licenses, copyrights, and build (using the release target).</li> - <li>Testing - JUnit, Cactus, web apps (for all "supported" containers). </li> - <li>Distributing - Checksum, sign, mirror, release, update Struts site, update Jakarta site, announce.</li> - </ul> - </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, - but should avoid a dependance on a nightly build. - Our release candidate can have a dependance on another RC, - but should not have a dependance on a beta (and certainly <b>not</b> a nightly build). - Our final release can only have dependencies on other final 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 do not need to quickly assembled them on the eve of a Release. - </li> - <li> - Test building the distribution under prior version of J2SE, if possible, - to ensure that we are still backwardly-compatible. - But, our Release distribution should be built using the <b>latest release of J2SE</b>, - to take advantage of all available compiler enhancements. - </li> - <li> - Before building the final release, run the JUnit and Cactus tests using the same - configuration used that will be used to build the Release distribution. - </li> - <li> - There is a "release" target in the buildfile that will zip and tar the releases. - Before uploading the release, extract the sample web applications and deploy the WARs under - each of the "supported" containers. - Play test each application under each container to be sure they operate nominally. - </li> - <li> - By the way, the nightly builds are being created on a machine of Craig McClanahan's. - If there are problems with a nightly build that seem infrastructure related, - Craig is the one to contact. - </li> - </ul> - - </section> - - -<section href="guidelines" name="Coding Conventions and Guidelines"> - - <p> - Source code and documentation contributed to the Struts repositories - should observe the: - </p> - - <ul> - - <li> - <a href="http://jakarta.apache.org/site/source.html">Jakarta project - guidelines</a>, - </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. - </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. - <code>:FIXME: we need to do this sometime (husted 2002-11-14)</code> - </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 <head-slap/>. - 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. - You do not need to change the copyright year unless you change the file. - Every source file should include the current Apache License and copyright. - </li> - - <li> - Provide high-level API compatibility for any changes made within the same - major release series (#.x). - Changes which adversely affect compatibility should be slotted for the - next major release series (++#.x). - </li> - - <li> - Our favorite books about programming are - <a href="http://www.amazon.com/exec/obidos/ISBN=0201633612/hitchhikeguidetoA/"> - Design Patterns</a> and - <a href="http://www.amazon.com/exec/obidos/ISBN=0201485672/hitchhikeguidetoA/"> - Refactoring</a>. - </li> - - <li> - Our favorite book about open source development is the - <a href="http://www.amazon.com/exec/obidos/ISBN=1565927249/hitchhikeguidetoA/"> - 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://www.tuxedo.org/~esr/jargon/html/entry/TANSTAAFL.html"> - <font size="-1">TANSTAAFL</font></a>.<br /> - (Except on Friday, when we favor - <a href="http://carbon.cudenver.edu/~mstilman/zaphod/">Douglas - Adams</a>. - <a href="http://news.bbc.co.uk/1/hi/uk/1326657.stm"> - <font size="-1">SLATFATF</font></a>.) - </li> - - </ul> - -</section> - <section> <p align="right"> - Next: <a href="news/index.html">News and Status</a> + Next: <a href="news/index.html">Release Guidelines</a> </p> </section>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]