WebSphere Commerce Build and Deployment tool repository structure
The WebSphere Commerce 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 that 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.
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 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
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:
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 that is introduced by the WebSphere Commerce 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
- In WebSphere Commerce Developer V8.0, 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. It is therefore imperative to exclude such modules from the repository. If a repository that employs a different structure than the default structure that is used by the Build and Deployment tool exists, and if it cannot be restructured, consider one of the following options:- 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.
- 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. - 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 leveraged. Refer to the SCM documentation for details. - If any default WebSphere Commerce Java EE modules
or libraries exist 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 takes precedence and is 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 is added or modified by your customization, check in the entire project into the repository. You need to check in the entire project because so that the build process can resolve build dependencies and compile correctly. - For any existing Web project that is modified by your 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 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 was not modified, do not include it in the repository.