It wouldn't be a bad idea to open bug or a feature requests to be
specify multiple locations for versioning report and mirror/comparator
Off the top of my head, I don't recall us doing anything special in
past the one time we had similar situation. And, off the top of my
both the "versioning report" and the "comparator" are all designed
against one drop location and one repo (respectively).
There might be some way to "hand edit" the reference.xml file to
Dali entries from SR2 with your release from December ... but ...
how easy that would be, and might be error prone. [And, Carl, maybe
what you were asking me about via IM and I misunderstood?].
But, if its just versioning problems for immediate (M6) you want to
it would probably be easiest to do a 'find' or directory listing of
interests you, sort it (to make compare work better), pipe it to a
file, and then do a diff compare of December version to M6 version.
Eclipse "compare with each other" function works pretty good at
highlighting significantly different parts. I hate to admit the
times I have used this approach to compare directory listings :)
The versioning report (from memory) still (partially) uses
directory listings etc., not the repo meta data (though, I'm
such a thing ... its been side lined). I think the versioning
be the hardest one to fix, since I think part of it reads "what is in
currently running version" (e.g. during JUnit testing) and compares
the reference ... but ... all pretty fuzzy all these years later.
guess is the versioning report, as it is now, would likely take
to fix ... a little "redesign" or something ... not impossible ...
more like a week or two of effort (just to guess) ... and it if
use the old fashioned "directory" approach, I'm not sure its worth
IMHO. Better to focus on one that uses repo metadata.
The comparator issue, [In addition to what Carl said in his reply
... ] if
there was one, is a bit different. In one way worse, in one way
better aspect, is if there is an "error or warning" then I think it is
still a legitimate "error or warning", of some sort, since it only
for errors or warnings" when the versions/qualifiers all match
[But, as Carl said, lots of "spurious ones" right now.] The worse
the comparator is ran as part of a p2.mirroring operation that says,
basically, if versions and qualifier match exactly, then take the
since should be the same content, but it then runs the comparator
sure it it is same content. So, this is "bad" in the sense that its
giving the right level of protection as if it was ran against the
December release. Such as, you might have a version now, in M6,
the same" as December's, but "newer" than Indigo SR1, so ... we'd
ending up with the newest one ... but, not the more comparable
December ... and that'd only be a problem if there really _is_ a
in content now, from December, even though the version/qualifier
same ... so as is, there is no "check" to test or see that.
problem. But ... would be good to fix before the "release", I would
think it is a "blocking problem" unless you are seeing some
looks real weird.
The mirror/comparator tasks would (likely) be the easiest to fix
just in the builder ... near the final "packager" tasks, I believe
probably use multiple reference repos for what it was mirroring
then, when I say "easy" I mean possibly 1 to 4 full days of effort).
From: Neil Hauge<neil.hauge@xxxxxxxxxx>
Date: 03/15/2012 01:09 PM
Subject: Re: [wtp-releng] Smoke Test Request for WTP 3.4.0 I-build
towards WTP 3.4.0
Sent by: wtp-releng-bounces@xxxxxxxxxxx
Chuck, Carl, and others,
I've realized that the current versioning report isn't giving us an
accurate picture of Dali's plugin and feature version correctness.
reason being that we released 3.1 in December, but the reference
the resport is the most recent maintenance build, which for us
us the right reference.
I can't remember what we did in this scenario the last time we did an
off-cycle release, but perhaps David or Tran remembers how we
with regards to version reporting. Perhaps we ran an ad-hoc report
the Dali release reference build?
Currently, I think we have some versions that need to be updated to
distinguish themselves from the 3.1 versions. Also, I noticed
there were a
large number of unexpected comparator errors in this build. We
require this list to be clean for an M build, correct?
On 3/15/2012 12:26 PM, Chuck Bridgham wrote:
Smoke Test Request for WTP 3.4.0 I-build towards WTP 3.4.0
Please document your Project's testing and approval of this
by noon(EST) Friday, or let us know if that's not possible.
Thanks - Chuck
Senior Architect, RAD Java EE Tools, WTP PMC Lead
IBM Software Lab - Research Triangle Park, NC
wtp-releng mailing list
wtp-releng mailing list
wtp-releng mailing list