WebSphere Commerce Build tool repository structure

The WebSphere Commerce Build tool is configured by default to use a specific reference repository structure. Use this repository structure because the default repository structure reduces configuration effort of the build process, and provides an intuitive structure that mirrors the WebSphere Commerce Developer workspace. If we are unable to use the default repository structure, the build process can be configured to adapt to our own repository structure.

Description of the default repository structure

Directory path	Description
workspace	Contains modules or projects that are part of the WebSphere Commerce Developer workspace. Refer to the next section for details on what to include in this directory in the workspace.
workspace/DataLoad	The Rational Application Developer simple project that is introduced by the WebSphere Commerce Build tool holds data files. Supported formats include SQL and XML files. These formats must conform to the WebSphere Commerce loading utilities (massload, acugload, acpload, and acpnlsload) formats. The structure of the DataLoad project provides a way to separate different types of data files and different target environments.A template of the empty DataLoad project is provided in the WCB_installdir/project-template directory, which can be imported into the WebSphere Commerce Developer workspace and checked into the repository. Populate and organize the project with our customization data, by creating directories in the DataLoad project named for each type of data you customize: SQL sql Massload XML: xml User (access) group acug Access control policy acp NL access control policy acpnls

Considerations for structuring the repository

There are some implications to the functions, performance, and configuration of the build and deployment process, and the development process of how the repository is structured. We must consider the following points when you set up the repository for use by the Build and Deployment tool:

• In WebSphere Commerce Developer Version 9, the default binary Java EE modules are included in the WC project. These modules might contain binding and configuration information specific to the development environment. If you include such modules in the repository, it might be included in the deployment packages by the build process. The server deployment process includes these modules as part of the partial application update, which might potentially introduce configuration issues on the deployed WebSphere Commerce application. Therefore, it is imperative that you exclude such modules from the repository. Check whether a repository exists that employs a different structure than the default structure used by the Build and Deployment tool. If it cannot be restructured, consider one of the following options:

  1. Customize the source extraction Ant script to exclude the default WebSphere Commerce Java EE modules from the check-out process, or delete them from the source after the check-out process.

  2. Use the ear.dir.excludes property in the build configuration file to exclude the default WebSphere Commerce Java EE modules from the deployment packages in the build process.

  3. Use the Excluding EAR assets from the deployment packages build feature to exclude the default WebSphere Commerce Java EE modules from the deployment packages in the build process.

• For the WC project, check in only the changed files to improve the build and deployment performance, and reduce the size of the deployment packages. For example, if the customization adds or changes only some properties files and XML files, check in the properties and XML files only. Many SCM supports a feature that excludes files from being checked into the repository and can be used. Refer to the SCM documentation for details.

• For WebSphereCommerceServerExtensionsData, WebSphereCommerceServerExtensionsLogic, or a new project that is added or modified by our customization, check in the entire project into the repository. Check in the entire project so that the build process can resolve build dependencies and compile correctly.

• For any existing web project that is modified by our customization, check in only the changed files to improve the build and deployment performance, and reduce the size of the deployment packages. For example, if the customization adds or changes only the Struts configuration file and some JSP files in the Stores project, check in the configuration and JSP files only.

• For the LOBTools project, the WebContent/config, WebContent/WEB-INF/.settings, and WebContent/WEB-INF/src directories are required to be checked into the repository. These assets are required by the build process to compile the XML source code for the Management Center definition syntax.

• For any project in the workspace that is not modified by our customization, do not check it into the repository. This avoids unnecessary work in the build and deployment processes. For example, if the CommerceAccelerator project was not modified, do not include it in the repository.

Related concepts
Advanced build features

Related tasks
Setting up source extraction Ant script
Configure packaging settings
Building packages

Related reference
Build configuration references