I finally got an end-to-end batch build working that creates the
installation file for the application that we're working on. I wanted to
pass on an insight that I got -- one that's definitely in the running
for the award of 'obvious insight of the day'. <g> And also point out a
minor enhancement opportunity to Object Arts.
First a bit of background. The batch file goes through a series of
steps, continuing on unless one of the steps returns an error. First it
builds a fresh working image from a (nearly) virgin image using a
combination of package files and packages from the Source Tracking
System repository. Then in runs all the unit and acceptance tests within
the fresh image. Then it takes the fresh image and runs the
ImageStripper to create the application's executable. Finally, it runs
InstallMaker to create a self extracting installation file.
A primary requirement of the batch build is to run without user
intervention. I had an issue with the OK MessageBox that pops up after
stripping is complete, right before it exits. I finally tracked it down
to the ImageStripper>>saveExecutable: method. I thought "no problem". I
overrode the method in my subclass of ImageStripper that I was already
using, leaving out the pesky MessageBox. Only the damn thing still
popped up!!
After some more thought and investigation, the answer came to me. It's
rather patently obvious (once you've been hit over the head with it) ...
Don't allow your subclass of ImageStripper to be stripped from the
image ;-)
In my own defense, I had been using this subclass of ImageStripper for a
few weeks without a problem. But all of it's overridden behavior had
been occurring during #prepareToStrip. So the fact that it was then
being stripped hadn't been an issue.
A couple of ways to avoid this problem come to mind. One is to include
the ImageStripper subclass directly in the (root) package that's being
deployed. The second, which is what I did, was to add the package that
it's in to the #requiredPackageNames method. That way enough of the
ImageStripper subclass will hang around so that it can do it's job.
My override of #saveExecutable: leaving out the MessageBox popup finally
worked. :-)
My thoughts for enhancement are that it should be a bit easier to
eliminate that final MessageBox. Either it could be parameterized as to
whether on not the message should be given. Or that portion of the
method could be extracted. I hate to override the entire
#saveExecutable: method just to change that one little part of it.
Cheers,
-Bill
-------------------------------------------
Bill Dargel
[hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105 USA