[izpack-devel] Running the Installer twice without exit/launch ?

[Markus Schlegel]

Thanks for your insight, Klaus

The "problem" is not the common things of the installer the three products
share, it's the program code itself.
All three programs will be installed with their own private JRE and all
three programs do share that same libraries. Some of them share the same
help (Server & Admin). If I make 3 Installers, they have sizes of 70MB, 50MB
and 45MB, means 165MB for Download. If I put them all together, I have only
on 70MB File...

All three Products will be installed in a seperate Folder, means no Product
will overwrite each others Uninstaller.

Also I agree, that the solution of installing a second product with the same
installer instance is kind of a hack for  IzPack 3.10. If I could inject the
language of the installer with a commandline flag, I could simply start a
new Instance of the Installer when the User presses "Install more Products"
at the end of the installation and the currently running installer could
exit normally. I proposed such a change some months ago, but it has been
declined. Any chance to integrate some language-flag now?

Anyway, this would be a good feature too for "Autorun"-Programs on CD's
(like we have), where the user already chooses his language of choice. It's
still annoying, when he has to choose the language again in the Installer,
then has to choose it again when he reruns the installer....

Regards
Markus

2007/6/5, Klaus Bartz <bartzkau at gmx.net>:
>
> Hi Markus,
> some years ago I have written an installation (with InstallShield 5.5)
> which contains the base server (product), the custom server data (project)
> and the client to write the common parts only once. During maintenance
> I have seen, that there was more work as in separated installations.
> Now we have three IzPack installations, one server, one admin client and
> one agent (the clients are installed with MSI).
> For common used custom panels or custom actions normaly I write a base
> class
> which do the most and the derived - type dependend - classes contains only
> the differences (sometimes empty classes because the needed different
> descriptions are automatically selected via the i18n stuff of IzPanel).
> I never rued to use different installations. No problems with
> uninstallation,
> no big installation for a admin client, no selection and dependencies
> overhead. One installation for one product is better, I mean. For me the
> problem begin at our admin clients because there are more than one, but
> that's
> no separated products else features (in MSI syntax, in other words
> sub-products).
> OK, that's my experience with a all-in-one device.
>
> In the moment I have not a good feeling about changing the place of
> writing uninstall data. And you have already the problem with one
> uninstaller.jar; means you cannot uninstall one of your products.
> It will be more or less a hack. If you use separated installation most you
> need one with less panels and only rare two or three (also less)
> installation
> which all can be handled (e.g. uninstalled) separatly.
>
> Long time I am missing maintenance with IzPack. At this point MSI is
> better
> than IzPack - nothing is perfect...
> I think with this a behavior you need will be easy to implement.
> But this implies some fundamental design changes. This will be needed much
> time.
> Until now I have nothad this time and no working group was found to share
> the work.
>
> Cheers
>
> Klaus
>
> Am 04.06.2007, 15:53 Uhr, schrieb Markus Schlegel <schlm3 at gmail.com>:
>
> > Hi
> >
> > A very special question, I know, but it's a requirement to my
> > installer....
> >
> > We have three parts of our product (Client, Server, Admin) packed into
> > one
> > installer (because they have a lot in common). The User can choose one
> on
> > the first panel. In most cases, a user has to install only one product
> on
> > each machine, but sometimes they have to install two (Server&Admin,
> > Client&Admin) or even all three products.
> >
> > What we wanted to do is to provide a Button on a "CustomFinishPanel"
> > which
> > when pressed returns to the first Page, so that the user can proceed
> with
> > the next Product installation directly. So far so good, that part worked
> > (with some CustomActions).
> >
> > What didn't work is the Uninstaller, because the uninstaller-log is
> > written
> > inside InstallerFrame.exit() --> writeUninstallData(), which is private.
> >
> > - What's the design decision to place that writeUninstallData() inside
> > exit() ? Wouldn't it be useful to write the InstallerData after all
> Packs
> > have been written and all "InstallerAction.afterPacks()" have been
> > performed?
> >
> > - Do you see other problems with this approach, or is it even a complete
> > insane idea?
> >
> > Thanks for your input
> >
> > Markus
>
>
>
> --
> Erstellt mit Operas revolutionärem E-Mail-Modul:
> http://www.opera.com/mail/
> _______________________________________________
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/izpack-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/izpack-devel/attachments/20070605/a88147aa/attachment.html