[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cbi-dev] tycho and qualifiers
|
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.
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.
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.
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
