Most developers will skip many of these steps because they probably        already have some of the components in place.        <OL>          <LI>Install a 1.5 or later JDK and set a Windows env. variable for            JAVA_HOME, with value of the absolute path to your JDK            installation root.            You can download a JDK from            <A HREF="http://java.sun.com/javase/">Sun</A>.          </LI> <LI>            Install or have deployment access to a 2.4-spec-compliant servlet            container like            <A HREF="http://tomcat.apache.org/">Tomcat</A> version 6.            (Could be installed on a different computer).          </LI> <LI>            Install a JDT variant of Eclipse, version 3.4.1 or later.            I prefer the plain <I>Java</I> package, because it doesn't            include tons of stuff that you will never use, like the much            larger distributions have.            After you extract the distribution, execute the startup binary            once with the <CODE>-initialize</CODE> switch.          </LI> <LI>            To install Subversive, the Subversion client plugin,            use pulldown menu <CODE>Help / Software Updates</CODE> and click            the <CODE>Install</CODE> button.            Bring up a web browser at the same time and browse to            <A HREF="http://www.polarion.com/products/svn/subversive.php?src=eclipseproject">    http://www.polarion.com/products/svn/subversive.php?src=eclipseproject</A>.            Back in Eclipse, click the <CODE>Available Software</CODE> tab             and Add the two "required" URLs listed in the "Latest Release"            section of that web page.            Select the latest available release of each of the four following            items and install them.<UL>              <LI>SVN Team Provider</LI>              <LI>JDT Ignore Extensions</LI>              <LI>Connectors / Subversive SVN Connectors</LI>              <LI>Connectors / SVNKit</LI>            </UL>            When done, you will be prompted to restart Eclipse.  Do so.          </LI> <LI>            After Eclipse restarts, use pulldown menu <CODE>File / Import</CODE>            and import from Subversion.            Enter URL of <CODE>https://jwebmail.svn.sourceforge.net/svnroot/jwebmail/trunk</CODE>            and no other detals (unless you're a team developer).            If it craps out, restart Eclipse and retry... or it could be a            bad Internet connection to Sourceforge.          </LI> <LI>            Get rid of any Eclipse views that you don't need.            Use pulldown <CODE>Window / Show View / Ant</CODE>.            Click the target icon in the Ant view toolbar to hide internal            Ant targets.            Right click in the view and add the Ant build file            <CODE>build.xml</CODE> from the root directory of the project.            At this point all of the listed Ant targets should work,            except for <CODE>gen-guide</CODE> and <CODE>all</CODE>, if you            don't have <CODE>xsltproc</CODE> installed.            Double click on <CODE>jwebmail</CODE> to execute the default target,            which builds the war file.            You will probably also want to execute the target            <CODE>javadoc</CODE> to build the JWebMail API spec docs with            entry point of <CODE>build/apidocs/index.html</CODE>.          </LI> <LI>            Now you just need to get IDE compilation working, and cooperating            with the Ant build.            Go to <CODE>Preferences / General / Workspace</CODE> to turn            <CODE>Build automatically</CODE> off and <CODE>Refresh</CODE>            and <CODE>Save</CODE> on.          </LI> <LI>            Use pulldown <CODE>Project / Clean...</CODE> to clean just            the <CODE>jwebmail</CODE> project...            and turn off the nasty <CODE>Start a build immediately</CODE>            button (definitely a bad thing for shared Ant setups).          </LI> <LI>            Execute the ant target <CODE>eclipse-setup</CODE> and set the            build variable as you instructed in the console output.          </LI> <LI>            Anybody who will be contributing code to this project, or to any            other project with professional standards should read the next            section too.          </LI>        </OL>      </P>    <A HREF="#install:ide">Top of section "IDE Setup"</A><A HREF="#install:intro">Top of section "Installing"</A><HR><A NAME="install:ide"></A><H2>3.4. IDE Code Contributors</H2><P>        People contributing code to the JWebMail project must create code        that isn't difficult for other developers to work with, and must        commit resources in a way that doesn't clobber other workers.        Even if you aren't going to commit code to our project,        you're welcome to use these procedures if you just like developing        like a professional, or if you are sharing with somebody else.      </P><P> <OL>        <LI>          Even though you are a graphical developer, you need to read          and understand the development rules above in the          <CODE>Build and Install from source</CODE> section bove.        </LI> <LI>          Back to eclipse.          A general tip is to be liberal with hitting <CODE>Apply</CODE>          and <CODE>OK</CODE> when changing Eclipse preferences.          It's much better now than with older versions, but Eclipse is known          to sometimes <I>not get</I> your changes.          If that happens, just repeat and make sure you apply.          Back to the task at hand, go to          <CODE>Windows / Preferences / Team / SVN / Properties Configuration</CODE>          and Import the file <CODE>samples/config-svn.txt</CODE>.          This file has specifically been massaged to do what it needs to do          while accommodating several serious parsing bugs in the Eclipse          Subversive plugin.        </LI> <LI>          The remaining items all involve importing Eclipse XML Java          style profiles.          <CODE>Window / Preferences / Java / Code Style</CODE>          First, go to the <CODE>Clean Up</CODE> and Import the file          <CODE>samples/cleanup-ecpro.xml</CODE>.        </LI> <LI>          Go to the <CODE>Formatter</CODE> and Import the file          <CODE>samples/formatter-ecpro.xml</CODE>.          Note that this formatter disabled word-wrapping for Java files,          because Eclipse does a truly terrible job at it.          It doesn't even enforce the rules as it explains and exemplifies them.          Sorry to say, but after running Eclipse's code formatter, you'll          need to apply word-wrapping manually (according to          <CODE>doc/conventions.txt</CODE>.          (The formatter works perfectly well for Javadoc and non-Javadoc          comments).        </LI> <LI>          Finally, go to <CODE>Code Templates</CODE>, but this time don't          load the profile at the global level.          That's because, whereas the other settings are good for any          Java project, these templates may not be appropriate for other          Java projects that you may work on in the same Eclipse workspace.          The only known issues with the code templates is that they will          insert useless blank Javadoc lines like "    *" if there are no          tags for a method, and it will insert a blank line after {'s and          before }'s.        </LI> <LI>          Click on the <CODE>Configure Project Specific Settings...</CODE>.          Select the <CODE>jwebmail</CODE> project and click <CODE>OK</CODE>.          Click the <CODE>Enable project specific settings</CODE> checkbox.          Import the file <CODE>samples/codetemplates-ecpro.xml</CODE>.        </LI> <LI>          In the upper tree, select <CODE>Comments / Types</CODE> and hit          the <CODE>Edit...</CODE> button.          (IMO it's rather counterintuitive that the lower box there is not          an editable box-- you must hit the <CODE>Edit...</CODE> button to          edit.          Change the text "Your Name Here" to your name, spelled out and          capitalized like that.        </LI> <LI>          Before exiting the <CODE>Properties for jwebmail...</CODE> screen,          make sure to check the <CODE>Automatically add comments...</CODE>          button and click the <CODE>Apply</CODE> and <CODE>OK</CODE> buttons.        </LI>      </OL></P><A HREF="#install:ide">Top of section "IDE Code Contributors"</A><HR><A NAME="install:logging"></A><H2>3.5. Logging setup</H2><P>        Webapp logging is best administered at the container level.        Most servlet containers were designed to work this way, and many        technology companies expend much effort to defeat Classloader        design and manage logging with delivered application artifacts.        Remember that logging settings are a runtime consideration which        should be modifiable after deployment by operations personnel.        JWebMail is exceptional in that it facilitates logging      </P><P>        Webapp bundles just Apache Commons Logging.        Commons Logging provides the front end for logging, where the        JWebMail application sends log messages.        Your servlet container will connect these generated messages to        a logging <I>back end</I> to write log files, database records, or        emails from them.        If you have a straight-forward servlet container, and you have        not added a logging product to it, then Commons Logging will        also handle the back end in the container space, just logging        to the console or stdout/stderr log with default settings.        But it is very easy to improve on that.        Some application servers have logging management utilities,        and you can use them to pipe the JWebMail log entries to        destinations using Gui tools or text files.        You'll have to see your App Server documentation about these        tools.        Otherwise, you can put text files in container-level classloader        directories to easily set up text, HTML, and even email-alert        logging.      </P><P>        I will explain how to set up really nice JWebMail logs using        Log4J as the back end (container-side) logging product on        Tomcat.  In my experience, everybody is satisfied with Log4j.        The procedure is very much the same to use another logging        back end product (see the Commons Logging documentation about        how to do it).  The setup procedure is the same for other        servlet containers (that don't force their logging management        system on you), except you just need to find out where the        system classpath directories are (or how to add them).      </P><P>Container logging setup with Log4j and Tomcat<UL>        <LI>          The default container classpath directory on Tomcat 6.x          is <CODE>CATALINA_HOME/lib</CODE> by default.          I.e., the "lib" subdirectory          of the Tomcat installation root directory.          You can put both Jar files and in .class files (in package          directory trees) into it.          (You can add other classpath directories by changing the          setting <CODE>common.loader</CODE> in the file          <CODE>conf/catalina.properties</CODE>).        </LI> <LI>          Copy a recent version of the file          <A HREF="">          log4j.jar</A> into the servlet container classpath directory.        </LI> <LI>          Copy a recent version of the file          <A HREF="">          admc-log4j.jar</A> into the servlet container classpath directory.        </LI> <LI>          Copy the file <CODE>log4j.xml</CODE> from the samples directory          of your JWebMail distribution into the servlet container classpath directory.        </LI> <LI>          Set the Java System Property <CODE>logdir.common</CODE> for Tomcat.          Our <CODE>log4j.xml</CODE> file uses this variable to set the          destination directory for log files independently of where Tomcat          is started from.  The best way to set Java System Properties for          Tomcat is by setting the environmental variable CATALINA_OPTS.          Where to set this variable depends on how you start Tomcat.          If you use one of Tomcat's startup scripts directly on the          command-line, then set the variable according to these samples.          On Windows,          <P><CODE>              CATALINA_OPTS="-Djava.awt.headless=true -Xms512m -Xmx1024m -XX:MaxPermSize=256m -Dlogdir.common=$HOME/logs"          </CODE></P>          On Unix,          <P><CODE>              set CATALINA_OPTS=-Djava.awt.headless=true -Xms512m -Xmx1024m -XX:MaxPermSize=256m -Dlogdir.common=c:/logs          </CODE></P>          The samples shows unrelated settings which are often useful.          See the Tomcat docs for details about them.        </LI> <LI>          Restart Tomcat.        </LI>      </UL>        If you prefer working with .properties files instead of .xml files,        you can make a <CODE>log4j.properties</CODE> file instead.        See the Log4j documentation about how to set up email alerts        with the SMTP appender, how to log to a database, etc.      </P><P>        Be aware that the file (<CODE>log4j.xml</CODE> or        <CODE>log4j.properties</CODE>) will control all messages which        reach Log4j in the container space.        If you have three other web apps deployed to this container without        log4j jar files bundled, their log messages will also be filtered        by this file.      </P><P>        Regardless of the container and logging product, if you manage        logging at the container level without a Gui, the server classpath        file will be the central point of application log management for        the container.        You can use package names to route messages to application-specific        destinations (files, emails, etc.).        The only tricky part of container-managed logs is routing messages        initiated by classes common to more than one webapp.        This isn't the place to discuss how to route such messages, but        you generally don't have to worry about it if your app catches all        throwables, and you have the same app deployed more than        once-at-a-time.      </P><A HREF="#install:logging">Top of section "Logging setup"</A><HR><A HREF="#install">Top of section "Installation"</A><A NAME="config"></A><TABLE WIDTH="100%" BGCOLOR="#a0d895" CELLSPACING="0" BORDER="0"><TR><TD><H1><CENTER>IV. Configuration</CENTER></H1></TD></TR></TABLE><P>      JWebMail has an administration interface which allows you to perform      several runtime administration tasks, including:      <UL>        <LI>Changing all configuration settings</LI>                <LI>Adding, deleting or editing JWebMail virtual domains</LI>        <LI>Adding, deleting or editing JWebMail users</LI>        <LI>Getting status information</LI>      </UL>      See the JWebMail Administrator Plugin section for details.