[IZPACK-1251] Installer with '(1)' in the file name cause generated uninstaller to fail Created: 12/May/15  Updated: 12/May/15  Resolved: 12/May/15

Status: Resolved
Project: IzPack
Component/s: Installer, Uninstaller
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There is problem with uninstaller.jar content when we use installer jar with "(1)" for example install (1).jar it very often case when we download installer several times.

In this case JarMerge performs replaceAll with "(1)" that treated as regular expression.

Thanks to Konstantin Zaitcev for reporting this and offering a fix.



 Comments   
Comment by Rene Krell [ 12/May/15 ]

Duplicate of IZPACK-1250





[IZPACK-1250] Installer with '(1)' in the file name cause generated uninstaller to fail Created: 12/May/15  Updated: 13/May/15  Resolved: 13/May/15

Status: Resolved
Project: IzPack
Component/s: Installer, Uninstaller
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There is problem with uninstaller.jar content when we use installer jar with "(1)" for example install (1).jar it very often case when we download installer several times.

In this case JarMerge performs replaceAll with "(1)" that treated as regular expression.

Thanks to Konstantin Zaitcev for reporting this and offering a fix.



 Comments   
Comment by Rene Krell [ 12/May/15 ]

Konstantin sent a pull request with a fix:
https://github.com/izpack/izpack/pull/349

Comment by Rene Krell [ 13/May/15 ]

Merged PR #349.





[IZPACK-1249] UserInputPanel - "custom" type input field - Swing button labels "Add"/"Remove" not translated Created: 12/May/15  Updated: 12/May/15  Resolved: 12/May/15

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Trivial
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The "Add"/"Remove" button labels for custom input fields on a UserInputPanel should be translated.

Adding the basic translations I know (english, german, czech) and asking the community to add translations for more languages.



 Comments   
Comment by Rene Krell [ 12/May/15 ]

Sent pull request:
https://github.com/izpack/izpack/pull/348

Comment by Rene Krell [ 12/May/15 ]

Merged PR #348.





[IZPACK-1248] UserInputPanel - "custom" input field layout improvements for console/GUI installers Created: 11/May/15  Updated: 12/May/15  Resolved: 12/May/15

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

For console as well as GUI installers there is a few complaints about the layout of the new "custom" type input field:

  • GUI: the button labels of "add"/"remove" should be "Add"/"Remove".
  • GUI: The insets of the "Add"/"Remove" buttons against the input rows should be increased.
  • Console: There is no user-friendly recognition which are the rows available for inputs, rather add row numbers or some indentations.
  • Console: It should be possible to directly edit specific rows without redisplaying and navigating all valid rows before.

TODO: There is still to be solved the translations of the user tests of the custom field for both installer types.



 Comments   
Comment by Rene Krell [ 11/May/15 ]

Sent pull request:
https://github.com/izpack/izpack/pull/346

Comment by Rene Krell [ 12/May/15 ]

PR #346 merged





[IZPACK-1247] Console installer - no title displayed for warning/error messages in comparison to GUI installer Created: 11/May/15  Updated: 12/May/15  Resolved: 12/May/15

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, the title for warning and error messages is not shown in console installations. This makes ot hard for the user know what's going on.

There should be a more user-firendly console interface as equivalent to error and warning messageboxes in Swing installers.

Example of the current behavior:
There is just shown the warning message of a panel validator:

Could not connect to broker URL: tcp://localhost:7000. Reason: java.net.ConnectException: Connection refused
Enter O for OK, C to Cancel:

Example of the desired behavior:
There should eb also shown the title and some horizontal lines as separators to recognize a messagebox equivalent:

------------------------------------------------------------------------------------------------------------
Validation failed - continuing installation
Could not connect to broker URL: tcp://localhost:7000. Reason: java.net.ConnectException: Connection refused
------------------------------------------------------------------------------------------------------------
Enter O for OK, C to Cancel:


 Comments   
Comment by Rene Krell [ 11/May/15 ]

Sent pull request #345:
https://github.com/izpack/izpack/pull/345

Comment by Rene Krell [ 12/May/15 ]

PR #345 merged.





[IZPACK-1246] PM WARNING: Cannot write to '/usr/share/applications' java.io.IOException: Permission denied when creating shortcuts under Linux Created: 11/May/15  Updated: 12/May/15

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Torsten Stolpmann Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS 5 testing the izpack-5.0.0-rc5-20150429.150112-25 snapshot.


Attachments: XML File Unix_shortcutSpec.xml    
Number of attachments : 1

 Description   

When creating shortcuts from the command line under Linux I receive the following warning. Please find attached the relevant shortcuts file.

Create shortcuts in the XDG-Menu
Enter Y for Yes, N for No:
n
May 11, 2015 3:40:15 PM WARNING: Cannot write to '/usr/share/applications'
java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:1006)
at java.io.File.createTempFile(File.java:1989)
at com.izforge.izpack.panels.shortcut.ShortcutPanelLogic.isWritable(ShortcutPanelLogic.java:760)
at com.izforge.izpack.panels.shortcut.ShortcutPanelLogic.initUserType(ShortcutPanelLogic.java:675)
at com.izforge.izpack.panels.shortcut.ShortcutConsolePanel.chooseEffectedUsers(ShortcutConsolePanel.java:198)
at com.izforge.izpack.panels.shortcut.ShortcutConsolePanel.run(ShortcutConsolePanel.java:144)
at com.izforge.izpack.installer.console.ConsoleInstallAction.run(ConsoleInstallAction.java:64)
at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:82)
at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:36)
at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:504)
at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:251)
at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:231)
at com.izforge.izpack.installer.console.ConsoleInstaller.run(ConsoleInstaller.java:183)
at com.izforge.izpack.installer.bootstrap.Installer.launchConsoleInstaller(Installer.java:262)
at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:225)
at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:193)
at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:72)



 Comments   
Comment by Rene Krell [ 12/May/15 ]

Did you run the installer with the according permissions, like root?
You should do so if you want to register system shortcuts.

Comment by Torsten Stolpmann [ 12/May/15 ]

Actually I do not wanted to create any shortcuts, this is why I answered no in the dialog. IMHO the installer should not try to write to the above directory in this case.





[IZPACK-1245] Console installer: panel DataValidator emitting a WARNING called three times before the panel switches Created: 07/May/15  Updated: 12/May/15  Resolved: 12/May/15

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There is a weird error when having a DataValidator emitting a Status.WARNING instead of error, but just for console installations. The Swing installer behaves like expected. In the console installation, the user must exactly three times confirm OK to get to the next panel.

I injected generating a stacktrace to figure out what is repeating here

Message broker connection

--> Row 1: URL: [tcp://localhost:7000]
Enter the row number (1..1) to edit, 2 to continue, 3 to redisplay, 4 to add a row
2
Could not connect to broker URL: tcp://localhost:7000. Reason: java.net.ConnectException: Connection refused
Enter O for OK, C to Cancel:
O
java.lang.Exception: O
        at com.izforge.izpack.core.handler.ConsolePrompt.confirm(ConsolePrompt.java:162)
        at com.izforge.izpack.core.handler.PromptUIHandler.emitWarning(PromptUIHandler.java:89)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isWarningValid(AbstractPanelView.java:514)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isValid(AbstractPanelView.java:486)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isValid(AbstractPanelView.java:451)
        at com.izforge.izpack.installer.panel.AbstractPanelView.validateData(AbstractPanelView.java:417)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isValid(AbstractPanelView.java:261)
        at com.izforge.izpack.installer.console.AbstractConsolePanel.promptEndPanel(AbstractConsolePanel.java:88)
        at com.izforge.izpack.panels.userinput.UserInputConsolePanel.run(UserInputConsolePanel.java:192)
        at com.izforge.izpack.installer.console.ConsoleInstallAction.run(ConsoleInstallAction.java:64)
        at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:82)
        at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:1)
        at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:509)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:254)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:234)
        at com.izforge.izpack.installer.console.ConsoleInstaller.run(ConsoleInstaller.java:183)
        at com.izforge.izpack.installer.bootstrap.Installer.launchConsoleInstaller(Installer.java:262)
        at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:225)
        at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:193)
        at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:72)

Press 1 to continue, 2 to quit, 3 to redisplay
1
Could not connect to broker URL: tcp://localhost:7000. Reason: java.net.ConnectException: Connection refused
Enter O for OK, C to Cancel:
O
java.lang.Exception: O
        at com.izforge.izpack.core.handler.ConsolePrompt.confirm(ConsolePrompt.java:162)
        at com.izforge.izpack.core.handler.PromptUIHandler.emitWarning(PromptUIHandler.java:89)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isWarningValid(AbstractPanelView.java:514)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isValid(AbstractPanelView.java:486)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isValid(AbstractPanelView.java:451)
        at com.izforge.izpack.installer.panel.AbstractPanelView.validateData(AbstractPanelView.java:417)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isValid(AbstractPanelView.java:261)
        at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:87)
        at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:1)
        at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:509)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:254)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:234)
        at com.izforge.izpack.installer.console.ConsoleInstaller.run(ConsoleInstaller.java:183)
        at com.izforge.izpack.installer.bootstrap.Installer.launchConsoleInstaller(Installer.java:262)
        at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:225)
        at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:193)
        at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:72)
Could not connect to broker URL: tcp://localhost:7000. Reason: java.net.ConnectException: Connection refused
Enter O for OK, C to Cancel:
O
java.lang.Exception: O
        at com.izforge.izpack.core.handler.ConsolePrompt.confirm(ConsolePrompt.java:162)
        at com.izforge.izpack.core.handler.PromptUIHandler.emitWarning(PromptUIHandler.java:89)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isWarningValid(AbstractPanelView.java:514)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isValid(AbstractPanelView.java:486)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isValid(AbstractPanelView.java:451)
        at com.izforge.izpack.installer.panel.AbstractPanelView.validateData(AbstractPanelView.java:417)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isValid(AbstractPanelView.java:261)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isValid(AbstractPanelView.java:239)
        at com.izforge.izpack.installer.panel.AbstractPanels.executeValidationActions(AbstractPanels.java:597)
        at com.izforge.izpack.installer.panel.AbstractPanels.isValid(AbstractPanels.java:177)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:249)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:234)
        at com.izforge.izpack.installer.console.ConsoleInstaller.run(ConsoleInstaller.java:183)
        at com.izforge.izpack.installer.bootstrap.Installer.launchConsoleInstaller(Installer.java:262)
        at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:225)
        at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:193)
        at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:72)

  [x] Include optional pack 'Application'
Enter Y for Yes, N for No:
...


 Comments   
Comment by Rene Krell [ 07/May/15 ]

The loop is caused in com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanelView, ConsolePanelView) which ignores the return status of a validation.
To be examined more in particular.

Comment by Rene Krell [ 11/May/15 ]

Sent pull request #347:
https://github.com/izpack/izpack/pull/347

Comment by Rene Krell [ 12/May/15 ]

PR #347 merged





[IZPACK-1244] Interrupting a console installation with CTRL-C causes a JLine exception stacktrace on the console output Created: 07/May/15  Updated: 07/May/15

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Pressing CTRL-C when waiting for user input lets a console installation fail with the following output:

jline.console.UserInterruptException
        at jline.console.ConsoleReader.readLine(ConsoleReader.java:2681)
        at jline.console.ConsoleReader.readLine(ConsoleReader.java:2269)
        at jline.console.ConsoleReader.readLine(ConsoleReader.java:2257)
        at com.izforge.izpack.util.Console.readLine(Console.java:92)
        at com.izforge.izpack.util.Console.prompt(Console.java:182)
        at com.izforge.izpack.panels.userinput.console.custom.ConsoleCustomField.display(ConsoleCustomField.java:199)
        at com.izforge.izpack.panels.userinput.UserInputConsolePanel.run(UserInputConsolePanel.java:177)
        at com.izforge.izpack.installer.console.ConsoleInstallAction.run(ConsoleInstallAction.java:64)
        at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:82)
        at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:1)
        at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:509)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:254)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:234)
        at com.izforge.izpack.installer.console.ConsoleInstaller.run(ConsoleInstaller.java:183)
        at com.izforge.izpack.installer.bootstrap.Installer.launchConsoleInstaller(Installer.java:262)
        at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:225)
        at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:193)
        at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:72)

[ Console installation FAILED! ]

Second example from the packs panel:

jline.console.UserInterruptException
        at jline.console.ConsoleReader.readLine(ConsoleReader.java:2681)
        at jline.console.ConsoleReader.readLine(ConsoleReader.java:2269)
        at jline.console.ConsoleReader.readLine(ConsoleReader.java:2257)
        at com.izforge.izpack.util.Console.readLine(Console.java:92)
        at com.izforge.izpack.util.Console.prompt(Console.java:401)
        at com.izforge.izpack.util.Console.prompt(Console.java:384)
        at com.izforge.izpack.util.Console.prompt(Console.java:431)
        at com.izforge.izpack.core.handler.ConsolePrompt.confirm(ConsolePrompt.java:206)
        at com.izforge.izpack.api.handler.AbstractPrompt.confirm(AbstractPrompt.java:148)
        at com.izforge.izpack.panels.packs.PacksConsolePanel.askUser(PacksConsolePanel.java:202)
        at com.izforge.izpack.panels.packs.PacksConsolePanel.drawHelper(PacksConsolePanel.java:160)
        at com.izforge.izpack.panels.packs.PacksConsolePanel.run(PacksConsolePanel.java:108)
        at com.izforge.izpack.installer.console.ConsoleInstallAction.run(ConsoleInstallAction.java:64)
        at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:82)
        at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:1)
        at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:509)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:254)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:234)
        at com.izforge.izpack.installer.console.ConsoleInstaller.run(ConsoleInstaller.java:183)
        at com.izforge.izpack.installer.bootstrap.Installer.launchConsoleInstaller(Installer.java:262)
        at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:225)
        at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:193)
        at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:72)

[ Console installation FAILED! ]

This exception should be caught and another message should be shown:

[ Console installation cancelled by user ]

The message

[ Console installation FAILED! ]

comes also (without a stacktrace) on choosing Quit in a console installation, should be the replaced by the message above as well.






[IZPACK-1243] FileNotFoundExecption in BaseUnpacker Created: 06/May/15  Updated: 06/May/15

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Conny Claus Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File install.xml    
Number of attachments : 1

 Description   

Installers containing at least two packs with parsable and executable files fail with FileNotFoundException in the second pack if the first pack uses a executable with stage postinstall.

Exception in thread "IzPack - Unpacker thread" java.lang.ClassCastException: java.io.FileNotFoundException cannot be cast to com.izforge.izpack.api.exception.IzPackException
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:273)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.run(UnpackerBase.java:235)
        at java.lang.Thread.run(Unknown Source)





[IZPACK-1242] Dynamic variable definitions with the same name and conditionid overwritten, although applying different filters for each of them Created: 21/Apr/15  Updated: 21/Apr/15  Resolved: 21/Apr/15

Status: Resolved
Project: IzPack
Component/s: Compiler, Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Provided a definition like this:

    <variable name="db.name" value="${db.url}" checkonce="true" condition="NotInstall+haveDatabaseURL+useMssql">
      <filters>
        <regex regexp="jdbc:jtds:sqlserver://[^:]+:\d+.*;DatabaseName=([^;]*)" select="\1" />
      </filters>
    </variable>
    <variable name="db.name" value="${db.url}" checkonce="true" condition="NotInstall+haveDatabaseURL+useMssql">
      <filters>
        <regex regexp="jdbc:jtds:sqlserver://[^:]+:\d+/([^:;]+)" select="\1" />
      </filters>
    </variable>

currently the first of the above two definitions withing <dynamicvariables> is ignored. A warning comes up during compiling:
Variable definition 'db.name' will be overwritten.

The currently rule for uniqueness of a dynamic variable is bound to comparing just its name and conditionid.

This is not correct. Both definitions should apply. If one of them results in a null value the one providing a non-null value should provide the final value.



 Comments   
Comment by Rene Krell [ 21/Apr/15 ]

Sent pull request https://github.com/izpack/izpack/pull/341.

Comment by Rene Krell [ 21/Apr/15 ]

PR #341 merged.





[IZPACK-1241] Builds using custom packaging type izpack-jar sometimes fail after fresh IzPack snapshot deployments Created: 17/Apr/15  Updated: 17/Apr/15  Resolved: 17/Apr/15

Status: Resolved
Project: IzPack
Component/s: Maven plugin
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Mostly a short time after fresh IzPack snapshot deployments I've noticed build failures when using the special packaing type izpack-jar in the POM.

There are appearing errors like this:

