I am trying to come up with an IzPack installer which gives 'Upgrade' vs
'Clean Install' options to the user.
I am trying to do this by creating a group of files for upgrade and another
group of files for clean install. The files in both groups will point to the
same source and will have different conditions.
For example:
<file src="../data.txt" override="true" unpack="false"
targetdir="$INSTALL_PATH" condition="cleanInstallType" />
<file src="../data.txt" override="update" unpack="false"
targetdir="$INSTALL_PATH" condition="upgradeInstallType" />
As seen above, two file elements are created for the file '../data.txt', one
with a condition of cleanInstall and another with upgrade. The override
attribute for both are also different, with a value of 'true' for
cleanInstall and a value of 'update' for upgrade.
The required functionality is achieved through this type of configuration.
But I find that the installation is extremely slowed down due to this and
the total space required (as shown in the Packs Panel) has doubled.
On investigating further, I saw in one of the posts,
http://markmail.org/message/rskzzksdfj5q6kim#query:+page:1+mid:e5glnykt2gd62mmo+state:results
http://markmail.org/message/rskzzksdfj5q6kim#query:+page:1+mid:e5glnykt2gd62mmo+state:results
, that this problem is due to some back referencing of files. Could anyone
please tell me how to solve this problem?
If I create a duplicate copy of all the files and use one for cleanInstall
and another for upgrade, the speed increases. But the installer jar size is
doubled due to this. Hence I dont think it would be very elegant to do it
that way.
Could anyone help me with this? Or suggest any better methods to implement
Upgrade vs CleanInstall with IzPack.
Expecting replies at the earliest as it is very urgent.
Thanks in Advance
Duggu
--
View this message in context: http://old.nabble.com/Installer-with-Upgrade-and-Clean-Install-options-tp30936604p30936604.html
Sent from the izpack - users @ codehaus mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Someone PLEASE HELP!!!!!
-Duggu
> -Thanks in Advance
> Duggu
>
>
--
View this message in context: http://old.nabble.com/Installer-with-Upgrade-and-Clean-Install-options-tp30936604p30976174.html
We something similar. Our installer looks for an existing installation in a defined area. A variable is set depending on this and then a condition “normalInstall” or “upgradeInstall” is created with the condition testing the variable that was set. The variable in your case could be set in the UI panel where you prompt the user.
…
<condition type="variable" id="upgradeInstallation">
<name>some_variable_that_you_set_based_on_the_prompt</name>
<value>true</value>
</condition>
<condition type="not" id="normalInstallation">
<condition type="ref" refid="upgradeInstallation"/>
</condition>
<condition type="variable" id="version_2_0_installed">
<name>UPGRADE_VERSION</name>
<value>2.0</value>
</condition>
<condition type="variable" id="version_2_1_installed">
<name>UPGRADE_VERSION</name>
<value>2.1</value>
</condition>
..
Then a ProcessPanel is used. This has different jobs that are conditioned on the “normalInstall” or “upgradeInstall” conditions. The jobs run “ant” with the correct target:
<job name="Customize CanogaView Application" condition="normalInstallation">
<os family="unix" />
<executefile name="$INSTALL_PATH/glassfish/lib/ant/bin/ant">
<arg>-q</arg>
<arg>-f</arg>
<arg>$INSTALL_PATH/app/pkg/core/build.xml</arg>
<arg>install</arg>
</executefile>
</job>
…
<job name="Provision Core Package" condition="upgradeInstallation_2_2">
<os family="unix" />
<executefile name="$INSTALL_PATH/glassfish/lib/ant/bin/ant">
<arg>-q</arg>
<arg>$undeploy_property</arg>
<arg>-f</arg>
<arg>$INSTALL_PATH/app/pkg/core/build.xml</arg>
<arg>-DupgradeVersion=$UPGRADE_VERSION</arg>
<arg>upgrade-package</arg>
</executefile>
</job>
You should be able to do something similar to this.
first I must ask, whether you intend to use IzPack 4.3 (JRE<6) or the Maven-
based 5.0 (JRE =>6). IzPack 5.0 has much more possibilities and features in
handling existing files. Depending on that information I can try to find a
way.
René
> Thanks in Advance
> Duggu