FYI â below is the Eclipse Platformâs approach towards getting an equivalent for the Mapfiles in Tycho.
Itâs still work in progress apparently but it is coming up.
From: eclipse-dev-bounces@xxxxxxxxxxx [mailto:eclipse-dev-bounces@xxxxxxxxxxx]
On Behalf Of Paul Webster
Sent: Wednesday, April 04, 2012 4:22 PM
To: General development mailing list of the Eclipse project.
Subject: Re: [eclipse-dev] Planning Meeting Notes - 4 April 2012
CBI is a further investment by the Eclipse Foundation in a common build infrastructure. The primary driving usecase right now is to be able to build the Eclipse Project using CBI (maven, tycho, foundation signing, hudson to drive the builds and tests, etc),
in preparation for their Long Term Support  initiative.
The Roadmap  describes the main issues CBI is working through and its current timetable. There's a code sprint next week in Ottawa  to get people together to complete some tasks.
Discussion Topic: CBI initiative and build qualifiers
One of the requirements is that we get reproducible build qualifiers for our plugins and features.
Bug 370707 - reproducible build version qualifiers
Bug 367581 - do not generate new version qualifier unless there are actual code changes
Currently the proposal (after discussion with Kim, John, and myself) is
here is the outline of required changes
* Introduce extension point in Tycho BuildQualifierMojo that will allow custom
logic to determine build timestamp.
* Implement jgit-based implementation of the extension point from the item
above that will use project last commit's timestamp as the build timestamp.
* Embed project last commit's timestamp either in project jar file or p2
metadata. This will be used to calculate feature version qualifier (see below).
* For bundle projects, version qualifier will be rendered from the build
timestamp using existing Tycho formatting configuration.
* For feature projects, build timestamp is selected is the latest timestamp of
the feature project itself and any features/bundles included in the feature.
* Implement new Tycho goal that will compared bundle and feature jars to a
baseline version and fail the build if new and baseline version have the equal
version but different contents. When this happens, developers are expected to
make artificial changes to changed projects to force new version qualifier.
It is taking the same approach we currently using in our auto-tagging, which is to derive the qualifier as the UTC timestamp of the last commit to touch that plugin or feature.
Discussion topic: The implication of this is that all of the bundles in 3.8/4.2 would have their qualifier bumped, even if they haven't changed in 3.8, to switch to qualifiers entirely derived from the source for that bundle. From that point on, the qualifier
would be derived from the source. Our current auto-tagging derives the qualifier the same way (but feeds that information into the map files).
I did a quick check. The only bundles that are the same between 3.7.0 and 3.8 M6 are:
Hi floor. Make me a sammich! - GIR