| The Commons package (as well as the other Jakarta packages) is distributed in both binary and source forms. The binary releases can be found at: http://jakarta.apache.org/site/binindex.cgi
The source code releases corresponding to the binary releases can be found at: http://jakarta.apache.org/site/sourceindex.cgi
Finally, if you are interested in the latest (possibly unstable) release of Commons (or any other Jakarta software), instructions on CVS access are provided at: http://jakarta.apache.org/site/cvsindex.html
Apache Jakarta The Apache Jakarta project (http://jakarta.apache.org) simply refers to the Java-related projects conducted under the Apache Software Foundation's banner. Other popular Jakarta projects include the Tomcat web application server, the Cactus test framework, and the Velocity template engine. Certain projects, such as Struts and Ant, were originally part of the Jakarta project but have since "graduated" to exist as top-level Apache projects. |
Generally speaking, you are advised to download the binary release at a minimum. The binary releases of the Commons projects covered in this book typically include a single JAR file, a README.txt, a LICENSE.txt file, and a docs directory. The JAR file should be added to your class path. For example, you would copy the JAR file to your WEB-INF/lib directory for a web application. You may also want to download the source distribution if you want to contribute to, debug, or examine the Commons package. Directory Conventions On my Windows development system, I install downloaded libraries into a single directory, c:\devenv\. This represents my personal repository of downloaded libraries (and associated documentation, samples, etc.). My development source trees are stored in another directory, c:\devrep\, which is controlled by a version control system (CVS, soon to be converted to Subversion). As libraries are required by projects, I copy the .jar files from the c:\devenv\ directory into the appropriate location in c:\devrep\. Therefore, project-specific dependencies are resolved by relative paths, but upon occasion, interim development is done with references to the c:\devenv\ directory. I don't use the c:\Documents and Settings\<username> directory because too many packages are confused by spaces in paths. On UNIX systems, I generally use ~\devrep\ and ~\devenv\. There's nothing particularly magical about this strategy, but it does keep my tools and documentation nicely separated from my development tree. |
|
