View Source

Introduction

Moves serves two primary functions: Creating releases and deploying those releases to Containers (a.k.a App Servers). This section discusses the release process in detail.

A typical MIT application (for example a web app) will contain

code specific to that application
MIT developed components
third party components (for example the spring framework)

We will call these MIT apps, MIT components and 3rd party components respectively.

Prerequisites

Subversion set-up

Each MIT app and MIT component exists as a maven project. That project is housed in a subversion repository, using the subversion "trunk, tags, branches" pattern. That is, for every MIT application and every MIT component, there exists a subversion URL which contains the sub-folders "trunk", "tags" and "branches". In general, development occurs in the "trunk" folder, but on rare occasions development can occur in a subfolder of the "branches" subfolder. (See http://svnbook.red-bean.com/en/1.2/svn.branchmerge.maint.html for an overview of the "trunk, tags, branches" pattern.

Maven set-up

Within trunk, there will be a file called pom.xml. All builds are built by Maven. The pom.xml tells maven how to build an app/component, and which components that app/component depends upon. While Maven is primarily designed for building java apps and components, plugins exist whereby it can be used to package and assemble other types of components/application. A complete overview of Maven is beyond the scope of this document. However, for those new to maven, the following is a great place to begin learning http://www.sonatype.com/books/maven-book/.

Declaring dependencies on 3rd Party components - the easy way

For many/most mainstream open source components (for example the Spring Framework), source and binary code is automatically accessible to your project simply by declaring a dependency. For example, to include the Spring framework, we would add the following dependency

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-web</artifactId>
    <version>3.0.3.RELEASE</version>
</dependency>

Since spring-web version 3.0.3 and all of it's dependencies exist in the standard maven repositories, then we're done.

Declaring dependencies on 3rd Party components which have their own repositories

It is possible to add repositories directly to your pom.xml. However, it is preferable to have a MIT Maven Repository Admin mirror the 3rd party repository. This will make the component available to all projects, while also decreasing network loads. (For the SAIS teams, the mirror configured in the MIT Maven Repository should be visible to the "saisGroupRepo" repository. See your network admin for details.) Once this is done, add your dependency to pom.xml as normal.

Declaring dependencies on 3rd Party components which do not have a maven distribution available.

Sometimes the 3rd party components we wish to use will not exist in the standard Maven repositories. This may be because they are closed source, or because the vendor has their own repository. In this case, you will potentially need to perform the following tasks

make up a group id (usually com.whateverthevendornameis) and artifactid (e.g my3rdpartycomponent)

rename the jar file to \[artifactid]-\[version].jar

create a jar file containing the source files, if available, and call it  \[artifactid]\-\[version]-sources.jar. This step is optional but STRONGLY recommended.

create a pom file (pom.xml) with the correct groupId and artifactId. This file should also contain any dependencies to jar files used by the component. If these components are in the standard maven repositories, use those dependencies. Otherwise repeat this process for each dependent component.

provide your MIT Maven Repository Admin with the pom.xml, \[artifactid]\-\[version].jar and optional  \[artifactid]-\[version]-sources.jar and request they add that to the appropriate  MIT Maven Repository for your group.

Once this is done, add your dependency to pom.xml as described in "Declaring dependencies on 3rd Party components - the easy way".

Declaring dependencies on MIT components

In our Continuous Integration environment, we desire to always (or nearly always!) build apps that depend on the latest version of a component. This ensures that we know as soon as possible when a change is made to a component that breaks a dependency from another app/component. Thus we want our "trunk" builds to always point to the latest available version of an MIT component. That will be the trunk build of the component itself. To accomplish this we do two things.

We specify a DEPENDENCY RANGE instead of a specific version
We configure the component to use snapshot builds (if available) when building an app/component that includes that component

Below is an example of an app which specifies a dependency range for the MIT component edu.mit.ist.es.common:sais-common-workflow

<dependency>
    <groupId>edu.mit.ist.es.common</groupId>
    <artifactId>sais-common-workflow</artifactId>
    <version>[0.0.0,999.999.999)</version>
</dependency>

Below is an excerpt from the sais-common pom.xml file which shos how to configure sais-common, such that applications which depend on sais-common will use snapshot builds when resolving a dependency range.

...
<build>
    <plugins>
        <plugin>
            <!-- because this component is a plugin, and because dev and ci
            builds always point to the LATEST SNAPSHOT, we will configure
            the maven-install-plugin to consider snapshot builds to the 
            local repo to be a release.
            -->
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-install-plugin</artifactId>
            <version>2.3.1</version>
            <configuration>
                <updateReleaseInfo>true</updateReleaseInfo>
            </configuration>
        </plugin>
        ...
    </plugins>
    ...
</build>
...