10:04:58 [ERROR] Failed to execute goal org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc5-SNAPSHOT:izpack (default-izpack) on project my-app: Execution default-izpack of goal org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc5-SNAPSHOT:izpack failed: A required class was missing while executing org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc5-SNAPSHOT:izpack: com/izforge/izpack/api/data/Info
10:04:58 [ERROR] -----------------------------------------------------
10:04:58 [ERROR] realm =    plugin>org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc5-SNAPSHOT
10:04:58 [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
10:04:58 [ERROR] urls[0] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-maven-plugin/5.0.0-rc5-SNAPSHOT/izpack-maven-plugin-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[1] = file:/var/lib/hudson-slave/maven-repositories/0/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
10:04:58 [ERROR] urls[2] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
10:04:58 [ERROR] urls[3] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/plexus/plexus-utils/1.5.15/plexus-utils-1.5.15.jar
10:04:58 [ERROR] urls[4] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-compiler/5.0.0-rc5-SNAPSHOT/izpack-compiler-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[5] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-native/5.0.0-rc5-SNAPSHOT/izpack-native-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[6] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-panel/5.0.0-rc5-SNAPSHOT/izpack-panel-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[7] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-util/5.0.0-rc5-SNAPSHOT/izpack-util-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[8] = file:/var/lib/hudson-slave/maven-repositories/0/org/jdom/jdom2/2.0.5/jdom2-2.0.5.jar
10:04:58 [ERROR] urls[9] = file:/var/lib/hudson-slave/maven-repositories/0/org/apache/maven/shared/maven-shared-jar/1.1/maven-shared-jar-1.1.jar
10:04:58 [ERROR] urls[10] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/plexus/plexus-digest/1.0/plexus-digest-1.0.jar
10:04:58 [ERROR] urls[11] = file:/var/lib/hudson-slave/maven-repositories/0/org/apache/bcel/bcel/5.2/bcel-5.2.jar
10:04:58 [ERROR] urls[12] = file:/var/lib/hudson-slave/maven-repositories/0/jakarta-regexp/jakarta-regexp/1.4/jakarta-regexp-1.4.jar
10:04:58 [ERROR] urls[13] = file:/var/lib/hudson-slave/maven-repositories/0/commons-collections/commons-collections/3.1/commons-collections-3.1.jar
10:04:58 [ERROR] urls[14] = file:/var/lib/hudson-slave/maven-repositories/0/org/picocontainer/picocontainer/2.14.1/picocontainer-2.14.1.jar
10:04:58 [ERROR] urls[15] = file:/var/lib/hudson-slave/maven-repositories/0/commons-lang/commons-lang/2.6/commons-lang-2.6.jar
10:04:58 [ERROR] urls[16] = file:/var/lib/hudson-slave/maven-repositories/0/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
10:04:58 [ERROR] urls[17] = file:/var/lib/hudson-slave/maven-repositories/0/org/apache/commons/commons-compress/1.3/commons-compress-1.3.jar
10:04:58 [ERROR] urls[18] = file:/var/lib/hudson-slave/maven-repositories/0/jline/jline/2.12/jline-2.12.jar
10:04:58 [ERROR] urls[19] = file:/var/lib/hudson-slave/maven-repositories/0/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.jar
10:04:58 [ERROR] urls[20] = file:/var/lib/hudson-slave/maven-repositories/0/org/java/net/substance/substance/6.0/substance-6.0.jar
10:04:58 [ERROR] urls[21] = file:/var/lib/hudson-slave/maven-repositories/0/org/pushing-pixels/trident/1.2/trident-1.2.jar
10:04:58 [ERROR] urls[22] = file:/var/lib/hudson-slave/maven-repositories/0/org/eclipse/swt/win32/win32/x86/3.3.0-v3346/x86-3.3.0-v3346.jar
10:04:58 [ERROR] urls[23] = file:/var/lib/hudson-slave/maven-repositories/0/net/java/dev/laf-widget/laf-widget/5.0/laf-widget-5.0.jar
10:04:58 [ERROR] urls[24] = file:/var/lib/hudson-slave/maven-repositories/0/asm/asm-all/2.2.3/asm-all-2.2.3.jar
10:04:58 [ERROR] urls[25] = file:/var/lib/hudson-slave/maven-repositories/0/net/java/dev/laf-plugin/laf-plugin/1.1/laf-plugin-1.1.jar
10:04:58 [ERROR] urls[26] = file:/var/lib/hudson-slave/maven-repositories/0/be/cyberelf/nanoxml/lite/2.2.3/lite-2.2.3.jar
10:04:58 [ERROR] urls[27] = file:/var/lib/hudson-slave/maven-repositories/0/com/incors/kunstoff-laf/2.0.2/kunstoff-laf-2.0.2.jar
10:04:58 [ERROR] urls[28] = file:/var/lib/hudson-slave/maven-repositories/0/com/jgoodies/looks/2.2.2/looks-2.2.2.jar
10:04:58 [ERROR] urls[29] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-core/5.0.0-rc5-SNAPSHOT/izpack-core-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[30] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-tools/5.0.0-rc5-SNAPSHOT/izpack-tools-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[31] = file:/var/lib/hudson-slave/maven-repositories/0/org/apache/ant/ant/1.9.4/ant-1.9.4.jar
10:04:58 [ERROR] urls[32] = file:/var/lib/hudson-slave/maven-repositories/0/org/apache/ant/ant-launcher/1.9.4/ant-launcher-1.9.4.jar
10:04:58 [ERROR] urls[33] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-uninstaller/5.0.0-rc5-SNAPSHOT/izpack-uninstaller-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[34] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-gui/5.0.0-rc5-SNAPSHOT/izpack-gui-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[35] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-installer/5.0.0-rc5-SNAPSHOT/izpack-installer-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[36] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-event/5.0.0-rc5-SNAPSHOT/izpack-event-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[37] = file:/var/lib/hudson-slave/maven-repositories/0/org/codehaus/izpack/izpack-api/5.0.0-rc5-SNAPSHOT/izpack-api-5.0.0-rc5-SNAPSHOT.jar
10:04:58 [ERROR] urls[38] = file:/var/lib/hudson-slave/maven-repositories/0/commons-io/commons-io/2.4/commons-io-2.4.jar
10:04:58 [ERROR] Number of foreign imports: 1
10:04:58 [ERROR] import: Entry[import  from realm ClassRealm[project>com.mycompany:my-app:01.02.00-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
10:04:58 [ERROR]
10:04:58 [ERROR] -----------------------------------------------------: com.izforge.izpack.api.data.Info
10:04:58 [ERROR] -> [Help 1]
10:04:58 [ERROR]
10:04:58 [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
10:04:58 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
10:04:58 [ERROR]
10:04:58 [ERROR] For more information about the errors and possible solutions, please read the following articles:
10:04:58 [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
10:04:58 [ERROR]

This happens on CI buildsystems like Hudson and during local builds accessing a repository manager as well.



 Comments   
Comment by Rene Krell [ 17/Apr/15 ]

Sent pull request https://github.com/izpack/izpack/pull/340

Comment by Rene Krell [ 17/Apr/15 ]

PR #340 merged.
Our builds based on izpack-jar work with this.





[IZPACK-1240] Message boxes after validation failures cannot be closed using ENTER, but just by ESC, SPACE or clicking on the Close button Created: 03/Apr/15  Updated: 03/Apr/15  Resolved: 03/Apr/15

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

On Unix, when validating user inputs, in case of validation errors or warnings the installer opens a messagebox with a focused 'Close' button, but pressing ENTER doesn't close it, just ESC, SPACE or clicking it directly close these messageboxes.

This is specific to the Look and Feel. Activate/override the "Button.defaultButtonFollowsFocus" setting in general for all L&F.



 Comments   
Comment by Rene Krell [ 03/Apr/15 ]

Sent pull request: https://github.com/izpack/izpack/pull/335

Comment by Rene Krell [ 03/Apr/15 ]

PR #335 merged.





[IZPACK-1239] HostAddressValidator not working as expected Created: 29/Mar/15  Updated: 01/Apr/15

Status: Open
Project: IzPack
Component/s: Panels
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: S Chaudhari Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5rc5


Number of attachments : 0

 Description   

com.izforge.izpack.panels.userinput.validator.HostAddressValidator does not work as expected it gives errors always even if the port is not in use.



 Comments   
Comment by Rene Krell [ 01/Apr/15 ]

Please add an example to reproduce.





[IZPACK-1238] UserInputPanel: input fields not focused automatically on panel activation Created: 26/Mar/15  Updated: 17/Apr/15  Resolved: 17/Apr/15

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

On opening a user input panel during a Swing-based installation, there is not automatically focused the first valid input field. Instead, the user must navigate or click on it to do any input.



 Comments   
Comment by Rene Krell [ 26/Mar/15 ]

Created pull request https://github.com/izpack/izpack/pull/334

Comment by Rene Krell [ 27/Mar/15 ]

PR #334 merged

Comment by Rene Krell [ 17/Apr/15 ]

File/dir input fields don't receive the focus correctly. Fixing it....

Comment by Rene Krell [ 17/Apr/15 ]

Issued another pull request: https://github.com/izpack/izpack/pull/339 with a fix for file/dir fields being able to receive the initial focus correctly.

Comment by Rene Krell [ 17/Apr/15 ]

PR #339 merged





[IZPACK-1237] File override attribute ignored Created: 17/Mar/15  Updated: 17/Mar/15

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.5
Fix Version/s: 4.3.5

Type: Bug Priority: Major
Reporter: Daniel Rutherford Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I have a pack in my install.xml containing file elements with the override attribute set to false. My understanding was that after the first install, the file would never be overridden for subsequent installs. When I run the installer, files are overridden as if the attribute was set to the default value update. I was able to verify this by manually changing the modified date on a single file and running the installer. The file that was changed was the only one that was overridden in the pack.






[IZPACK-1236] Should (static) variables be evaluated in all xml definitions? Created: 14/Mar/15  Updated: 17/Mar/15

Status: Open
Project: IzPack
Component/s: Compiler
Affects Version/s: 5.0
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Tom Helpstone Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When defining a installer, some of the configuration is evaluated during install. So you can use variables for this attributes.

Other attributes are evaluated during compile. The dynamic variables can not be used at this stage, because they can evaluated only during install. But the static variables are available during compile also and could be useful for customized builds.

Some attributes did accept static variables since 2010, others were added within IZPACK-1234.

There still may be attributes were static variables would be useful. It could be a reasonable idea to resolve static variables in the XML-parser, so that variables could be used in all definitions without special handling on the sprecific attribute.

Any comments on this?



 Comments   
Comment by Tom Helpstone [ 17/Mar/15 ]

Just replacing variables for all attributes while reading xml during compilation would not be a valid option:

A variable may have a static default value, which could be overwritten during installation with a dynamic value. The dynamic variable is not be available druing compile, so the static value would be taken.

So variable substition for installation-related attributes have to be resolved during installation, not during compile. Only compilation-related attribuites (e.g. defining the source of the files) should be handled with variables substitution during compile.

conclusion:

  1. The solution in IZPACK-1234 is reasonable. Maybe a small helper "readAttributeAndSubstituteVariables" could be implemented.
  2. all attributes used during compilation only have to be found and the variable substition has to be implemented
  3. Because of the possible impact, such a refactoring is should be done in 5.1 only.
  4. But IZPACK-1234 should be targeted to 5.0




[IZPACK-1235] <fileset>: documentation and source are different Created: 14/Mar/15  Updated: 14/Mar/15

Status: Open
Project: IzPack
Component/s: Compiler, Documentation
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Tom Helpstone Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Referring to http://docs.codehaus.org/display/IZPACK/Adding+a+set+of+files a <fileset> must have a "dir"-attribute and may have a "file"-attribut which is relativ to the "dir".

But the source code in CompilerConfig.java behaves different:

  1. "file" is not relative to "dir"
  2. "dir" is mandatory in line 3164, but it should be optional in lines 3165-3189)
  3. If "dir" should be mandatory, "file" has to be relative to dir.

Either source or documentation should be adapted. Which variant should survive?






[IZPACK-1234] Usage of variables for pack content Created: 13/Mar/15  Updated: 19/Mar/15  Resolved: 19/Mar/15

Status: Resolved
Project: IzPack
Component/s: Compiler
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File installer.xml    
Number of attachments : 1

 Description   

When defining a pack, you can include files with three different definitions:

  1. <singlefile> for inclusion of a single file to a target file
  2. <file> for inclusion of a single file to a target directory
  3. <fileset> for inclusion of a set of files to a target directory

See the following definition as the starting point for the further investigations:

  <packs>
    <pack name="singlefile" required="false" >
      <description>including a singlefile</description>
      <singlefile target="${INSTALL_PATH}/singlefile/file1.txt" src="files/file1.txt" />
    </pack>
    <pack name="file" required="false" >
      <description>including a file</description>
      <file targetdir="${INSTALL_PATH}/file" src="files/file1.txt" />
    </pack>
    <pack name="fileset" required="false" >
      <description>including a fileset</description>
      <fileset targetdir="${INSTALL_PATH}/fileset" dir="files" >
        <include name="file1.txt" />
      </fileset>
    </pack>
  </packs>

Inside the "target" / "targetdir" attributs there are variables used already. This variables will be computated during install time later.

It may helpful to use variables or properties for defining the source also, because your build process could produce some artifacts with some variable names (things like a version or a varianbt for example). Therefore variables should be allowed for the "src" and "name"-attributes:

  • Using dynamic variables would not be a reasonable idea, because the value will not be available on compilation, but only later during installation, which is too late.
  • Using static variables (or properties) should be possible. The values are known on compilation already.

So the following definition should work as well:

  <variables>
    <variable name="srcDir" value="files" />
    <variable name="var" value="file2.txt" />
  </variables>
  <packs>
    <pack name="singlefile" required="false" >
      <description>including a singlefile</description>
      <singlefile target="${INSTALL_PATH}/singlefile/file1.txt" src="files/file1.txt" />
      <singlefile target="${INSTALL_PATH}/singlefile/${var}" src="files/${var}" />
    </pack>
    <pack name="file" required="false" >
      <description>including a file</description>
      <file targetdir="${INSTALL_PATH}/file" src="files/file1.txt" />
      <file targetdir="${INSTALL_PATH}/file" src="files/${var}" />
    </pack>
    <pack name="fileset" required="false" >
      <description>including a fileset</description>
      <fileset targetdir="${INSTALL_PATH}/fileset" dir="${srcDir}" >
        <include name="file1.txt" />
        <include name="${var}" />
      </fileset>
    </pack>
    <pack name="fileset2" required="false" >
      <description>including a fileset with a single file</description>
      <fileset targetdir="${INSTALL_PATH}/fileset2" dir="${srcDir}" file="files/${var}" >
         <!-- see https://jira.codehaus.org/browse/IZPACK-1235 for inconsistence of "dir and "file" -->
      </fileset>
    </pack>
  </packs>

But the 3 elements behave different when using variables for the source of the file:

  • <singlefile>: both file1.txt and file2.txt do work – fine!
  • <file> does complain during compile: "Source file files\${var} not found"
  • <fileset> the <include> does work, but the dir="${srcDir}" does not find the source dir.


 Comments   
Comment by Tom Helpstone [ 13/Mar/15 ]

example installer

Comment by Tom Helpstone [ 13/Mar/15 ]

com.izforge.izpack.compiler.CompilerConfig.processSingleFileChildren(File, IXMLElement, PackInfo) does contain some extra code for resolving variables:

            File file = new File(src);
            if (!file.isAbsolute())
            {
                file = new File(compilerData.getBasedir(), src);
            }

            // if the path does not exist, maybe it contains variables
            if (!file.exists())
            {
                try
                {
                    file = new File(variableSubstitutor.substitute(file.getAbsolutePath()));
                }
                catch (Exception e)
                {
                    assertionHelper.parseWarn(singleFileNode, e.getMessage());
                }
                // next existance checking appears in pack.addFile
            }

When the file is not found, it the file is renewed with variables in the complete path resolved.

Comment by Tom Helpstone [ 14/Mar/15 ]

Probably one could substitute variables without first checking for the existence of a file. But this may break some existing installers, even it is not very likely. So I've ported the solution found in <singlefile> to the attributes of <file> and <fileset>. See pull request 330

Comment by Rene Krell [ 19/Mar/15 ]

PR #330 merged.
Thank you.





[IZPACK-1233] PackValidator Class Not Found Created: 11/Mar/15  Updated: 11/Mar/15

Status: Open
Project: IzPack
Component/s: None
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lou Aloia Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Custom pack validator class cannot be loaded when running an installer, built with maven, due to a ClassNotFoundException: com.izfore.izpack.panels.treepacks.PackValidator. The problem is that the PackValidator class is not included in the generated installer jar. This worked in IzPack version 4.3. However, the PackValidator class is in com.izforge.izpack.installer package in that version.






[IZPACK-1232] PacksConsolePanel prints the id of the packs in console mode, not the localized pack names Created: 10/Mar/15  Updated: 19/Mar/15  Resolved: 19/Mar/15

Status: Resolved
Project: IzPack
Component/s: Installer, Translations
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Aitor Sánchez Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to IZPACK-1222 Some text is hardcoded in english in ... Resolved
is related to IZPACK-1206 PacksConsolePanel does auto-select an... Resolved
Number of attachments : 0

 Description   

PacksConsolePanel prints the id of the packs in console mode, not the localized pack names.

It will be helpful that the packs and description will printed localized, as the user has in the packlang.xml, not only the id defined in install.xml



 Comments   
Comment by Aitor Sánchez [ 11/Mar/15 ]

Hi!

I've tried to solve this issue with the pull request https://github.com/izpack/izpack/pull/329

It is not completely solved because it is related with other issue IZPACK-1222, that talks about hardcoded messages in console classes
http://jira.codehaus.org/browse/IZPACK-1222

Comment by Aitor Sánchez [ 12/Mar/15 ]

This ticket seems to be related with the issue IZPACK-1222, because the localized pack names are already being used in the other packs console implementation TreePacksConsolePanel. Now I am using this class.

Comment by Rene Krell [ 19/Mar/15 ]

PR #329 merged.
Thank you.





[IZPACK-1231] AntActionsInstallerListener: Improve error handling and messageboxes Created: 09/Mar/15  Updated: 16/Mar/15  Resolved: 11/Mar/15

Status: Resolved
Project: IzPack
Component/s: Documentation, Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to IZPACK-1220 AntActionsInstallerListener: Add Ant ... Open
Number of attachments : 0

 Description   

If there occur Ant build failures in AntActionInstallerListener they are handled poorly at the moment. In each case, the installation fails with a messagebox containing the complete error trace not very useful for people just using an installer.

The error handling should be enhanced to the following possibilities:

  • Hide the Ant stacktrace from the user or open it optionally
    Ant build stacktraces can be still seen in the AntAction log file.
  • info, warning and error level


 Comments   
Comment by Rene Krell [ 09/Mar/15 ]

Sent pull request: https://github.com/izpack/izpack/pull/328

Comment by Rene Krell [ 11/Mar/15 ]

Pull request merged, will add to documentation.





[IZPACK-1230] 'Can't find named resource: packsLang.xml & packsLang.xml_eng' while installing Created: 06/Mar/15  Updated: 11/May/15

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sabrina Gidley Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File installer.PNG     PNG File IzPack - Installation of Klaros-Testmanagement 4.3.0-SNAPSHOT_2015-05-11_12-59-14.png    
Number of attachments : 2

 Description   

When trying to install via command line using the current 5.0.0.-rc5-Snapshot (izpack-installer-5.0.0-rc5-20150227.180304-16.jar) the installer is starting to unpack the files, a error comes up saying: 'Can't find named resource: packsLang.xml & packsLang.xml_eng.

The installation is interrupted here.



 Comments   
Comment by Rene Krell [ 11/May/15 ]

There are several warnings of that kind but I haven't recognized an aborting installation in the latest tests.
Can you please provide a stacktrace by adding -DSTACKTRACE=true to the command line.

Comment by Torsten Stolpmann [ 11/May/15 ]

There you go (using izpack-5.0.0-rc5-20150429.150112-25):

May 11, 2015 12:54:06 PM SEVERE: Cannot find named resource: 'packsLang.xml' AND 'packsLang.xml_eng'
com.izforge.izpack.api.exception.ResourceNotFoundException: Cannot find named resource: 'packsLang.xml' AND 'packsLang.xml_eng'
at com.izforge.izpack.core.resource.ResourceManager.getLanguageResourceString(ResourceManager.java:366)
at com.izforge.izpack.core.resource.ResourceManager.getInputStream(ResourceManager.java:136)
at com.izforge.izpack.core.resource.DefaultLocales.getMessages(DefaultLocales.java:275)
at com.izforge.izpack.api.data.LocaleDatabase.newMessages(LocaleDatabase.java:262)
at com.izforge.izpack.installer.unpacker.UnpackerBase.getStepName(UnpackerBase.java:808)
at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:440)
at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:397)
at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:251)
at com.izforge.izpack.installer.unpacker.UnpackerBase.run(UnpackerBase.java:233)
at com.izforge.izpack.panels.install.InstallConsolePanel.run(InstallConsolePanel.java:137)
at com.izforge.izpack.panels.install.InstallConsolePanel.run(InstallConsolePanel.java:69)
at com.izforge.izpack.installer.console.ConsoleInstallAction.run(ConsoleInstallAction.java:64)
at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:82)
at com.izforge.izpack.installer.console.ConsolePanels.switchPanel(ConsolePanels.java:36)
at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:504)
at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:251)
at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:231)
at com.izforge.izpack.installer.console.ConsoleInstaller.run(ConsoleInstaller.java:183)
at com.izforge.izpack.installer.bootstrap.Installer.launchConsoleInstaller(Installer.java:262)
at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:225)
at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:193)
at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:72)

Please note that the same installer also displays an empty page when installing in GUI mode in Step 5 (Select Installation Packages).

Comment by Rene Krell [ 11/May/15 ]

The missing resources are needed by the PacksPanel and PacksConsolePanel.
You should explicitly include them for the languages you support, example:

Example of install.xml:

    <resources>
        ...
        <res id="packsLang.xml_eng" src="@{izpack.build.directory}/i18n/packsLang.xml_eng"/>
        <res id="packsLang.xml_deu" src="@{izpack.build.directory}/i18n/packsLang.xml_deu"/>
    </resources>


    <packs>
        <pack id="pack.application" name="Application" required="yes">
          ...
        </pack>
        <pack id="pack.templates" name="Templates" required="no">
          ...
        </pack>
    </packs>

Example contents:

File resource packsLang.xml_eng

<?xml version="1.0" encoding="UTF-8"?>
<izpack:langpack version="5.0" xmlns:izpack="http://izpack.org/schema/langpack" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://izpack.org/schema/langpack http://izpack.org/schema/5.0/izpack-langpack-5.0.xsd">
  <str id="pack.application" txt="My Application" />
  <str id="pack.application.description" txt="This pack contains only application files without templates." />
  <str id="pack.templates" txt="Application templates" />
  <str id="pack.templates.description" txt="This pack contains the application templates." />
templates." />
</izpack:langpack>

File resource packsLang.xml_deu

<?xml version="1.0" encoding="UTF-8"?>
<izpack:langpack version="5.0" xmlns:izpack="http://izpack.org/schema/langpack" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://izpack.org/schema/langpack http://izpack.org/schema/5.0/izpack-langpack-5.0.xsd">
  <str id="pack.application" txt="Meine Anwendung" />
  <str id="pack.application.description" txt="Dieses Paket enthÃÆ’€lt nur Anwendungs-Dateien ohne Templates." />
  <str id="pack.templates" txt="Templates" />
  <str id="pack.templates.description" txt="Anwendungs-Templates" />
templates." />
</izpack:langpack>
Comment by Rene Krell [ 11/May/15 ]

The difference in behavior between console and GUI installation mode seems to be a flaw in exception handling.
Would not call it a blocker since there is an easy way to solve this.

Comment by Torsten Stolpmann [ 11/May/15 ]

Thanks a lot for the proposed fix, which actually resolves the problem

For the root cause of this I think the following part of our install.xml may be responsible (We decided to drop German Support somewhere along the way):

  <locale>
    <langpack iso3="eng" />
    <!-- <langpack iso3="deu"/> -->
  </locale>

this has been working up to 5.0.0-rc3 where izpack silently falls back to the information in the packs section:

  <packs>
    <pack id="pack.tomcat" name="Tomcat 8 Application Server" required="yes">
      <description>The Tomcat ${version.tomcat} Web Application Server.</description>
     ...
    </pack>
    <pack id="pack.klaros" name="Klaros-Testmanagement ${project.version}" required="yes">
      <description>The Klaros-Testmanagement Application Version ${project.version}.</description>
     ...
    </pack>
    <pack id="pack.documentation" name="PDF-Documentation" required="no">
      <description>The Klaros-Testmanagement ${project.version} Documentation in PDF Format.</description>
     ...
    </pack>
  </packs>

I suggest that the former behavior should be restored if possible.

Comment by Rene Krell [ 11/May/15 ]

Ok, leaving this open for now.
Your suggestion needs to be decided or simply resolved if easy.
Thanks so far for the quick responses.





[IZPACK-1229] Filter for lowercase and uppercase Created: 05/Mar/15  Updated: 19/Mar/15  Resolved: 06/Mar/15

Status: Resolved
Project: IzPack
Component/s: Compiler, Documentation
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: New Feature Priority: Minor
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When defining dynamic variables you can use filters to modify the value. Currently only a regex and a location filter are available.

I have a use case, where I need to have a variable with all lowercase, independent ot the input of the user. The regex filter is not able to handle this, because the Java regex-functionality does not include a case-conversion like available in Perl with \l.

So I want to implement a lowercase and uppercase Filter.



 Comments   
Comment by Rene Krell [ 05/Mar/15 ]

The casesensitive attribute of the regexp filter didn't help here?
See http://docs.codehaus.org/display/IZPACK/Dynamic+Variables

Comment by Rene Krell [ 05/Mar/15 ]

I will answer to myself Probably not, if the final variable value should be lowercase. The attribute casesensitive is just for matching, no conversion is done.

Comment by Tom Helpstone [ 05/Mar/15 ]

