CC's logo



CC's Build System

Introduction
Basic individual project build and deployment
More advanced project build and deployment
Extracting commonality
Repository building
Automatic Repository building
Adding a Project to the Process
CC's specific Maven goals
Auto-versioning deployment system
Automatic deployment interface
Adding unit testing


Other Information

Maven Definitions
Jelly Scripting Hints



Automatic Deployment Interface

The automatic deployment system is for internal developers only and is meant to simplify the tedious, error-prone process of creating releases for CC's unique applications. It is intended to allow programmers and activity developers to forget about the details of Maven and CVS and create a easy to follow standard process for deploying projects. However, this simplicity comes at a cost, since lack of knowledge by a user may cause release information to be lost, so it is imperative that users of this system understand it, understand their project in relation to other projects, and never overwrite a previously released version unless they know they are doing it. Although an overwritten release can be recovered since everything will be in CVS, the information retrieval will not be trivial. That is one of the motivations of this process in the first place, since simply using CVS tags for marking milestones can not guarantee the information will not be lost and a release can be recreated. Self-referencing file catalogs of a project with file versions and a tag name is used to keep that type of information and it is checked into CVS. Then a version map is maintained to hold project release versions, the last released version of a project, it's dependencies and their versions, and the file catalog's version number for the project. With all of that information, there will always be enough information to recreate a release deployment.

Many of the options may not make much sense or seem useful for some developers, but as mentioned earlier, there are multiple application setups that require these options. If a developer is unsure of what an option will do, they should use the test deployment interface (different web address than the normal deployment page), which uses test cvs and deployment repositories. Otherwise, use the Test Mode: option on the main page.

Below is a screenshot of the top of the automatic deployment page:

Top of deployment page

The section of the deployment page in the image above has all of the selectable options needed to execute a project's deployment.
The bottom part of the deployment page shown below is mostly for informational purposes:

Bottom of deployment page

