WebSphere Commerce Build and Deployment tool repository structure

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

Default 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 should be included in this directory in the workspace.
workspace/DataLoad	The Rational Application Developer simple project introduced by the Build and Deployment 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 `WCBD_installdir`/project-template directory, which can be imported into the WebSphere Commerce Developer workspace and checked into the repository. Use the following steps to populate and organize the project with your customization data: At the root of the `DataLoad` project, create the directory with the specified name 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 In each of the following directories created in the preceding steps: If you have data that is common to all the target environment, create a directory called `common`, and place the common data files in the directory. If you have data that is specific to a target environment, create a directory specific to the target environment and place the target-specific data files in the directory. For example, `prod` for the production environment, and `qa` for the QA environment. Note: If you are loading data to an Oracle database by using the massload and idresgen utilities as part of running the WCBD utility (for example, through acpload), ensure that you update the idresgen.customizer property value to OracleConnectionCustomizer in your wcbd-deploy.properties file. For more information about deployment properties, see Server deployment configuration properties.
workspace/StaticWeb	The Rational Application Developer static Web project introduced by the Build and Deployment tool, holds static Web server assets. A template of the empty `StaticWeb` project is provided in the `WCBD_installdir`/project-template directory, which can be imported into the WebSphere Commerce Developer workspace and checked into the repository. The project can then be populated with the static Web server assets. Note: Management Center Store preview does not retrieve static content from the StaticWeb project. If you want to preview static assets, ensure that you keep a copy in the `Store_archivedir`. Only copy static assets that are production-ready to the StaticWeb project. The StaticWeb project exists for the sole purpose of deploying static content to a web server at deployment time to serve your deployed store.

Considerations for structuring the repository

There are some implications to the functionality, performance, and configuration of the build and deployment process, as well as the development process of how the repository is structured. You must consider the following points when setting up the repository for use by the Build and Deployment tool:

In WebSphere Commerce Developer Version 7.0, the out-of-the-box 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 subsequently includes these modules as part of the partial application update, thereby introducing configuration issues on the deployed WebSphere Commerce application. It is therefore imperative to exclude such modules from the repository. If there is already an existing repository that employs a different structure than the default structure used by the Build and Deployment tool, and if it cannot be restructured, consider one of the following options:
1. Customize the source extraction Ant script to exclude the out-of-the-box WebSphere Commerce Java EE modules from the checkout process, or delete them from the source after the checkout process.
2. Use the ear.dir.excludes property in the build configuration file to exclude the out-of-the-box 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 out-of-the-box WebSphere Commerce Java EE modules from the deployment packages in the build process.
For the WC project, you are recommended to check in only the changed files. This will 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, only these files should be checked into the repository. Many SCM supports a feature that excludes files from being checked into the repository and can be leveraged. Refer to the SCM documentation for details.
If any out-of-the-box WebSphere Commerce Java EE module or library exists in both the WebSphere Commerce or WebSphere Commerce Developer installation directory and the WC project in the source directory as extracted from the repository, the copy in the source directory will take precedence and loaded into the compilation and EJBDeploy classpath in the build process. This ensures that there are no duplicate entries and only the most relevant entries in the classpath, with respect to how the repository is organized.
For WebSphereCommerceServerExtensionsData, WebSphereCommerceServerExtensionsLogic, or a new project that has been added or modified by your customization, check in the entire project into the repository. This is required by the build process to resolve build dependencies, and to compile correctly.
For any existing Web project that is modified by your customization, check in only the changed files if possible. This will 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, only these files should be checked into the repository.
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 OpenLaszlo source code.
For any project in the workspace that has not been modified by your customization, do not check it into the repository. This avoids unnecessary work in the build and deployment processes. For example, if the CommerceAccelerator project has not been modified, it is not necessary to include it in the repository.