I've implemented a generic filter casestyle which uses String.toLowerCase() and String.toUpperCase(). The action is selected with the style-attribute. Example:

    <variable name="var1" value="{$var} >
      <filters> <casestyle style="lowercase" /> </filters>
    </variable>
    <variable name="var2" value="{$var} >
      <filters> <casestyle style="uppercase" /> </filters>
    </variable>

I'm not sure how the filter should be named. casestyle or just case ?

Comment by Tom Helpstone [ 05/Mar/15 ]

I've documented the filter in http://docs.codehaus.org/display/IZPACK/Dynamic+Variables

Comment by Rene Krell [ 05/Mar/15 ]

Well-done. Personally I would call it just <case style="upper|lower"/>, to make it short, but this is just cosmetic.

Comment by Tom Helpstone [ 06/Mar/15 ]

I've changed to the short form for the user interface (installer.xml)

Comment by Rene Krell [ 06/Mar/15 ]

Merged pull request https://github.com/izpack/izpack/pull/326.
Thank you for contributing.

Comment by Tom Helpstone [ 06/Mar/15 ]

Please do not forget to put the changed xsd to the webserver.





[IZPACK-1228] Defining an unknown filter in dynamic variable is silently ignored Created: 05/Mar/15  Updated: 19/Mar/15  Resolved: 05/Mar/15

Status: Resolved
Project: IzPack
Component/s: Compiler
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In a definition like

    <variable name="var1" value="{$var2} >
      <filters>
        <unkownFilter />
      </filters>
    </variable>

the unknown filter is silently ignored. Should be handled as an severe error, because Installer will not behave like intended.



 Comments   
Comment by Rene Krell [ 05/Mar/15 ]

This is more a general problem in the compiler.
The whole compiler should be refactordered IMHO in some of the next major versions to be strict and allow just known elements and attributes including checking value ranges.

Comment by Rene Krell [ 05/Mar/15 ]

Merged according PR https://github.com/izpack/izpack/pull/325
Thanks for contributing.





[IZPACK-1227] NullPointerException in ConfigurationInstallerListener, if patchFile hasn't been defined in the descriptor Created: 27/Feb/15  Updated: 27/Feb/15  Resolved: 27/Feb/15

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Critical
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

A NPE occurs during performing the ConfigurationInstallerListener when there is just a toFile attribute defined in the ConfigurationActionSpec.xml resource, without the patchFile attribute.

Feb 27, 2015 6:39:22 PM SEVERE: java.lang.NullPointerException
com.izforge.izpack.api.exception.InstallerException: java.lang.NullPointerException
        at com.izforge.izpack.event.ConfigurationInstallerListener.performAllActions(ConfigurationInstallerListener.java:357)
        at com.izforge.izpack.event.ConfigurationInstallerListener.afterPack(ConfigurationInstallerListener.java:261)
        at com.izforge.izpack.installer.event.InstallerListeners.afterPack(InstallerListeners.java:287)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:412)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:251)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.run(UnpackerBase.java:233)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
        at com.izforge.izpack.util.config.SingleOptionFileTask.writeConfigurable(SingleOptionFileTask.java:127)
        at com.izforge.izpack.util.config.SingleConfigurableTask.execute(SingleConfigurableTask.java:217)
        at com.izforge.izpack.event.ConfigurationActionTask.execute(ConfigurationActionTask.java:71)
        at com.izforge.izpack.event.ConfigurationAction.performInstallAction(ConfigurationAction.java:59)
        at com.izforge.izpack.event.ConfigurationInstallerListener.performAllActions(ConfigurationInstallerListener.java:353)
        ... 6 more


 Comments   
Comment by Rene Krell [ 27/Feb/15 ]

Fixed in pull request https://github.com/izpack/izpack/pull/322





[IZPACK-1226] ConfigurationInstallerListener does not remove entries as configured Created: 24/Feb/15  Updated: 19/Mar/15  Resolved: 24/Feb/15

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Critical
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Number of attachments : 0

 Description   

The ConfigurationInstallerListener can be used to add, change or remove entries from e.g. propertiy-files. Removing entries does not work as supposed when a entry should be removed regardless of it's value.

example configuration
<izpack:configurationactions version="5.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:izpack="http://izpack.org/schema/configurationactions"
      xsi:schemaLocation="http://izpack.org/schema/configurationactions
      http://izpack.org/schema/5.0/izpack-configurationactions-5.0.xsd">
  <pack name="Demo" >
    <configurationaction order="afterpack" >
        <configurable tofile="demo.properties" type="options">
        <entry key="key1" operation="remove" />
        <entry key="key2" operation="remove" lookupType="regexp" value=".*" />
      </configurable>
    </configurationaction>
  </pack>
</izpack:configurationactions>

"key2" will be removed, but "key1" isn't removed, but should be so also.

I've tested in 5.0.0-rc5-SNAPSHOT, but the problem should exist since 2010.



 Comments   
Comment by Tom Helpstone [ 24/Feb/15 ]

The error s caused by an wrong if-condition in com.izforge.izpack.util.config.SingleConfigurableTask in method deleteOptions(). The analog method keepOptions() is done well.

Comment by Tom Helpstone [ 24/Feb/15 ]

Even worse: Because of the wrong if-condition entries will be removed regardless of their value, when an old value is configured for selection.

Comment by Tom Helpstone [ 24/Feb/15 ]

sent PR 320

Comment by Rene Krell [ 24/Feb/15 ]

Oops, good catch, thank you.

Comment by Rene Krell [ 24/Feb/15 ]

Pull request merged.
Thank you again.





[IZPACK-1225] IzPack 5.0rc3 Compile error Unable to create directory Created: 23/Feb/15  Updated: 01/Apr/15  Resolved: 29/Mar/15

Status: Resolved
Project: IzPack
Component/s: Compiler
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: S Chaudhari Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When including zip file with folders the compile gives below errors any way we can avoid this? or are there any solutions

Unable to create directory v2.4.4\plugins
com.izforge.izpack.api.exception.CompilerException: Unable to create directory v2.4.4\plugins
at com.izforge.izpack.compiler.CompilerConfig.processFileChildren(CompilerConfig.java:1123)
at com.izforge.izpack.compiler.CompilerConfig.addPacksSingle(CompilerConfig.java:798)
at com.izforge.izpack.compiler.CompilerConfig.addPacks(CompilerConfig.java:697)
at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:327)
at com.izforge.izpack.compiler.bootstrap.CompilerLauncher.main(CompilerLauncher.java:52)
Caused by: java.io.IOException: Unable to create directory v2.4.4\plugins
at org.apache.commons.io.FileUtils.forceMkdir(FileUtils.java:2384)
at com.izforge.izpack.compiler.CompilerConfig.addArchiveContent(CompilerConfig.java:1510)
at com.izforge.izpack.compiler.CompilerConfig.processFileChildren(CompilerConfig.java:1106)
... 4 more



 Comments   
Comment by S Chaudhari [ 29/Mar/15 ]

It was fixed in latest code rc5





[IZPACK-1224] Build failing - maven 3.2.5, JDK 1.6 on Windows 7 Created: 23/Feb/15  Updated: 19/Mar/15  Resolved: 19/Mar/15

Status: Resolved
Project: IzPack
Component/s: Build
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: S Chaudhari Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Local


Number of attachments : 0

 Description   

Hi,

After cloning the git repository and as per instruction ran 'mvn install' but it gives below error

Concurrency config is parallel='both', perCoreThreadCount=true, threadCount=4, useUnlimitedThreads=false
Running com.izforge.izpack.util.config.base.RegTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.562 sec
Running com.izforge.izpack.util.config.base.spi.IniParserTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running com.izforge.izpack.util.DefaultTargetPlatformFactoryTest
unix,version=null,arch=unknown,symbolicName=null,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactoryTest$Un
ixA

linux,version=null,arch=unknown,symbolicName=null,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactoryTest$L
inuxA

windows,version=null,arch=unknown,symbolicName=null,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactoryTest
$WinA

debian_linux,version=null,arch=unknown,symbolicName=null,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactor
yTest$DebianA

windows,version=6.1,arch=unknown,symbolicName=WINDOWS_7,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactory
Test$Win7

windows,version=null,arch=x64,symbolicName=null,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactoryTest$Win
X64

windows,version=null,arch=x86,symbolicName=null,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactoryTest$Win
X86

windows,version=6.1,arch=x64,symbolicName=WINDOWS_7,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactoryTest
$Win7X64

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running com.izforge.izpack.util.JVMHelperTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running com.izforge.izpack.util.OsConstraintHelperTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec
Running com.izforge.izpack.util.PlatformModelMatcherTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec
Running com.izforge.izpack.util.PrivilegedRunnerTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Running com.izforge.izpack.util.config.SingleConfigurableTaskTest
Feb 23, 2015 4:39:41 PM com.izforge.izpack.util.config.SingleIniFileTask readSourceConfigurable
WARNING: INI file D:\Sumeet\Wawanesa\PRASE%20Build%20POC\IzPack\SourceCode\izpack\izpack-util\target\test-classes\com\izforge
\izpack\util\config\oldversion.ini to patch from could not be found, no patches will be applied

+++ C:\Users\sumeetc\AppData\Local\Temp\junit3063824709023317607\to.ini +++

+++ D:\Sumeet\Wawanesa\PRASE%20Build%20POC\IzPack\SourceCode\izpack\izpack-util\target\test-classes\com\izforge\izpack\util\c
onfig\expected_after_merge.ini +++

java.io.FileNotFoundException: D:\Sumeet\Wawanesa\PRASE%20Build%20POC\IzPack\SourceCode\izpack\izpack-util\target\test-classe
s\com\izforge\izpack\util\config\expected_after_merge.ini (The system cannot find the path specified)

at java.io.FileInputStream.open(Native Method)

at java.io.FileInputStream.<init>(FileInputStream.java:120)

at java.io.FileReader.<init>(FileReader.java:55)

at com.izforge.izpack.util.config.SingleConfigurableTaskTest.printFileContent(SingleConfigurableTaskTest.java:156)

at com.izforge.izpack.util.config.SingleConfigurableTaskTest.testIniCommentsAtEnd(SingleConfigurableTaskTest.java:144
)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)

at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)

at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)

at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)

at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)

at org.junit.rules.RunRules.evaluate(RunRules.java:18)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)

at org.junit.runners.ParentRunner.run(ParentRunner.java:300)

at org.junit.runners.Suite.runChild(Suite.java:128)

at org.junit.runners.Suite.runChild(Suite.java:24)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)

at org.junit.runners.ParentRunner.run(ParentRunner.java:300)

at org.junit.runner.JUnitCore.run(JUnitCore.java:157)

at org.junit.runner.JUnitCore.run(JUnitCore.java:136)

at org.junit.runner.JUnitCore.run(JUnitCore.java:127)

at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:51)

at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:108)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)

at com.sun.proxy.$Proxy0.invoke(Unknown Source)

at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)

at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)

at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)

Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1,201,560.811 sec <<< FAILURE!
Running com.izforge.izpack.util.xmlmerge.XmlMergeTest
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.118 sec <<< FAILURE!

Results :

Failed tests:
testIniCommentsAtEnd(com.izforge.izpack.util.config.SingleConfigurableTaskTest): expected:<false> but was:<true>

Tests in error:
testMergeFilesWithXPathTagMatcherReplace2Files(com.izforge.izpack.util.xmlmerge.XmlMergeTest)

Tests run: 22, Failures: 1, Errors: 1, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] IzPack parent ...................................... SUCCESS [ 1.963 s]
[INFO] IzPack native module parent ........................ SUCCESS [ 0.299 s]
[INFO] IzPack native module ............................... SUCCESS [ 0.943 s]
[INFO] IzPack tools module ................................ SUCCESS [ 0.584 s]
[INFO] IzPack api module .................................. SUCCESS [ 2.046 s]
[INFO] IzPack util module ................................. FAILURE [ 23.488 s]
[INFO] IzPack test commons module ......................... SKIPPED
[INFO] IzPack core module ................................. SKIPPED
[INFO] IzPack gui module .................................. SKIPPED
[INFO] IzPack installer module ............................ SKIPPED
[INFO] IzPack panel module ................................ SKIPPED
[INFO] IzPack event module ................................ SKIPPED
[INFO] IzPack uninstaller module .......................... SKIPPED
[INFO] IzPack compiler module ............................. SKIPPED
[INFO] IzPack Maven Plugin ................................ SKIPPED
[INFO] IzPack ant module .................................. SKIPPED
[INFO] IzPack wrapper module .............................. SKIPPED
[INFO] IzPack dist module ................................. SKIPPED
[INFO] IzPack install/uninstall test listeners ............ SKIPPED
[INFO] IzPack test module ................................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 29.957 s
[INFO] Finished at: 2015-02-23T16:40:02-05:00
[INFO] Final Memory: 21M/349M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.7.2:test (default-test) on project izpack-uti
l: There are test failures.
[ERROR]
[ERROR] Please refer to D:\Sumeet\Wawanesa\PRASE Build POC\IzPack\SourceCode\izpack\izpack-util\target\surefire-reports for t
he individual test results.
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin
:2.7.2:test (default-test) on project izpack-util: There are test failures.

Please refer to D:\Sumeet\Wawanesa\PRASE Build POC\IzPack\SourceCode\izpack\izpack-util\target\surefire-reports for the indiv
idual test results.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:
51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures.

Please refer to D:\Sumeet\Wawanesa\PRASE Build POC\IzPack\SourceCode\izpack\izpack-util\target\surefire-reports for the indiv
idual test results.
at org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:74)
at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:642)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :izpack-util
D:\Sumeet\Wawanesa\PRASE Build POC\IzPack\SourceCode\izpack>



 Comments   
Comment by Rene Krell [ 09/Mar/15 ]

Are you able to check whether https://github.com/izpack/izpack/pull/327 fixes this for you?

Comment by S Chaudhari [ 09/Mar/15 ]

Hi Rene,

I am new to git any idea how to pull this https://github.com/izpack/izpack/pull/327 using git clone command.

Regards,
Sumeet

Comment by Rene Krell [ 10/Mar/15 ]

Hi Sumeet, instructions for testing locally can be found by clicking at the details at the end of each PR:
... You can also merge branches on the command line.:
Step 1: From your project repository, check out a new branch and test the changes.

git checkout -b akuhtz-akuhtz-master master
git pull git://github.com/akuhtz/izpack.git akuhtz-master
mvn verify

After testing, you can switch back to master and delete that branch:

git checkout master
git branch -d akuhtz-akuhtz-master
Comment by Rene Krell [ 19/Mar/15 ]

PR #327 merged, which apparently resolves this.
Thank you.





[IZPACK-1223] Installer loads custom classes from <jar> tags before checking a required Java version Created: 19/Feb/15  Updated: 19/Feb/15

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependent
is depended upon by IZPACK-1217 Make IzPack installers more modular -... Open
Number of attachments : 0

 Description   

An IzPack installer loads currently all custom classes in advance before checking the Java version defined by the optional tag like this:

<javaversion>1.7</javaversion>

For example, if the installer is launched in JRE 6, but some libraries imported by <jar> are compiled using JDK 7 the installer fails on starting with the following stacktrace:

Nov 11, 2014 3:59:31 PM INFO: Logging initialized at level 'INFO'
Nov 11, 2014 3:59:31 PM INFO: Commandline arguments:
Nov 11, 2014 3:59:32 PM INFO: Detected platform: windows,version=6.2,arch=x64,sy
mbolicName=WINDOWS_8,javaVersion=1.6.0_37
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/github/sa
rdine/Sardine : Unsupported major.minor version 51.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(Unknown Source)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$000(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
        at java.lang.Class.getDeclaredConstructors(Unknown Source)
        at org.picocontainer.injectors.ConstructorInjector$3.run(ConstructorInjector.java:409)
        at org.picocontainer.injectors.ConstructorInjector$3.run(ConstructorInjector.java:407)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.picocontainer.injectors.ConstructorInjector.getConstructors(ConstructorInjector.java:407)
        at org.picocontainer.injectors.ConstructorInjector.getSortedMatchingConstructors(ConstructorInjector.java:383)
        at org.picocontainer.injectors.ConstructorInjector.getGreediestSatisfiableConstructor(ConstructorInjector.java:134)
        at org.picocontainer.injectors.ConstructorInjector.getGreediestSatisfiableConstructor(ConstructorInjector.java:112)
        at org.picocontainer.injectors.ConstructorInjector.access$100(ConstructorInjector.java:52)
        at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:337)
        at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:272)
        at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:370)
        at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
        at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
        at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:646)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:671)
        at com.izforge.izpack.core.container.AbstractContainer.getComponent(AbstractContainer.java:131)
        at com.izforge.izpack.core.factory.DefaultObjectFactory.create(DefaultObjectFactory.java:74)
        at com.izforge.izpack.core.factory.DefaultObjectFactory.create(DefaultObjectactory.java:102)
        at com.izforge.izpack.installer.container.impl.CustomDataLoader.addInstallerListener(CustomDataLoader.java:141)
        at com.izforge.izpack.installer.container.impl.CustomDataLoader.loadCustomData(CustomDataLoader.java:116)
        at com.izforge.izpack.installer.container.impl.InstallerContainer.resolveComponents(InstallerContainer.java:145)
        at com.izforge.izpack.installer.container.impl.GUIInstallerContainer.resolveComponents(GUIInstallerContainer.java:94)
        at com.izforge.izpack.installer.container.impl.InstallerContainer.fillContainer(InstallerContainer.java:79)
        at com.izforge.izpack.core.container.AbstractContainer.initialise(AbstractContainer.java:303)
        at com.izforge.izpack.core.container.AbstractContainer.initialise(AbstractContainer.java:283)
        at com.izforge.izpack.installer.container.impl.GUIInstallerContainer.<init>(GUIInstallerContainer.java:44)
        at com.izforge.izpack.installer.bootstrap.InstallerGui.run(InstallerGui.java:43)
        at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:21)
        at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:193)
        at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:72)

This happens apparently before the <javaversion> tag is evaluated and therefore doesn't lead to a "controlled" stopping of the installer with a reasonable user dialog informing the user about a mismatching.Java version.



 Comments   
Comment by Rene Krell [ 19/Feb/15 ]

An OSGI framework for all custom features (listeners) could solve this problem by automatically isolate the classloaders.
Custom classes should be loaded on demand instead at installer start time.

I added an appropriate linke, nevertheless it is possible to remove it in case one comes with a different approach of implementation for this particular problem.





[IZPACK-1222] Some text is hardcoded in english in console classes Created: 18/Feb/15  Updated: 19/Mar/15  Resolved: 19/Mar/15

Status: Resolved
Project: IzPack
Component/s: Translations
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Aitor Sánchez Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to IZPACK-1206 PacksConsolePanel does auto-select an... Resolved
is related to IZPACK-1232 PacksConsolePanel prints the id of th... Resolved
Number of attachments : 0

 Description   

Using the application in console mode and with Spanish as language, I have realized that some text and labels have been set in English hardcoded.

For example, I have found
1.
class "TargetConsolePanel"
method "public boolean run(InstallData installData, Console console)"
text: "Select target path ["

2.
class "ConsoleChoiceField"
method "public boolean More ...display()"
text: "input selection: "

I don't know if it could be more text hardcoded like that. I have found this ones at the moment.



 Comments   
Comment by Aitor Sánchez [ 18/Feb/15 ]

Some more:

class "PacksConsolePanel"
text: This static variables are prompt without translation
private static final String REQUIRED = "required";
private static final String NOT_SELECTED = "Not Selected";
private static final String ALREADY_SELECTED = "Already Selected";
private static final String DONE = "Done!";
private static final String SPACE = " ";

Comment by Aitor Sánchez [ 12/Mar/15 ]

Hi!,

It seems like the last comment is now out of date. This class has been changing and now the statics does not exist, but the text is used hardcoded too in the code.

This has been solved in the other console implementation TreePacksConsolePanel, that used localized messages and localized pack names. It is related with the other issue: IZPACK-1232 http://jira.codehaus.org/browse/IZPACK-1232

Comment by Aitor Sánchez [ 17/Mar/15 ]

Solved in Pull request: https://github.com/izpack/izpack/pull/332

Add the localization support for some text hardcoded in the code (console classes).
1.
class "TargetConsolePanel"
method "public boolean run(InstallData installData, Console console)"
text: "Select target path ["
2.
class "ConsoleChoiceField"
method "public boolean More ...display()"
text: "input selection: "

Comment by Rene Krell [ 19/Mar/15 ]

PR #332 merged.
Thank you.





[IZPACK-1221] Introduce XML patching using (Maven) Config Processor Created: 16/Feb/15  Updated: 16/Feb/15

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: None
Fix Version/s: 5.1

Type: New Feature Priority: Major
Reporter: Rene Krell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This feature is inspired by the useful utility Maven Config Processor Plugin:

The above utility allows to modify properties and xml files by removing, modifying or adding elements based on transformation rules defined in XML and especially for XML patching using XPath expressions.

The tool is very sophisticated and could be integrated as optional feature / listener to IzPack, as a complement to the ConfigurationInstallerListener. In comparison to the Config Processor the latter one does a just three-way merge of files directly using rules for patching, which is a different use case.






[IZPACK-1220] AntActionsInstallerListener: Add Ant task for to open messageboxes and wait for confirming them Created: 09/Feb/15  Updated: 16/Mar/15

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.1

Type: Improvement Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to IZPACK-1231 AntActionsInstallerListener: Improve ... Resolved
Number of attachments : 0

 Description   

