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 the
past the one time we had similar situation. And, off the top of my head,
both the "versioning report" and the "comparator" are all designed to
against one drop location and one repo (respectively).
There might be some way to "hand edit" the reference.xml file to replace
Dali entries from SR2 with your release from December ... but ... not
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 what
interests you, sort it (to make compare work better), pipe it to a text
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 old-fashioned
directory listings etc., not the repo meta data (though, I'm working on
such a thing ... its been side lined). I think the versioning report
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. But my
guess is the versioning report, as it is now, would likely take more
to fix ... a little "redesign" or something ... not impossible ... but,
more like a week or two of effort (just to guess) ... and it if does
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 exactly.
[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 to
sure it it is same content. So, this is "bad" in the sense that its not
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, that "is
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 are the
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 not
think it is a "blocking problem" unless you are seeing some concrete
looks real weird.
The mirror/comparator tasks would (likely) be the easiest to fix --- its
just in the builder ... near the final "packager" tasks, I believe --
probably use multiple reference repos for what it was mirroring (and
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. The
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 handled
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
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