Re: [tycho-dev] A Mojo to validate version consistency

[David M Williams <david_williams@xxxxxxxxxx>]

> 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