There should be a possibility to interrupt a running target and waiting for a user response.
This could be achieved by a special Ant task utilizing IzPack messageboxes (error, warning, information).
Translating error messages should be possible from this task.
There might be also the possibility to retry a certain block of Ant code if the user wishes it.






[IZPACK-1219] Allow installer to expire on specified date Created: 06/Feb/15  Updated: 16/Feb/15  Resolved: 16/Feb/15

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: New Feature Priority: Minor
Reporter: Bill Root Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Some installers – such as those for alpha, beta, or test versions of a product – need to expire to prevent use after a given date. While the installed program can (and should) time out, it would be frustrating and bad form to let a user install an expired program.

This can be implemented as an optional variable:

<variables>
...
<!-- Make the installer expire -->
<variable name="InstallerExpiresDate" value="2016-01-01" />
...
</variables>



 Comments   
Comment by Rene Krell [ 06/Feb/15 ]

Pull request: https://github.com/izpack/izpack/pull/312

Comment by Rene Krell [ 06/Feb/15 ]

Just from my intuition - wouldn't it be more convenient to define an additional optional element in the <info> section instead of forciblz reserving a variable for this? This would fit more to the other checks, wouldn't it?

Comment by Bill Root [ 08/Feb/15 ]

It would certainly be more consistent with the other checks, and I'm making the change. I can see that it would also be more convenient in that date format errors can be shown during installer compilation.

Comment by Rene Krell [ 09/Feb/15 ]

Thanks, you can refresh the existing pull request if you want on the same branch where you created it from.

Comment by Bill Root [ 09/Feb/15 ]

I pushed my variable -> info changes to my github fork. From what I read, the changes should automatically be included in the pull request.

I updated the Dynamic+Installer+Requirements doc page. Should I move the <expiresdate> text to the <info> page, or just add it there?

Comment by Rene Krell [ 09/Feb/15 ]

Did you really push or just commit it to optotronic:expired-checker - https://github.com/optotronic/izpack/commits/expired-checker ?
I cannot actually see any changes here.
I you push it to the same branch like the original pull request it usually updates the pull request automatically, that's true.

Comment by Bill Root [ 09/Feb/15 ]

Wrong branch, sorry. You should be able to see it now?

Comment by Rene Krell [ 09/Feb/15 ]

Yeah, now the pull request seems to be refreshed. I'll check this soon. Thank you, Bill!

Comment by Rene Krell [ 16/Feb/15 ]

Merged pull request.
Thank you.





[IZPACK-1218] Dynamic variables: escape="false" ignored for reading values from configuration files Created: 05/Feb/15  Updated: 05/Feb/15  Resolved: 05/Feb/15

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Assuming the following configuration file wrapper.conf:

wrapper.java.command=C:\Program Files\Java\jdk1.7.0_51\bin\java

and the following dynamic variable definition:

<variable name="java.cmd" type="options" escape="false" ignorefailure="true" file="${INSTALL_PATH}/bin/wrapper.conf" key="wrapper.java.command">
  <filters>
    <regex regexp="[/\\]+" replace="/" global="true" />
  </filters>
</variable>

After refreshing. the variable java.cmd should have been evaluated to C:/Program Files/Java/jdk1.7.0_51/bin/java.
Actually It contains C:Program FilesJavajdk1.7.0_51/bin/java.

This happens just for reading values from files, plain values with backslashes work as expected.



 Comments   
Comment by Rene Krell [ 05/Feb/15 ]

Pull request: https://github.com/izpack/izpack/pull/313 - merged.





[IZPACK-1217] Make IzPack installers more modular - add feature interface Created: 02/Feb/15  Updated: 19/Feb/15

Status: Open
Project: IzPack
Component/s: Compiler, Documentation, Installer
Affects Version/s: None
Fix Version/s: 5.1

Type: New Feature Priority: Critical
Reporter: Rene Krell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
supercedes IZPACK-118 Support for variable substitution ins... Reopened
dependent
depends upon IZPACK-1223 Installer loads custom classes from <... Open
Number of attachments : 0

 Description   

We need an approach to decrease the installer size depending on the user's needs and at the same time offer an approach how to add and isolate features which need additional external libraries or other resources. In the past, there have been often blocked good ideas because they would introduce overhead and increase the installer size for all users, not just for those using that idea.

The best way we currently offer are listeners, but they don't separate resources and external libraries. For instance, the ConfigurationInstallerListener for merging configuration files needs to define:

  • the listener in the <listeners> section
  • the resource "ConfigurationActionsSpec.xml" in the <resources> section
  • jdom2.jar, jaxen.jar etc. as <jar> elements
  • mapping/renaming of configuration files when overwriting, for example to *.configbak

The above items could be ideally added as feature, maybe having its descriptor or even source code (Maven module) completely separated.
The IzPack "feature" discussed here should completely replace old-style listeners. All listeners should be written as features and assembled separately, not in the basic elements of install.xml (resources, jar, listeners, packs, ...).

A feature should be defined as one block of XML in install.xml and might consist of:

  • a name
  • an optional set of jar files additionally needed at runtime
  • a optional set of orther binary or text resources additionally needed at runtime
  • additional translations
  • a set of panel implementations
  • prerequisites which might have been check at install time (OS, architecture, JRE, ...)
  • ...

The implementation should then plug into a given API which is still to define. Plugin points could be:

  • execution beforepacks (before any pack is installed)
  • execution beforepack (immediately before files of a certain pack are installed)
  • execution afterpacks after all pack is installed)
  • execution afterpack (immediately after file of a certain pack are installed)
  • execution beforefile (before a file is installed)
  • execution afterfile (after a file has been installed)
  • mapping of file names for installed files
  • the progress bar
  • logging
  • ...

This API should be versioned and stable within one and the same version. An API version might have prerequisites, like the minimum JDK/JRE version supported, increasing the minimum required JDK should increase the API version.
Another consideration is giving features an own classloader, containing the IzPack plus its additional classpath. This feature classpath will not be available in the rest of the IzPack code. This way there can be ensured using of one and the same fully qualified classnames, but with different meaning or different versions between two different features.
There should be a set of standard features available for IzPack built along with IzPack itself

This issue is still an open discussion.
The main goals are clear:

  • make the resulting installers contain exactly what the user needs, without megabytes of overhead
  • make definitions in install.xml more transparent - divide the knowledges between assembling a feature (feature developer) and using a feature.


 Comments   
Comment by Rene Krell [ 02/Feb/15 ]

I'm thinking about a small-sized OSGI framework fulfilling many of the above points.
I wonder how to minimize the footprint in file size of the resulting installer, or whether this would significantly reduce existing code, because frameworks like Felix or Equinox take about 1,2 MB of extra space. Knopflerfish is quite small, I'm not sure, whether its license is compatible, but it seems so.

Nevertheless, using OSGI we might for example opt out all the listeners which are deployed within the compiled installer jar by default. This would also easily solve the problem of how to make logging universal - instead of using a pre-defined framework for logging, logging can be added as a special log service (feature).

Any ideas?





[IZPACK-1216] Dynamic Variables with conditions depending on a dynamic variable Created: 02/Feb/15  Updated: 02/Feb/15  Resolved: 02/Feb/15

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File installer.xml     Java Archive File test-IZPACK-1216-5.0.0-rc4.jar     Java Archive File test-IZPACK-1216-5.0.0-rc5-SNAPSHOT-with-IZPACK1215.jar     Java Archive File test-IZPACK-1216-5.0.0-rc5-SNAPSHOT-with-IZPACK1216.jar    
Issue Links:
Supercedes
is superceded by IZPACK-1182 Evaluation of dynamic variables, whic... Resolved
Testcase included: yes
Number of attachments : 4

 Description   

When using dynamic variables with a condition, which depends on a dependent dynamic variable the refresh() loop is terminated to early since IZPACK-1213.

<dynamicvariables>
  <variable name="var1" value="1" checkonce="true" />
  <variable name="var1" value="2" checkonce="true" condition="cond1"/>
  <variable name="var2" value="${var1}" />
  <variable name="var3" value="${var2}" />
  <variable name="var4" value="${var3}" />
  <variable name="var5" value="${var4}" />
</dynamicvariables>

<conditions>
  <condition id="cond1" type="variable"> <name>var5</name> <value>1</value> </condition>
</conditions>


 Comments   
Comment by Tom Helpstone [ 02/Feb/15 ]

uploaded a test-installer based on different versions of izpack:


installer.xml – the definition of the installer


test-IZPACK-1216-5.0.0-rc4.jar --Test installer based on IzPack-5.0.0-rc4

As expected the refresh() does terminate, but the value of var5 is stable not before the second DataCheckPanel.


test-IZPACK-1216-5.0.0-rc5-SNAPSHOT-with-IZPACK1215.jar

The refresh() does terminate with a loop detection
-> limit for loop has to be increased

Comment by Tom Helpstone [ 02/Feb/15 ]

test-IZPACK-1216-5.0.0-rc5-SNAPSHOT-with-IZPACK1216.jar

The variable var5 gets the correct value "2" on the first DataCheckPanel already

Comment by Tom Helpstone [ 02/Feb/15 ]

Sent pull request 310

Comment by Rene Krell [ 02/Feb/15 ]

Pull request merged.





[IZPACK-1215] cyclic reference does produce a loop Created: 31/Jan/15  Updated: 17/Apr/15  Resolved: 02/Feb/15

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Archive File InstallerTest-before-IZPACK-1215.jar     Java Archive File InstallerTest-with-IZPACK-1215.jar     XML File installer.xml    
Issue Links:
Supercedes
is superceded by IZPACK-1182 Evaluation of dynamic variables, whic... Resolved
Testcase included: yes
Number of attachments : 3

 Description   

A cyclic reference like

<dynamicvariables>
  <variable name="a" value="${b}" />
  <variable name="b" value="${a}" />
</dynamicvariables>

produce a loop (at least since inclusion of IZPACK-1182).

The cyclic reference is not a valid definition of course, but the installer should detect and report the loop.



 Comments   
Comment by Tom Helpstone [ 01/Feb/15 ]

installer.xml does produce a loop during refresh of dynamic variables because of a cyclic definition

  <dynamicvariables>
    <variable name="a" value="${b}" />
    <variable name="b" value="${a}" />
  </dynamicvariables>

The Installer InstallerTest-before-IZPACK-1215.jar demonstrates this loop.

After Implementing IZPACK-1215, the loop is ended with a appropriate message:
com.izforge.izpack.api.exception.InstallerException: Refresh of dynamic variables seem to produce a loop. Stopped after 4 iterations. (Maybe a cyclic dependency of variables?)
See InstallerTest-with-IZPACK-1215.jar

Comment by Tom Helpstone [ 01/Feb/15 ]

sent Pull Request 309

Comment by Rene Krell [ 02/Feb/15 ]

Thanks





[IZPACK-1214] File/Dir fields with property readonly=true problems in Console mode Created: 30/Jan/15  Updated: 30/Jan/15  Resolved: 30/Jan/15

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Ahmed Abu Lawi Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to IZPACK-1195 Improve and enhance displaying of rea... Resolved
Number of attachments : 0

 Description   

Fields that inherit from AbstractConsoleFileField with read readonly=true will cause the console panel to rerun when it shouldn't.



 Comments   
Comment by Ahmed Abu Lawi [ 30/Jan/15 ]

PR sent https://github.com/izpack/izpack/pull/308

Comment by Rene Krell [ 30/Jan/15 ]

Pull request #308 merged.
Thank you for contributing.





[IZPACK-1213] DynamicVars with Checkonce and different conditions do not work Created: 28/Jan/15  Updated: 29/Jan/15  Resolved: 29/Jan/15

Status: Resolved
Project: IzPack
Component/s: None
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Tom Helpstone Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Using dynamic variables with the same name but different conditions like the following example from http://docs.codehaus.org/display/IZPACK/Lifecycle+of+dynamic+variables does not work

<dynamicvariables>
<variable name="thechoice" value="fallback value">
<variable name="thechoice" value="choice1" condition="cond1">
<variable name="thechoice" value="choice2" condition="cond2">
</dynamicvariables>

I would expect the "fallback value" only then, when neither cond1 nor cond2 is true. As soon as one of the conditions is set, the value should change.



 Comments   
Comment by Tom Helpstone [ 29/Jan/15 ]

Did not realize, that ordering of variables is important. So my Unit-Test was wrong
-> Closing this issue

Comment by Tom Helpstone [ 29/Jan/15 ]

Did not realize, that ordering of variables is important. So my Unit-Test was wrong.





[IZPACK-1212] UserInputPanel: Radio defaults apply just for the first radio field on one and the same panel Created: 23/Jan/15  Updated: 27/Jan/15  Resolved: 27/Jan/15

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Supposed there is the following installer defined:
userInputSpec.xml:

<izpack:userinput version="5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:izpack="http://izpack.org/schema/userinput" xsi:schemaLocation="http://izpack.org/schema/userinput http://izpack.org/schema/5.0/izpack-userinput-5.0.xsd">

  <panel id="panel.test">
    <field type="title" txt="Test panel" id="text.test.title" />
    <field type="radio" variable="dbsystem">
      <spec txt="with set">
        <choice txt="MSSQL" value="mssql" id="text.dbsystem.mssql" />
    <choice txt="Oracle" value="oracle" id="text.dbsystem.oracle" set="true" />
    <choice txt="SAP Hana" value="hdb" id="text.dbsystem.hana" />
      </spec>
    </field>
    <field type="divider"/>
    <field type="radio" variable="dbsystem2">
      <spec txt="with default">
    <choice txt="MSSQL" value="mssql" id="text.dbsystem.mssql" />
    <choice txt="Oracle" value="oracle" id="text.dbsystem.oracle" default="true" />
    <choice txt="SAP Hana" value="hdb" id="text.dbsystem.hana" />
      </spec>
    </field>
    <field type="divider"/>
    <field type="radio" variable="dbsystem3">
      <spec txt="just relying on variable">
        <choice txt="MSSQL" value="mssql" id="text.dbsystem.mssql" />
        <choice txt="Oracle" value="oracle" id="text.dbsystem.oracle" />
        <choice txt="SAP Hana" value="hdb" id="text.dbsystem.hana" />
      </spec>
    </field>
  </panel>

</izpack:userinput>

install.xml

  ...
  <conditions>
    <condition type="exists" id="haveInstallPath">
      <variable>INSTALL_PATH</variable>
    </condition>
  </conditions>
  ....
  <dynamicvariables>
    <variable name="dbsystem" value="mssql" condition="!haveInstallPath"/>
    <variable name="dbsystem" value="hdb" condition="haveInstallPath"/>
    <variable name="dbsystem2" value="mssql" condition="!haveInstallPath"/>
    <variable name="dbsystem2" value="hdb" condition="haveInstallPath"/>
    <variable name="dbsystem3" value="mssql" condition="!haveInstallPath"/>
    <variable name="dbsystem3" value="hdb" condition="haveInstallPath"/>
  </dynamicvariables>
  ....
  <panels>
    <panel classname="TargetPanel" id="panel.target"/>
    <panel classname="UserInputPanel" id="panel.test"/>
    <panel classname="InstallPanel"/>
  </panels>
  ...

There are always working the defaults just for the first of the radio fields, not for the subsequent fields, regardless if the default should come from the variable value itself or from the set/default attributes of each choice.



 Comments   
Comment by Rene Krell [ 26/Jan/15 ]

Created pull request https://github.com/izpack/izpack/pull/305 with a fix.

Comment by Rene Krell [ 27/Jan/15 ]

Pull request merged.





[IZPACK-1211] UserInputPanel: Missing variable resolution in attribute <field><spec text="..."/><field> including the according translations Created: 22/Jan/15  Updated: 24/Feb/15  Resolved: 24/Feb/15

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Provided there is a panel specification in userInputSpec.xml like this:

<panel id="panel.test">
    <field type="title" txt="Test panel" id="text.test.title" />
    <field type="staticText" align="left" txt="${INSTALL_PATH}${FILE_SEPARATOR}${application.folder}" />
    <field type="text" variable="targetsettings.target">
    <spec txt="Target directory: ${INSTALL_PATH}${FILE_SEPARATOR}" id="text.targetsettings.target" size="20" set="${application.folder}" />
         <validator class="com.izforge.izpack.panels.userinput.validator.NotEmptyValidator" txt="Target directory path is mandatory!" id="text.targetsettings.target.error" />
    </field>
</panel>

and a <panel> section in install.xml like this

<panels>
    <panel classname="TargetPanel" id="panel.target"/>
    <panel classname="UserInputPanel" id="panel.test"/>
    ...
</panels>

there doesn't happen any variable resolution for the txt="Target directory: ${INSTALL_PATH}${FILE_SEPARATOR}" attribute value including its translations although the according variables are set.

Should be translated here to make variable replacement consistent everywhere.



 Comments   
Comment by Rene Krell [ 22/Jan/15 ]

Created pull request: https://github.com/izpack/izpack/pull/304

It should solve this problem in common. All static text fields of Swing installers are translated on panel activation now by default, without forcing the developer to override this in the according field implementation explicitly. This way there are also other fields fixed that were affected by this, for instance rule fields.
Most GUI fields have at least one label by default, which can be specified in <spec/>.

Comment by Rene Krell [ 22/Jan/15 ]

Merged pull request.

Comment by Rene Krell [ 24/Feb/15 ]

Added another pull request with a post-fix:
https://github.com/izpack/izpack/pull/321

Comment by Rene Krell [ 24/Feb/15 ]

Pull request #321 merged





[IZPACK-1210] IzPack cannot build with JDK 8 Created: 17/Jan/15  Updated: 19/Jan/15  Resolved: 19/Jan/15

Status: Resolved
Project: IzPack
Component/s: Build
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Thomas Hauser Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Fedora 21
openjdk version "1.8.0_25"
OpenJDK Runtime Environment (build 1.8.0_25-b18)
OpenJDK 64-Bit Server VM (build 25.25-b02, mixed mode)


Number of attachments : 0

 Description   

Attempting to build izpack from master results in the following errors:
[ERROR] /home/thauser/community/izpack/izpack-util/src/main/java/com/izforge/izpack/util/config/base/BasicProfile.java:[159,29] remove(java.lang.Object,java.lang.Object) in com.izforge.izpack.util.config.base.BasicProfile cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.String is not compatible with boolean
[ERROR] /home/thauser/community/izpack/izpack-util/src/main/java/com/izforge/izpack/util/config/base/BasicRegistry.java:[28,8] remove(java.lang.Object,java.lang.Object) in com.izforge.izpack.util.config.base.BasicProfile cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.String is not compatible with boolean
[ERROR] /home/thauser/community/izpack/izpack-util/src/main/java/com/izforge/izpack/util/config/base/Profile.java:[59,12] remove(java.lang.Object,java.lang.Object) in com.izforge.izpack.util.config.base.Profile clashes with remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.String is not compatible with boolean
[ERROR] /home/thauser/community/izpack/izpack-util/src/main/java/com/izforge/izpack/util/config/base/Ini.java:[32,8] remove(java.lang.Object,java.lang.Object) in com.izforge.izpack.util.config.base.BasicProfile cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.String is not compatible with boolean
[ERROR] /home/thauser/community/izpack/izpack-util/src/main/java/com/izforge/izpack/util/config/base/Reg.java:[32,8] remove(java.lang.Object,java.lang.Object) in com.izforge.izpack.util.config.base.BasicProfile cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.String is not compatible with boolean
[ERROR] /home/thauser/community/izpack/izpack-util/src/main/java/com/izforge/izpack/util/config/base/Wini.java:[32,8] remove(java.lang.Object,java.lang.Object) in com.izforge.izpack.util.config.base.BasicProfile cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.String is not compatible with boolean
[ERROR] /home/thauser/community/izpack/izpack-util/src/main/java/com/izforge/izpack/util/config/base/ConfigParser.java:[410,12] remove(java.lang.Object,java.lang.Object) in com.izforge.izpack.util.config.base.BasicProfile cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.String is not compatible with boolean

This is caused by a new method in the Map interface in Java 8, which has the same method signature as the remove(Object,Object) in Profile except that it returns a boolean.



 Comments   
Comment by Thomas Hauser [ 17/Jan/15 ]

Link to new method:

http://docs.oracle.com/javase/8/docs/api/java/util/Map.html#remove-java.lang.Object-java.lang.Object-

Comment by Rene Krell [ 19/Jan/15 ]

Pull request https://github.com/izpack/izpack/pull/302 merged.
Thank you.





[IZPACK-1209] Would like to contribute Created: 06/Jan/15  Updated: 06/Jan/15  Resolved: 06/Jan/15

Status: Closed
Project: IzPack
Component/s: Documentation
Affects Version/s: 5.0
Fix Version/s: None

Type: Wish Priority: Trivial
Reporter: Christophe Marteau Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: documentation
Remaining Estimate: 15 minutes
Time Spent: Not Specified
Original Estimate: 15 minutes

Number of attachments : 0

 Description   

Hi,

I Would like to contribute to the documentation because I'm using izpack and i notice errors in documentation. I dont known how to get a wiki account.

Sorry for my english.

Errors found :

http://docs.codehaus.org/display/IZPACK/Windows+Registry+Access and
http://docs.codehaus.org/pages/viewpage.action?pageId=230398039 :

The end tag "natives" miss "/"

http://docs.codehaus.org/pages/viewpage.action?pageId=230398039 :

