[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Planning Meeting Notes - 4 April 2012

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