JOSIF Main Page | Version Numbering | Updating Project Versions

Introduction

(a short video accompanies this page which can be downloaded from http://sourceforge.net/projects/openoss/files/JOSIF/DeveloperOnRamp/2012-10-04_Subversion_Tagging_or_Branching_A_JOSIF_Release.wmv)

Each project using the JOSIF tooling consists of multiple modules which have dependency relationships between themselves and on other external projects. Version numbers are set in pom.xml and tigestripe.xml files. As far as possible we have tried to use symbols to ensure versions only need to be set in one place. However there are in practice a number of places in a given project where version numbers need to be aligned. This page outlines the process for updating the version numbers in an existing project

Note that following the release of 1.0.0 the subversion trunk is in the process of being updated to 1.1.0-SNAPSHOT - All Trunk Plugins will be renumbered to version 1.1 - DO NOT mix and match 1.1 and 1.0 plugins in an eclipse workspace as you will cause the tigerstripe.xml files to reference both versions - not a good idea. Instead if you are updating REMOVE THE OLD TIGESTRIPE PLUGINS FIRST and then update your project.

After an update, please remember to do mvn eclipse:eclipse on all projects to ensure the updated dependencies are correctly referenced in the eclipse workspace

Using the Project Creator

In most cases the simplest and safest way to update a project is to re-create the project's build files using the latest Project Creator. Fill in the desired project name, version and a modelID which matches that in your current project and the project creator will create new build files. You should do a diff (best done in Eclipse) between the new project build files and the old project to ensure that you copy across any local changes.

Note that an annoying problem with tigestripe (which has been reported as a bug) is that every time a tigerstripe.xml file is edited within the Tigerstripe editor, it is saved with a different ordering of the xml elements in the file. This makes it tedious to compare files in your project with the newly created ones or previous vesions. In practice, I tend not to use the tigerstripe editor to edit tigerstripe.xml files but use an xml editor instead - this preserves the ordering and makes comparison easier.

Manual Update

If you have to update the version of a number of projects, a global edit may be easier than using the project creator. The following instructions are presently complete - but there may be more things to change in future versions - so beware.

Updating your Project's version

If you are just updating the version of your own project then you need to change both the tigestripe.xml and pom.xml files in your build.

The pom.xml in the <project name>_BaseProject directory is referenced by all the other modules. For instance the header for the TIP_Common_BaseProject looks like;

  <groupId>org.tmforum.tip</groupId>
  <artifactId>TIP_Common_BaseProject</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <name>TIP_Common_BaseProject</name>
  <packaging>pom</packaging>

All of the downstream modules reference this pom file by version thus;

  <parent>
    <groupId>org.tmforum.tip</groupId>
    <artifactId>TIP_Common_BaseProject</artifactId>
    <version>1.0.0-SNAPSHOT</version>
  </parent>

In this case all references to

<version>1.0.0-SNAPSHOT</version>

must be changed to the new version.

Similarly the tigerstripe.xml files will generate transient dependencies which are also tagged with this version. Each plugin in the tigestripe.xml file will have element such as

    <property name="groupId">org.tmforum.tip</property>
    <property name="version">1.0.0-SNAPSHOT</property>
    <property name="artifactId">TIP_Common_SoapSpecPackageTransientDependency</property>

You must replace

<property name="version">1.0.0-SNAPSHOT</property>

with a reference to the same version as defined in the base project's pom.xml

Updating your Project's Platform or Framework dependencies

The majority of the other dependencies are contained in the based projects's pom.xml. You can change the version of libraries used in the build here but note that the build system has been tested with the dependencies generated by the project creator. Other versions may not work or may conflict with each other. However you are welcome to try.

The key variables you may wish to update in the base project pom.xml are those referencing the version of Framework or Platform your project references. These variables are listed below;

   <tip.framework.major.minor.version>1.1</tip.framework.major.minor.version>  Should be two integers separated by a point x.x 
   <tip.framework.point.version>0</tip.framework.point.version>                Should be an integer with with no point         
   <tip.framework.snapshot.value>-SNAPSHOT</tip.framework.snapshot.value>      Should be empty '' or '-SNAPSHOT'               

   <tip.platform.major.minor.version>1.1</tip.platform.major.minor.version>   Should be two integers separated by a point x.x 
   <tip.platform.point.version>0</tip.platform.point.version>                 Should be an integer with with no point         
   <tip.platform.snapshot.value>-SNAPSHOT</tip.platform.snapshot.value>       Should be empty '' or '-SNAPSHOT'               

We have a 3 number version system;

major.minor.point

. However only the major and minor numbes are used to label models, profiles and plugins within tigerstripe workspaces. This is so that we can issue minor updates to tigerstripe artifacts without having to update every tigerstripe.xml file to match.

Each plugin in a tigerstripe.xml file is referenced by it's version number and this must match the major and minor number of the platform or framework plugin being used. For instance the plugin id for the documentation plugin is given by

   <plugin disableLogging="false" enabled="true" groupId="Hewlett-Packard Company, Cisco Systems" logLevel="0" pluginId="TIP_Doc_Generator(@TIP-FRAMEWORK-MAJOR-VERSION@.@TIP-FRAMEWORK-MINOR-VERSION@)" version="@TIP-FRAMEWORK-MAJOR-VERSION@.@TIP-FRAMEWORK-MINOR-VERSION@">

where the @TIP-FRAMEWORK-MAJOR-VERSION@ and @TIP-FRAMEWORK-MINOR-VERSION@ values must match the major and minor version of the plugin to be used. For TIP Framework version 1.1.0, This would be set to

   <plugin disableLogging="false" enabled="true" groupId="Hewlett-Packard Company, Cisco Systems" logLevel="0" pluginId="TIP_Doc_Generator(1.1)" version="1.1">

Similarly the other generators must also be updated:

   <plugin disableLogging="false" enabled="true" groupId="Nortel Networks, Hewlett-Packard Company" logLevel="0" pluginId="TIP_Soap_Generator(1.1)" version="1.1">
   <plugin disableLogging="false" enabled="true" groupId="OpenNMS" logLevel="0" pluginId="TIP_JvtSpec_Generator(1.1)" version="1.1">
   <plugin disableLogging="false" enabled="true" groupId="OpenNMS" logLevel="0" pluginId="TIP_EjbImpl_Generator(1.1)" version="1.1">
   <plugin disableLogging="false" enabled="false" groupId="OpenNMS" logLevel="0" pluginId="TIP_SoapImpl_Generator(1.1)" version="1.1">

In addition the tigerstripe.xml COMMON_MODEL_VER property must be set to match the Framework major.minor version as shown below;

   <property name="COMMON_MODEL_VER">1.1</property>

This manual update can work well but it is error prone for the innocent. As stated above, the easiest way to make sure you haven't forgotten anything is to use the latest project creator to create new files and do a diff against the files in your project to find the differences to change.