The correct call to the listener seems to be :
<listeners>
<listener classname="RegistryInstallerListener" stage="install" >
<os family="windows"/>
</listener>
<listener classname="RegistryUninstallerListener" stage="uninstall" >
<os family="windows"/>
</listener>
</listeners>



 Comments   
Comment by Rene Krell [ 06/Jan/15 ]

Thank you.
Please do not raise issues for documentation-only fixes.

Register a Codehause Xircles and edit it straight-forward.





[IZPACK-1208] Enhance panel configuration options (syntax, add conditions) Created: 19/Dec/14  Updated: 21/Dec/14  Resolved: 21/Dec/14

Status: Resolved
Project: IzPack
Component/s: Documentation, Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In future, it should be possible to define panel configuration entries using the element name as the option name directly, similar to Maven.

Additionally there should be used optional conditions which must evaluate true before the given value applies.

The old syntax <param name="..." value="..." /> will be preserved for compatibility reasons to not break older environments, but I will recommend to use the newer one.

Example:

<panel classname="TargetPanel" id="panel.target">
  <configuration>
    <!-- Don't show warning if target directory already exists -->
    <param name="ShowExistingDirectoryWarning" value="false" />
  </configuration>
</panel>

should be written now:

<panel classname="TargetPanel" id="panel.target">
  <configuration>
    <!-- Don't show warning if target directory already exists -->
    <ShowExistingDirectoryWarning>false</ShowExistingDirectoryWarning>
  </configuration>
</panel>

which can be enhanced by a condition:

<panel classname="TargetPanel" id="panel.target">
  <configuration>
    <!-- Don't show warning if target directory already exists -->
    <ShowExistingDirectoryWarning condition="isUninstaller|isUpdate">false</ShowExistingDirectoryWarning>
  </configuration>
</panel>


 Comments   
Comment by Rene Krell [ 19/Dec/14 ]

Pull request for a couple of issues: https://github.com/izpack/izpack/pull/300

Comment by Rene Krell [ 21/Dec/14 ]

Pull request merged





[IZPACK-1207] Make TargetPanel.warn ("The directory already exists! Are you sure you want to install here and possibly overwrite existing files?") message optional Created: 18/Dec/14  Updated: 22/Dec/14  Resolved: 22/Dec/14

Status: Resolved
Project: IzPack
Component/s: Documentation, Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

On TargetPanel, there is a message TargetPanel.warn ("The directory already exists! Are you sure you want to install here and possibly overwrite existing files?") shown uncondtionally.

This might be inconvenient if you want to provide an update installer, which counts with existing files in the target directory.

An option would be needed for being able to deactivate this warning and continue wit the installation.

Note:
There is already a optional ShowCreateDirectoryMessage boolean IzPack variable used for controlling a similar warning whether the target directory should be created if it doesn't exist. This approach might be enough for now.



 Comments   
Comment by Rene Krell [ 19/Dec/14 ]

Pull request for a couple of issues: https://github.com/izpack/izpack/pull/300

Comment by Rene Krell [ 22/Dec/14 ]

Pull request merged





[IZPACK-1206] PacksConsolePanel does auto-select and skip conditioned packs if the conditions evaluate true Created: 18/Dec/14  Updated: 19/Mar/15  Resolved: 22/Dec/14

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to IZPACK-1222 Some text is hardcoded in english in ... Resolved
relates to IZPACK-1232 PacksConsolePanel prints the id of th... Resolved
Number of attachments : 0

 Description   

Currently, if there is a pack definition like this:

<packs>
    <pack name="Templates" required="no" id="pack.templates" condition="withTemplates">
      <description>Templates</description>
      <fileset dir="@{izpack.staging.directory}/templates" />
    </pack>
    ...
</packs>

if the pack condition withTemplates evaluates true, the pack is just selected and a user change is skipped in a console mode installation.
This behavior is different from the established behavior in the GUI PacksPanel, like described more detailled recently in http://docs.codehaus.org/display/IZPACK/Packs.

The PacksConsolePanel should use the same logic for the condition and required attributes like the PacksPanel.



 Comments   
Comment by Rene Krell [ 18/Dec/14 ]

Sent pull request https://github.com/izpack/izpack/pull/299

Comment by Rene Krell [ 22/Dec/14 ]

Pull request merged





[IZPACK-1205] UserInputPanel: displayHidden and readonly attribute flaws Created: 15/Dec/14  Updated: 30/Jan/15  Resolved: 16/Dec/14

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to IZPACK-1195 Improve and enhance displaying of rea... Resolved
Supercedes
is superceded by IZPACK-1204 UserInputPanel bug fixing sprint Resolved
Number of attachments : 0

 Description   

Read-only fields on UserInputPanel does still not work as designed and described in http://docs.codehaus.org/display/IZPACK/Displaying+panels+and+fields+read-only.

Especially overriding these attributes on panel level for all single panel fields not defining the same attribute and override the panel attribute value on field level had the wrong behavior.

The GUI as well as console installer mode is affected by these problems in a different manner.



 Comments   
Comment by Rene Krell [ 16/Dec/14 ]

Fixed by merging pull request: https://github.com/izpack/izpack/pull/296





[IZPACK-1204] UserInputPanel bug fixing sprint Created: 15/Dec/14  Updated: 16/Dec/14  Resolved: 16/Dec/14

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Task Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
supercedes IZPACK-1203 UserInputPanel choice fields (radio, ... Resolved
supercedes IZPACK-1205 UserInputPanel: displayHidden and rea... Resolved
Number of attachments : 0

 Description   

There is a couple of bug fixes and improvements to implement in UserInputPanel towards to 5.0. They are added as subissues.



 Comments   
Comment by Rene Krell [ 15/Dec/14 ]

Sent pull request with fixes: https://github.com/izpack/izpack/pull/296

Comment by Rene Krell [ 16/Dec/14 ]

Pull request merged.





[IZPACK-1203] UserInputPanel choice fields (radio, combo) with conditions on each don't use current condition state Created: 15/Dec/14  Updated: 16/Dec/14  Resolved: 16/Dec/14

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by IZPACK-1204 UserInputPanel bug fixing sprint Resolved
Number of attachments : 0

 Description   

On the panel

  <panel id="panel.dboperation" summaryKey="key.dboperation.title">
    <field type="title" txt="Database operation selection" id="text.dboperation.title" />
    <field type="staticText" align="left" txt="Choose the preferred database action:" id="text.dboperation.description" />
    <field type="space" />
    <field type="radio" variable="db.operation" summaryKey="key.dboperation">
      <spec>
        <choice txt="Build instance as administrator" value="create_instance" id="text.dboperation.create_instance" conditionid="Install"/>
        <choice txt="Rebuild instance as administrator" value="recreate_instance" id="text.dboperation.recreate_instance" conditionid="Install"/>
        <choice txt="Build structure as existing user" value="create_structure" id="text.dboperation.create_structure" conditionid="Install"/>
        <choice txt="Rebuild structure as existing user" value="recreate_structure" id="text.dboperation.recreate_structure" conditionid="Install"/>
        <choice txt="Don't touch, already manually installed" value="create_none" id="text.dboperation.create_none" conditionid="Install"/>
        <choice txt="Update existing instance as administrator" value="update_instance" id="text.dboperation.update" conditionid="Update"/>
        <choice txt="Update existing structure as existing user" value="update_structure" id="text.dboperation.update" conditionid="Update"/>
        <choice txt="Don't touch, already manually updated" value="update_none" id="text.dboperation.update_none" conditionid="Update"/>
        <choice txt="Drop instance as administrator" value="drop_instance" id="text.dboperation.drop_instance" conditionid="Uninstall"/>
        <choice txt="Drop structure as existing user" value="drop_structure" id="text.dboperation.drop_structure" conditionid="Uninstall"/>
        <choice txt="Don't touch, drop manually later" value="drop_none" id="text.dboperation.drop_none" conditionid="Uninstall"/>
      </spec>
    </field>
  </panel>

There don't work the single choice conditions correctly. Actually their conditions are evaluated just on installer start, the state of the choice conditions when the panel gets really activated is ignored.

The <choice ... conditionid="..." /> attribute was initially meant to hide the appropriate choice when the condition is not met when the panel get activated, before laying out the panel.



 Comments   
Comment by Rene Krell [ 16/Dec/14 ]

Fixed by merging pull request: https://github.com/izpack/izpack/pull/296





[IZPACK-1202] NPE in AndCondition due to a bad condition definition Created: 06/Dec/14  Updated: 05/Feb/15  Resolved: 05/Feb/15

Status: Resolved
Project: IzPack
Component/s: Compiler
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

A wrong variable definition:

<condition type="and" id="withInfoChannelSupport">
  <name>withInfoChannelSupport</name>
  <value>false</value>
</condition>

leads to the following NPE during the installer execution:

Dec 6, 2014 2:08:52 AM SEVERE: java.lang.NullPointerException
com.izforge.izpack.api.exception.ContainerException: java.lang.NullPointerException
        at com.izforge.izpack.core.container.AbstractContainer.initialise(AbstractContainer.java:311)
        at com.izforge.izpack.core.container.AbstractContainer.initialise(AbstractContainer.java:283)
        at com.izforge.izpack.installer.container.impl.GUIInstallerContainer.<init>(GUIInstallerContainer.java:44)
        at com.izforge.izpack.installer.bootstrap.InstallerGui.run(InstallerGui.java:43)
        at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:217)
        at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:193)
        at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:72)
Caused by: java.lang.NullPointerException
        at com.izforge.izpack.core.rules.logic.AndCondition.isTrue(AndCondition.java:64)
        at com.izforge.izpack.core.rules.logic.AndCondition.isTrue(AndCondition.java:64)
        at com.izforge.izpack.core.rules.RulesEngineImpl.isConditionTrue(RulesEngineImpl.java:339)
        at com.izforge.izpack.core.rules.RulesEngineImpl.isConditionTrue(RulesEngineImpl.java:326)
        at com.izforge.izpack.core.data.DefaultVariables.refresh(DefaultVariables.java:323)
        at com.izforge.izpack.api.data.AutomatedInstallData.refreshVariables(AutomatedInstallData.java:229)
        at com.izforge.izpack.installer.panel.AbstractPanelView.canShow(AbstractPanelView.java:271)
        at com.izforge.izpack.installer.panel.AbstractPanels.canShow(AbstractPanels.java:594)
        at com.izforge.izpack.installer.panel.AbstractPanels.getNext(AbstractPanels.java:338)
        at com.izforge.izpack.installer.panel.AbstractPanels.getNext(AbstractPanels.java:357)
        at com.izforge.izpack.installer.gui.DefaultNavigator.configureVisibility(DefaultNavigator.java:476)
        at com.izforge.izpack.installer.gui.DefaultNavigator.<init>(DefaultNavigator.java:113)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
        at java.lang.reflect.Constructor.newInstance(Unknown Source)
        at org.picocontainer.injectors.AbstractInjector.newInstance(AbstractInjector.java:147)
        at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:348)
        at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:272)
        at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:370)
        at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
        at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
        at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:646)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:632)
        at org.picocontainer.parameters.BasicComponentParameter$1.resolveInstance(BasicComponentParameter.java:105)
        at org.picocontainer.parameters.ComponentParameter$1.resolveInstance(ComponentParameter.java:136)
        at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:75)
        at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:315)
        at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:341)
        at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:272)
        at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:370)
        at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
        at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
        at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:646)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:671)
        at com.izforge.izpack.installer.container.impl.GUIInstallerContainer.resolveComponents(GUIInstallerContainer.java:100)
        at com.izforge.izpack.installer.container.impl.InstallerContainer.fillContainer(InstallerContainer.java:79)
        at com.izforge.izpack.core.container.AbstractContainer.initialise(AbstractContainer.java:303)
        ... 6 more

There should be a better check for a bad definition at compile time.



 Comments   
Comment by Ahmed Abu Lawi [ 15/Jan/15 ]

Pull request sent. https://github.com/izpack/izpack/pull/301

Comment by Rene Krell [ 16/Jan/15 ]

Thank you for the contribution, well done.

Comment by Rene Krell [ 05/Feb/15 ]

I have to tweak this solution a bit.
Actually there is also a possibility to have nested logical conditions, like this:

    <condition type="exists" id="Update">
        <file>${INSTALL_PATH}/some_path</file>
    </condition>
    <condition type="not" id="Install">
        <condition type="ref" refid="Update" />
    </condition>
    <condition type="and" id="linuxInstallOrUpdate">
      <condition type="ref" refid="izpack.linuxinstall" />
      <condition type="or" id="installOrUpdate">
        <condition type="ref" refid="Install" />
        <condition type="ref" refid="Update" />
      </condition>
    </condition>

which isn't covered neither in unit tests nor in the documentation.

Comment by Rene Krell [ 05/Feb/15 ]

Merged pull request #314 with a tweak.
I fixed and cleant-up also the documentation to reflect the current state. Only aggregate conditions can be defined nested.





[IZPACK-1201] Split user input field attribute "set" into "set" and "default" Created: 04/Dec/14  Updated: 09/Dec/14  Resolved: 09/Dec/14

Status: Resolved
Project: IzPack
Component/s: Documentation, Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependent
is depended upon by IZPACK-1197 Variable and dynamic variable improve... Resolved
Number of attachments : 0

 Description   

Split user input field attribute set to set and default

If a user input field in a UserInputPanel defines a set attribute if should have precedence over the current variable value in each case.
Add a default attribute to clean up the ambiguosity against the set attribute - default should be a real default value in case there is neither an initial one nor a user-specified on available for the field.

Update: Further changes which might also break existing environments:

  • In rule fields, there is no longer supported using field processor classnames directly in the 'set' attribute in a way like this: <spec set="0:defaultVal:classname" .../>.
  • In rule fields, both attributes, set and default, have to be defined as formatted, plain value which must match the given layout, no longer along with the layout tags like before. This makes initial, default and variable values consistent and directly comparable.


 Comments   
Comment by Rene Krell [ 09/Dec/14 ]

Resolved in https://github.com/izpack/izpack/pull/295 for the superior issue.





[IZPACK-1200] Allow default value overrides of dynamic variables from the <variables> section Created: 04/Dec/14  Updated: 09/Dec/14  Resolved: 09/Dec/14

Status: Resolved
Project: IzPack
Component/s: Compiler, Documentation, Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependent
is depended upon by IZPACK-1197 Variable and dynamic variable improve... Resolved
Number of attachments : 0

 Description   

If the name of a dynamic variable is also used in a variable definition in the <variables> section it should be the default value of the dynamic variable instead of unsetting it during refreshing if there are no further conditions matching in the <dynamicvariables> section for that variable.

This is also one step towards uniting variables and dynamicvariables in the future.



 Comments   
Comment by Rene Krell [ 09/Dec/14 ]

Resolved in https://github.com/izpack/izpack/pull/295 for the superior issue.





[IZPACK-1199] Don't refresh a dynamic variable if it has been set by the user on a UserInputPanel Created: 03/Dec/14  Updated: 05/Feb/15  Resolved: 09/Dec/14

Status: Resolved
Project: IzPack
Component/s: Documentation, Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to IZPACK-1117 Allow dynamic variable to be static u... Resolved
dependent
is depended upon by IZPACK-1197 Variable and dynamic variable improve... Resolved
Number of attachments : 0

 Description   

This issue is some kind of refinement of Miles' issue IZPACK-1117 reported more recently:

The current implementation of dynamic variables in 5.0.0-rc4 refreshes dynamic variables on each panel change, which subsequently might set a whole chain of conditions depending on them.

A dedicated dynamic variable is currently also refreshed if it has been assigned a value from a user input field. This should not happen.

Freezing variables:

  • The change here is that if the installer reaches a UserInputPanel with a user input field assigning a dynamic variable a value, the dynamic variable should be blocked by that panel as soon as the user presses the Next button and before the variables are refreshed again.
  • If there are more than one blocker panels that modify a dedicated variable, block immediately when passing the first one of them in order in case of Next.

Unfreezing variables:

  • If the user presses Prev an reaches an UserInputPanel blocking a variable from refreshing again, it should stop the variable from blocking.
  • If there the user presses Prev and there are no longer blocking UserInputPanels on a dynamic variable, the variable should get unblocked and available for refreshing again.
    This is the case as soon as the installer wizard reached the first panel in order overriding the variable's value, thus, all blocking panels must free a dynamic variable before it actually available again for refreshing.
  • If there are more than one blocker panels that modify a dedicated variable, wait until passing the first one in case of Prev for unblocking.

Freezing and unfreezing includes value changes and unsetting a variable value if no condition matches any longer.



 Comments   
Comment by Rene Krell [ 09/Dec/14 ]

Resolved in https://github.com/izpack/izpack/pull/295 for the superior issue.

Comment by Rene Krell [ 30/Jan/15 ]

Merged also pull requests #305 and #307 with post-fixes.

Comment by Rene Krell [ 05/Feb/15 ]

Merged also https://github.com/izpack/izpack/pull/311, which adds a unit test for the implementation. Thanks for this contribution.





[IZPACK-1198] Don't allow dynamic variable definitions with the same name and condition twice during compiling Created: 03/Dec/14  Updated: 04/Dec/14  Resolved: 04/Dec/14

Status: Closed
Project: IzPack
Component/s: Compiler
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, the compiler allows defining double variable definitions in the <dynamicvariables> section in install.xml like:

<dynamicvariables>
  <variable name="name1" condition="Cond1"/>
  <variable name="name1" condition="Cond1"/>
</dynamicvariables>

There just a warning written to the debug log.

