Description Igor Fedorenko 2012-02-06 07:02:54 EST

Here are some implementation ideas how to make build version qualifiers reproducible. 

From the original bug 367581:
<quote>
When reproducing historical builds, eg, Indigo SR1, the build is expected to
produce identical results (ideally, byte-to-byte identical) and should use the
same version qualifier as the original build. This implies that version
qualifier is embedded in either project sources, map files or some other
versioned metadata.
</quote>

=== The goals

1. MUST HAVE. Rebuild of a historical platform versions from a git tag, i.e. 
   3.8M4, generates the same build version qualifier as the original build.

=== Analysis

Tycho build generates two types of version qualifiers. 

Eclipse/OSGi/P2 artifact versions that end with literal '.qualifier' 
(without quotes) will have '.qualifier' string replaced with the build version
qualifier. The version qualifier will be embedded in the
artifacts produced by the build and will be used by the clients of the 
artifacts, i.e. P2 and OSGi, during install-time and run-time dependency
resolution.

In addition, -SNAPSHOT version of Maven artifacts deployed to (remote) Maven
repositories is replaced with a version determined in parts by the content of 
the repository. Maven expanded -SNAPSHOT version is not embedded in the 
artifacts and is only used to resolve -SNAPSHOT versions of the artifacts from
Maven artifact repositories.

Other notes

Different modules of the same Eclipse Platform source tree (PDE, JDT, etc) 
often have different major/minor/micro versions.

Multiple source trees are built as part of the same monolith reactor build.
Different source trees may use different version qualifiers. It is not clear
if different modules of the same source tree may use different version.

Different source trees may use different qualifier replacement approaches. For
example, one source tree may choose to update versions in project sources
(pom.xml, bundle manifests, etc) while another source tree may choose to 
calculate version qualifier from git commit.

=== Possible implementations

==== Reproducing Maven and Eclipse/OSGi/P2 versions

The only way to reproduce Maven version is to replace -SNAPSHOT with specific
qualifier in pom.xml files and corresponding Eclipse/OSGi/P2 configuration 
files (bundle manifests, feature.xml and so on) and commit the changed files to 
the git repository. 

Here is a rough outline of the flow that generates the same version qualifier
for all modules of the same source tree

- merge 'master' onto 'integration'. To avoid conflicts with locally expanded
  build qualifiers, use "--strategy=recursive --strategy-option=theirs"
  git-merge options.
- execute tycho-versions-plugin:set-qualifier goal to set version qualifier 
  both in pom.xml and in relevant Eclipse/OSGi/P2 metadata files.
- commit changed files to git 'integration' branch and tag the commit.

Note that tycho-versions-plugin:set-qualifier goal does not exist yet and will
need to be implemented.

==== Derive build version qualifier from git commit

As was discussed on one of CBI conf calls, Eclipse Platform team plans to use
some sort of algorithm to calculate build version qualifier from git commit.
Implementation of Tycho version qualifier expansion logic will need to be 
extended to support this.

Using this approach, it is not possible to generate different version 
qualifiers for different modules of the same source tree.