Versions Compared

Old Version 7

changes.mady.by.user Unknown User (eotoole@mit.edu)

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (eotoole@mit.edu)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

  1. make up a group id (usually com.whateverthevendornameis) and artifactid (e.g my3rdpartycomponent)
  2. Wiki Markuprename the jar file to \ [artifactid]-\[version].jarunmigrated-wiki-markup
  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.unmigrated-wiki-markup
  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.

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

...

  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 builtunmigrated-wiki-markup
  12. 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 MarkupMoves 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

...

  1. Each released component will exist in the MIT Maven repositoryunmigrated-wiki-markup
  2. 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 releaseunmigrated-wiki-markup
  3. For each released component, the \ [component's subversion url]/trunk/pom.xml file's version element will have been incremented.

Creating a branch

Moves provides a facility for creating branches. If you need to branch a project, and if that project might have a release associated with it, then you should use Moves to create a branch.

When should I create a branch?

The answer to this is almost never. Branches add complexity, and changes made to a branch must be applied to the trunk. The process is subject to human error.

Valid reasons for creating a branch include

  1. Emergency bug fixes. Suppose you have example-web-app version 1.2.3 on production, and trunk is not in a releasable state. A critical bug needs fixing and you cannot wait until the next scheduled release. In this case you need to
    1. Branch the release on production (1.2.3).
    2. Branch any dependent components that must have code changes
    3. Fix the bugs
    4. Release the branch release
    5. Merge the fix back into trunk
  2. Concurrent development. Suppose you have a major change in example-web-app that requires a 6 month developer effort. Meanwhile, the business requires minor enhancements to be released every month. In this case you should create the branch, and apply the minor fixes and releases to that branch.
    1. Merge all branch changes back into trunk frequently.
    2. When the major release is ready, the branch should no longer be worked on.

Branch prerequisites

  1. A branch must be created from a release tag. Thus, if you want to create a branch from trunk you should
    1. make sure trunk builds
    2. create a release of trunk (it's ok to do nothing with that release... moves just needs the tag for a branch point)
  2. For each dependent component you must decide if you want to create a branch of that component.
    1. If the dependent component does not need to change (ie you are only changing code in your application), there is nothing to do.
    2. If you wish to use the trunk version of the dependent component, then change the version of the dependency in your application back to a range (ie <version>[0.0.0,999.999.999)</version>).
    3. If you wish to use a branch version of the dependent component, then complete these steps for the dependent component, and set up a BRANCH RANGE. (See "Branching Example" below for how to create a dependent branch range).

Branching example.

Let's suppose we have application example-web-app which has version 2.5.3 deployed to production. It depends on edu.mit.ist.es.common:sais-common:3.1.5 (the sais-common component version 3.1.5). Let's suppose it also depends on edu.mit.ist.es.components:example-component:1.2.3 (example-component version 1.2.3). A bug is found in production, and the trunk is not in a releasable state (perhaps we have a bunch of untested changes). We need a release as soon as possible. It is found that the bug fix requires changes to sais-common and example-web-app, but not to example-component.

(In trunk, example-web-app is at version 2.6.0-SNAPSHOT, sais-common is at 4.1.2-SNAPSHOT and example-component is at 1.2.4-SNAPSHOT).

The following will need to occur.

  1. Use moves to create a branch of example-web-app version 2.5.3. (This will become version 2.5.3b1.0-SNAPSHOT)
  2. Use moves to create a branch of sais-common component version 3.1.5. (This will become version 3.1.5b1.0-SNAPSHOT)
  3. Check out the example-web-app branch code (from [example-web-app-svn-url]/branches/releases/2.5.3b1).
  4. Check out the sais-common branch code (from [sais-common-svn-url]/branches/releases/3.1.5b1).
  5. edit the sais-common dependency in example-web-app's pom.xml, so that
    Code Block
    langxml
    titleRange dependency example
    From:
<dependency>
    <groupId>edu.mit.ist.es.common</groupId>
    <artifactId>sais-common</artifactId>
    <version>3.1.5</version>
</dependency>
To:
<dependency>
    <groupId>edu.mit.ist.es.common</groupId>
    <artifactId>sais-common</artifactId>
    <version>[3.1.5b1.0, 3.1.5b1.999)</version>
</dependency>

Your project should now build and deploy. Moreover, Moves will allow you to select a branch build after you commit all of your changes.

Once the branch has been created, the release process is much like the trunk release process. However, instead of the versions incrementing from, say 1.2.3-SNAPSHOT to 1.2.4-SNAPSHOT, they will increment from, say 1.2.3b1.0-SNAPSHOT to 1.2.3b1.1-SNAPSHOT. This allows you to perform multiple releases on the branch, until the branch cycle is completed. The corresponding released versions will be 1.2.3b1.1, 1.2.3b1.2, 1.2.3b1.3 etc.

Screenshots

TODOSince the ranges have been removed from the branch,