You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by br...@apache.org on 2002/04/07 05:04:16 UTC

cvs commit: jakarta-commons-sandbox/net/xdocs code-standards.xml project.xml tasks.xml

brekke      02/04/06 19:04:15

  Added:       net/xdocs code-standards.xml project.xml tasks.xml
  Log:
  Started some documentation.  Lifted the coding stanard from Turbine and created
  the tasks.xml that maven pulls in automagically.  The tasks include Daniel Savarese's
  list from his site about the future of NetComponets and links to the contrib'd patch
  from Steve Cohen.
  
  Revision  Changes    Path
  1.1                  jakarta-commons-sandbox/net/xdocs/code-standards.xml
  
  Index: code-standards.xml
  ===================================================================
  <?xml version="1.0"?>
  
  <document>
  
   <properties>
    <title>Coding Standards</title>
    <author email="jon@latchkey.com">Jon S. Stevens</author>
    <author email="jvanzyl@apache.org">Jason van Zyl</author>
   </properties>
  
  <body>
  
  <section name="Coding Standards">
  
  <p>
  This document describes a list of coding conventions that are required
  for code submissions to the project. By default, the coding conventions
  for most Open Source Projects should follow the existing coding conventions
  in the code that you are working on. For example, if the bracket is on
  the same line as the if statement, then you should write all your code
  to have that convention.
  </p>
  
  <p>
  <strong>If you commit code that does not follow these conventions, you
  are responsible for also fixing your own code.</strong>
  </p>
  
  <p>
  Below is a list of coding conventions that are specific to Jakarta Commons/Net
  everything else not specificially mentioned here should follow the official
  <a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">Sun
  Java Coding Conventions</a>.
  </p>
  
  <p>
  1. Brackets should begin and end on a new line and should exist even
  for one line statements. Examples:
  </p>
  
  <source test=""><![CDATA[
  if ( foo )
  {
      // code here
  }
  
  try
  {
      // code here
  }
  catch (Exception bar)
  {
      // code here
  }
  finally
  {
      // code here
  }
  
  while ( true )
  {
      // code here
  }
  ]]></source>
  
  <p>
  2. Though it's considered okay to include spaces inside parens, the
  preference is to not include them. Both of the following are okay:
  </p>
  
  <source test=""><![CDATA[
  if (foo)
  
  or
  
  if ( foo )
  ]]></source>
  
  <p>
  3. 4 space indent. <strong>NO tabs</strong>. Period. We understand
  that many developers like to use tabs, but the fact of the matter is
  that in a distributed development environment where diffs are sent to
  the mailing lists by both developers and the version control system
  (which sends commit log messages), the use tabs makes it impossible to
  preserve legibility.
  </p>
  
  <p>
  In Emacs-speak, this translates to the following command:
  
  <source><![CDATA[
  (setq-default tab-width 4 indent-tabs-mode nil)
  ]]></source>
  </p>
  
  <p>
  4. Unix linefeeds for all .java source code files. Other platform specific
  files should have the platform specific linefeeds.
  </p>
  
  <p>
  5. JavaDoc <strong>MUST</strong> exist on all methods.  If your code
  modifications use an existing class/method/variable which lacks
  JavaDoc, it is required that you add it.  This will improve the
  project as a whole.
  </p>
  
  <p>
  6. The Jakarta License <strong>MUST</strong> be placed at the top
  of each and every file.
  </p>
  
  <p>
  7. If you contribute to a file (code or documentation), add yourself to the
  authors list at the top of the file. For java files the 
  preferred Javadoc format is:
  </p>
  
  <source><![CDATA[
  @author <a href="mailto:user@domain.com">John Doe</a>
  ]]></source>
  
  <p>
  8. All .java files should have a @version tag like the one below.
  </p>
  
  <source><![CDATA[
  @version $Id: code-standards.xml,v 1.1 2002/04/07 03:04:15 brekke Exp $
  ]]></source>
  
  <p>
  9. Import statements must be fully qualified for clarity.
  </p>
  
  <source><![CDATA[
  import java.util.ArrayList;
  import java.util.Hashtable;
  
  import org.apache.foo.Bar;
  import org.apache.bar.Foo;
  ]]></source>
  
  <p>
  And not
  </p>
  
  <source><![CDATA[
  import java.util.*;
  import org.apache.foo.*;
  import org.apache.bar.*;
  ]]></source>
  
  <hr noshade="true" size="1"/>
  
  <p>
  X/Emacs users might appreciate this in their .emacs file.
  </p>
  
  <source><![CDATA[
  (defun apache-jakarta-mode ()
    "The Java mode specialization for Apache Jakarta projects."
    (if (not (assoc "apache-jakarta" c-style-alist))
        ;; Define the Apache Jakarta cc-mode style.
        (c-add-style "apache-jakarta" '("java" (indent-tabs-mode . nil))))
  
    (c-set-style "apache-jakarta")
    (c-set-offset 'substatement-open 0 nil)
    (setq mode-name "Apache Jakarta")
  
    ;; Turn on syntax highlighting when X is running.
    (if (boundp 'window-system)
        (progn (setq font-lock-support-mode 'lazy-lock-mode)
               (font-lock-mode t))))
  
  ;; Activate Jakarta mode.
  (if (fboundp 'jde-mode)
      (add-hook 'jde-mode-hook 'apache-jakarta-mode)
    (add-hook 'java-mode-hook 'apache-jakarta-mode))
  ]]></source>
  
  <p>
  Thanks for your cooperation.
  </p>
  
  </section>
  
  </body>
  </document>
  
  
  
  1.1                  jakarta-commons-sandbox/net/xdocs/project.xml
  
  Index: project.xml
  ===================================================================
  <?xml version="1.0" encoding="ISO-8859-1"?>
  <project name="Jakarta Commons/Net" href="http://jakarta.apache.org/commons/net/">
  
    <title>Jakarta Commons/Net</title>
    <logo href="/images/logo.jpg">Jakarta Commons/Net</logo>
  
    <body>
      <menu name="Development">
        <item name="Coding Specifications"   href="/code-standards.html"/>
      </menu>
    </body>
  </project>
  
  
  
  1.1                  jakarta-commons-sandbox/net/xdocs/tasks.xml
  
  Index: tasks.xml
  ===================================================================
  <?xml version="1.0"?>
  <document>
  
    <properties>
      <title>Tasks</title>
      <author email="Jeff.Brekke@qg.com">Jeffrey D. Brekke</author>
    </properties>
  
    <body>
      <section name="Tasks">
        <p>
          <ul>
            <li>
              Convert code to specified coding standards.  Use checkstyle once
              it is integrated into Maven.
            </li>
            <li>
              Evaluate/Integrate existing file list parsing patch from Steve Cohen.
              <ul>
                <li>
                  <a href="http://groups.yahoo.com/group/devel-netcomponents/files/NetComponents-1.3.8a-src.tar.gz">
                  Patch</a>
                </li>
                <li>
                  <a href="http://groups.yahoo.com/group/devel-netcomponents/message/85">Description</a>
                </li>
              </ul>
            </li>
            <li>
              Clean out any classes that don't belong in this project.  Probably classes from
              org.apache.commons.util and org.apache.commons.io could be moved to their corresponding
              commons projects.
            </li>
            <li>
              Create proposal documents for the project.
            </li>
            <li>
              DefaultFTPFileLister doesn't work with every FTP server. 
              Some Microsoft and VMS FTP servers foil it. It is also 
              wasteful of memory in that it parses the listing into a
              complete set of FTPFile instances when it could store the 
              listing and just parse the listing on demand through an 
              iterator. An FTPFileListParser implementation should be 
              created that is backed by the original listing and iterates 
              through it using a regular expression. Regular expressions 
              could be installed based on FTP server system id's, so when 
              a user runs across an unsupported server, he can register a 
              regular expression rather than create a completely new 
              hand-parsed FTPFileLister implementation. ( Partially implemented
              by patch listed above )
            </li>
            <li>
              Make buffer size settable for FTP data transfers using 
              retrieveFile(). retrieveFile() uses Util.copyStream and a 
              1024 byte buffer which is too small for some applications 
              (Solaris SMP).
            </li>
            <li>
              Divorce FTPClient from TelnetClient, getting rid of the 
              TelnetClient threads which cause problems on some platforms 
              (e.g., MacOS).
            </li>
            <li>
              Parse the client/server interactions without creating so many 
              strings. Many operations are slow because of this.
            </li>
            <li>
              Add ESMTP and extended NNTP commands (e.g., NNTP authentication).
            </li>
            <li>
              Make NNTPClient.listNewsgropus() and NNTPClient.listNewNews() 
              more efficient. Don't preparse into lots of little objects.
            </li>
            <li>
              TLS for FTP
            </li>
          </ul>
        </p>
      </section>
    </body>
  </document>
  
  
  

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>