Re: [eclipse-dev] Planning Meeting Notes - 4 April 2012

[Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx>]

CBI Update:

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 [1] initiative.

The Roadmap [2] describes the main issues CBI is working through and
 its current timetable.  There's a code sprint next week in Ottawa [3] 
to get people together to complete some tasks.

[1] http://wiki.eclipse.org/LTS

[2] http://wiki.eclipse.org/CBI/Eclipse_Platform_Build_Roadmap

[3] http://wiki.eclipse.org/CBI/Code_Sprint_April_11_2012


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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=367581#c13

----
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:
org.eclipse.core.boot_3.1.200.

v20100505.jar
org.eclipse.core.contenttype_3.4.100.v20110423-0524.jar
org.eclipse.core.expressions_3.4.300.v20110228.jar
org.eclipse.core.filesystem.linux.x86_64_1.2.0.v20110423-0524.jar
org.eclipse.core.net.linux.x86_64_1.1.0.I20110331-0827.jar
org.eclipse.core.runtime.compatibility.registry_3.5.0.v20110505/
org.eclipse.update.configurator_3.3.100.v20100512.jar
org.eclipse.update.core_3.2.500.v20110330.jar
org.eclipse.update.scheduler_3.2.300.v20100512.jar

-- 
Paul Webster
Hi floor.  Make me a sammich! - GIR