Since the name and condition are the unique keys of a dynamic variable (also used in the equals() override, this behavior makes no sense and should be changed. The compiler should fail with an appropriate message in this case.



 Comments   
Comment by Rene Krell [ 04/Dec/14 ]

This shouldn't be done because there are also constellations like

        <variable name="previous.version.manifest" jarfile="${INSTALL_PATH}/lib/app_v1.jar" entry="META-INF/MANIFEST.MF" type="options" key="Implementation-Version" ignorefailure="true" condition="haveInstallPath">
          <filters>
            <regex regexp="\s*(.*)\s*" select="\1" />
          </filters>
        </variable>
        <variable name="previous.version.manifest" jarfile="${INSTALL_PATH}/lib/shared/app_v2.jar" entry="META-INF/MANIFEST.MF" type="options" key="Implementation-Version" ignorefailure="true" condition="haveInstallPath">
          <filters>
            <regex regexp="\s*(.*)\s*" select="\1" />
          </filters>
        </variable>

Thus, the key and condition cannot be treated as unique in each use case.





[IZPACK-1197] Variable and dynamic variable improvements Created: 03/Dec/14  Updated: 16/Dec/14  Resolved: 09/Dec/14

Status: Resolved
Project: IzPack
Component/s: Compiler, Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Task Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates IZPACK-1160 Dynamic variables unset if none of a ... Resolved
dependent
depends upon IZPACK-1117 Allow dynamic variable to be static u... Resolved
depends upon IZPACK-1199 Don't refresh a dynamic variable if i... Resolved
depends upon IZPACK-1200 Allow default value overrides of dyna... Resolved
depends upon IZPACK-1201 Split user input field attribute "set... Resolved
Number of attachments : 0

 Description   

Enhancements of dynamic variables (http://docs.codehaus.org/display/IZPACK/Dynamic+Variables) and their subsequent improvements is one of the major features introduced with IzPack 5.0.

Nevertheless, there is a couple of issues left with the goal of using them more smoothly.

A special focus is integrating static and dynamic variables as much as possible.

I will add subissues for dedicated things to be solved.



 Comments   
Comment by Rene Krell [ 04/Dec/14 ]

Opened a first pull request https://github.com/izpack/izpack/pull/295 to address the following subissues:

Comment by Rene Krell [ 09/Dec/14 ]

Pull request https://github.com/izpack/izpack/pull/295 merged.





[IZPACK-1196] executable in packs is ignored Created: 02/Dec/14  Updated: 02/Dec/14

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Wheeler Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: executable,, pack
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5.0.0-rc4, windows 7, Java 8


Attachments: Text File executablebug.txt    
Number of attachments : 1

 Description   

Using both forms of the executable statement, the program does not get executed.
The attached extract from my install.xml shows both forms (one is commented out for test purposes.






[IZPACK-1195] Improve and enhance displaying of readonly UserInputPanels Created: 01/Dec/14  Updated: 30/Jan/15  Resolved: 01/Dec/14

Status: Resolved
Project: IzPack
Component/s: Installer, Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: New Feature Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to IZPACK-1205 UserInputPanel: displayHidden and rea... Resolved
relates to IZPACK-1214 File/Dir fields with property readonl... Resolved
Number of attachments : 0

 Description   

This issue enhances the introduced read-only fields and panels from issue IZPACK-1120. The issue dealt exclusively for panels which are not displayed due to some not fulfilled condition and introduced the displayHidden attribute in the UserInputSpec.xml resource for panels and fields.

To make this more universal I'd infringe the rule to not introduce new features to 5.0 any longer and put it to a more complete shape.

Imagine the following possibilities including those of IZPACK-1120:

UserInputSpec.xml:

Introduced by IZPACK-1120:

<panel id="panel.dbsettings.review" displayHidden="true">
...
</panel>
<panel id="panel.dbsettings.review2" >
  <field ... displayHidden="true">
  </field>
...
</panel>

displayHidden="true" (default "false") introduced displaying a panel or just dedicated user input fields to be displayed read-only although they have been disabled according to a condition on the panel (install.xml, UserInputSpec.xml) or on the field (UserInputSpec.xml) .

New attributes:

<panel id="panel.dbsettings.review" displayHiddenCondition="SomeCondition">
...
</panel>
<panel id="panel.dbsettings.review2" >
  <field ... displayHiddenCondition="SomeCondition">
  </field>
...
</panel>

The displayHiddenCondition attribute enhances and replaces the displayHidden condition introduced by IZPACK-1120 and makes the related behavior dependent on another condition. Thus, the related panel or field gets displayed read-only only if a general condition on that panel or field disables it for displaying and the condition defined by displayHiddenCondition gets true.

<panel id="panel.dbsettings.review" readonly="true">
...
</panel>
<panel id="panel.dbsettings.review2" >
  <field ... readonly="true">
  </field>
...
</panel>

The readonly attribute is completely new and reverses the logic - readonly="true" means to display a complete panel or field read-only in general in case it is not disabled by a general panel or field condition.

<panel id="panel.dbsettings.review" readonlyCondition="SomeCondition">
...
</panel>
<panel id="panel.dbsettings.review2" >
  <field ... readonlyCondition="SomeCondition">
  </field>
...
</panel>

The new readonlyCondition attribute enhances and replaces the readonly condition and makes the related behavior dependent on another condition. Thus, the related panel or field gets displayed read-only only if it is not disabled by a general panel or field condition and the condition defined by readonlyCondition gets true.



 Comments   
Comment by Rene Krell [ 01/Dec/14 ]

Created pull request #294: https://github.com/izpack/izpack/pull/294

Comment by Rene Krell [ 01/Dec/14 ]

Pull request merged.
Deployed to repository in current 5.0.0-rc5-SNAPSHOT.





[IZPACK-1194] "contains" condition does not work for checking plain <variable> values Created: 01/Dec/14  Updated: 01/Dec/14  Resolved: 01/Dec/14

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to IZPACK-1120 Allow displaying fields when their co... Resolved
Number of attachments : 0

 Description   

The "contains" condition, introduced in 5.0, does not work for the following example:

<condition type="contains" id="mssqlUrlFound">
   <variable>jdbc.url</variable>
   <value>jdbc:jtds:sqlserver</value>
</condition>

This affects probably more usecases using plain value checks, because an invalid check causes the condition to make a regex check due to the default byLine="true" instead of comparing plain values. This failed due to an uninitialized regex pattern.



 Comments   
Comment by Rene Krell [ 01/Dec/14 ]

Created pull request #293: https://github.com/izpack/izpack/pull/293

Comment by Rene Krell [ 01/Dec/14 ]

Pull request merged.
Deployed to repository in current 5.0.0-rc5-SNAPSHOT.





[IZPACK-1193] packsLang.xml_eng is ignored Created: 27/Nov/14  Updated: 16/Jan/15  Resolved: 16/Jan/15

Status: Resolved
Project: IzPack
Component/s: Installer, Panels
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Wheeler Assignee: Rene Krell
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5.0.0-rc4, Windows 7, Java 8


Attachments: XML File install.xml     File packsLang.xml_eng    
Number of attachments : 2

 Description   

The language overrides specified in packsLang.xml_eng are ingored and the panel shows the name and description from the pack element in install.xml



 Comments   
Comment by Ahmed Abu Lawi [ 15/Jan/15 ]

Hi Ron,

I'm not sure if you've resolved this issue yet but from the install.xml and packsLang.xml_eng attached it looks like you're using the "name" attribute instead of the "id" attribute to get the packs langpack.

You can look here for reference, http://docs.codehaus.org/display/IZPACK/Packs.

I believe that this issue should be closed.

Comment by Rene Krell [ 16/Jan/15 ]

Ahmed is right.
You got to define a <pack id="..."/> and use it in the packsLang.xml_* as identifier.
Example (german):
install.xml:

<resources>
    <res id="packsLang.xml_eng" src="i18n/packsLang.xml_eng"/>
    <res id="packsLang.xml_deu" src="i18n/packsLang.xml_deu"/>
</resources>

<packs>
    <pack condition="!Uninstall" id="pack.core" name="Core files" required="yes">
        <description>Core files</description>
        ...
    </pack>
</packs>

packsLang.xml_deu:

<str id="pack.core" txt="Programmdateien" />
<str id="pack.core.description" txt="FÃŒr die Anwendung erforderliche Dateien." />

On the other hand, I understand this mistake from the view point of inconsistencies regarding the usage of <pack name="..."/> and <pack id="..."/>, which are still present.
For instance <createForPack/> tags in userInputSpec.xml and pack references in AntActionSpec.xml resources still refer to the name attribute, which should be cleant up in future.

Comment by Ron Wheeler [ 16/Jan/15 ]

Thanks. Fixed my problem
I have updated the docs to make this clearer.





[IZPACK-1192] If no PacksPanel specified install dies with Cannot find named resource: 'packsLang.xml AND 'packsLang.xml_eng' Created: 27/Nov/14  Updated: 27/Nov/14

Status: Open
Project: IzPack
Component/s: Installer, Panels
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Wheeler Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5.0.0-rc4 Windows 7 Java8


Number of attachments : 0

 Description   

If you do do not specify a packsPanel in the panels section, the install dies after throwing up an error dialogue saying
Cannot find named resource: 'packsLang.xml AND 'packsLang.xml_eng'
If there are no optional packs, then I would expect it to just install all the "required" packs.
If there are optional packs but no packsPanel, it should give an error saying that "The install.xml contains optional packs but has no packPanel"
Providing the packsPanel in th panels and adding the resource file packsLang.xml_eng makes the error go away and the installation continues.






[IZPACK-1191] misspelling laf name results in NullPointerException Created: 25/Nov/14  Updated: 19/Jan/15  Resolved: 19/Jan/15

Status: Resolved
Project: IzPack
Component/s: Compiler, Maven plugin
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Ron Wheeler Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 Java 8,


Issue Links:
Duplicate
duplicates IZPACK-1189 aqua laf causes NullPointerException ... Resolved
duplicates IZPACK-1190 metal laf causes NullPointerException Resolved
Number of attachments : 0

 Description   

<laf name="konststoff">
<os family="windows" />
<os family="unix" />
</laf>

causes a NullPointerException

<laf name="kunststoff">
<os family="windows" />
<os family="unix" />
</laf>
works fine.

Would be nice to give a more useful message that refers to the laf not being a valid choice.



 Comments   
Comment by Rene Krell [ 19/Jan/15 ]

Pull request https://github.com/izpack/izpack/pull/303 raised by Thomas Hauser.

Comment by Rene Krell [ 19/Jan/15 ]

Thanks for contributing





[IZPACK-1190] metal laf causes NullPointerException Created: 25/Nov/14  Updated: 19/Jan/15  Resolved: 19/Jan/15

Status: Resolved
Project: IzPack
Component/s: Compiler, Maven plugin
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Ron Wheeler Assignee: Rene Krell
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 Java 8


Issue Links:
Duplicate
is duplicated by IZPACK-1191 misspelling laf name results in NullP... Resolved
Number of attachments : 0

 Description   

<laf name="metal">
<os family="windows" />
</laf>
[ERROR] Failed to execute goal org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc4:izpack (default-cli) on project adtransform-installer: Failure: NullPointerException -> [Help 1]



 Comments   
Comment by Rene Krell [ 19/Jan/15 ]

Duplicate of IZPACK-1191





[IZPACK-1189] aqua laf causes NullPointerException in compile Created: 25/Nov/14  Updated: 19/Jan/15  Resolved: 19/Jan/15

Status: Resolved
Project: IzPack
Component/s: Compiler, Maven plugin
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Ron Wheeler Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 7 Java 8


Issue Links:
Duplicate
is duplicated by IZPACK-1191 misspelling laf name results in NullP... Resolved
Number of attachments : 0

 Description   

<laf name="aqua">
<os family="windows" />
</laf>

[ERROR] Failed to execute goal org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc4:izpack (default-cli) on project adtransform-installer: Failure: NullPointerException -> [Help 1]



 Comments   
Comment by Rene Krell [ 19/Jan/15 ]

Duplicate of IZPACK-1191





[IZPACK-1188] windows laf causes NullPointerException Created: 25/Nov/14  Updated: 25/Nov/14

Status: Open
Project: IzPack
Component/s: Compiler, Maven plugin
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ron Wheeler Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 Java 8


Number of attachments : 0

 Description   

<laf name="windows">
<os family="windows" />
</laf>
[ERROR] Failed to execute goal org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc4:izpack (default-cli) on project adtransform-installer: Failure: NullPointerException -> [Help 1]






[IZPACK-1187] liquid laf fails to compile - missing class com.birosoft.liquid Created: 25/Nov/14  Updated: 25/Nov/14

Status: Open
Project: IzPack
Component/s: Compiler, Maven plugin
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ron Wheeler Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 7 java8


Number of attachments : 0

 Description   

[ERROR] Failed to execute goal org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc4:izpack (default-cli) on project adtransform-installer: Failure: The path 'com/birosoft/liquid//' is not present inside the classpath.






[IZPACK-1186] metouia laf causes NullPointerException in Maven Created: 25/Nov/14  Updated: 25/Nov/14

Status: Open
Project: IzPack
Component/s: Compiler
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ron Wheeler Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 7 java8


Number of attachments : 0

 Description   

<laf name="metouia">
Failed to execute goal org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc4:izpack (default-cli) on project adtransform-installer: Failure: NullPointerException






[IZPACK-1185] laf substance not compatible with Java 8 Created: 25/Nov/14  Updated: 23/Apr/15

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Wheeler Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: exception, java8, runtime
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Wundows 7 Java 8


Attachments: XML File install.xml     Text File laf_blog_error_log.txt    
Number of attachments : 2

 Description   

When install.xml includes
<laf name="substance">
<os family="windows" />
<os family="unix" />
<param name="variant" value="creme-coffee" />
</laf>
The installer crashes with
24-Nov-2014 10:47:09 PM com.izforge.izpack.installer.container.provider.GUIInstallDataProvider load
INFO: Using laf org.pushingpixels.substance.api.skin.SubstanceMistAquaLookAndFeel
24-Nov-2014 10:47:09 PM com.izforge.izpack.installer.bootstrap.Installer start
SEVERE: java.lang.IllegalStateException: This method must be called on the Event Dispatch Thread

When the laf section is removed, the installer runs.

I could not get
<laf name="liquid"> to compile
Failure: The path 'com/birosoft/liquid//' is not present inside the classpath. (with liquid)



 Comments   
Comment by Devin Snyder [ 22/Apr/15 ]

http://stackoverflow.com/questions/17627617/cant-set-a-theme-because-of-a-stacktrace might explain why

Comment by Bar Zecharya [ 23/Apr/15 ]

The error also occurs with Java 7.
In my case (from install.xml):

<guiprefs width="800" height="600" resizable="no">
<splash>images/splash.png</splash>
<laf name="substance">
<os family="windows" />
<os family="unix" />
<param name="variant" value="mist-silver" />
</laf>
<modifier key="useHeadingPanel" value="yes" />
</guiprefs>





[IZPACK-1184] Pack size is always shown as 0 Created: 20/Nov/14  Updated: 20/Nov/14

Status: Open
Project: IzPack
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sravani chukka Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Hi,

I have some loose packs, and the size of them is always shown as 0 bytes. How do i calculate the size or hide the column which shows the size.

I have already tried adding below GUIprefs in my install.xml but still no luck.

<modifier key="doNotShowPackSizeColumn" value="true"/>
<modifier key="doNotShowRequiredSize" value="yes"/>






[IZPACK-1183] DynamicVariableImpl: Implementation of .equals() and .hashcode() is not correct Created: 18/Nov/14  Updated: 21/Nov/14  Resolved: 21/Nov/14

Status: Resolved
Project: IzPack
Component/s: Compiler, Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Number of attachments : 0

 Description   

A dynamic variable probably always has a name (although there is a constructor, which does not set the name!)

But the condition can remain null, so equals() and hashCode() must handle this case.
Initializing the conditionid field with an empty string is not a solution, because some parts rely on "null" as an unset condition



 Comments   
Comment by Tom Helpstone [ 20/Nov/14 ]

sent pull request 292

Comment by Rene Krell [ 21/Nov/14 ]

Pull request merged.
Thank you.





[IZPACK-1182] Evaluation of dynamic variables, which depends on another one, fails Created: 18/Nov/14  Updated: 17/Apr/15  Resolved: 17/Apr/15

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Critical
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours

Attachments: XML File installer.xml     Java Archive File test-DependentVars-1.0.0.jar     Java Archive File test-DependentVars-1.0.1.jar     Java Archive File test-DependentVars-1.0.2.jar     Java Archive File test-DependentVars-1.0.3.jar     Java Archive File test-DependentVars-1.0.4.jar    
Issue Links:
Supercedes
supercedes IZPACK-1216 Dynamic Variables with conditions dep... Resolved
supercedes IZPACK-1215 cyclic reference does produce a loop Resolved
Number of attachments : 6

 Description   

If you use a dynamic variable, which does rely in its evaluation on another dynamic variable, you can get unresolved values during the first few panels. If it is combined with a checkonce="true" the variable could stay unresolved for ever.



 Comments   
Comment by Tom Helpstone [ 18/Nov/14 ]

Added attachment with an example Installer showing the problem with dynamic variables like

<variable name="var01" value="${var00}" />
Comment by Tom Helpstone [ 18/Nov/14 ]

Run the example installer with java -jar test-DependentVars-1.0.0.jar
All variables should have the value "Value", which is recursive derived from ${var00}.

On the first DataCheckPanel you will see ${var01} ... $[var06} with this values, The remaining variables will have the values "${var01}", "${var02}", ...

On the second DataCheckPanel the variables ${var07} ... ${var13} have the correct value, on the third one also ${var14} ... ${var19}. Variable ${varCheckOnce} will remain on the value "${var19}", because it is evaluated only once.

Comment by Tom Helpstone [ 18/Nov/14 ]

The dynamic variables are evaluated in com.izforge.izpack.core.data.DefaultVariables.refresh().

This method is called several times during installation via com.izforge.izpack.api.data.AutomatedInstallData.refreshVariables():

  • check of requirements
  • validation of a panel
  • switching the panel
    and via com.izforge.izpack.api.data.AutomatedInstallData.refreshDynamicVariables():
  • check, whether a panel can be shown
  • validation of dynamic conditions

Every time the refresh() is done, it does make one cycle over all dynamic variables, trying to resolve them. The results are made visible after the complete cycle only.

So in our cascade of variables, the value is propagated by one on each refesh().

Comment by Tom Helpstone [ 18/Nov/14 ]

Bug-Fixing:

variant 1:
If we would calculate a dependency tree for the dynamic variables, we could evaluate them in the correct order.

variant 2:
We can remember, whether one of the variables has been changed. We rerun the evaluation in refresh() until none of the variables did change. We have to think about cyclic references which could result in a loop.

I think, that variant 2 is easier to implement and the changes will be local in the class.

Comment by Tom Helpstone [ 27/Jan/15 ]

Installer created with IZPACK-1182 included

Comment by Tom Helpstone [ 27/Jan/15 ]

The Installer test-DependentVars-1.0.1.jar was build on the same installer.xml, but with the modifications of IZPACK-1182 included.
All variables var00, var01, ..., var19 are available with the stable value already after the first iteration (this is, how it should behave)

Comment by Rene Krell [ 27/Jan/15 ]

Can you retry please with the current HEAD from master 5.0.0-RC5-SNAPSHOT (also deployed to the snapshot repository a few hours ago).
I merged some fixes regarding variable refreshes.

Comment by Tom Helpstone [ 27/Jan/15 ]

Installer with an additional fix for dynamic variables with checkonce="true"
-> varCheckOnce is set to "Value" also

Comment by Rene Krell [ 27/Jan/15 ]

I tried your latest installer 1.0.2 on Linux.
Is this fixed for you, did I get the message right?

Comment by Tom Helpstone [ 27/Jan/15 ]

Yes, you are right - this issue is solved with the last installer example.

But I have to rebase to the actual version of IzPack and confirm the solution. I've got a conflict on the first try. So I have to check.

Comment by Rene Krell [ 27/Jan/15 ]

Ok. Beginning with 5.0 RC5, there is also an improvement regarding dynamic variables. As soon as they are set by a panel and you go forward and leave that panel they get blocked for further changes from refreshes. If you go backward over the same panel again they are unblocked.
This seemed to be most intuitive for most usecases: If a user enters a value this has priority. Before the panel is reached, the default value of a field can be initialized by dynamic variables, after that the user value is frozen and cannot be changed by a (mostly uncontrolled or unwanted) refresh.

Hopefully that fits.

Comment by Rene Krell [ 27/Jan/15 ]

This issue doesn't happen any longer and has been fixed probably by commits for several issues regarding dynamic variable handling.

Please reopen in case it happens again.
Thanks for reproducing this and the hints.

Comment by Tom Helpstone [ 28/Jan/15 ]

This Issue is not fixed in 5.0.0-rc5-SNAPSHOT (5037a)
-> I will try to merge on rc5-SNAPSHOT

Comment by Tom Helpstone [ 28/Jan/15 ]

This installer is based on 5.0.0-rc5-SNAPSHOT (5037a)
The problem does occur here (again)
-> I'll check and merge my corrections on 5.0.0-rc5-SNAPSHOT

Comment by Tom Helpstone [ 28/Jan/15 ]

test-DependentVars-1.0.4.jar is based on the actual master 5.0.0-rc5-SNAPSHOT plus my corrections from IZPACK-1182 merged into the updated master.
-> 5.0.0-rc5-SNAPSHOT-52185
The installer does behave well again.

Comment by Tom Helpstone [ 28/Jan/15 ]

sent pull request 306

Comment by Rene Krell [ 28/Jan/15 ]

This pull request still makes some trouble, it breaks some latest implementation (blocking of variables reserved/ set by panels against refreshing when moving forward in the installer wizard).

Maybe also my fault with my test case, I will check this soon.

Thank you.

Comment by Tom Helpstone [ 28/Jan/15 ]

At least the implemented unit tests were ok.

But I've now constructed a test case, which seems to produce a loop with IZPACK-1182. Without IZPACK-1182 this test does not loop, but the result seems to be wrong.

I'll investigate ...

Comment by Rene Krell [ 28/Jan/15 ]

Yes, this can be always a problem, it seems you need to apply an algorithm for avoiding loops in general.
If it is too difficult we can live for now with the variant of assigning the variables straight-forward in the order they are defined, its on the user to have the correct order.

Comment by Rene Krell [ 29/Jan/15 ]

I'm actually not sure whether it is a good idea to make IzPack working like a "programming language". From my point of view, for dynamic variables it is sufficient to evaluate them in one run in the order of definition. Imagine something like

<variable name="a" value="${b}"/>
<variable name="b" value="${a}"/>

You won't be able to reasonable resolve that. If you want a complex variable assignment as you suggest, those cases must be catched at compile time.

Even worse if you add conditions to them, which can be also defined in a similar way, you get a complexity which the user hardly overlooks just by looking at it for more complex installers. For example, there might be something like:

<dynamicvariables>
  <variable name="a" value="${b}" condition="cond1"/>
  <variable name="b" value="${a}" condition="cond2"/>
</dynamicvariables>
...
<conditions>
  <condition type="and" id="cond1">
    <condition type="ref" refid="cond2"/>
    <condition type="ref" refid="cond3" />
  </condition>
  <condition type="and" id="cond2">
    <condition type="ref" refid="cond1"/>
    <condition type="ref" refid="cond3" />
  </condition>
  <condition type="and" id="cond3">
    <condition type="ref" refid="cond1"/>
    <condition type="ref" refid="cond2" />
  </condition>
</conditions>

which is crap, but legal. This must be catched by the compiler correctly, if you want a complete resolution.
The way IzPack it did and does is doing evaluation once in one run.
For cases like above we'd need a more sophisticated compiler recognizing infinite loops.

Comment by Rene Krell [ 30/Jan/15 ]

Merged pull request https://github.com/izpack/izpack/pull/306, works for me.

Comment by Tom Helpstone [ 31/Jan/15 ]

I don't know how much "programming language" is needed, but recursive variables are very useful. Think about the following usecase:

The Installation path of several packages could be constructed from a common path prefix and a module specific path suffix. The resulting path will be used at several locations of the install.xml. Of course you may use ${path_prefix}/${module1_suffix} at all of this locations. But it would be easier to define a
<variable name="module1_path" value="${path_prefix}/${module1_suffix}" />
and use only this dynamic variable, which depend on other ones.
Maybe the module1 is used in several installers and is included there with it's own xml. Then the variable "module1_path" will be a good parameter, which could be defined different in different installers.

A definition like

<dynamicvariables>
  <variable name="a" value="${b}" />
  <variable name="b" value="${a}" />
</dynamicvariables>

will be nonsense of course. It would be nice, if it would be detected while building the installer. But I think, this is not possible, especially, when conditions are used also.

In the actual implementation of IZPACK-1182 this example will result in a loop. This loop has to be detected and reported in DefaultVariables.java.

I'll work on this in IZPACK-1215.

Comment by Rene Krell [ 02/Feb/15 ]

By means of "programming language" I rather meant full resolution of variables in many cycles instead of evaluating all once for each refresh in the order they are defined, how it has been usually done in IzPack from the beginning.
It is ok so far, if there will appear some pitfall I'll let you know. I'll add some unit tests for variable blocking next time.

Comment by Rene Krell [ 17/Apr/15 ]

I have a more complex testcase here, where this doesn't work as expected. Shortly something like

<variable "name1" value="${name2}"/>
<variable "name2" value="somevalue"/>

in this order didn't set variable name1 to "somevalue", but left it "${name2}".

The reason seems to be a bad condition in the code:
DefaultVariables.java, line 365:

  if (newValue==null || ! newValue.contains("$"))

should probably be:

  if (!(newValue == null || newValue.contains("$")))

Maybe I'm in mistake, but the above change solves this situation for me.
@Tom, could you please check this also?

Comment by Rene Krell [ 17/Apr/15 ]

Sent pull request https://github.com/izpack/izpack/pull/338

Comment by Rene Krell [ 17/Apr/15 ]

Merged PR #338 to be able to continue testing, please reopen in case this makes some trouble for you.

Comment by Tom Helpstone [ 17/Apr/15 ]

@Rene:
I'm short of time at the moment, so I will recheck in about 2 weeks. But your fix seems reasonable to me:
My check for null was probably intended to avoid a NPE only. My testcases did have only back references, no forward reference. My installer does not use forward references, because I read it like a linear programm. So I was feeling happy with my implementation.

The old implementation probably did resolve forward references (after enough iterations), so the new one should also.

Thanks for fixing this!





[IZPACK-1181] Test failures in 40a713e Created: 10/Nov/14  Updated: 10/Nov/14

Status: Open
Project: IzPack
Component/s: None
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Erwin Mueller Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_71"
OpenJDK Runtime Environment (fedora-2.5.3.0.fc20-x86_64 u71-b14)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
Maven home: /home/devent/apps/apache-maven-3.2.3
Java version: 1.7.0_71, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.16.6-203.fc20.x86_64", arch: "amd64", family: "unix"


Attachments: Text File com.izforge.izpack.util.PrivilegedRunnerTest.txt     XML File TEST-com.izforge.izpack.util.PrivilegedRunnerTest.xml    
Number of attachments : 2

 Description   

Checkout master branch on commit 40a713e
compile & install on root pom.xml

IzPack util module
Failed tests:
testGetElevatorOnUnix(com.izforge.izpack.util.PrivilegedRunnerTest): expected:<8> but was:<10>
testGetElevatorOnWindows(com.izforge.izpack.util.PrivilegedRunnerTest): expected:<6> but was:<8>
testGetElevatorOnMacOSX(com.izforge.izpack.util.PrivilegedRunnerTest): expected:<4> but was:<6>






[IZPACK-1180] ConfigurationInstallerListener: Nested <entry> remains empty if it didn't exist before Created: 07/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If a property file is created by ConfigurationListener, or nested <entry> doesn't still exist before applyiong configuration actions, the nested entries are left empty and their value attribute isn't applied at all.

Example

<configurable type="options" keepOldKeys="true" keepOldValues="true"
        tofile="${INSTALL_PATH}/db.properties"
      >
        <entry key="driver" value="org.firebirdsql.jdbc.FBDriver" />
        <entry key="url" value="jdbc:firebirdsql:${db.host}/${db.port}:##user.dir#/" />
        <entry key="file" value="${database.scriptsfolder}/${db.name}.fdb" />
        <entry key="user" value="${db.user}" />
        <entry key="pass" value="${db.password}" />
      </configurable>

if db.properties doesn't exist the ConfigurationInstallerListener leaves it in this state:

driver=
url=
file=
user=
pass=


 Comments   
Comment by Rene Krell [ 07/Nov/14 ]

Sent pull request with a fix: https://github.com/izpack/izpack/pull/291

Comment by Rene Krell [ 07/Nov/14 ]

Merged pull request.





[IZPACK-1179] Automatically add jars to install.xml from Maven project dependencies Created: 07/Nov/14  Updated: 07/Nov/14

Status: Open
Project: IzPack
Component/s: Maven plugin
Affects Version/s: 5.0
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Rene Krell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Instead of manually adding <jar> definitions it would be nice if the Maven plugin would be able to automatically add project dependencies (with includes/excludes) to an installer.

This should be an optional choice.






[IZPACK-1178] Cannot create shortcuts on unix platforms. Created: 06/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

Status: Resolved
Project: IzPack
Component/s: None
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Ahmed Abu Lawi Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Fedora 20


Number of attachments : 0

 Description   

If a shortcut panel is specified in the install.xml, the ShotcutPanel is skipped if the installer is not being run on windows. This is being caused by an NPE in the ShortcutPanel.java because a variable referenced later, is only being initialized if the platform is Windows.



 Comments   
Comment by Ahmed Abu Lawi [ 06/Nov/14 ]

PR sent https://github.com/izpack/izpack/pull/290

Comment by Rene Krell [ 07/Nov/14 ]

Merged pull request https://github.com/izpack/izpack/pull/290





[IZPACK-1177] AutomationHelper not found Created: 06/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Trivial
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When using a HelloPanel or a FinishPanel inside an installer and doing an unattented installation for this, you get the following error like:

06.11.2014 15:24:48 WARNING: AutomationHelper class not found for panel class: com.izforge.izpack.panels.hello.HelloPanel

This is, because these panels do not have an AutomationHelper.



 Comments   
Comment by Tom Helpstone [ 06/Nov/14 ]

Solution: add a new class HelloPanelAutomation.class, which does provide an empty implementation

It would be possible to write the text of the HelloPanel to stdout, so that the information would be logged in an unattented installation. But my goal was to get rid of the warning, so I decided to provide an empty implementation only.

Comment by Tom Helpstone [ 06/Nov/14 ]

Pull Request #289 generated
https://github.com/izpack/izpack/pull/289

Comment by Tom Helpstone [ 07/Nov/14 ]

updated the pull request, adding FinishPanelAutomation

Comment by Tom Helpstone [ 07/Nov/14 ]

Some other panels like HTMLInfoPanel do not have an AutomationHelper also. But they don't give a warning during unattented installation. There seems to be some more magic behind the scenes - do not investigate further, because at the moment the HelloPanel and the FInishPanel are on my target.

Comment by Rene Krell [ 07/Nov/14 ]

Merged pull request.





[IZPACK-1176] Maven Dependencies in izpack-native-* still refer to 5.0.0-rc3-SNAPSHOT Created: 10/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

Status: Resolved
Project: IzPack
Component/s: Build
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Critical
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: 15 minutes
Time Spent: Not Specified
Original Estimate: 15 minutes

Number of attachments : 0

 Description   

Some of the maven projects still do refer to a previuos release candidate.



 Comments   
Comment by Tom Helpstone [ 10/Oct/14 ]

sent PR#282

Comment by Tom Helpstone [ 10/Oct/14 ]

Why do the izpack-native modules stay on the old version? Is there something missing in the process of switching to a new release (candidate).

Comment by Rene Krell [ 16/Oct/14 ]

Pull request #282 merged.
Thanks for contributing.

Comment by Rene Krell [ 16/Oct/14 ]

These modules are not included in the build because they are dependend on the build OS and some licensed compiler tools.
If you want, you can try to control this using profiles to not let builds and releases fails when including them to the parent build again.





Eclipse does show several warnings (IZPACK-1103)

[IZPACK-1175] Class is a raw type. References to generic type Class<T> should be parameterized Created: 10/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

Status: Resolved
Project: IzPack
Component/s: Compiler, Installer, Uninstaller
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Sub-task Priority: Trivial
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Number of attachments : 0

 Description   

com.izforge.izpack.compiler.Compiler does reference both
com.izforge.izpack.api.event.InstallerListener and
com.izforge.izpack.api.event.UnInstallerListener in a non parameterized way.

It would be better to have a common interface for both Listerner types and to use a parameterized Class<T> in Compiler.

Unfortunately the InstallerListener and UninstallerListener do not share much methods, because things are names differently for installation and uninstallation. This could be improved, but it woul also affect custom implementations of this interface, so we only could deprecate the old methods for a long time. I would suggest NOT to harmonize the methods.

But nevertheless I would suggest to create a common parent, so that the use of the (un)installers can be parameterized.



 Comments   
Comment by Tom Helpstone [ 10/Oct/14 ]

submitted PR#281

Comment by Rene Krell [ 16/Oct/14 ]

Pull request #281 merged.
Thanks for contributing.





[IZPACK-1174] Schema for panelType element missing jar attribute Created: 03/Oct/14  Updated: 03/Oct/14

Status: Open
Project: IzPack
Component/s: Build, Compiler, Panels
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: David Paterson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Problem exists in master/HEAD


Number of attachments : 0

 Description   

element:
<xs:complexType name="panelType">

is mssing:
<xs:attribute type="xs:string" name="jar" use="optional"/>

Example usage:
<panel classname="com.mycompany.installer.panels.TargetPanel"
id="targetPanel" jar="../build/installer/lib/myCompanyInstaller.jar" />






[IZPACK-1173] Make single-instance locking of the installer configurable Created: 29/Sep/14  Updated: 07/Nov/14  Resolved: 17/Oct/14

Status: Resolved
Project: IzPack
Component/s: Compiler, Documentation, Installer
Affects Version/s: None
Fix Version/s: 5.0

Type: Improvement Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File singleinstance.PNG    
Issue Links:
Related
relates to IZPACK-10 Single Instance Closed
Number of attachments : 1

 Description   

There is a built-in feature of popping up a message which asks the user whether an already running instance of the same installer should be ignored or rather whether to abort (see attachment).

This can be inconvenient for some use cases (clustering, sub-calls when an installer calls itself with different options,...).

Allow to disable this behavior, the default of enabling it should be unchanged.



 Comments   
Comment by Rene Krell [ 02/Oct/14 ]

Sent pull request: https://github.com/izpack/izpack/pull/279

Comment by Rene Krell [ 17/Oct/14 ]

Can be also controlled

  • in the <info> section:
    <singleinstance>false</singleinstance>
  • on the command line:
    -DMULTIINSTANCE=true

If at least one of both has the mentioned value the installer is allowed to run multiple instances.





[IZPACK-1172] Add option to forbid user installation if This programm was already installed (CheckedHelloPanel) Created: 26/Sep/14  Updated: 26/Sep/14

Status: Open
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: None

Type: Wish Priority: Minor
Reporter: Dmitriy Black Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I would be great if on CheckedHelloPanel I could forbid user to continue installtion if this programm was previously installed.
For eg. add attribute choise="YES_NO|OK"
if YES_NO then it would be like it is now.
if OK then only warinng will be displayed to restrict user continue installation.






[IZPACK-1171] NPE in IoHelper Created: 26/Sep/14  Updated: 26/Sep/14

Status: Open
Project: IzPack
Component/s: Utilities
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dmitriy Black Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows. Affects 5.0.0-rc3


Attachments: JPEG File NPE.JPG     JPEG File NPE -log.JPG    
Number of attachments : 2

 Description   

In my installer I am working with Windows Registry. I added RegistryInstallerListener to installer. I also don't need uninstaller, that is why in install.xml I have next:

<info>
<appname>AppName</appname>
<appversion>1.1.0</appversion>
<url>http://www.my.site.com/</url>
<uninstaller write="no" />
</info>

When my installation reaches installPanel, after all packs are executed NPE accured. Without any stacktrace. I debugged this and found the cause:

The cause is in method com.izforge.izpack.util.IoHelper.translatePath(String, Variables)

here is the source code:

public static String translatePath(String destination, Variables variables)

{ destination = variables.replace(destination); return translatePath(destination); }

In my case destination is null cause I do not have uninstall path. And method translatePath(destination) do not perform check for null.

here is the source code for translatePath method:
public static String translatePath(String destination)
{
// Convert the file separator characters

// destination = destination.replace('/', File.separatorChar);
// Undo the conversion if the slashes was masked with
// a backslash

// Not all occurencies of slashes are path separators. To differ
// between it we allow to mask a slash with a backslash infront.
// Unfortunately we cannot use String.replaceAll because it
// handles backslashes in the replacement string in a special way
// and the method exist only beginning with JRE 1.4.
// Therefore the little bit crude way following ...
if (destination.contains("
/") && !destination.contains(MASKED_SLASH_PLACEHOLDER))

{ // Masked slash found, placeholder not included in destination -> // perform masking. destination = replaceString(destination, "\\/", MASKED_SLASH_PLACEHOLDER); // Masked slashes changed to MASKED_SLASH_PLACEHOLDER. // Replace unmasked slashes. destination = destination.replace('/', File.separatorChar); // Replace the MASKED_SLASH_PLACEHOLDER to slashes; masking // backslashes will // be removed. destination = replaceString(destination, MASKED_SLASH_PLACEHOLDER, "/"); }

else

{ destination = destination.replace('/', File.separatorChar); }

return destination;
}

here is the stack trace, that I copied from eclipse debug:
Thread [IzPack - Unpacker thread] (Suspended)
IoHelper.translatePath(String) line: 655
IoHelper.translatePath(String, Variables) line: 610
RegistryInstallerListener.registerUninstallKey() line: 548
RegistryInstallerListener.afterPacks(List<Pack>) line: 300
RegistryInstallerListener.afterPacks(List<Pack>, ProgressListener) line: 215
InstallerListeners.afterPacks(List<Pack>, ProgressListener) line: 306
Unpacker(UnpackerBase).postUnpack(List<Pack>, FileQueue, List<UpdateCheck>) line: 681
Unpacker(UnpackerBase).unpack() line: 247
Unpacker(UnpackerBase).run() line: 228
Thread.run() line: 744

I attached screen shoots with error.
It would be a good thing to have more info on such errors. at least stacktrace. I tunrned on DEBUG mode.






[IZPACK-1170] Izpack ant task does not work if you use try to embed the install config inline Created: 19/Sep/14  Updated: 19/Sep/14

Status: Open
Project: IzPack
Component/s: Build
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: David Paterson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5.0.0RC3


Number of attachments : 0

 Description   

I have the following task defined in build.xml:

<echo message="Running IzPack to build the installer..."/>
<izpack output="$

{tomcat7.build.servicepack.dir}

/Infrared360-Tomcat7-ServicePack-$

{server.version}

-installer.jar"
installerType="standard"
inheritAll="true"
basedir="$

{build.installer.dir}

"
compression="deflate"
compressionlevel="9">
<config><![CDATA[<izpack:installation version="5.0"
xmlns:izpack="http://izpack.org/schema/installation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://izpack.org/schema/installation http://izpack.org/schema/5.0/izpack-installation-5.0.xsd">

<info>
<appname>Infrared 360</appname>
<appversion>5.0.1</appversion>
<appsubpath>Infrared360</appsubpath>
<javaversion>1.6</javaversion>
</info>
...
If fails with the following error:

[echo] Running IzPack to build the installer...
[izpack] Exception in thread "Thread-0" java.lang.NullPointerException: componentInstance cannot be null
[izpack] at org.picocontainer.adapters.InstanceAdapter.getInstanceClass(InstanceAdapter.java:69)
[izpack] at org.picocontainer.adapters.InstanceAdapter.<init>(InstanceAdapter.java:50)
[izpack] at org.picocontainer.DefaultPicoContainer.addConfig(DefaultPicoContainer.java:506)
[izpack] at com.izforge.izpack.core.container.AbstractContainer.addConfig(AbstractContainer.java:172)
[izpack] at com.izforge.izpack.ant.IzpackAntRunnable.run(IzpackAntRunnable.java:43)
[izpack] at java.lang.Thread.run(Thread.java:744)

I've tried many permutations but always end up with same exception if there is a nested <config/> tag.






[IZPACK-1169] Make UnpackerBase easier to sub class Created: 19/Sep/14  Updated: 22/Sep/14

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Minor
Reporter: Andres Olarte Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Abstract class UnpackerBase would be easier to sub class if the fields of the class were marked protected instead of private.



 Comments   
Comment by Andres Olarte [ 19/Sep/14 ]

Pull request: https://github.com/izpack/izpack/pull/277

Comment by Tim Anderson [ 20/Sep/14 ]

Don't do it this way; expose the fields you want to access using protected methods.

Comment by Andres Olarte [ 22/Sep/14 ]

Tim,

I updated my code as per your comment.

Thanks,

Andres





[IZPACK-1168] Bugfixing sprint week 38 Created: 19/Sep/14  Updated: 22/Sep/14  Resolved: 22/Sep/14

Status: Resolved
Project: IzPack
Component/s: None
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Task Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
supercedes IZPACK-1165 Package names not translated Resolved
supercedes IZPACK-1167 Avoid unclosed stream during unpacking Resolved
supercedes IZPACK-1166 Re-introduce panel translations using... Resolved
Number of attachments : 0

 Description   

See the subtasks for more information.



 Comments   
Comment by Rene Krell [ 19/Sep/14 ]

First wave of fixes: https://github.com/izpack/izpack/pull/276





[IZPACK-1167] Avoid unclosed stream during unpacking Created: 18/Sep/14  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by IZPACK-1168 Bugfixing sprint week 38 Resolved
Number of attachments : 0

 Description   

When updating an application while reusing the installation information from the previous setup, there can be left an open stream if an error occurs (class UnpackerBase):

try
{
    packs = (List<Pack>) oin.readObject();
}
catch (Exception exception)
{
    throw new InstallerException("Failed to read previous installation information", exception);
}
for (Pack pack : packs)
{
    installedPacks.add(pack);
}
FileUtils.close(oin);
FileUtils.close(fin);

Fix this by moving closing of the streams to a finally clause.



 Comments   
Comment by Rene Krell [ 19/Sep/14 ]

Fixed within https://github.com/izpack/izpack/pull/276





[IZPACK-1166] Re-introduce panel translations using the panel id as key without the classname as prefix Created: 18/Sep/14  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: IzPack
Component/s: Installer, Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by IZPACK-1168 Bugfixing sprint week 38 Resolved
Number of attachments : 0

 Description   

This has been more or less even a regression against earlier versions, see also http://docs.codehaus.org/display/IZPACK/Translating+Panel+Headlines:

Translating panel elements, like the headline or other labels could be in some previous versions done not only using the syntax <classname>.<panelID.<key> as the translation key in the resource CustomLangPack.xml_(<iso_code>), but also just using <panelID.<key>.

This possibility got lost after some refactoring.

Reintroducing this brings the following advantage:
If there are inherited panels, which use the appropriate labels from the parent class, the inherited classes do not need to redefine the translations with their classname prefix, but can continue to use the fixed translation keys.

In this phase this affects:

  • all panels: headline, summaryCaption
  • InstallPanel: all elements
  • FinishPanel: all elements

Example of usage:

install.xml:

<panels>
    <panel classname="InstallPanel" id="panel.install.install" condition="Install"/>
    <panel classname="InstallPanel" id="panel.install.update" condition="Update"/>
    <panel classname="InstallPanel" id="panel.install.uninstall" condition="Uninstall"/>
    <panel classname="FinishPanel" id="panel.finish.install" condition="Install"/>
    <panel classname="FinishPanel" id="panel.finish.update" condition="Update"/>
    <panel classname="FinishPanel" id="panel.finish.uninstall" condition="Uninstall"/>
</panels>

customLangPack.xml_eng:

  <str id="InstallPanel.panel.install.install.headline" txt="Installation in progress" />
  <str id="InstallPanel.panel.install.update.headline" txt="Update in progress" />
  <str id="InstallPanel.panel.install.uninstall.headline" txt="Uninstallation in progress" />
  <str id="FinishPanel.panel.install.headline" txt="Installation completed" />
  <str id="FinishPanel.panel.update.headline" txt="Update completed" />
  <str id="FinishPanel.panel.uninstall.headline" txt="Uninstallation completed" />

can be also written as

  <str id="panel.install.install.headline" txt="Installation in progress" />
  <str id="panel.install.update.headline" txt="Update in progress" />
  <str id="panel.install.uninstall.headline" txt="Uninstallation in progress" />
  <str id="panel.install.headline" txt="Installation completed" />
  <str id="panel.update.headline" txt="Update completed" />
  <str id="panel.uninstall.headline" txt="Uninstallation completed" />

This way you can for instance inherit custom panels from InstallPanel and FinishPanel without changing the translation keys to your custom classnames.



 Comments   
Comment by Rene Krell [ 19/Sep/14 ]

Fixed within https://github.com/izpack/izpack/pull/276





[IZPACK-1165] Package names not translated Created: 18/Sep/14  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: IzPack
Component/s: Installer, Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by IZPACK-1168 Bugfixing sprint week 38 Resolved
Number of attachments : 0

 Description   

The resources packsLang.xml is currently ignored for translating package names according to
http://docs.codehaus.org/display/IZPACK/Translating+Packages+in+PacksPanel
Instead, there are shown the default package names (attribute <pack name="..." .../> from install.xml regardless of which language has been chosen in the language dialog when the installer is launched.

The following parts are affected by this issue:

  • PacksPanel
  • InstallPanel - the package names shown in the "Pack installation progress" bar


 Comments   
Comment by Rene Krell [ 19/Sep/14 ]

Fixed within https://github.com/izpack/izpack/pull/276





Eclipse does show several warnings (IZPACK-1103)

[IZPACK-1164] unused imports Created: 17/Sep/14  Updated: 02/Oct/14  Resolved: 18/Sep/14

Status: Resolved
Project: IzPack
Component/s: Build
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Sub-task Priority: Trivial
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc4
Remaining Estimate: 15 minutes
Time Spent: Not Specified
Original Estimate: 15 minutes
Environment:

Eclipse IDE SpringToolSuite-3.6


Number of attachments : 0

 Description   

unused imports cause 51 warnings;



 Comments   
Comment by Tom Helpstone [ 17/Sep/14 ]

removed unused imports. This does eliminate 51 warnings.

Comment by Tom Helpstone [ 17/Sep/14 ]

sent PR #274





[IZPACK-1163] Provide validation for user input values entered during an automated installation Created: 15/Sep/14  Updated: 18/Sep/14

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Minor
Reporter: Ahmed Abu Lawi Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This is an improvement on a pending feature that was been submitted. This issue works with http://jira.codehaus.org/browse/IZPACK-1138, and http://jira.codehaus.org/browse/IZPACK-1102.

When a user is prompted for a missing value in the auto-install.xml, the value entered should be validated by the same validators that are used during a console or gui installation. Only after all validation passes should the value be entered into installData.

I suggest that during the automated installation, the installer should read the userInputSpec.xml for any validators and validate the input before continuing.



 Comments   
Comment by Ahmed Abu Lawi [ 15/Sep/14 ]

I have begun to work on this issue.

Comment by Ahmed Abu Lawi [ 18/Sep/14 ]

As I said I've started to work on this issue, however the work is dependent on a number of issues that are currently unresolved. The work isn't done yet and I can't send a PR until other issues are resolved, but I wanted to see if the manner in which I'm solving this issue is ok.

The majority of the changes are in this file, https://github.com/ahmedlawi92/izpack/blob/autoValidators/izpack-panel/src/main/java/com/izforge/izpack/panels/userinput/UserInputPanelAutomationHelper.java in the runAutomated function.

There are two things I'm unsure of. If I got access to the userInputSpec in an acceptable way on line 184, and if creating a DefaultObjectFactory as I did in line 174, to use to create the FieldValidatorObjects is acceptable.

Thank you for any input.





[IZPACK-1162] XSD: <condition type="contains"> is missing Created: 12/Sep/14  Updated: 12/Sep/14  Resolved: 12/Sep/14

Status: Resolved
Project: IzPack
Component/s: Compiler
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Trivial
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc4
Remaining Estimate: 15 minutes
Time Spent: Not Specified
Original Estimate: 15 minutes

Number of attachments : 0

 Description   

In the XSD for <condition> the variant type="contains" is missing.



 Comments   
Comment by Tom Helpstone [ 12/Sep/14 ]

PR "Izpack-1162" sent (https://github.com/izpack/izpack/pull/271)
(sorry for not giving a descriptive title)

Comment by Rene Krell [ 12/Sep/14 ]

Pull request #271 merged.
Thanks for contributing.

I will replicate this also to the website for XML editors working with the remote schema.





[IZPACK-1161] UserInputPanel - dynamic hiding/unhiding of fields depending on conditions affected by settings of radiobutton fields on the same panel broken Created: 11/Sep/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There is a problem with dynamically hiding/unhiding user panel fields bound to conditions that are being changed in the same panel.

Example:

<field type="radio" variable="dbsystem" summaryKey="key.dbsystem">
  <spec>
    <choice txt="MSSQL" value="mssql" id="text.dbsystem.mssql" />
    <choice txt="Oracle" value="oracle" id="text.dbsystem.oracle" set="true" />
    <choice txt="SAP Hana" value="hdb" id="text.dbsystem.hana" />
  </spec>
</field>
<field type="staticText" align="left" txt="Please select whether you want to use Oracle RAC (real application clusters) architecture." id="text.orarchsettings.description" conditionid="OraDBSelected" />
  <field type="staticText" align="left" txt="Please select whether you want to use MSSQL named instance." id="text.mssqlarchsettings.description" conditionid="mssqlDBSelected" />
  <field type="space" conditionid="mssqlDBSelected|OraDBSelected" />
  <field type="check" variable="oraarch" conditionid="OraDBSelected" summaryKey="key.dbsystem.oraclerac">
  <spec txt="Use Oracle RAC (real application clusters) architecture." true="true" false="false" set="false" id="text.oraarch.label" />
</field>

Displaying of "oraarch" is bound to condition OraDBSelected which is evaluated as true when the "Oracle" radiobutton is selected. "Oracle" is pre-selected by default but the condition is not resolved as true (and therefore the oraarch is not even displayed and the variable resolved).

This means that the panel content has to be refreshed dynamically even on activating to show the current state.



 Comments   
Comment by Rene Krell [ 11/Sep/14 ]

Trivial fix in pull request https://github.com/izpack/izpack/pull/270:
No action event triggered on setSelected(boolean) for JRadioButton, must be called explicitly.





[IZPACK-1160] Dynamic variables unset if none of a couple of dynamic variable definitions fits conditions although set in UserInputPanel Created: 29/Aug/14  Updated: 16/Dec/14  Resolved: 16/Dec/14

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Duplicate Votes: 0
Labels: 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by IZPACK-1197 Variable and dynamic variable improve... Resolved
Number of attachments : 0

 Description   

This is a regression against RC2:

There has been introduced the following change on dynamic variables:
Dynamic variables are unset if none of a couple of dynamic variable definitions concerning one and the same variable name fits its conditions.

This is useful for cleaning up variables that are not needed but has one side effect:
Although the same variable has been set in a UserInputPanel, after leaving that panel the variable is unset again.

Example:

Imagine there is an installer handling installations from scratch or update to previous versions. The app allows handling of different database systems.

<dynamicvariables>
  <variable name="dbsystem" value="mssql" checkonce="true" condition="updateMSSQL+!Install"/>
  <variable name="dbsystem" value="oracle" checkonce="true" condition="updateOracle+!Install"/>
  <variable name="dbsystem" value="hdb" checkonce="true" condition="updateHANA+!Install"/>
</dynamicvariables>

If ${dbsystem} is used now in a UserInputPanel as target variable of an user input field, like:

<field type="radio" variable="dbsystem">
  <spec>
    <choice txt="MSSQL" value="mssql" id="text.dbsystem.mssql" />
    <choice txt="Oracle" value="oracle" id="text.dbsystem.oracle" set="true" />
    <choice txt="SAP Hana" value="hdb" id="text.dbsystem.hana" />
  </spec>
</field>

the variable ${dbsystem} is unset after leaving this panel although there has been chosen a value by the user.

Workaround: Explicitly refresh ${dbsystem} for installations from scratch:

<dynamicvariables>
  <variable name="dbsystem" value="${dbsystem}" condition="Install"/>
  <variable name="dbsystem" value="mssql" checkonce="true" condition="updateMSSQL+!Install"/>
  <variable name="dbsystem" value="oracle" checkonce="true" condition="updateOracle+!Install"/>
  <variable name="dbsystem" value="hdb" checkonce="true" condition="updateHANA+!Install"/>
</dynamicvariables>

The above workaround should not be necessary. If a variable receives a value from a panel it should get priority and unsetting this variable in case of unmet conditions should not be allowed. However, changing it in a matching dynamic variable definition should be still possible.

Preserving a value from a user input field should happen just in case a user CHANGED the value explicitly, NOT when displaying an unchanged default value.



 Comments   
Comment by Rene Krell [ 16/Dec/14 ]

Solved in IZPACK-1197





[IZPACK-1159] Rule field doesn't show the value of the underlying variable Created: 25/Aug/14  Updated: 26/Aug/14  Resolved: 26/Aug/14

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This is a regression against 5.0.0 RC2:
Currently, all rule fields in a UserInputPanel are shown empty even if the underlying variable has a valid initial value. Furthermore, the underlying variable is emptied after leaving the according panel.



 Comments   
Comment by Rene Krell [ 26/Aug/14 ]

Forgot to announce: https://github.com/izpack/izpack/pull/269
Merged now, problem disappeared with this fix.





[IZPACK-1158] Allow user to pass variables from the command line Created: 25/Aug/14  Updated: 02/Oct/14

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Ahmed Abu Lawi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The user should have some method of passing variables from the command line to installData. This relates to issue IZPACK-1138.

In the proposed implementation the user would be able pass variables in two ways.

1) By writing out the key-value pairs on the command line as follows,

java -jar <installer jar> -variables var1=value1,var2=value2

2) Passing in a variables file containing a list of key value pairs, for example

java -jar <installer jar> -varfile myVariablesFile

where myVariablesFile contains the following,

var1=value1
var2=value2

In both implementations the var1 and var2 will be entered into installData with value1 and value2 as their values respectively.



 Comments   
Comment by Ahmed Abu Lawi [ 25/Aug/14 ]

PR sent, https://github.com/izpack/izpack/pull/268

Comment by Tom Helpstone [ 26/Aug/14 ]

It could be valuable to allow optionally a ini-file format for the varfile.

Example:

[section1]
var1=value1
var2=value2
[section2]
var1=value3

would be equivalent to

section1.var1=value1
section1.var2=value2
section2.var1=value3

This can be used, when similar things are configured for different components. For example a mailing or logging configuration for several components, which are identical for most use cases, but not for all. With the Ini-File format most people can Copy&Paste this parts, avoiding misconfiguration.

Comment by Ahmed Abu Lawi [ 15/Sep/14 ]

Sorry for taking so long to reply Tom.

That sounds like a pretty good idea, I'll look into adding that functionality to the pull request.

Comment by Rene Krell [ 29/Sep/14 ]

There should be considered the availability of system properties from wherever variables are resolved during the installation, see http://docs.codehaus.org/display/IZPACK/Variables:
The syntax for accessing them is
${SYSTEM[variable.name]}

In this case you can decide from within the installer whether to use the compiled-in variable or the one from the command line.

Comment by Ahmed Abu Lawi [ 01/Oct/14 ]

Hi Rene,

I'm not sure I fully understand your last comment.

From the link you posted I understand that you can currently pass variables into the installer from the command line by passing it as a System property, and reference those in the xml files using the ${SYSTEM[variable.name]} syntax.

I still believe that believe that this feature would prove useful to users of the installer. It would make running a truly unattended installation while omitting sensitive information from auto-install.xml, as described in IZPACK-1138, possible.

I've also updated the PR to include support for ini files. It works as follows,

Example:
var1=value1
[section1]
var1=value1
var2=value2
[section2]
var1=value3

would be equivalent to
var1=value1
section1.var1=value1
section1.var2=value2
section2.var1=value3

Comment by Rene Krell [ 02/Oct/14 ]

Initially I'm really glad about your contribution. I just wanted to notice you that it is generally possible to pass values on the command line directly to the installer. Just for discussing.
Your way is of course more comfortable.

Anyway I suggest not to put this into 5.0.0, because we are still in a stabilizing phase with release candidates to finally release it. As soon as we finally release it, we will reopen the trunk for new features. Maybe this could be put also into a 5.0.X later or 5.1. We will open branches for those versions later. Would this be ok for you?

Comment by Rene Krell [ 02/Oct/14 ]

Omitting password values from being written to auto-install.xml can be done separately probably still in 5.0.0. I'm aware of this, but this is a standalone issue.

Comment by Ahmed Abu Lawi [ 02/Oct/14 ]

I actually wasn't aware of that feature before you posted the link, thank you for letting me know.

Also I completely understand and would definitely be fine leaving this for a later release.

Comment by Rene Krell [ 02/Oct/14 ]

Maybe we even get this in. I'm currently releasing RC4.
It is just about having a couple of test results in the next cycle.
I'm still not sure whether there will be a RC5, it depends also on what the other developers and contributors wish.





[IZPACK-1157] ConfigurationInstallerListener: not possible to patch one and the same file twice from within one specification Created: 22/Aug/14  Updated: 22/Aug/14

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Rene Krell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It seems the following ConfigurationActionsSpec.xml resource doesn't work the way it should:

<izpack:configurationactions version="5.0"
                             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                             xmlns:izpack="http://izpack.org/schema/configurationactions"
                             xsi:schemaLocation="http://izpack.org/schema/configurationactions http://izpack.org/schema/5.0/izpack-configurationactions-5.0.xsd">

  <pack name="Core files">

    <configurationaction order="afterpack">

      <!-- Patch and merge all property files -->
      <configurableset type="options" cleanup="true" keepOldKeys="false" keepOldValues="true" overwrite="true"
                       todir="${INSTALL_PATH}/config"
                       condition="isCompatibleUpgrade">
        <fileset dir="${INSTALL_PATH}/config">
          <include name="*.properties.configbak"/>
        </fileset>
        <mapper type="glob" from="*.properties.configbak" to="*.properties"/>
      </configurableset>

      <configurable type="options" cleanup="true"
                    tofile="${INSTALL_PATH}/config/system.properties"
                    condition="isCompatibleUpgrade">
        <entry key="prop1" value="false"/>
        <entry key="prop2" value="true"/>
      </configurable>

    </configurationaction>

  </pack>

</izpack:configurationactions>

The expectation is first to overtake old values of preserved keys to the new configuration and after that explicitly setting prop1 and prop2.
If a file should be patched two or more times it must be explicitly excluded from configurableset and patched separately:

<izpack:configurationactions version="5.0"
                             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                             xmlns:izpack="http://izpack.org/schema/configurationactions"
                             xsi:schemaLocation="http://izpack.org/schema/configurationactions http://izpack.org/schema/5.0/izpack-configurationactions-5.0.xsd">

  <pack name="Core files">

    <configurationaction order="afterpack">

      <!-- Patch and merge all property files -->
      <configurableset type="options" cleanup="true" keepOldKeys="false" keepOldValues="true" overwrite="true"
                       todir="${INSTALL_PATH}/config"
                       condition="isCompatibleUpgrade">
        <fileset dir="${INSTALL_PATH}/config">
          <include name="*.properties.configbak"/>
          <exclude name="system.properties*"/>
        </fileset>
        <mapper type="glob" from="*.properties.configbak" to="*.properties"/>
      </configurableset>

      <configurable type="options" cleanup="true" keepOldKeys="false" keepOldValues="true"
                    patchfile="${INSTALL_PATH}/config/system.properties.configbak"
                    tofile="${INSTALL_PATH}/config/system.properties"
                    condition="isCompatibleUpgrade">
        <entry key="prop1" value="false"/>
        <entry key="prop2" value="true"/>
      </configurable>

    </configurationaction>

  </pack>

</izpack:configurationactions>

It should be fixed to meet the initial expectation.






[IZPACK-1156] Allow replaceInstallPath attribute for file fields Created: 18/Aug/14  Updated: 19/Aug/14

Status: Open
Project: IzPack
Component/s: Installer
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Improvement Priority: Minor
Reporter: Ahmed Abu Lawi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Allow a replaceInstallPath attribute that can be added to the specs of a user input panel file, directory or multiple file field.

If this attribute is set to true, the installer will check to see if the install path is a sub path of the given file or directory and replace any instances of the install path with the variable, ${INSTALL_PATH}.

While performing the auto install, the ${INSTALL_PATH} variable will be substituted with the install path provided at the top of the auto-install.xml file.

This feature will allow users of the auto install to update the install path in only one part of the auto-install.xml file instead of updating every path that needs be changed.



 Comments   
Comment by Rene Krell [ 19/Aug/14 ]

I don't still understand this sufficiently, especially the advantage of this. If this concerns just an auto-install.xml you can use every kind of XML preprocessing (Maven Config Processor Plugin) to replace some placeholders.
Furthermore, throughout an IzPack installation, you can use ${INSTALL_PATH} to replace this placeholder the path chosen in TargetPanel on the fly.

Do you need this for exporting the auto-install.xml from FinishPanel, or rather for reusing an existing auto-install.xml in an unattended installation to not repeat something in it?

Can you please explain this with an example from scratch?

Comment by Ahmed Abu Lawi [ 19/Aug/14 ]

Hello Rene,

Sorry if the original post wasn't clear.

This feature is intended to make the unattended installer easier to use by maintaining paths relative to the target in the auto-install.xml. It will allow the user to change the target path declared at the top of the auto-install.xml and have all other relative paths be adjusted to stay relative to the new target. The attribute should be renamed to 'relativePath' since it marks paths as relative to the target.

Consider the following example,

1) Set the relativePath attribute for a file, dir or multiple file field. Not setting a value will default to false.

<field type="file" align="left" variable="vault.path" summaryKey="vault.path.description">
<description id="vault.path.description"/>
<spec size="34" relativePath="true" />
</field>

2) The target path entered in the target panel during the regular installation is set to '/home/user/install_directory'

3) On the panel with the file field defined by the xml above, the file's path is given by the user as '/home/user/install_directory/vault'

4) When writing the auto-install.xml entries for fields with relativePath=true, the installer will substitute '/home/user/install_directory' with '$

{INSTALL_PATH}'. So the entry in the auto-install.xml file for the 'vault.path' variable above will be '${INSTALL_PATH}

/vault'

5) A new user, user2, will use the auto-install.xml that was just produced and change the target path to '/home/user2/my_install_folder'

6) When user2 runs the automated installation, the product will be installed while maintaining all relative paths to his new target. In this example the vault will be installed at '/home/user2/my_install_folder/vault'

Without this feature, user2 would have to manually (or using some other xml transformation as you mentioned) change the target path and all other install paths from '/home/user/my_install_folder' to '/home/user2/my_install_folder'.





[IZPACK-1155] VariableCondition is missing replace-call Created: 14/Aug/14  Updated: 14/Aug/14  Resolved: 14/Aug/14

Status: Resolved
Project: IzPack
Component/s: None
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Erik Bergfur Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When using ${SYSTEM[variable.name]} in a condition, the value does not get replaced.

I don't have a proper build set up, but here is a suggested code-change:

diff --git a/izpack-core/src/main/java/com/izforge/izpack/core/rules/process/VariableCondition.java b/izpack-core/src/main/java/com/izforge/izpack/core/rules/process/VariableCondition.java
index 6247cc4..b2ec4d5 100755
--- a/izpack-core/src/main/java/com/izforge/izpack/core/rules/process/VariableCondition.java
+++ b/izpack-core/src/main/java/com/izforge/izpack/core/rules/process/VariableCondition.java
@@ -98,6 +98,7 @@ public class VariableCondition extends Condition
             else
             {
                 Variables variables = installData.getVariables();
+                val = variables.replace(val);
                 return val.equals(variables.replace(value));
             }
         }
--
1.9.0.msysgit.0


 Comments   
Comment by Rene Krell [ 14/Aug/14 ]

Which version of IzPack is this reported against 5.0.0 RC2, 5.0.0 RC3 (current master) etc.?

Comment by Erik Bergfur [ 14/Aug/14 ]

The bug appears in current master with the changes in IZPACK-1066

Comment by Rene Krell [ 14/Aug/14 ]

Sent pull request https://github.com/izpack/izpack/pull/266 based on this hint.

Comment by Rene Krell [ 14/Aug/14 ]

Pull request #266 merged.
Thanks for the hint.





[IZPACK-1154] Default value selection for combo fields Created: 12/Aug/14  Updated: 14/Aug/14  Resolved: 14/Aug/14

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Miles Tjandrawidjaja Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Testcase included: yes
Patch Submitted:
Yes
Number of attachments : 0

 Description   

After going through some GUI test and recently seeing http://jira.codehaus.org/browse/IZPACK-1152 I found out that the set attribute is not working as intended for combo boxes, but the set attribute works fine for radio fields.

1. Fix set attribute for combo boxes.
2. Fix UserInputPanel Tests included tests for combo box and radio buttons

I've also realize processor does not compile for combo boxes.
Maybe it is no longer supported, otherwise an issue should be opened.

Example of previous specification that does not compile, and looks like perhaps no supported.

<field type="combo" variable="combo4">
    <spec txt="Combo4:" id="combo4.id">
        <choice processor="com.izforge.izpack.panels.userinput.ComboProcessor" set="value4"/>
    </spec>
</field>


 Comments   
Comment by Miles Tjandrawidjaja [ 12/Aug/14 ]

PR sent: https://github.com/izpack/izpack/pull/265

Comment by Rene Krell [ 14/Aug/14 ]

Pull request #256 merged.
Thanks for contributing.





[IZPACK-1153] GUI Target Panel Test is Fixes Created: 12/Aug/14  Updated: 13/Aug/14  Resolved: 13/Aug/14

Status: Resolved
Project: IzPack
Component/s: Installer, Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Test Priority: Minor
Reporter: Miles Tjandrawidjaja Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Patch Submitted:
Yes
Number of attachments : 0

 Description   

The testEmptyPath and testNotWritable test in TargetPanelTest is currently not correct.

1. testEmptyPath expects a warning about entering an empty path

  • Warning about empty path cannot happen since when entering an empty path the target panel is filled with the default value of "user.dir". It is very likley the "user.dir" exists, otherwise how could you launch the JVM from there? At this point instead you will receive the "TargetPanel.warn" message instead.
  • Therefore this test should be testing for "TargetPanel.warn"
  • Also when there is a possibility of overwriting contents on the file system it seems like we actually want to warn with a question, rather than ask a question. A new prompt should be implemented to handle this type of case.

2. testNotWritable gets the wrong "root" directory

  • The temporary folder object actually overwrites the getRoot() method and return the root of the temporary folder instead of the root of the path.
  • This should be updated to retrieve the appropriate root directory


 Comments   
Comment by Miles Tjandrawidjaja [ 12/Aug/14 ]

PR sent: https://github.com/izpack/izpack/pull/264

Comment by Rene Krell [ 13/Aug/14 ]

Pull request #264 merged.
Thanks for this contribution.





[IZPACK-1152] Default value selection of choice fields (radio, combo) broken - set attribute does not work like in RC2 Created: 11/Aug/14  Updated: 11/Aug/14  Resolved: 11/Aug/14

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified