Page History

...

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.

...

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

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

3. Wiki Markup
   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. Wiki Markup
   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 Once this is done, add your dependency to pom.xml as normal.

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.

1. We specify a DEPENDENCY RANGE instead of a specific version
2. 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 example of a