Page 3 of 3   « previous page

SCM
Maven also provides plug-ins that support various version management systems like CVS, ClearCase, and Subversion. A Maven build can use these plug-ins to automate tasks of files from the version systems based on the tagged version of the project until the deployment components are packaged.

Project Site
Most organizations maintain a list of projects, their stakeholders, and the status on/using portal-based applications. Maven generates a site with project data based on the information provided to it. This site contains details on the project's users, mailing lists, dependencies, and issues tracked and offers a quick project overview.

Maven Build Process Architecture
Let's define a build process architecture based on Maven and a repository product named Artifactory (see Figure 1).

The system and actors represented in the figure are:
1)  Developers: Individuals working to develop a code base for the project using an IDE (such as RAD).
2)  Developer Workstation: The system on which the developers develop, unit test, and build deployable components from the code base as part of the project development lifecycle.
3)  Local Repository: The location (folder) on the developer workstation that caches the dependent artifacts of the project derived from the internal repository during the Maven build.
4)  Maven: An open source build management tool from Apache.
5)  Internal Repository: A centralized repository in an organization used to maintain dependent artifacts for all its projects.
6)  Artifactory: An open source repository management application that provides caching, security, and user-friendly GUIs for managing artifacts. It comes as a WAR application that can be easily deployed and started on any Web container like Apache Tomcat.
7)  CVS Repository: A version management system that manages the project code base and its versions.
8)  Build Server: The system in which the support engineers build projects using the code base from CVS and then execute Maven on it.
9)  Build Engineers: Individuals working on building the project from the code base and deploying the components resulting from Maven's execution on the project to the respective servers.

This process architecture is explained in the context of building a project that will deliver an in-house artifact or reusable component.
1)  The developer creates a new project and defines a folder structure that can either adhere to Maven standards or an organization's own established standards. Note that with non-Maven standards, the POM.xml has to be configured with source directories for Maven to execute.
2)  As part of the development, the developer enhances the code base and defines the project-dependent artifacts in POM.xml.
3)  The developer builds the project using Maven. Maven uses POM.xml as input and executes tasks (prepares resources, compiles, unit tests, packages) according to the build lifecycle set by Maven internally for the artifact. During task execution, Maven resolves the project dependencies first by locating the artifacts in the local repository, or if not there then in the internal or external repositories. Maven caches the dependent artifacts in the local repository when they are first downloaded from the internal or external repositories.
4)  Steps 2 & 3 are repeated until the programmer has finished developing and testing the generated JAR artifacts. He then tags the code base in the version management system and prepares it for release by providing the project name and version information to the build engineers.
5)  Build engineers retrieve the tagged version of the project and prepare to build the project.
6)  Build engineers build the project using Maven and Maven executes the project per the build lifecycle and along the way resolves dependent artifacts from the repositories.
7)  The project build results in the generation of the JAR artifact that will be used across projects and so has to be maintained in the internal repository like other dependent artifacts. Build engineers can use one of the execution tasks in Maven's build lifecycle to deploy the generated JAR artifact to the internal repository. Build engineers can also deploy the artifact to the internal repository manually by uploading it through Artifactory's Web interface.

Case Study - Build a Web Application Project
Let's see how to start and build a Web application project using Maven based on this build process architecture. You need to have Maven and Artifactory installed.

Maven and Artifactory Configuration
The internal repository is managed by Artifactory and deployed in Tomcat. Artifactory has a single configuration file called artifactory.config.xml and following details are configured there:
1)  Local repositories are logical groupings of the artifacts in the repository. Each local repository is defined by a logical name (like Commercial repo, Open source repo) and whether it stores only releases or snapshots.
2)  The remote repository is the external repository and this element is configured with the URL: http://repo1.maven.org.

Maven is configured for downloading artifacts from the internal repository. The configurations for this are done in Settings.xml:
1)  Provide the internal repository URL for artifact releases and snapshots.
2)  Provide the user credentials for these repositories.
3)  Provide proxy server information if the repository server is behind a proxy.

Project Folder Structure
The first most important task before starting project development is to create a folder structure that is meaningful and easy for developers from a build perspective. Maven suggests a directory structure for each type of artifact (JAR, WAR, EAR) or organizations can create folders according to their own standards. The example used here follows Maven's suggested directory structure and refered to the code samples for the layout.

Update POM.xml
It is suggested that Maven projects start with the template POM.xml generated by the Maven plug-ins available for each artifact type. This template POM.xml is located under the project's main folder and is updated as project development progresses. The POM file is mainly enhanced by dependency artifacts, multi-modules during the project lifecycle.

Maven Build Release
Maven projects are built using these commands:

• 'mvn package' - It packages the deployable component by building from the project source and puts it in the 'target' folder under project root folder.
• 'mvn install' - It packages the deployable component and installs it in the local repository.
• 'mvn deploy'- It packages and deploys it in the internal repository.

For web-based application projects, the generated artifact (WAR) is to be deployed in an application server. So 'mvn package' is used to build the artifact and then build engineers deploy it to the application server.

Convert Existing Projects to Maven-Enabled
When there's an enterprise-wide Maven build process to be implemented, the priorities are:
1)  The existing project structure should not be altered. This is to make sure that the developers/support engineers on the project are at ease; the POM.xml for these projects has to have a 'build' element configured with the appropriate source location.
2)  Smooth transition from the old build process. Developers and support engineers have to be trained on the new build process and its benefits over the old process.
3)  Maven-enable one project at a time without changing the existing code base except for the addition of the POM.xml file. Test the project build after creating the POM file and then implement this build process as part of a production fix or release.

Conclusion
The process architecture detailed here was based on Maven and Artifactory tools to meet the enterprise objective of having a stable build process. The point of choosing Maven, its critical features, and the concept of repositories that help meet the objective were explained. The build process was detailed with actors, tools, and their responsibilities and finally demonstrated by building a sample Web application.

This build process is applicable to most enterprises with slight variations for the organizations' policies and preferences for using an external repository in automated way, the extent of the automation needed, and the use of CruiseControl/Continuum as part of this architecture for continuous builds.

Page 3 of 3   « previous page