> Definition of wrong:
> * build version strictly inferior to version found in baseline
> * version equals with the one in baseline, but *with different
> content*. (so reproducible builds as documented in https://
> wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers would still
> * same x.y.z but with different qualifier.
> With those rules, you immediately notice as a Build Error when an
> artifact has not been upversioned.
Does this work with features, as well as bundles?
How do you treat "differences" that are due,
say, to merely the timestamp of the jar signature changing? -- i.e. not
really "different" in a meaningful way.
And, "branding bundles" (which, some teams configure
to have same qualifier as "build id" -- I assume the mojo is
just disabled for those? (But, those have a way of peculating up to the
And ... of course, there's always the "philosophical
difference" that some like a build to fail, other like it to continue
with a clear warning/error in a separate file.
I don't mean to sound discouraging, but some of these
are hard or complicated problems, and was wondering how much the tool could
And, by all means ... the more tools the better! So, even
if doesn't fit all cases or projects, I'm sure many would greatly appreciate
I'm not sure if Tycho-extras or "CBI" would
be better/different home for it ... but, I'd think either would be a fine
place to contribute it (I mean, from my perspective, not that I have any
say over tycho-extras).
Mickael Istria <mistria@xxxxxxxxxx>
discussion <cbi-dev@xxxxxxxxxxx>, Tycho developers list <tycho-dev@xxxxxxxxxxx>,
02/05/2015 10:16 AM
A Mojo to validate version consistency
For JBoss Tools, as we work on different streams, we often forget to update
the version on the "master" stream, so that we end up with some
latest snapshots whose version is inferior to the one of the latest release
(from a maintenance stream). We used to catch it late in the release process,
when there are deadline and it's much more difficult to fix it.
Other projects we contribute to, such as Eclipse Platform ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=443353
) or WebTools ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=457292
) also have the same issue from time to time.
We've implemented a Mojo, that hooks on the verify phase of any Maven artifact
creating p2 IUs using Tycho (eclipse-plugin, eclipse-feature, eclipse-repository),
which takes as input a "baseline" -usually the last released
p2 repository- and that compares the version of artifacts produced by the
build with the one in the baseline, and would fail with an explicit message
when a version is wrong.
Definition of wrong:
* build version strictly inferior to version found in baseline
* version equals with the one in baseline, but *with different content*.
(so reproducible builds as documented in https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers
would still work)
* same x.y.z but with different qualifier.
With those rules, you immediately notice as a Build Error when an artifact
has not been upversioned.
For JBoss Tools, it did catch several errors as soon as we did set up the
mojo ( https://github.com/jbosstools/jbosstools-build/commit/492e584c817683ad7121627a3e6af39f2b9d5b3e
) , and we are already very happy with it since errors are fixed with a
regular change, instead of having to be fixed later, maybe even requiring
us to respin some builds.
I believe it provides good value to any project built with Tycho. So we'd
like to contribute it upstream. I believe the best location for such mojo
would be to have it in tycho-extras (or tycho "regular"). Would
such a contribution be welcome there?