[
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
