[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [eclipse-dev] Planning Meeting Notes - 4 April 2012
- From: Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx>
- Date: Wed, 4 Apr 2012 10:21:57 -0400
- Delivered-to: email@example.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Hsakb75kz5P1U2gv0cWFYLYBGB+mbQqz0W3KP8/FI6s=; b=FyS8vjoKScUcKAVzG8n0b4nt+x0ggQavDQbbDV7wPBIhtyM50diGtvPhBN2WpWaq20 wWHACruFCeJ5btocCUIjDtOFOp3YSYxAEqORGT/1Hlt9KIMbIKDDpv2483fRfuMLMmyG HXuaswUmJxcgjesIUKh7XYfYWg98kiKE/xj24a4XGWVOZSkCEl7mVhk2EnBGo++5woqa 0W86XnzBeANTlO+fbrpG/0dcfjK7GWMyEm3xppD1W1y/tvS6YYku5sdS4jbtvRkYu+q/ /hv68Z+lc7QnDCOtuUhWOY3Qd4xVU4DT77cvsVMGpu0gpdPJEBeyb3+X8cY229hl9Gix ZoyQ==
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.
reproducible build version qualifiers
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.
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