Re: [Installbase-devel] InstallBase 1.0a3 and recursive file groups

[Damon C. <da...@yo...>]

> Close - since I need a different set of JVM files for each platform, I'd
> have to give each parent directory a different name ("jvmwin", "jvmlin",
> etc.) in the final install tree. Which would work, but what I ended up
> doing was throwing together a Windows install to see how things work, and
> doing lots of right-clicking. :)

    Hrmm...  There still should be an easier way to do it.  I guess I would
probably just make the subdirectories for each JVM. 0-]  I'll throw something
to improve the situation into the next release (which should be shortly, I
hope).

> All it really takes care of is finding a JVM on the user's system if one
> (with the proper versioning) is already installed, and installing a
> bundled one if not. Since we use the latest JDK, it'd end up being
> installed most of the time anyway - so I just have InstallBase copy it
> over, no matter what.

    My plan is to start adding more checking code for InstallBase.  Like
some routine that could check a system for their JVM and determine if a
new one needs to be installed, etc...  Someone had a request for some
similar functionality on Windows.  Basically to determine the existence/
version of ODBC and update if needed.

    It's not a hard thing to do, you just have to know what you're looking
for and define the rules.  I wouldn't even know where to start for most of
it. 0-]

> At the end of the install (on Windows 2000), right before I clicked the
> Finish button, I once got an error about not being able to delete
> blank.zip from the temporary directory (permission denied). None of the
> shortcuts were created and the temp dir was left behind after. I haven't
> been able to duplicate it since - any idea what might have caused it?

    I saw this just a minute ago, but it was due to an error in my
install.  I've never seen it otherwise, but I know it's possible.

> "Permission Denied" doesn't make sense since I was Administrator. Might
> have been a sharing violation since I had a filesystem Explorer window
> open at the time, but it wasn't looking at anything near Administrator's
> local settings folder at the time.

    It's caused by InstallBase having the blank.zip open (in the temp
directory) when the Finish button is clicked.  InstallBase's last action
is to clean up the temp directory it was using.  For some reason, part of
InstallBase had opened blank.zip and not closed it.  So, when it attempted
to delete it, Windows complained because the file was opened.  This isn't
a problem on UNIX, it'll just wipe it out anyway.  Windows has some safety
(read: annoying) measures in place to prevent accidents.

    This is also why when the uninstall runs, it must first copy itself
to a temporary directory and THEN uninstall the program.  If it tries to
uninstall from the install dir, it can't delete itself because it's already
running. *sigh*  I just love Windows. 0-]  This will also make it difficult
to add a cool feature I have planned.  It will be easy to implement on
UNIX and a pain on Windows.

Damon