Byron,
thanks for the mea-culpa.
usually I force myself to rebuild the entire workspace, and then unzip
the resulting distribution before running QL avoiding any sort of jar
file copying between your build and the QL glassfish modules
directory, this is just too error prone to do differently.
jerome
On May 9, 2009, at 10:49 PM, Byron Nevins wrote:
> I wanted this event to just slide away silently into my rear view
> mirror but I have received a formal request to do some explaining so
> here goes:
>
> ================================================
> May 6 6PM -- I checked in source without noticing that another
> module depended on the changes. Oops.
> Build broken
> May 6 8 PM -- FIXED -- Sorry, mea culpa!
> ================================================
>
> Our Release Engineers are (of necessity) part vampire which explains
> the error discovery time below
>
> May 7 -- 4 AM -- Quicklook Test Errors discovered
> May 7 -- 11:27 AM -- Quicklook Test Errors Fixed -- Sorry!
>
> Here's how I managed to bungle up the QL Tests -- learn the easy way
> by reading this.
> • I reinstalled GlassFish from the build from before my changes
> because of a QL bug -- you can not run it twice in a row
> • I am SUPPOSED to now copy over the 2 jars with the changed
> classes. OOPS. Forgot this step. And I ran QL on 3 different
> computers to be absolutely positively sure ;-)
> • Run thorough QL tests which of course pass with flying colors
> because my new classes are not there at runtime
> • Doh!
>
> ================================================
>
> May 7 -- 6PM Web devtests are reported to be failing. IT #8262
> My response was, of course, say what?!? I thought we did not have
> devtests for V3. Surprise! We do. There is even a Hudson job
> running the web portion of the devtests.
> May 7 8 PM Jane Young rides to the rescue and backs out my changes.
>
> This gets really boring now. If you are still reading this my hat
> is off to you...
>
> Apparently what happened was that there was a bug in the devtests --
> stop-domain never was really called.
> The immediately following start-domain would always error because
> the domain was still running. I suspect my ill-fated changes
> changed the start-domain from a warning to a solid error thus
> illuminating the bug in the devtests themselves.
>
> =================================================
>
> Lessons Learned:
>
> Modifying any code that has "public" or "protected" in it is
> treacherous! Note that protected is exactly as bad as public. It
> is virtually impossible to find all possible users -- e.g. what if a
> project is pulled in as a binary but the source is dependent on the
> public thing you just changed. The safest course is to chisel the
> public or protected into stone and never remove it or change
> signatures. Avoiding making methods protected or public is a wise
> course.
>
> In my case I did not change the public signatures but I "improved"
> the behavior just a bit. Big mistake. Very treacherous waters!
>
>