jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • IzPack
  • IZPACK-537

Refresh dynamic variables also at the beginning of the installation to be able to use them for installerrequirement conditions

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 5.0
  • Component/s: Documentation, Installer
  • Labels:
    None
  • Testcase included:
    yes

Description

There might be used dynamic variables for gathering certain conditions to be evaluated in the installerrequirements at the very early phase of the installation. Example:

<info>
...
<installerrequirements>
<installerrequirement
condition="iscompatibleupgrade"
message="The current upgrade is not compatible with a previously installed version"/>
</installerrequirements>
</info>

<dynamicvariables>
<variable name="previous.version" checkonce="true"
file="${INSTALL_PATH}/installation.properties" type="options"
key="version"/>
</dynamicvariables>

<conditions>
<condition type="or" id="iscompatibleupgrade">
<condition type="variable">
<name>previous.version</name>
<value>1.0</value>
</condition>
<condition type="variable">
<name>previous.version</name>
<value>1.1</value>
</condition>
</condition>
<conditions>

This is not possible at the moment, because dynamic variables are still not refreshed in that installation phase.

I would add refresshing them already at the very early beginning of an installation to make cases as above possible.

Issue Links

is superceded by

Task - A task that needs to be done. IZPACK-520 Implement basic upgrade handling

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Gregor B. Rosenauer added a comment - 20/Sep/10 10:25 AM

I'd still vote for this issue to be resolved, as dynamic variables are necessary for much simpler usecases, too:
As static variables cannot be nested (only built-in variables are substituted in the definition), one has to use dynamic variables, which are not parsed at the beginning of the installation, which leads to obscure errors (see below).

E.g., installation paths cannot be easily appended, as in:

<variable name="POSTGRES_NAME" value="postgresql-8.4.4-1" />
<!-- won't work, which forces us to re-type the name, which is ugly and error-prone -->
<variable name="POSTGRES_INSTALLER value="$POSTGRES_NAME.exe"/>

Using dynamic variables does not help us here neither, because they are not parsed at the beginning of the installation, which causes the "src"-attribute to be un-substituted, but the "target"-attribute is actually substituted since it is only parsed when actually copying the files to the target directory:

<file src="${MY_SRC_PATH}/..." target="${MY_TARGET_PATH}">

This is ambiguous behaviour and could be easily avoided if static variables where a bit more useful and/or dynamic variables would be parsed at beginning.

Show
Gregor B. Rosenauer added a comment - 20/Sep/10 10:25 AM I'd still vote for this issue to be resolved, as dynamic variables are necessary for much simpler usecases, too: As static variables cannot be nested (only built-in variables are substituted in the definition), one has to use dynamic variables, which are not parsed at the beginning of the installation, which leads to obscure errors (see below). E.g., installation paths cannot be easily appended, as in:
<variable name="POSTGRES_NAME" value="postgresql-8.4.4-1" />
<!-- won't work, which forces us to re-type the name, which is ugly and error-prone -->
<variable name="POSTGRES_INSTALLER value="$POSTGRES_NAME.exe"/>
Using dynamic variables does not help us here neither, because they are not parsed at the beginning of the installation, which causes the "src"-attribute to be un-substituted, but the "target"-attribute is actually substituted since it is only parsed when actually copying the files to the target directory:
<file src="${MY_SRC_PATH}/..." target="${MY_TARGET_PATH}">
This is ambiguous behaviour and could be easily avoided if static variables where a bit more useful and/or dynamic variables would be parsed at beginning.

People

  • Assignee:
    Rene Krell
    Reporter:
    Rene Krell
Vote (0)
Watch (1)

Dates

  • Created:
    05/Mar/10 2:28 AM
    Updated:
    20/Sep/10 10:25 AM
    Resolved:
    21/Apr/10 5:34 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.