The red numbers are not on the actual page, but are added here as markers for the descriptions that follow.

  1. The Repository: entry on the first line is the root of the CVS repository. It is configurable on the server only.
  2. The Repository Module: selection box has a list of all the buildable Maven projects in the CVS repository. Some modules can be excluded from the search if configured on the server. On initial loading of the page, the first project viewable in this selection box will load values for the other options. Otherwise, when the value of this selection box is changed, the page will be reloaded with values for the newly selected project.
  3. The Deploy Directory: option is used to select the final server/directory for the deployment and to retrieve dependency artifacts. This is very important because higher level projects can't be deployed to servers that depend on artifacts that it can not download from the same server unless a complete build is done. The reason the deployment will fail is because Maven downloads dependencies before trying to run any goal and we need to ensure that clients will be able to download dependencies when needed, so we point Maven to the same server that a client would point to (see the Check available releases option). The deployment directory list is obtained from the Projects/Builds/deployment.locations file in the CVS repository listed at the top of the deployment page, so they new locations may be added, deleted, or edited by checking out the file and modifying it.
  4. Check available releases checkbox is used to make sure dependency releases are available on the server we have selected. When this checkbox is enabled, the informational section at the bottom of the deployment page will be updated with a checkmark icon next to any dependency releases listed. If the dependency release is available on the server, it may be selected to be used as a the dependency version for the current deployment. The first time this box is selected, it will reload the page, but once it is selected, the availablility of the dependencies will be checked anytime a new module is selected.
  5. The Jnlp release checkbox is used to indicate the the deployment is a jnlp deployment rather than a jar deployment. It is up to the developer to know whether the project is a jnlp project or not as special parameters must be set in the project's project.xml and project.properties files (see the ccjnlp plugin docs).
  6. The Project Release Version: edit box is for specifying the actual release version number or name for the project and it's dependencies (depending on the option selection combination). Be sensible with the naming; choose a name that may mean something or ties into a naming standard and try to avoid non-alphanumeric characters other than periods, dashes, and underlines ( '.', '-', '_' ). Also, check if there is a release with the same name already. If there is and you do not enable the Mapping For Re-Releases option, you will overwrite the mapping information for the earlier release.
  7. Test Mode: is used for testing the build without actually deploying it to the server or effecting CVS files, so changes from testing will not available for later releases. Dependencies will be accessed locally for multiproject builds by using the maven.jar.override property rather than downloaded from the server, since a new dependency version may not be on the server if it wasn't deployed before the test run. This option is very important for testing large multiproject builds where it is unclear whether dependencies are compatible with each other.
  8. The Restore Project After Release: option is used to put the project back in the state it was before the deployment was performed. Usually, projects should have most of their dependencies specified as SNAPSHOT versions for development so developers will always be assured they are getting the most up-to-date versions of the dependencies. During the deployment, the dependency versions should be specified as a specific version rather than a SNAPSHOT so the release is essentially frozen at that point. So, the deployment will change the dependencies to particular versions specified by the options in the deployment web page, check in the project.xml file, make a catalog, and tag the files for the release. After the deployment has completed, the old project.xml file will be placed back on the HEAD of the CVS project, making the project ready for development again.
  9. Mapping For Re-Releases: option is what allows us to re-release an old release reliably. The map refers to mapping release versions to a project, the dependency versions for that release, and a file catalog version in CVS for a listing of all the project's files. The mapping can be done during multiproject builds so a recursive mapping can drill down through all dependencies that a project may consist of. If this option is selected and the matches a previous release for the project, the information from the map will be used to recreate the deployment. If this option is not selected and there already exists a mapping for the release version, it will be overwritten with the new information and CVS tags will be moved, so it is very important to check available releases before naming a new one. This option is not available for multiproject builds using this interface because the map already has dependency versions specified and selecting new versions doesn't make any sense since it the Build Project and Dependencies option allows for that with less steps.
  10. Build Project and Dependencies: is used to create a multiproject build that will recursively build the project, all of it's dependencies, and any dependencies they may have. Specifying dependency versions will cause all uses of that dependency to use the specified version so it is ensured that all jar files are compatible.
  11. Update All Dependency Versions: is used to create a multiproject release so all dependencies and the project itself will be released as the release specified in the Project Release Version edit box. This is the default for multiproject builds since a release should mark all components at that time as part of the release. Again, previous releases with the same version for the project and dependencies will be overwritten in the map and CVS tags will be moved, so it is very important that a unique release version is specified or the developer knows what they are doing.
  12. The Dependency column lists all the dependency project names for the currently selected project. If the dependency is a link, a user may click on the link to reload the page with the dependency as the new currently selected project. This is helpful when a dependency must be released before the major project.
  13. The Project Version column lists the version of the dependency in the current selected project's project.xml file. These values will be restored after the deployment if the Restore Project After Release option is enabled, or if not enabled, will be updated to the values selected in the dependency's Release Version column.
  14. The Last Released Version column indicates the last entry from a release in the version mapping file for the dependency. If there is no entry for a dependency in this column, it means there is no last release for it. This entry will change after the deployment if running a multiproject build with the Update All Dependency Versions option enabled.
  15. The Release Version column is for specifying the dependency version. These selections will have no effect if using the Mapping For Re-Releases or the Update All Dependency Versions options. If a dependency is marked as not configurable, it means it is not a CC project or is not buildable through this interface.
  16. The Try Release button is used to submit the form.
  17. The Project Name column is from the project's POM <name> attribute.
  18. The Project Path column indicates it's location on the cvs server.
  19. The Last Released Version is the last released entry for this project in the version map, the same as for he dependencies.
  20. The Project Version is from the project's POM <currentVersion> attribute.
  21. The Project Parent is listed here, if a project has a parent, so that if there is any problems building or Maven activity is not correct, it may be checked out and the project can be built offline.
  22. The Released Versions column is for previous releases listed in the version map. Clicking on the link will cause a changelog report to popup.
  23. The Catalog Version indicates the file catalog CVS version number for the release. This will contain the tag name and all the files names and CVS versions for all the files in the project. The file catalog is in the top of the project tree for each project.
  24. The Dependency column indicates the dependencies used in that release of the project.
  25. The Dependency Version column lists the dependency version for that release of the project.

 
 

All Contents Copyright © 2005, The Concord Consortium.
All Rights Reserved. Privacy Policy

Last modified: Thursday, 07-Jul-2005 12:22:26 EDT