Once you have your development server up and running you are ready to start custom development. The ccm-devel-create.pl creates a skeleton application directory for your project where you should place your custom code. You should have a directory for each custom application you develop in your dev directory and an entry in project.xml. This chapter will detail the layout of the application directory and configuration files, however the details of actually writing XSL, Java, PDL, and JSP are beyond the scope of this document, please refer to the guides on CCM Website or other resources. Log in as your development user and run the command ccm-profile projectname . cddev to change into the development directory. Make the desired code changes ant deploy to deploy and test the changes. If you are using CVS check in the changes. The dev directory will contain one or more application directories. Each of these directories will be built as a single unit, but may depend on functionality provided by other applications. An application directory contains several subdirectories: application name | | + -- application.xml | | + -- etc/ | | | | | + -- enterprise.init.in | | + -- web/ | | | | | + -- packages | | + -- src/ | | | | | + -- com/arsdigita/ | | + -- pdl/ | | + -- com/arsdigita/ This holds any custom fragments your package will need to add to the system initializer file, enterprise.init, in a file called enterprise.init.in. When you are building your project, one of the steps you will take will be running a task that concatenates all the appropriate enterprise.init.in fragments together into one master configuration file. etc/ might also contain custom libraries or other special files your package relies on. This directory contains the PDL files for custom data objects your application creates and uses. If you explore the pdl/ directory, you'll see it is organized like Java packages, with directories following a package hierarchy. Like Java, PDL code is organized in packages (called models), and PDL objects can extend other PDL objects. This directory contains the custom SQL files that create, drop, and upgrade the database schema for your application, and a single custom create script (oracle-se-create.sql, for example) for each database you want your application to run on. SQL files are organized by package and by the database they are appropriate for. Note that auto generated sql, which is what most of your sql will be, only appears in the build and deployment directories, not in this sql/ directory. holds the Java source code for your package. It is organized according to the standard Java package directory hierarchy. This holds Junit and other test classes for your application. test/ will have at least a src/ directory underneath it, and it may have other directories holding non-Java files necessary for running your application tests. This holds files from your application that should be deployed directly to the servlet container's webapp root (like the document root for a web server, the webapp root is the directory where the servlet container looks for Java classes, and for JSPs and any static files it needs to serve). Under web/ you will find a packages/ directory; in a complete application, you might also see a STATIC/ or assets/ directory for static files like graphics or CSS. The packages/ directory under web/ deserves a few special words. packages/ is the location for the XSL for your application, and also for any JSPs you may want to include. Note that a ccm package is not the same thing as a Java package; a &CCM; application can contain many &CCM; packages, which can contain many Java packages. The distinction is that a &CCM; package is represented by a row in a &CCM; system table, can be mounted at site nodes and can have its own dispatcher. A Java package is simply a unit of code organization, and is not tracked by &CCM; in any way. XSL stylesheets for a package go under the packages/package-name/xsl/ directory. Custom JSPs go under the packages/package-name/www/ directory. application.xml provides metadata about an application, primarily for use when building a package. <?xml version="1.0" encoding="ISO-8859-1"?> <ccm:application name="aplaws-custom" prettyName="The APLAWS customization and styling package" version="1.0.0" release="1"> <ccm:dependancies> <!-- <ccm:requires name="core" version="5.0.0"/> --> </ccm:dependancies> <ccm:contacts> <!-- <ccm:contact uri="http://www.redhat.com/software/ccm" type="website"/> <ccm:contact uri="mailto:cms@redhat.com" type="support"/> --> </ccm:contacts> <ccm:description> The aplaws-custom package customizes the APLAWS system. </ccm:description> </ccm:application> As with project.xml, the most commonly changed parameters are attributes of the top level element, <ccm:application>: The machine friendly name of the application. This is not normally changed once it has been set. The human friendly name of the application. The version number of the application. This always consists of 3 numbers, separated by '.', which have decreasing significance from left to right. By convention, the first number is the 'very major' version number. This is normally only changed to signify a very significant enhancement or change in functionality. The second number is less major, but still represents a significant new version. The third number is the minor version number. You will normally change this number for bug fixes or minor enhancements. If you specified this application in the extendsVersion attribute of project.xml then the value you specify here will be top level version number for your project. The release number specifies a particular build of a version number. By convention, you should increase the release number only if you are correcting something which should have been in the original release, or something so minor it could not possibly impact on any other part of the system, such as a typo. When increasing the version number, you should reset the release number to 1. If you specified this application in the extendsVersion attribute of project.xml then the value you specify here will be top level release number for your project. The <ccm:dependancies>, <ccm:contacts> and <ccm:description> elements are placeholders for future functionality, and are not currently used. The Concurrent Versions System (CVS) is a powerful file system-based tool for managing changes made to a code base. It is particularly useful for tracking changes across time and for facilitating collaboration of multiple developers on the same code. This section will provide a brief introduction to CVS and the very basic commands. However it is strongly recommended that you study the CVS manual to take full advantage of this tool. CVS works by storing all changes in a central repository, called the CVS repository. Developers can make copies of the code from the CVS repository - called a check out - and make changes to the code. Joe Developer is happy with the changes the the developer can submit the new changes to the repository (called a check in). If a Bob Developer comes along and checks out the same code base, it will now have the changes that Joe made, along with the history of how Joe changed the code. Because both developers are always referring to the central CVS repository code changes can be easily shared. CVS can provide you with the following capabilities for your code base: Remember what all the previous checked-in versions of a file contained, using its repository. Show you the difference between what's in your tree and what's in the repository. Help you merge changes made simultaneously by multiple authors who might have been unaware of each other's work. Group a snapshot of currently checked-in versions of files as a partcular release Revert back to a previous version of the code. Act as a backup and restore facility. Once you have made changes to a file you need to notify the repository of your changes. You can do this with the command cvs commit. You can retrieve changes that other developers have made with the command cvs update. You should always run cvs update before you start working to make sure that the files you are working on are up to date. CVS is a very popular software and there is endless online documentation on how to use it. There is also help available in the manual page for CVS and command line help. CVS online documentation. man cvs cvs --help-options: List of options you can use with CVS. cvs --help-commands: List of commands you can use with CVS.