You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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.

Pre-requisites

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

Spring-web Framework Dependency
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-web</artifactId>
    <version>3.0.3.RELEASE</version>
Since spring-web version 3.0.3 and all of it's dependencies exist in the standard maven repositories, then we're done.
</dependency>

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

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

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

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

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

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

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

In these cases it is preferred to store the binary file (usually .jar), a corresponding source jar, and a pom.xml file that contains dependencies in the MIT Maven Repository (https://maven-mit-edu.ezproxyberklee.flo.org). See your MIT maven admin for access and repository rules. It is possible to also declare 3rd party repositories in your pom.xml, which is NOT a desirable solution. Finally it is possible to request the

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.

  • No labels