[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cbi-dev] tycho and qualifiers

There are two related but distinct usecases here

1. Bundle and feature versions should not change unless the contents of
the bundle/feature changes. This is tracked as bug 367581 [1]

2. rebuild of an old historical version should produce the same
qualifier as the original build. In other words, version qualifiers
should be reproducible. This is tracked as bug 370707 [2] and I provided an overview of available options in the bug.


To decide how to approach reproducible build qualifiers, the Platform team needs to answer two key questions

- do you require Maven version of platform artifacts to be reproducible? I do not believe this is necessary.

- does the Platform team plan to use the same version qualifier for all projects from the same git repository or not?

Also see some comments inline


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=367581 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=370707

--
Regards,
Igor

On 12-02-09 8:31 AM, Paul Webster wrote:
One of the issues we need to overcome is w.r.t. generating qualifiers
for the build.

With looking at building the Eclipse SDK, we have all of our qualifiers
in the *.map files:
http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/tree/org.eclipse.releng/maps

The usecase that is the root of this is for a given build input, we must
generate the same bundles/versions/qualifiers, or put another way a
bundle should not change its qualifier unless the bundle contains changes.

I know that hasn't been looked at yet, but I was wondering what thoughts
there were with integrating this usecase into a maven/tycho build.  Even
with smaller projects I find no way to deal with the qualifiers holding
up maven adoption.

3 things that come to mind:

1) allow tycho to read the map files.  This is a good bridge to existing
PDE project, but places the burden on tycho for having a mapping for
bundle location in the large build repo to the matching map file line,
and that sounds complicated and error prone.

The real problem here is matching sources to map files. Map files provide another version control system on top of GIT. It is possible to implement Tycho build that uses map files, but, quite frankly, this would negate one key Maven/Tycho benefit -- project sources alone would not fully describe build results.


2) Embed the bundle qualifier in its pom.xml. This is simple and error prone. I like the simple part :-) Having things released properly for integration builds would go back to "most things got released ... but not all" that we used to see, even when we had the CVS Releng Tools. Also, our current thoughts on simply taking the UTC timestamp of the last commit to change the bundle would cause problems, as updating the pom.xml will introduce a new commit in that bundle ... that sounds loopy.


I believe this can be automated relatively easily as part of integration branch merge procedure.

3) Allow tycho to derive the qualifier from git.  For a given build
input, this is reproducible.  It doesn't change the repo to record the
information.  I like that nightlies could then generate bundles with the
same qualifiers (for changes up to that point).   But this would place
the burden on tycho again, although maybe it could be provided as a
plugin to tycho as some kind of qualifier support.  But that plugin
would need to pull in at least JGit in order to derive the information.

I see two variations of this approach. Tycho can derive build qualifier from commit timestamp or commit message can include actual version qualifier, i.e. "Tycho-VersionQualifier: 1.2.3.20120408-1200". I think this would be a good addition to Tycho feature set regardless if the Platform team decides to take this approach or not.


What can we do here? This is important functionality when your product has >100 plugins, and we have more than that :-)

Later,
PW

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


_______________________________________________ cbi-dev mailing list cbi-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/cbi-dev