[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-dev] A Mojo to validate version consistency

> 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.


Good point. But if your mojo runs after the "comparator", then seems like many/most bundles would have same version/qualifier/contents due to the comparator's actions.

> Failing requires people to fix it as soon as the error happens,
> that's a more agile pattern.


Yes, and I could see how that would be helpful in a "Gerrit/Hudson" check of a single contribution (assuming comparator not used?) but I disagree, philosophically, that is is always more "agile". For example, in a large team, with large builds, that work in world-wide time zones, people may not be able to react and fix "as soon as the error happens", since they would be asleep! :) so then the rest of the team must wait 12 to 24 hours to get that fixed, and once that is fixed, another error may show up in an "opposite" timezone, again requiring a 12 to 24 hour wait to get a fix. Whereas "continue on fail" often allows both errors to be detected at once, so there are less "waiting periods" over all. Of course, I think some would say "working in different time zones" is not agile to begin with and/or that "a large build" is not agile by definition. But, that's a whole different level of "agile patterns".

I should point out, but surely you (readers) are aware, that the "API Tools" in PDE will notify you -- even before a commit -- if a bundle's version needs updating, assuming it's been "turned on" given a proper reference. (It does not "work" on features, though, just bundles, which is partially why I was asking about that).

But, even with API tools, I still see a usefulness for "all the checking that can be done", even if redundant, simply because we all know some committers forget to turn on API Tools checking, occasionally. I'd say it is most useful in the "micro" case (such as Gerrit checking one commit) and the "macro" case, where "release management" might want to check on "the whole (simultaneous :) release ... which includes feature/bundles they do not work on or have direct control over.

Thanks again, keep up the good work!





From:        Mickael Istria <mistria@xxxxxxxxxx>
To:        tycho-dev@xxxxxxxxxxx,
Date:        02/09/2015 09:20 AM
Subject:        Re: [tycho-dev] A Mojo to validate version consistency
Sent by:        tycho-dev-bounces@xxxxxxxxxxx




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.

--
Mickael Istria
Eclipse developer at
JBoss, by Red Hat
My blog - My Tweets_______________________________________________
tycho-dev mailing list
tycho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-dev