[izpack-user] Installer with Upgrade and Clean Install options

787 views
Skip to first unread message

Duggu

unread,
Feb 16, 2011, 3:00:18 AM2/16/11
to us...@izpack.codehaus.org

Hi All,

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


Duggu

unread,
Feb 21, 2011, 5:57:57 AM2/21/11
to us...@izpack.codehaus.org

Still stuck with this.

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

Will Milspec

unread,
Mar 9, 2011, 3:09:37 PM3/9/11
to us...@izpack.codehaus.org, Duggu
Hi,

Mod this question up.

fwiw, we have the same need/desire. Figuring this out would speed up and ease our switch to izpack

Our current installer (installanywhere) is more "wizard-ish". It's one of those technologies that "demos well", but over time becomes a PITA to maintain as complexity grows. That said, it's fairly straightforward to implement 'if then else' logic.

our process currently looks like this:
-prompt user: installing or upgrading?
-if upgrading
   specify the old directory 
   prompt users for a few 'upgrade parameters'
   set the ant target to 'upgrade
 else
   prompt users for 'install parameters'
   set the ant target to 'install'
  fi
-write parameters to a property file
-install/unzip files
-run the ant target

The installer handles a) prompting users for parameters b) figuring out which ant target to run c) installing the actual files d) running ant. Ant does all the "heavy lifting" (deploying the application, upgrading the database, etc)

 I know that izpack can solve this problem, but from initial reading and documentation , the "best route" did not seem obvious (at least to me: i may be missing something)


will


Brett Bergquist

unread,
Mar 9, 2011, 5:53:34 PM3/9/11
to us...@izpack.codehaus.org, Duggu

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.

René Krell

unread,
Mar 10, 2011, 3:14:37 AM3/10/11
to us...@izpack.codehaus.org
Hi Duggu,

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

Reply all
Reply to author
Forward
0 new messages