Well, the way I've done it is to do a sed parsing of files to find
invocations of "new SqlException". This is inherently a brittle
approach because it isn't using the real semantics of Java to figure
this out. So if somebody writes something a little different, things
get munged up.
The real issue where I keep having to fix the script (and yes, mere
mortals can do it, but one has to wonder if they'll be motivated) is
that there are variables used in the invocation of the constructor, and
I have to substitute those variables with generic strings so the test
will compile. I have an idea how I might handle this in one swell foop
with a grand sed incantation, and if I can, this would add some
significant stability to the test. I would be willing to try to put
this into the nightlies if I can accomplish this.
The "right" way to do this would be to write something that is somehow
an extension of or a plugin to the compiler which can find out using
real Java semantics where all the invocations are and generate code as a
result. That's not my itch to scratch.
David
Rick Hillegas wrote:
Hi David,
How volatile is this test and how hard to fix it when it breaks? Can
mere mortals help out here? Do you think that, with a little more work,
it's feasible to drop this into the nightly test run some day? I'm not
speculating about who might want to scratch that itch, just wondering
how gnarly this is.
Thanks,
-Rick
David Van Couvering wrote:
The problem with running it as nightlies is that it is liable to fail
at compile time when new messages are added -- I regularly have to
update the sed script to adjust for these new messages. I would hate
to have the build fail because of this.
If you have any ideas, let me know, but that was the reason I didn't
suggest it for nightlies.
David
Kathey Marsden wrote:
David Van Couvering wrote:
There's a test I'd like to see run as part of release verification.
[snip]
This involves a lot of substitution work, and each time new
SqlExceptions are introduced, it tends to require some tweaking
[snip]
I could run this test myself as part of my validation of the
release, but it would be great to have this documented as one of the
tests to run.
If there are no objections, I can add a link to instructions on how
to run it off of the general "how to cut a release" page.
It seems like since this test is sensitive to individual changes and
it might expose issues that would hold up the release, running it as
part of making the release might be a bit late. It would be best if
we could get folks running nightlies to add this in. That way it
doesn't become a fire drill at release time.
Kathey
