Page History

...

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/.

The pom.xml file contains an element called version. In the subversion trunk *the version will always contain the -SNAPSHOT suffix.

Declaring dependencies on 3rd Party components - the easy way

...

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 normaldescribed in "Declaring dependencies on 3rd Party components - the easy way"..

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

...

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<common</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>
...

Adding your project to the Projects Directory

The Release Process

When you use Moves to perform a release of a component/application, the following steps happens

1. Moves will check out the trunk source of the component/application from subversion
2. Moves will parse the pom.xml to see if any dependency ranges are found. Moves will assume these dependency ranges are themselves MIT components.
3. For each component found, moves will check out that component and recursively perform this set of steps.
4. Moves will present you with a build page. For each component you will be given the option of performing a new build, or using an existing release
5. Moves will take your input and use that to create a branch. The project version in the branch will be the same as the version in trunk, with the "-SNAPSHOT" suffix removed. Thus if your project is at version 2.1.5-SNAPSHOT, the branch version will be 2.1.5.
6. Moves will increment the version in trunk. In our example above, the project version in trunk will become 2.1.6-SNAPSHOT.
7. Moves will replace the dependency ranges in the branch with the versions that were calculated based on your selections. These can be previously released versions, or if you elected to release a new component, it will be the version of the component which will be released as part of this build.
8. Moves will build each component for which you selected to build a new release
9. Moves will build your top level component/application
10. Moves will release each component/application that has been built to the MIT Maven repository
11. Moves will commit the trunk changes (i.e. the incremented SNAPSHOT version) for each component/application that has been built

12. Wiki Markup
    Moves will commit the branch changes for each released component (i.e the release version, and resolved dependency ranges) to the \[subversion url]/tags/releases/\[version] tag

13. Wiki Markup
    Moves will copy the working branches for each released component to the \[component's subversion url]/tags/releases/\[version] tag

14. Moves will remove the working branches for each released component

Thus at the end of the process, the following changes will have occurred:

1. Each released component will exist in the MIT Maven repository

2. Wiki Markup
   A tag containing the source code for each released component will exist in \[component's subversion url]/tags/releases/\[version] tag. The pom.xml file's version element in that tag will have the release version, and any dependency ranges in that tag will have been replaced with the version of that component that was used in the release

3. Wiki Markup
   For each released component, the \[component's subversion url]/trunk/pom.xml file's version element will have been incremented.