Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

SCM integration

SCM (Software Configuration Management), which is also referred to as version control, is the core of the project. If your organization uses an SCM system, there is an easy way to place information into the POM file. The following code snippet declares a local SVN repository:

[…]
   <scm>
    <connection>
        scm:svn:http://127.0.0.1/svn/my-project
     </connection>
    <developerConnection>
        scm:svn:http://127.0.0.1/svn/myproject
    </developerConnection>
    <tag>HEAD</tag>
    <url>http://127.0.0.1/websvn/my-project</url>
  </scm>
[…]

The Maven SCM plugin or site generation uses these SCM configurations in the POM file to perform some tasks and goals. Eclipse, through the M2Eclipse plugin, will materialize your Maven project from SCM using these configurations.

Tip

Maven SCM supports the repositories SVN, Git, CVS, Jazz, Bazaar, Mercurial, Perforce, StarTeam, and CM Synergy.

Maven SCM Plugin

Maven SCM Plugin is a vendor-independent plugin to gain access to SCM supported by Maven. It allows you to execute the basic versioning functionalities of check-in, check-out, update, tag, branch, add, and remove.

The following code snippet declares the plugin in the pom.xml file:

  […]
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-scm-plugin</artifactId>
        <version>1.9</version>
        <configuration>
          <connectionType>connection</connectionType>
        </configuration>
      </plugin>
    </plugins>
  </build>
  […]

The connectionType tag declares the SCM connection to use.

You can check your configuration is correct by executing the validation goal:

$ mvn scm:validate

The result is as follows:

…
[INFO] connectionUrl scm connection string is valid.
[INFO] project.scm.connection scm connection string is valid.
[INFO] project.scm.developerConnection scm connection string is valid.
[INFO] ------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------
…

You can perform an SVN checkout by executing the checkout goal:

$ mvn scm:checkout

The result is as follows:

…
[INFO] Executing: svn checkout http://localhost/svn/example/ /ws
[INFO] Working directory: C:wsxample	arget
[DEBUG] Checked out revision 0.
[INFO] ------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------
…

Tip

If the checkout does not work, check that you have correctly installed the SCM client on the client machine, whether it's SVN, Git, and so on. The SCM Maven plugin works with the native client. The client must be accessible and the bin directory must be declared on the PATH settings.

Other useful available goals are as follows:

scm:branch -Dbranch=<name>: This is used to branch the project
scm:checkin: This is used to commit changes
scm:tag -Dbranch=<name>: This is used to tag a certain revision
scm:list: This is used to get the list of project files
scm:update: This is used to update the working copy with the latest changes

Maven Release Plugin

Maven Release Plugin is the most important plugin in a CI project; the plugin allows us to tag the source code using the SCM information and change the POM release and snapshot version. It is based on two phases: the prepare phase and the perform/rollback phase. As the first step, the plugin asks the user for a specific version, prepares the release version, and makes the tag of the component. As the second step, Maven deploys (or rolls back) the changes.

The plugin was introduced after Maven 2, but it is strongly recommended to use Maven Version 3.0.4 or later. The plugin makes some assumptions:

The start version must be a snapshot version (SNAPSHOT)
The allowTimestampedSnapshots and ignoreSnapshots dependencies must be released or set to true
No changes have to be committed

The plugin performs some actions:

It changes the current version to a release version by removing the SNAPSHOT suffix
It tags all the changes
It packages and installs the current version on the local repository
It sets the current version to a new snapshot version and commits it (by default, a +1 will be added to the final version number)

To add the plugin, you have to configure the pom.xml file, as follows:

[…]
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.5</version>
         <configuration>
   <tagBase>
http://127.0.0.1/websvn/my-project/tags
</tagBase>
   </configuration>
</plugin>
    </plugins>
   </build>
[…]

The next step is to launch Maven, as follows:

$ mvn release:clean release:prepare

Maven will ask for the new released version ID, tag name, and new development release (SNAPSHOT) ID:

What is SCM release tag or label for "Chp5Release Test"? (com.mycompany.project
s:my-first-maven-project) my-first-maven-project-1.0: :
…
What is SCM release tag or label for "Chp5 Release Test"? (com.mycompany.project
s:my-first-maven-project) my-first-maven-project-1.0: :
…
What is the new development version for "Chp5 Release Test"? (com.mycompany.proj
ects:my-first-maven-project) 1.1-SNAPSHOT: :
…
[INFO] Release preparation complete.
[INFO] -----------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] -----------------------------------------------------

Then, you can deploy the changes on a remote repository:

$ mvn release:perform

Maven will check out from SCM and release the project (deploy and site-deploy) on the remote repository. This step requires the definition of the repository location.

Deploying on the remote repository

The released software must be deployed on the remote (Nexus) repository in order to be accessible by every developer. Generally speaking, it is a good idea to create different repositories for each team of your organization on the remote server in order to control access to the artifacts; in our case, we use the default Nexus repositories. If your organization doesn't require strict access to some artifacts, the default Nexus installation is what you are looking for.

To publish the released plugin on Nexus, we have to define the release or snapshot repository, and we can call the maven deploy command:

$ mvn deploy

You can also use the following command if you use Maven Release Plugin:

$ mvn release:perform

In the pom.xml file, we have to define the repository manager (Nexus) URL:

[…]
<properties>
    <repo-id>nexus_releases</repo-id>
    <repo-name>Nexus Release</repo-name>
    <repo-url>
      http://localhost/nexus/content/repositories/releases/
    </repo-url>
</properties>
[…]
    <distributionManagement>
      <repository>
        <id>${repo-id}</id>
        <name>${repo-name}</name>
        <url>${repo-url}</url>
     </repository>
     </distributionManagement>
[…]

If the repository requires authentication, we have to define the credentials in the settings.xml file:

    <server>
      <id>nexus_releases</id>
      <username>admin</username>
      <password>admin123</password>
    </server>

Formally speaking, the example proposed here is not correct, and Maven offers two types of repository declarations: repository and snapshotRepository. A snapshotRepository declaration is used only for the snapshot artifact. A repository declaration is used for the release and snapshot artifacts if the snapshot repository has not been declared. To conclude, a more correct definition of the repositories is as follows:

[…]
  <distributionManagement>
<repository>
   <id>${repo-id}</id>
   <name>${repo-name}</name>
   <url>${repo-url}</url>
</repository>
<snapshotRepository>
   <id>${repo-snapshot-id}</id>
   <name>${repo-snapshot-name}</name>
   <url>${repo-snapshot-url}</url>
</snapshotRepository>
</distributionManagement>
[…]

In this case, Maven will deploy the release artifact in the release repository and snapshot artifact (version x.x.x-SNAPSHOT) in the snapshot repository.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for SCM integration

Create new playlist

Sign In

Sign Up

SCM integration

Tip

Maven SCM Plugin

Tip

Maven Release Plugin

Deploying on the remote repository

Table of Contents for
SCM integration