| Re: [tycho-dev] A Mojo to validate version consistency |
|
On 02/06/2015 10:05 PM, David M
Williams wrote:
Does this work with features, as well as bundles?I believe it would fail against features with the same rules as it fails with bundles. However, I didn't study the behaviour against features in details, I add this somewhere to my todo-list. 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.We don't sign bundles for JBoss Tools, so we didn't face this issue. In case of reproducible version, that I think you have in Platform, then the "new" bundle gets replaced by the older one in case they are built from the same commit. So the signature of the new bundle is not used, and the mojo would compare the build artifact (which is actually the one in baseline because there have been no change) with the one in baseline, so it wouldn't complain. If you have the opportunity to give it a try and report some things to improve for features, I'd be glad to adapt the mojo code. 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 feature).There is a <skip> configuration element for such nasty use-cases ;) 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.Yes, I'm aware of that. But I'm 101% in having build failing immediately in front of the developer than having it putting reports somewhere that someone will have to look at sometime... Failing requires people to fix it as soon as the error happens, that's a more agile pattern. For Platform, just imagine that with the Mojo, Gerrit contributions would get a -1 from Jenkins if contributor forgot to bump the version. Isn't it simple and clean? I don't mean to sound discouraging, but some of these are hard or complicated problems, and was wondering how much the tool could be configured.The <skip> flag is already a good configuration flag: either bundle/feature conforms to OSGi rules, and mojo applies; or it doesn't, and we skip mojo. |