Depot Version
Home
Ant Tasks
Tools
API
Integration
 Apache Incubator > Depot > Version 

Depot Version: Dynamic Version Interface

Overview

The Dynamic Version Interface is a convention and codeless interface specification that allows version information to be communicated between classes without code linkage. For example, a version reporting system (perhaps a dynamic 'about' box in an Eclipse plug-in) can extract versions from packages (Javasoft, Jakarta, etc.) without having statically link code to create it.

Assumptions

  • Java introspection is available within the inspecting (calling) client.

Overview

There are three components to this specification, all of which can be implemented without third-party code. There are choices available within this specification, however all choices are still relatively simple, portable, and non-invasive yet (hopefully) migration safe. See examples below.

Class Naming Convention{...}.version.Version
Interface (Signatures){...}.getVersionString()
Version Layouts1.1.1-alpha

Class Naming

For package "personal.my.stuff" the class naming convention allows:

Primary Search Locationpersonal.my.stuff.version.Version
Secondary Search Locationpersonal.my.stuff.Version

{primary package path}.version.Version.class

Notes:

  • The ".version" sub-package keeps (perhaps automatically generated) separate, and out of the way.
  • The class naming convention allows both 'brute force' and 'dynamic loader' implementations, whilst preserving efficiency.

Java Interfaces

A single method or public field

Option #1: Simple Field

	public static final String VERSION = "1.1.1-alpha";
	

Option #2: Simple Method

	public String getVersion();

Option #3: Compound Method (Beaner)

	public int getMajor();	
	public int getMinor();
	public String getReleaseLevel();
	public int getPoint();
Note
Choices are support to allow for developer preferences and/or tooling implementations.
Note
Extension interfaces (signatures) are allowed (to describe location, or add attributes) but these are 100% optional.

Version Layouts

If not, we've need a number of "version format" choices (and perhaps even "version versions".)

Appendix -- Examples

Example #1: Simple 'Field' Form
	package personal.my.stuff.version;

	public class Version
	{
			//	Major = 3, Minor = 0, Point = 1, Release Level = beta
		public static final String		VERSION_STRING	= "3.0.1-beta";
	}
Example #2: Explicit Simple 'Field' Form
	package personal.my.stuff.version;

	public class Version
	{
		// For versioning of versions...
		//	*Optional*
		public static final String		VERSION_FORMAT	= "Apache Depot Version";
		//	*Optional*
		public static final String		VERSION_VERSION	= "1.0.1-alpha";

		//	Major = 3, Minor = 0, Point = 1, Release Level = beta
		public static final String		VERSION_STRING	= "3.0.1-beta";
	}
Example #3: Simple Method Form
	package personal.my.stuff.version;

	public class Version
	{
		public getVersion() { return "3.0.1-beta"; }
	}
Example #3: Compound Form
	package personal.my.stuff.version;

	//	3.2.1-alpha
	public class Version
	{
		public int 		getMajor(){ return 3; }
		public int 		getMinor(){ return 2; }
		public String 	getMinor(){ return "alpha"; }
		public int 		getPoint(){ return 1; }
	}

Example Extensions

  • Attributes -- user defined extensions
Attributes

To allow the addition of "arbitrary" pices on information (such as build date, build user) the "Attribute" extension is allowed.

	public HashMap getAttributes()
	{
		HashMap attributes = new HashMap();	

					//	Store some settings...
		attributes.put( "org.apache.depot.version.build.date", new Date());
		attributes.put( "org.apache.depot.version.build.user", "user_xxx@apache.org");

		return attributes;
	}

References

Apache Commons Versioninghttp://jakarta.apache.org/commons/versioning.html
Javasoft JAR (Manifest) Specificationhttp://java.sun.com/j2se/1.4.1/docs/api/java/util/jar/Manifest.html
Javasoft Optional Package Versioninghttp://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html

by Adam R. B. Jack