[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="https://izpack.github.io/schema/langpack" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://izpack.github.io/schema/langpack https://izpack.github.io/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="https://izpack.github.io/schema/langpack" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://izpack.github.io/schema/langpack https://izpack.github.io/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="https://izpack.github.io/schema/configurationactions"
      xsi:schemaLocation="https://izpack.github.io/schema/configurationactions
      https://izpack.github.io/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="https://izpack.github.io/schema/userinput" xsi:schemaLocation="https://izpack.github.io/schema/userinput https://izpack.github.io/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="https://izpack.github.io/schema/installation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://izpack.github.io/schema/installation https://izpack.github.io/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="https://izpack.github.io/schema/configurationactions"
                             xsi:schemaLocation="https://izpack.github.io/schema/configurationactions https://izpack.github.io/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="https://izpack.github.io/schema/configurationactions"
                             xsi:schemaLocation="https://izpack.github.io/schema/configurationactions https://izpack.github.io/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

Number of attachments : 0

 Description   

Currently, the default value selection of radio and combo fields does not work any longer like in RC2.

For example, instead of marking a radio choice selected like this:

<field type="radio" variable="dbms" summaryKey="key.dbms">
  <spec>
    <choice txt="MSSQL" value="mssql" id="text.dbsystemsettings.mssql" />
    <choice txt="Oracle" value="oracle" id="text.dbsystemsettings.oracle" set="true" />
    <choice txt="SAP Hana" value="hdb" id="text.dbsystemsettings.hana" />
  </spec>
</field>

the installer expects the default value to be set as as variable value in the "set" attribute of the <spec> tag.

This breaks existing installers.



 Comments   
Comment by Rene Krell [ 11/Aug/14 ]

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

Comment by Rene Krell [ 11/Aug/14 ]

Pull request #263 merged.





[IZPACK-1151] Shortcut Logic Improvements and Fixes Created: 05/Aug/14  Updated: 11/Aug/14  Resolved: 11/Aug/14

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

Type: Improvement 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 following proposal is to allow greater flexibility of the user options in the shortcut panel. This issue should cover both https://jira.codehaus.org/browse/IZPACK-1128 and https://jira.codehaus.org/browse/IZPACK-1086.

1. Allow desktop shortcuts to be independent of start menu shortcuts

2. Allow startup shortcuts to be independent of start menu shortcuts
Attributes: programGroup, applications, startMenu still fall under the start menu category

3. Data put into the automatic installation file has been updated since startup and desktop shortcuts are now independent of start menu shortcuts. Update should still be backwards comptabile with older automatic installation files.

4. Originally when using the "applications" attribute without a "programGroup" attribute defined, on Windows mahcines, the user is still able to select in which subdirectory to place the shortcut shortcut. When the user selects one of these directories the shortcut ends up in the top of the application hierarchy regardless of their choice. For UI reasons we can keep this options area but present only a "Default" option. Also when using ther "programGroup" attribute we should present a "Default" option to be consistent. The "Default" option provides the same functionality as if none of the options were selected.

5. Refactored shortcuts panels / logic so that it is easier to reason.

  • The shortcuts spec is only read everytime the user has reached the shortcut panel, and not on startup. We may now more easily reason that spec always has to be updated based on the variables it contains (think variable substitutor). A read of the specification file on startup is ineffective as variables may have not yet been set
  • When running a GUI installation on startup all ShortcutPanel components are generated. When the user reaches the panel the shortcut speicification will be read and the panel view will update accordingly by hiding/showing. This way we can more easily reason the difference between the shortcut logic and the views that represent it
  • Constant strings have been moved to its own file "ShortcutConstants.java". There are enough constants that we should seperate this concern, it adds alot of noise if left in ShortcutPanelLogic


 Comments   
Comment by Miles Tjandrawidjaja [ 05/Aug/14 ]

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

Comment by Rene Krell [ 11/Aug/14 ]

Resolved merge conflicts and pushed merge request #260 manually.
Thank you.





[IZPACK-1150] Uninstaller fails when .installationinformation or automatic file is generated in the same installation path Created: 29/Jul/14  Updated: 11/Aug/14  Resolved: 11/Aug/14

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

Type: Bug Priority: Major
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   

When running the Uninstaller.jar, it will inform you that the target directory ($INSTALL_PATH) cannot be removed and that administrative privileged may be required. For some cases (which includes a default use case) this is incorrect.

1. If the .installationinformation file is created the uninstaller should remove this file.
2. If the automatic installation file is created in the target path the uninstaller should remove this file. We do not want to remove the automatic installation if it is not placed in the target path.

When the two points above are resolved the target path should be empty of installer files and can now be removed of the directories contains no more files.



 Comments   
Comment by Miles Tjandrawidjaja [ 29/Jul/14 ]

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

Comment by Rene Krell [ 11/Aug/14 ]

Pull requesr #258 merged.
Thank you.





[IZPACK-1149] Automatic file generation fails when choosing not to install shortcuts through console installation Created: 28/Jul/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: 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   

Currently if the shortcut panel is being used, and the installer is being run as a console installation, installer fails to generate the auto-install.xml if the user choose not to install the shortcuts.



 Comments   
Comment by Miles Tjandrawidjaja [ 28/Jul/14 ]

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

Comment by Rene Krell [ 11/Aug/14 ]

Pull request #257 merged.
Thank you.





[IZPACK-1148] Directory paths not being validated, causes installation failures in Windows Created: 24/Jul/14  Updated: 26/Jul/14  Resolved: 26/Jul/14

Status: Resolved
Project: IzPack
Component/s: Installer
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
Environment:

Windows


Patch Submitted:
Yes
Number of attachments : 0

 Description   

Input towards the TargetPanel and ShortCutPanel should be validated based on the running OS contraints. For Window's we should follow http://msdn.microsoft.com/en-us/library/aa365247.aspx (see the reserved characters under Naming Convention).

Since these constraints or not validated when hitting next, the installation fails when it tries to write out to some directory like C:\bad?. Also the ShortcutPanel just does not create the shortcuts.



 Comments   
Comment by Miles Tjandrawidjaja [ 24/Jul/14 ]

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

Comment by Rene Krell [ 26/Jul/14 ]

Pull request merged.
Thanks for contributing.





[IZPACK-1147] JDKPathPanel Issues Created: 24/Jul/14  Updated: 25/Jul/14  Resolved: 25/Jul/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: Unassigned
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   
  • GUI JDKPathPanel does not persist path field
  • Console mode appropriately shows default JAVA_HOME while GUI does not (tries to show path to JRE)
  • Console mode does not provide auto-completion
  • JDKPathPanel.skipIfValid allows skipping panel in GUI but is not being applied to the console
  • JDKPathPanel.skipIfValid only includes values "yes" and "no", I think it should also include values "true" and "false" to be consistent
  • Error message strings in JDKPathPanel are hard coded in english
  • Console JDKPathPanel and GUI JDKPathPanel are out of sync
  • A lot of code duplication between Console JDKPathPanel and GUI JDKPathPanel


 Comments   
Comment by Miles Tjandrawidjaja [ 24/Jul/14 ]

PR sent: https://github.com/izpack/izpack/pull/252
Edit: I think I need to do more tests in Windows regarding the registryRevolver

Comment by Rene Krell [ 24/Jul/14 ]

Pull request #252 merged.
Thank you for contributing.





[IZPACK-1146] GUI Installer - UserInputPanel radiobutton/checkbox variables set even though the panel hasn't been visited Created: 23/Jul/14  Updated: 23/Jul/14  Resolved: 23/Jul/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 has introduced since 5.0.0-rc2:

For UserInputPanels in GUI/Swing installers the variables for radiobuttons and checkboxes are already set to the default values although the panel hasn't been reached. This is not the behavior like originally designed in IzPack. Variables should be unset as long as the panel that sets them hasn't been left or as long as an explicit variable or dynamicvariable definition doesn't set them explicitly.

This breaks existing installers in a nasty way, especially if there are conditions bound to such variables that rely on the original behavior.

The background of NOT setting UserInputVariables to its defaults from the beginning is that you are able to run the installer in different modes (e.g. update vs. installation or MSSQL vs. Oracle DB) by skipping certain panels according to the input the user made, in most cases utilizing conditions or pack selection conditions. If a panel is skipped and thus not valid for that mode then the according variables should not even been touched or set along with the panel definition.



 Comments   
Comment by Rene Krell [ 23/Jul/14 ]

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





[IZPACK-1145] GUI Installer - radiobutton/checkbox variables set even if the panel hasn Created: 23/Jul/14  Updated: 27/Jan/15  Resolved: 27/Jan/15

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

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

Number of attachments : 0

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

This bug report seems incomplete; what happens with the buttons?

Comment by Rene Krell [ 27/Jan/15 ]

Sorry, this is of course invalid





[IZPACK-1144] Button field to perform custom actions and validations Created: 22/Jul/14  Updated: 07/Oct/14  Resolved: 07/Oct/14

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

Type: New Feature 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   

It would be nice to have a button field to give the user a choice to perform custom actions or validations that are non-critical. A use case for this would be testing a connection to a given service based on the information the user has provides (ex. ldap, web-app).

Example button field implementation below:

<field type="button" id="label">
    <spec id="button.text" successMsg="success.msg">
        <run class="com.you.button.Test" >
            <msg id="error.msg" name="error"/>
            <msg id="warning.msg" name="warn"/>
        </run>
    </spec>
</field>

The field allows us to customize the button label, and the text of the button. We also provide a success message, and any amount of messages that may be useful to the custom action/validator. The custom action/validator may access strings based on the given names.

It may be easier to understand how this button field works by presenting an example.
1. Clone sample installer from https://github.com/mtjandra/SampleInstaller.
2. Build IzPack with the pull request indicated in the comments
3.Checkout "buttonField" branch and run ./build.sh to build the installer
4. Finally run the sample installer "java -jar installer/target/sample-installer.jar".
5. You will find the buttons on the pokedex panel.

Button is supported both in console and gui installations.
If it looks good, the online-documentation will be updated.



 Comments   
Comment by Miles Tjandrawidjaja [ 22/Jul/14 ]

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

Comment by Rene Krell [ 26/Jul/14 ]

Interesting feature, worth to go to 5.0, no breakings or destabilizing code.
Pull request merged.
Thanks for contributing.

Comment by Rene Krell [ 22/Aug/14 ]

I tried this according to the documentation:

<field type="custom" minRow="1" maxRow="3" variable="creature.count">
    <spec>
        <col>
            <field type="combo" variable="creature.type" summaryKey="creature.type">
                <description id="creature.type"/>
                <spec id="creature.type">
                    <choice id="creature.type.1" value="Bulbasaur"/>
                    <choice id="creature.type.2" value="Charmander"/>
                    <choice id="creature.type.3" value="Geodude"/>
                    <choice id="creature.type.4" value="Mew"/>
                    <choice id="creature.type.5" value="Pikachu"/>
                    <choice id="creature.type.6" value="Squirtle"/>
                </spec>
            </field>
            <validator class="com.izforge.izpack.panels.userinput.validator.UniqueValidator" id="creature.unique" />
        </col>
        <col>
            <field type="combo" variable="creature.colour">
                <description id="creature.colour"/>
                <spec id="creature.colour">
                    <choice id="creature.colour.1" value="Blue"/>
                    <choice id="creature.colour.2" value="Green"/>
                    <choice id="creature.colour.3" value="Indigo"/>
                    <choice id="creature.colour.4" value="Orange"/>
                    <choice id="creature.colour.5" value="Red"/>
                    <choice id="creature.colour.6" value="Violet"/>
                    <choice id="creature.colour.7" value="Yellow"/>
                </spec>
            </field>
        </col>
        <col id="creature.name">
            <field type="text" variable="creature.name" summaryKey="creature.name">
                <spec id="creature.name" size="10"/>
                <validator class="com.izforge.izpack.panels.userinput.validator.NotEmptyValidator" id="creature.name.empty" />
            </field>
        </col>
    </spec>
</field>

With this, I get not default values in the comboboxes, they are simply empty.

Can you have a look at it, please?

Comment by Miles Tjandrawidjaja [ 22/Aug/14 ]

Hello I just tried with the latest IzPack and it seems to be working for me.
I think maybe the problem you are encountering is that you do not have the "creature.type.1" id defined in your CustomLangPack.xml.
Try changing the choice "id" to "txt" and you should see values in the comboBox.
I tested with https://github.com/mtjandra/SampleInstaller which should be using this exact configuration in its UserInputSpec.xml.





[IZPACK-1143] Allowed to remove a row from custom field when at minimum amount of rows Created: 22/Jul/14  Updated: 23/Jul/14  Resolved: 23/Jul/14

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

Type: Bug Priority: Major
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   

There is a bug where you may remove a row from a customField even if you are already at the minimum amount of rows. This is a bug due to the CustomInputField.java setEnable method.

Also if the minRow and maxRow are equivalent we should hide the row control buttons as they are of no use.



 Comments   
Comment by Miles Tjandrawidjaja [ 22/Jul/14 ]

PR: https://github.com/izpack/izpack/pull/249

Comment by Rene Krell [ 23/Jul/14 ]

Merged.





[IZPACK-1142] SplashScreen appears in console and automatic installation Created: 21/Jul/14  Updated: 25/Jul/14  Resolved: 25/Jul/14

Status: Resolved
Project: IzPack
Component/s: Installer
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

Patch Submitted:
Yes
Number of attachments : 0

 Description   

When running installer thought console or automatic mode, splash screen (if defined) will appear and remain until installer. The source of the problem is that the splash screen is defined in the jar's MANIFEST.MF file. To avoid having the splash screen appear in console or automatic mode we must remove the splash screen attribute from the MANIFEST.MF file.

Proposal.
1. Add splash screen as a resource, similar to the heading panel
2. Splash screen will be defined as a modifier in the <guiprefs> similar to the heading panel attributes. This seems intuitive since it only applies to the GUI installation.
3. Allow the value of the modifier contain how for the minimum amount of time the splash screen should be displayed for in milliseconds. Since the splash screen is shown later in the program execution it appear for a much shorter time, also splash screen appears only for an instant for faster machines. To meet some UI requirements we should allow the user to define how long to have the splash screen remain.
4. Splash screen should launch once installer recognizer it is running in GUI mode

Note: By removing the logic of the <splash> screen attribute this will cause incompatibility with older installations as they would have to update their specifications to use the splash screen.



 Comments   
Comment by Miles Tjandrawidjaja [ 21/Jul/14 ]

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

Comment by Rene Krell [ 22/Jul/14 ]

Pull request merged.
Thank you for this contribution.

Comment by Rene Krell [ 22/Jul/14 ]

Please adapt the documentation with the hint of accidentally breaking existing installers.
This is an acceptable level of breakage, though

Comment by Miles Tjandrawidjaja [ 22/Jul/14 ]

Sorry it looks like I forgot to test with not declaring the splash image as a resource.
It tries to load the splash even when its not defined and since its not in try block it does not catch the exception when a resource is not found.
This is really bad, please apply fix https://github.com/izpack/izpack/pull/248

Comment by Miles Tjandrawidjaja [ 22/Jul/14 ]

SEVERE: Image icon resource not found in /resources/Splash.image
This is not an acceptable level of breakage!
Please apply the fix above.
Should now only fail if you specify the "useSplashScreen" modifier but have not declared your Splash.image resource.

Comment by Rene Krell [ 23/Jul/14 ]

Merged, thank you.





[IZPACK-1141] Automated Installation Prompts User for Missing Values Created: 18/Jul/14  Updated: 18/Jul/14

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

Type: Improvement Priority: Major
Reporter: Francisco Canas 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   

An automated installation should prompt the user when a value is found missing from a userInputPanel entry in the automated xml file.

For example, if the automated xml file has the following entry:
<com.izforge.izpack.panels.userInputPanel id="admin.user.panel">
<entry key="admin.username" value="admin"/>
<entry key="admin.password"/>
</com.izforge.izpack.panels.userInputPanel>

The Automated installer should prompt the user for the missing password before continuing with the installation.

This is related to http://jira.codehaus.org/browse/IZPACK-1138 and http://jira.codehaus.org/browse/IZPACK-1102



 Comments   
Comment by Francisco Canas [ 18/Jul/14 ]

Submitted a PR for this issue: https://github.com/izpack/izpack/pull/245





[IZPACK-1140] Install should respect headingImageBorderSize GUI preference Created: 18/Jul/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: Minor
Reporter: Miles Tjandrawidjaja Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File bad_border.png     PNG File imageToLeft.png     PNG File imageToRight.png    
Patch Submitted:
Yes
Number of attachments : 3

 Description   
<guiprefs width="800" height="600" resizable="no">
  <modifier key="useHeadingPanel" value="yes"/>
  <modifier key="headingImageOnLeft" value="yes"/>
  <modifier key="headingImageBorderSize" value="0"/>
  <laf name="looks">
    <os family="unix"/>
    <os family="windows"/>
    <os family="mac"/>
  </laf>
</guiprefs>

Even though the headingImageBorderSize is set to 0, the heading is still shifted to the right by 12 pixels. See attached image.



 Comments   
Comment by Miles Tjandrawidjaja [ 18/Jul/14 ]

PR sent: https://github.com/izpack/izpack/pull/243
Let me know if I'm missing something and if there is already a way to get rid of the 12 pixel shift from specification file.

Comment by Rene Krell [ 18/Jul/14 ]

Merged pull request #243, thank you.

Comment by Rene Krell [ 11/Aug/14 ]

This inset is necessary for the case of using header labels in panels. Without shifting it to the right they are aligned directly to the left border of the installer frame without any space, which is ugly.

The solution for fixing the shifted green background must be different.

Comment by Rene Krell [ 11/Aug/14 ]

For now, reverted by merging pull request https://github.com/izpack/izpack/pull/262.

Can you please have a look at it again?

Comment by Ahmed Abu Lawi [ 20/Oct/14 ]

Hello,

I've made a change so that if an image is to the left it will press against the border, and if a label is on the left there will be a 12 pixel offset. I've sent a PR, https://github.com/izpack/izpack/pull/285.

The change is shown in the two images I posted. imageToLeft.png had the following guiprefs

<guiprefs width="800" height="600" resizable="no">
<splash>images/splash.png</splash>
<modifier key="useHeadingPanel" value="yes"/>
<modifier key="headingImageOnLeft" value="yes"/>
<modifier key="headingImageBorderSize" value="0"/>
<laf name="looks">
<os family="unix"/>
<os family="windows"/>
<os family="mac"/>
</laf>
</guiprefs>

And imageToRight.png had these gui prefs,

<guiprefs width="800" height="600" resizable="no">
<splash>images/splash.png</splash>
<modifier key="useHeadingPanel" value="yes"/>
<modifier key="headingImageBorderSize" value="0"/>
<laf name="looks">
<os family="unix"/>
<os family="windows"/>
<os family="mac"/>
</laf>
</guiprefs>

Comment by Rene Krell [ 07/Nov/14 ]

Merged pull request https://github.com/izpack/izpack/pull/285.
Thanks.





[IZPACK-1139] Building Izpack fails if abrt-java-connector packages is installed Created: 18/Jul/14  Updated: 18/Jul/14  Resolved: 18/Jul/14

Status: Resolved
Project: IzPack
Component/s: Installer
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-rc3
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

Fedora 20
java version "1.7.0_60"
abrt-java-connector-1.0.10-1.fc20.x86_64 package installer


Number of attachments : 0

 Description   

Build failed if abrt-java-connector package was installed on the system. This caused an additional argument, -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on, to be passed to the jvm.

Printing the result of elevatorCommand in the unit test produces this output.
[xterm, -title, Installer, -e, sudo, java, -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on, -jar, installer.jar]

The additional argument caused the following tests to fail because they were expecting one less argument to be returned by getJVMArguments(). Removing the package or having getJVMArguments to ignore arguments beginning with -agentpath solves the issue.

The abrt-java-connector package comes installed on some distributions of linux.

Failed tests:
testGetElevatorOnUnix(com.izforge.izpack.util.PrivilegedRunnerTest): expected:<8> but was:<9>
testGetElevatorOnWindows(com.izforge.izpack.util.PrivilegedRunnerTest): expected:<6> but was:<7>
testGetElevatorOnMacOSX(com.izforge.izpack.util.PrivilegedRunnerTest): expected:<4> but was:<5>

Tests run: 22, Failures: 3, Errors: 0, Skipped: 0
[INFO] IzPack util module ................................ FAILURE [2.136s]



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

Merged your pull request https://github.com/izpack/izpack/pull/244.

Thanks for your contribution.

Comment by Ahmed Abu Lawi [ 18/Jul/14 ]

Thank you





[IZPACK-1138] Omitting passwords (or other sensitive info) from automated xml files. Created: 17/Jul/14  Updated: 02/Oct/14  Resolved: 02/Oct/14

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

Type: Improvement Priority: Major
Reporter: Francisco Canas 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   

This is a proposal for an enhancement to the current automated xml file generation:

There should be an attribute we are able to set into an input field in the UserInputPanel spec that tells the Installer to omit the value of this input from the generated automated xml file. Usage would be something like:
<field type="password" variable="admin.user.password" tooltip="admin.user.tooltip" omitFromAuto="true">
...

The most common use-case for this feature is for user passwords, which are currently written in plaintext in the auto xml.

For this feature to be useful, we may need two other distinct (but related) ehancements:

  • A command line argument used in conjunction with the auomated xml that lets a user specify any variable=value pairs to be set into the install data. This way, these variable=value pairs can be used instead of prompting the user when an input with a matching variable is found to be missing from the auto xml file, which means that unattended installations can still be unattended even when they require passwords or other sensitive values entered.

Usage of the above would be something like:
java -jar target/myInstaller.jar -variables admin.user.password=qwe123

Alternatively or additionally, we could also have a file passed in as an argument that contains all needed variable=value pairs:
java -jar target/myInstaller.jar -varfile ./myvars.txt



 Comments   
Comment by Ahmed Abu Lawi [ 22/Aug/14 ]

PR sent for the first issue described, the omitting of data from the auto-install.xml.
https://github.com/izpack/izpack/pull/267

Comment by Rene Krell [ 02/Oct/14 ]

Very good improvement. Will check this.

Comment by Rene Krell [ 02/Oct/14 ]

One more comment: I would appreciate applying omitFromAuto="true" by default for fields of type "password". What about this small enhancement of your pull request?

Comment by Rene Krell [ 02/Oct/14 ]

In future, I would enhance this even a bit more - during saving auto-install.xml ask for a master password, encrypting all passwords, and on launching an auto-installation asking for that master password again (interactively or on the command line). This would be a highlight for those who care about security.

Comment by Rene Krell [ 02/Oct/14 ]

I modified and merged this manually.

Functional difference to your implementation:

  • In auto-install.xml, there is now dumped the empty value (value="") instead of omitting this attribute value completely for the case of omitting.
  • Passwords are omitted by default, now, but this can be overridden using omitFromAuto="false". So, the security feels better

Of course I'm open for further discussions.

Comment by Rene Krell [ 02/Oct/14 ]

I already documented it here: http://docs.codehaus.org/display/IZPACK/Fields.

Thanks for contributing.

Comment by Ahmed Abu Lawi [ 02/Oct/14 ]

I agree that the omitFromAuto should default to true for password fields.

One reason that I chose to omit value completely from the auto-install.xml was because I was developing this feature with this PR in mind, https://github.com/izpack/izpack/pull/245. For the unattended installer to prompt the user for input I need someway do differentiate a value that I would like to be prompted vs. a field that legitimately had "" as input.

I also agree that your idea of requesting a master password and encrypting all passwords in the auto-install.xml would be a great direction to take this feature in the future.

Comment by Rene Krell [ 02/Oct/14 ]

Regarding:
One reason that I chose to omit value completely from the auto-install.xml was because I was developing this feature with this PR in mind, https://github.com/izpack/izpack/pull/245. For the unattended installer to prompt the user for input I need someway do differentiate a value that I would like to be prompted vs. a field that legitimately had "" as input.
We can do this in the next cycle. Important is not to break the automatic installation due to a missing attribute, which was the main background for me along with a comfortable way of adding the passwords manually after finishing the installer. Lets discuss this further to bring it to a good end

We can do this change along with the other issue in the appropriate build request directly if it doesn't break anything.

Comment by Ahmed Abu Lawi [ 02/Oct/14 ]

Right now including value="", is probably the best option so as to not break the current unattended installations.

If other changes are added in later build cycles, a change can always be made then.

Thanks for including the feature





[IZPACK-1137] Variables not resolved in default values and labels of user input fields Created: 17/Jul/14  Updated: 17/Jul/14  Resolved: 17/Jul/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   

Currently, there are no current variable values replaced in default values ('set' attribute) and in static label text. This has probably gone lost with some recent merges.

Make this working again.



 Comments   
Comment by Rene Krell [ 17/Jul/14 ]

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

Comment by Rene Krell [ 17/Jul/14 ]

Pull request merged.





[IZPACK-1136] NPE in trace mode when gathering traced variables on the first panel Created: 17/Jul/14  Updated: 17/Jul/14  Resolved: 17/Jul/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-rc3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

On launching an GUI installer in trace mode by -DTRACE=true -DSTACKTRACE=true the installer fails with the following output:

Jul 17, 2014 11:55:10 AM SEVERE: Error when switching panel
java.lang.NullPointerException
        at com.izforge.izpack.installer.debugger.Debugger.getChangedVariables(Debugger.java:171)
        at com.izforge.izpack.installer.debugger.Debugger.debugVariables(Debugger.java:118)
        at com.izforge.izpack.installer.debugger.Debugger.switchPanel(Debugger.java:400)
        at com.izforge.izpack.installer.gui.InstallerFrame.switchPanel(InstallerFrame.java:551)
        at com.izforge.izpack.installer.gui.InstallerFrame$5.switchPanel(InstallerFrame.java:410)
        at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:128)
        at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:36)
        at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:496)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:250)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:345)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:328)
        at com.izforge.izpack.installer.gui.InstallerFrame.navigateNext(InstallerFrame.java:891)
        at com.izforge.izpack.installer.gui.InstallerController$2.run(InstallerController.java:50)
        at com.izforge.izpack.installer.gui.InstallerController.run(InstallerController.java:64)
        at com.izforge.izpack.installer.gui.InstallerController.launchInstallation(InstallerController.java:44)
        at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:60)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.awt.EventQueue.access$400(Unknown Source)
        at java.awt.EventQueue$2.run(Unknown Source)
        at java.awt.EventQueue$2.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at com.izforge.izpack.installer.gui.IzPanelView.validateDynamicConditions(IzPanelView.java:109)
        at com.izforge.izpack.installer.panel.AbstractPanelView.isValid(AbstractPanelView.java:244)
        at com.izforge.izpack.installer.gui.IzPanelView.isValid(IzPanelView.java:61)
        at com.izforge.izpack.installer.panel.AbstractPanels.executeValidationActions(AbstractPanels.java:545)
        at com.izforge.izpack.installer.panel.AbstractPanels.isValid(AbstractPanels.java:173)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:245)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:345)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:328)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.navigate(DefaultNavigator.java:562)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.access$100(DefaultNavigator.java:525)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler$1$1.run(DefaultNavigator.java:545)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.awt.EventQueue.access$400(Unknown Source)
        at java.awt.EventQueue$2.run(Unknown Source)
        at java.awt.EventQueue$2.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)


 Comments   
Comment by Rene Krell [ 17/Jul/14 ]

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

Comment by Rene Krell [ 17/Jul/14 ]

Pull request #238 merged.





[IZPACK-1135] Custom Fields should produce correct automatic installation file through console Created: 16/Jul/14  Updated: 17/Jul/14  Resolved: 17/Jul/14

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

Type: Bug Priority: Major
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   

Implementation of the creation of the automatic installation file through console was recently added, and the current "custom" fields do not properly generate automatic installation file through console installation.



 Comments   
Comment by Miles Tjandrawidjaja [ 16/Jul/14 ]

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

Comment by Rene Krell [ 17/Jul/14 ]

Pull request merged.





[IZPACK-1134] Password field not working for console installations in Windows only Created: 16/Jul/14  Updated: 18/Jul/14  Resolved: 18/Jul/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: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by IZPACK-1090 Allow tab completion and password mas... Resolved
Number of attachments : 0

 Description   

At the latest master, there is a problem in console installations with password fields in Windows:

Please specify application server manager user name and password.

Manager user: [admin]


Manager password:

Invalid application server manager password!

Press 1 to redisplay, 2 to quit

It is not possible to set passwords. For Linux it works fine.



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

Resolved along with IZPACK-1090





[IZPACK-1133] Counter in progress bar shows wrong total number of steps Created: 15/Jul/14  Updated: 17/Jul/14  Resolved: 17/Jul/14

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

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

Attachments: PNG File CorrectedSteps2Finished.png     PNG File CorrectedSteps2.png     PNG File CorrectedStepsFinished.png     PNG File CorrectedSteps.png     XML File install.xml     PNG File Step3of3_ButDisplayedAs3of4.png     PNG File tm-0449_count.png    
Number of attachments : 7

 Description   

The progress bar of the installer frame shows one step more for the total number of steps.
We have 11 panels configured, but the progress bar displays "Step X of 12". So when the last step is reached (see screenshot) it shows "Step 11 of 12" and the progress bar is not full, even though there are no more steps.

Looking at the code it seems that the problem is in the com.izforge.izpack.installer.gui.InstallerFrame.performHeadingCounter(IzPanelView) method. To construct the displayed message "Step X of Y", 1 is added to the index of the current panel, but 1 is added to the number of visible panels are well. So for 11 visible panels we get 12 steps.



 Comments   
Comment by Jens Meissner [ 15/Jul/14 ]

The attachment install.xml contains a very simple configuration that can be used to reproduce the problem.
I also attached a screenshot of the last step using this config.

Comment by Thomas Hauser [ 16/Jul/14 ]

Hello Jens,
Your diagnoses was correct. I've submitted a PR for this request here: https://github.com/izpack/izpack/pull/235

Screenshots with the fix are included, with an InstallPanel added so that something was being installed.

Comment by Thomas Hauser [ 16/Jul/14 ]

Fix applied with both type="progressbar" and type="text".

Comment by Jens Meissner [ 17/Jul/14 ]

Thanks for the quick response.

Comment by Rene Krell [ 17/Jul/14 ]

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

Thanks for your contribution.





[IZPACK-1132] PacksPanel and TreePacksPanel caught in infinite loop Created: 14/Jul/14  Updated: 14/Jul/14  Resolved: 14/Jul/14

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

Type: Bug Priority: Major
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   

Originally pointed out by Rene, when using a condition for a pack and the condition evaluates to false, the installer gets trapped in an infinite loop.

Furthermore the TreePacksPanel is not appropriately updating the UI when the condition switches from false to true.



 Comments   
Comment by Miles Tjandrawidjaja [ 14/Jul/14 ]

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

Comment by Rene Krell [ 14/Jul/14 ]

Pull request merged.
Will also do some complex installer tests.





[IZPACK-1131] Allow mustExist attribute for file fields. Created: 10/Jul/14  Updated: 11/Aug/14  Resolved: 11/Aug/14

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

Type: Improvement 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   

It would be nice to have the mustExist attribute to file fields, as directories already have them. The file field has an allowEmptyValue, but that only lets you enter either a valid file or leave an empty path. The use case for this is if the installer would generate the file for you if it does not exist.

Also ensure not to print "null" during console installation if there is no label for a file field.



 Comments   
Comment by Miles Tjandrawidjaja [ 10/Jul/14 ]

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

Comment by Rene Krell [ 11/Aug/14 ]

Pull request #230 merged.
Thank you.





[IZPACK-1130] Dynamically add Fields to a Panel Created: 09/Jul/14  Updated: 16/Jul/14  Resolved: 16/Jul/14

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

Type: Epic 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   

It would be nice to be able to dynamically add or remove fields from a UserInputPanel.
We could have a row of fields that can be added or removed on the click of a button.
All functionality of existing fields would be re-used.

We could specify the minimum and maximum amount of rows that are possible to be dynamically located.
Suggested defaults:
> Default minRow = 1
> Default maxRow = 5

We could validate based on a given column.
For example we may want all values in a specific column to be unique.

Custom fields can take in a condition id just like any other fields.
Although there is currently no support for condition id for fields specified within the custom field.

The auto.xml for custom fields should generate the auto.xml as though the fields defined in the custom field were defined as regular.
(Please try sample installer below and create a auto.xml to be understand)

Console installation displays custom fields as though displaying the individual fields as normal.
But at the end of each row we ask if the user wants to possibly add another row, continue or redisplay.
If the user chooses to redisplay at this point we redisplay for only the current row.
If the user chooses to continue regular end prompt is shown.
If redisplay is choosen at this point we display the custom field from the beginning.

Summarizing a custom field will show the attributes with a number pre-appended.
This will be better to understand by creating and running my sample installer below.

It may be easier to understand the custom field by looking at a sample specification.
To have a first hand experience please fetch and build with my PR.
Next clone https://github.com/mtjandra/SampleInstaller, checkout "customFields", and run the "build.sh" to build the installer.
If you pick the two or more creatures of the same species you will get a warning as it does not pass the UniqueColumn validation put in place.
Check out the specification files and feel free to play around with it.

Let me know of any questions or concerns.
A custom field maximizing code re-usability by using the existing fields.
I don't believe I've modified any of the existing fields.
The custom field is a great use case when the user can specify multiple attributes, with the constrain of other fields being necessary.



 Comments   
Comment by Miles Tjandrawidjaja [ 09/Jul/14 ]

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

Again please try fetch this PR and build IzPack.
Next clone https://github.com/mtjandra/SampleInstaller, checkout "customFields", and run the "build.sh" to build the installer.
This is recommended if you really want to understand what I have added.

Comment by Rene Krell [ 16/Jul/14 ]

Pull request #229 merged.
Thanks for your contribution.

Comment by Rene Krell [ 16/Jul/14 ]

Is this documented in Confluence? It would be nice if you added there the whole code of your sample installer.

Comment by Miles Tjandrawidjaja [ 16/Jul/14 ]

Alright I see its merged now, I will add documentation.

I was also thinking it would be a good idea to have a sample installer in the IzPack group.
This may lower the barrier for new comers who want to try out IzPack, and we can promote "good" practices.
For example it took me a while to figure out how to add custom panels, validation and actions.
And for a new comer having to make a lot of spec files from scratch could take a lot of time and may turn them away.
Just a suggestion.

Thanks for all the work you are putting into this by the way!





[IZPACK-1129] Unattended install still prompts user for decision on overriding files Created: 08/Jul/14  Updated: 16/Jul/14  Resolved: 16/Jul/14

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

Type: Bug Priority: Major
Reporter: Gareth Sullivan 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   

Packs are defined with override="asktrue"

In UI mode user is prompted if installer is about to overwrite an existing file

In unattended mode, a console prompt asks for confirmation to overwrite the file(s) meaning that the install is not unattended as it requires user input.

Below are the results of using different values for the fileset override parameter in the packs definition

override="true"
UI Mode - File is overwritten without prompting user
Unattended Mode - File is overwritten without console prompt

override="false"
UI Mode - File is NOT overwritten, no prompts for user
Unattended Mode - File is NOT overwritten, no console prompts

override="asktrue"
UI Mode - User is prompted to overwrite file or not, default selection is "Yes"
Unattended Mode - User is prompted on console overwrite file or not

override="askfalse"
UI Mode - User is prompted to overwrite file or not, default selection is "No"
Unattended Mode - User is prompted on console overwrite file or not

From the user documentation

"Use asktrue or askfalse if the user should be interactively asked what to do and supply default value for non-interactive use."

I would expect that "asktrue" would override the files when run in unattended mode, and for "askfalse" to NOT override the files in unattended mode



 Comments   
Comment by Gareth Sullivan [ 08/Jul/14 ]

Recreated the issue in a very simple project, based on the IZPack documentation (http://docs.codehaus.org/display/IZPACK/Writing+Installation+Descriptions)

The install.xml is

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

<info>
<appname>Test</appname>
<appversion>0.0</appversion>
<appsubpath>myapp</appsubpath>
<javaversion>1.6</javaversion>
</info>

<locale>
<langpack iso3="eng"/>
</locale>

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

<panels>
<panel classname="TargetPanel"/>
<panel classname="PacksPanel"/>
<panel classname="InstallPanel"/>
<panel classname="FinishPanel"/>
</panels>

<packs>
<pack name="Test Core" required="yes">
<description>The core files needed for the application</description>
<fileset dir="main/resources/plain" targetdir="$

{INSTALL_PATH}" override="asktrue"/>
<parsable targetfile="${INSTALL_PATH}

/test.properties"/>
</pack>
</packs>

</izpack:installation>

and the auto.xml is

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<AutomatedInstallation langpack="eng">
<com.izforge.izpack.panels.target.TargetPanel id="UNKNOWN (com.izforge.izpack.panels.target.TargetPanel)">
<installpath>/Users/garethsullivan/Desktop/Monday</installpath>
</com.izforge.izpack.panels.target.TargetPanel>
<com.izforge.izpack.panels.packs.PacksPanel id="UNKNOWN (com.izforge.izpack.panels.packs.PacksPanel)">
<pack index="0" name="Test Core" selected="true"/>
</com.izforge.izpack.panels.packs.PacksPanel>
<com.izforge.izpack.panels.install.InstallPanel id="UNKNOWN (com.izforge.izpack.panels.install.InstallPanel)"/>
<com.izforge.izpack.panels.finish.FinishPanel id="UNKNOWN (com.izforge.izpack.panels.finish.FinishPanel)"/>
</AutomatedInstallation>

Comment by Francisco Canas [ 10/Jul/14 ]

This issue was caused by the UnpackerBase class's isOverwriteFile() method not checking for the type of installation (automated vs console or gui) and always prompting the user for 'askTrue' and 'askFalse'.

I have made a PR to address it: https://github.com/izpack/izpack/pull/231

Comment by Rene Krell [ 16/Jul/14 ]

Pull request #231 merged.
Thank you for your contribution.





[IZPACK-1128] It should be possible to create a shortcut on the Desktop without creating shortcuts in the Start Menu Created: 08/Jul/14  Updated: 10/Jul/14

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

Type: Wish Priority: Major
Reporter: Gergö Gabor Ilyes-Veisz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ShortcutPanel
Windows 7 Professional 32bit


Number of attachments : 0

 Description   

By an installer created with IzPack 5.0.0-rc1 using the built-in ShortcutPanel it isn’t possible to create a shortcut on the Desktop without creating shortcuts in the Start Menu.

It would be great for our project if it were possible.



 Comments   
Comment by Thomas Hauser [ 10/Jul/14 ]

This issue looks similar to IZPACK-1086.





[IZPACK-1127] Polishing Pack Views Created: 07/Jul/14  Updated: 08/Jul/14  Resolved: 08/Jul/14

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

Type: Bug Priority: Trivial
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   

1. TreePacksConsole should only accept input when the Enter key is pressed, not when an individual character is entered.

2. Required packs should always be gray in the GUI.

3. Evaluate conditions for onSelect and onDeselect. This condition dictates weather onSelect or onDeselect should execute.



 Comments   
Comment by Miles Tjandrawidjaja [ 07/Jul/14 ]

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

Comment by Rene Krell [ 08/Jul/14 ]

Pull request merged.





[IZPACK-1126] Try/catch/finally process panel job groups. Created: 07/Jul/14  Updated: 16/Jul/14  Resolved: 16/Jul/14

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

Type: Improvement Priority: Minor
Reporter: Francisco Canas 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   

I would like to propose two new process panel job attributes that let us separate jobs in the ProcessPanel.Spec.xml class into three groups that are executed similarly to a try/catch/finally statement in java:

catch="true" adds a job to the 'catch' group.
final="true" adds a job to the 'final' group.
If neither of these attributes is present, the job is added to the standard group (the 'try' group).

As an example:
<job name="try">
<executeclass name="org.izpack.processpanel.BooleanProcessJob">
</executeclass>
</job>
<job name="catch" catch="true">
<executeclass name="org.redhat.processpanel.BooleanProcessJob">
</executeclass>
</job>
<job name="final" final="true">
<executeclass name="org.redhat.processpanel.BooleanProcessJob">
</executeclass>
</job>

The 'try' job will always run. The 'catch' job will only run if the 'try' job fails. The 'final' job will always run regardless of failures.



 Comments   
Comment by Francisco Canas [ 09/Jul/14 ]

I've sent a PR with the implementation of the above proposal: https://github.com/izpack/izpack/pull/225

Comment by Rene Krell [ 16/Jul/14 ]

Pull request https://github.com/izpack/izpack/pull/225 merged.
Thanks for your contribution.

Comment by Francisco Canas [ 16/Jul/14 ]

You're welcome. I've also added some basic documentation for this feature here:
http://docs.codehaus.org/display/IZPACK/Process+Panel





[IZPACK-1125] ConfigurationInstallerListener - footer comments are not preserved Created: 04/Jul/14  Updated: 07/Jul/14  Resolved: 07/Jul/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-rc3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

During merging configuration using the ConfigurationInstallerListener, there get lost footer comments not followed by another uncommented key-pair value.
This affects Windows INI files and option files, like Java Service Wrapper configurations and property files.



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

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

Comment by Rene Krell [ 07/Jul/14 ]

Pull request merged.





[IZPACK-1124] Navigator and panel button mnemonics in GUI Installer. Created: 03/Jul/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

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

Type: New Feature Priority: Trivial
Reporter: Francisco Canas 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   

GUI Installer panels could have button shortcuts (mnemonics) based on the first letter of their caption text, so the user can activate the buttons with these keyboard shortcuts. ie:

quit - 'alt-q'
next - 'alt-n'
previous - 'alt-p'
browse - 'alt-b'

etc...



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

https://github.com/izpack/izpack/pull/223

Comment by Rene Krell [ 07/Jul/14 ]

Pull request merged.





[IZPACK-1123] Tooltips for userInputPanel fields. Created: 03/Jul/14  Updated: 04/Jul/14  Resolved: 04/Jul/14

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

Type: New Feature Priority: Trivial
Reporter: Francisco Canas 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   

Adding tooltips to userInputPanel fields by specifying the 'tooltip' attribute inside fields in the userInputSpec.xml:

<field type="text" variable="admin.user" tooltip="admin.user.tooltip">
<spec id="admin.user" size="15" set="admin"/>
</field>



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

https://github.com/izpack/izpack/pull/220

Comment by Rene Krell [ 04/Jul/14 ]

Pull request merged.
Can you please add this to the user documentation at Confluence?

Thank you.





[IZPACK-1122] new methods in InstallerListener and UninstallerListener Created: 01/Jul/14  Updated: 02/Jul/14

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

Type: Improvement Priority: Critical
Reporter: olivier gattaz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Number of attachments : 0

 Description   

The the InstallerListener and UninstallerListener have not a symetric life cycle.

It would be a great enhancement to have a "cleanUp()" method in the InstallerListener and UninstallerListener interfaces, to be able to release the engaged ressources when the user click on the "quit" button

Proposal
It would be not so complicated to automatically call the new "cleanUp()" method of the listener if they are automatically registered as "CleanupClient".

It's necessary to register automatically the listeners as "CleanupClient" (if they implement the interface) because in our custom classes we don't have access to the InstallerContainer to retreive the instance of the Housekeeper component.

look at the methods :
com.izforge.izpack.util.Housekeeper.registerForCleanup(CleanupClient)
com.izforge.izpack.util.Housekeeper.shutDown(int, boolean)






[IZPACK-1121] autoInstall.xml file has duplicated panel nodes after console installation run Created: 01/Jul/14  Updated: 02/Jul/14

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

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

windows 7


Number of attachments : 0

 Description   

When the installation data get saved at FinishConsolePanel for automatic installation the autoInstall.xml is created with duplicated panel XML nodes. That happens because at startup the ConsolePanelsProvider.provide(...) method calls PanelsProvider.prepare() method with add XML data for all panels. Then at the FinishConsolePanel when the "Generate an automatic installation script" is selected the FinishConsolePanel.getAutomatedPanels(...) method gets invoked. That calls the AutomatedPanelsProvider.provide(...) method which makes another call to the PanelsProvider.prepare() causing adding panel XML nodes again causing duplicates.

The workaround was found by createing the custom FinishConsolePanel with overridden getAutomatedPanels(...) method like the following:

  @Override
  protected AutomatedPanels getAutomatedPanels(final InstallData installData) {
    final List<AutomatedPanelView> panels = new ArrayList<>();
    final ConsolePanelAutomationHelper helper = new ConsolePanelAutomationHelper();
    for (final Panel panel : installData.getPanelsOrder()) {
      final AutomatedPanelView panelView = new AutomatedPanelView(panel, factory, installData, helper);
      panels.add(panelView);
    }
    return new AutomatedPanels(panels, installData);
  }


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

This issue is probably reported against 5.0.0-rc2.

Beginning from commit 817d9f7f5446ee7ecb5d23bdf4d09cd88e1d6e1d there is no longer called

addPanelXml(panel, installData);

from
PanelsProvider.prepare(...).

See the details here: https://github.com/izpack/izpack/commit/817d9f7f5446ee7ecb5d23bdf4d09cd88e1d6e1d

This commit affects also the API and the format of the autoinstall.xml, see IZPACK-1099.

Please recheck with 5.0.0-rc3-SNAPSHOT.

Comment by Eugene o [ 01/Jul/14 ]

That's Correct. I used 5.0.0-rc1. Then I moved to 5.0.0-rc2 but the problem I encountered persisted.

Comment by Rene Krell [ 02/Jul/14 ]

I did not mean 5.0.0-rc2, but 5.0.0-rc3-SNAPSHOT, thus the current development trunk. Please check it, the changes have been made just a couple of weeks ago.

Comment by Eugene o [ 02/Jul/14 ]

You were wondering "Which version did you check this against..", then you edited to "This issue is probably reported against 5.0.0-rc2".
So I just confirmed that by explaining my steps before I reported this issue otherwise I would not say "That's correct".
So the 5.0.0-rc2 is the latest avalable at https://izpack.github.io/downloads/ which we currently use for our product.
Thanks for letting us know that the bug is resolved in the comming rc3.

Comment by Rene Krell [ 02/Jul/14 ]

Vice versa, we would be glad if you would give it a try in advance. There is no huge testing team in the background here, but just unit and integration tests and what the users report for their projects. The autoinstall fix in RC3 has been made after a report from another company, maybe you have been faced with another one. I mentioned referring to the code you referred to, which has been refactored.





[IZPACK-1120] Allow displaying fields when their conditionid evaluates to false, but as disabled Created: 27/Jun/14  Updated: 01/Dec/14  Resolved: 09/Jul/14

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

Type: New Feature Priority: Minor
Reporter: Miles Tjandrawidjaja Assignee: Rene Krell
Resolution: Fixed Votes: 1
Labels: 5.0.0-rc3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to IZPACK-1194 "contains" condition does not work fo... Resolved
Patch Submitted:
Yes
Number of attachments : 0

 Description   

It would be nice if the installer had both the options to hide, or disable fields from the UserInputPanels when the field's conditionid evaluates to false. Some UI people prefer this.

1. Be able to set this effect for the entire panel
2. Be able to set this effect for individual fields



 Comments   
Comment by Miles Tjandrawidjaja [ 08/Jul/14 ]

PR Sent https://github.com/izpack/izpack/pull/219

Comment by Rene Krell [ 09/Jul/14 ]

Pull request merged.





[IZPACK-1119] Allow Descriptions for 'radio', 'dir', and 'file' fields. Created: 26/Jun/14  Updated: 04/Jul/14  Resolved: 04/Jul/14

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

Type: New Feature 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   

Allow <description> tags withing the for 'radio', 'dir' and 'file' fields. This is useful when you have text related to one of those fields, and you would like that information to be hidden whenever the 'radio' 'dir' or 'file' fields are hidden.

Example.

<!-- For radio button -->
<field type="radio" variable="a.option" summaryKey="a.option" conditionid="some.cond">
    <description id="a.option.info"/>
    <spec>
        <choice id="a.option.1" value="default"/>
        <choice id="a.option.2" value="offset"/>
        <choice id="a.option.3" value="custom"/>
    </spec>
</field>
<!-- For file/dir -->
<field type="file" align="left" variable="b.path" summaryKey="b.path" conditionid="another.cond">
    <description id="b.description"/>
    <spec size="34" prefX="500" mustExist="false"/>
</field>


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

https://github.com/izpack/izpack/pull/218

Comment by Rene Krell [ 04/Jul/14 ]

Please prepare the documentation in Confluence. Thanks.

Comment by Rene Krell [ 04/Jul/14 ]

Pull request merged.





[IZPACK-1118] AntAction listener - add flag "logfile_append" to append to existing Ant action log files Created: 25/Jun/14  Updated: 25/Jun/14  Resolved: 25/Jun/14

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

Type: New Feature 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 the built-in Antaction listeners, there is currently the possibility to log to separate logfiles, but each action requires an own log file, because it doesn't append to existing ones.

Add the possibility to choose whether to append to an Ant action log file or not.
Attribute name: logfile_append (Default: false)

Example:

<antcall order="beforepack" buildresource="service.xml" logfile="${ant.log.file}" logfile_append="true">
  <property name="INSTALL_PATH" value="${INSTALL_PATH}" />
  <property name="service.name" value="${service.name}" />
  <target name="preinstall" />
</antcall>


 Comments   
Comment by Rene Krell [ 25/Jun/14 ]

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

Comment by Rene Krell [ 25/Jun/14 ]

Pull request merged.





[IZPACK-1117] Allow dynamic variable to be static until it's default value changes Created: 24/Jun/14  Updated: 09/Dec/14  Resolved: 09/Dec/14

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

Type: New Feature Priority: Minor
Reporter: Miles Tjandrawidjaja Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to IZPACK-1199 Don't refresh a dynamic variable if i... Resolved
dependent
is depended upon by IZPACK-1197 Variable and dynamic variable improve... Resolved
Number of attachments : 0

 Comments   
Comment by Miles Tjandrawidjaja [ 24/Jun/14 ]

Proposed Workflow

<variable name="A" value="${INSTALL_PATH}/extras" freeze="true"/>
<field type="dir" align="left" variable="A">
    <spec size="34" prefX="500" mustExist="false"/>
</field>
  1. Default value is represented by the "value" defined in the variable tags.
  2. On start set real value and cache the value ${INSTALL_PATH} ($INSTALL_PATH evaluates to /home/me)
  3. After each panel we evaluate its default (\$INSTALL_PATH) and check to see if the default has changed by comparing to its cache.
    • For example if the target panel has changed the value of $INSTALL_PATH to /home/you, then set the value for variable A from /home/me to /home/you, the cache is also updated to /home/you
  4. When we get to the field that modifies variable A, real value is modified, but nothing is cached.
    • This real value will now persist until the default value is update
    • In this case the only way the default value can be updated is it $INSTALL_PATH changes
    • The cache can only contain whatever is evaluated by the default value
  5. If you go back to target panel and modify $INSTALL_PATH the evaluated default value will not match cache. In this case we "refresh" the variable setting the value of variable A to its newly evaluated defaulted value and update the cache.

See the preceding discussion at https://github.com/izpack/izpack/pull/210#issuecomment-46647764

Using a time stamp was mentioned since the equality of values does not guarantee whether the value has been set in a panel or during variable refresh. Still I think we must cache the value as a timestamp would not be enough information. For the use case I am trying to describe above I do not think just comparing timestamps are sufficient.

My main reasons why I think we need to cache and must compare to its value are below:

  • We must figure out when the default value has been altered.
  • Dynamic variables attempt to refresh (load its defaults) on every panel switch. If the previously evaluated default value was not cached, there is no way to compare weather the newly evaluated default value is different from the previously evaluated default value.
  • Note we never have to compare values that have been set directly from the panel. The only concern is the current evaluated default value and the previously evaluated default value. Whenever we set a variable from a panel directly we shall persist. The only time we refresh the variable is if the variable's default value is changed implicitly.
  • As the xml snippet shows above, if the default value for a variable A is ${INSTALL_PATH}, then anytime the value of INSTALL_PATH has changed, set the value of A to ${INSTALL_PATH}. This value is persisted until A is updated. Any time A is updated, that new value persists and does not refresh. Refresh only should occur when A's default variable changes, in this case INSTALL_PATH'

Hope that makes sense, perhaps we are thinking of different use cases. Please expand on the timestamp method if you like. I will try and make some changes to have it working as described above to try and be more clear. This way it might be easier for you to point out where the timestamp could be implemented and why the caching of the value might not be necessary. I am sorry if I misinterpreted what you have mentioned previously, don't want to cause any headaches!

EDIT: Now i remember I originally used updateTrigger to generalize the "has default value updated" to "whenever <my_specified_variable> has updated".

EDIT 2: Actually my reverted commit shows exactly what I'm describing for the "freeze" attribute. https://github.com/mtjandra/izpack/commit/bc24ef5e895c493da8f0ab3008c410981cb9dc39. It does not however describe the "updateTrigger" attribute.

Comment by Rene Krell [ 03/Dec/14 ]

I have a different proposal described in issue IZPACK-1199.
From all the years using Izpack in production environments this should be an optimal way without any further attributes on dynamic variables.
How about that?

Comment by Rene Krell [ 09/Dec/14 ]

Has the same background like IZPACK-1199 - which uses another approach without further attributes on variable definitions so far. At the end the effect should be similar. I found IZPACK-1199 and its method of freezing more intuitive in terms of IzPack, freezing dynamic variables as soon as they are set from a panel, combined with a better default handling from IZPACK-1200 and IZPACK-1201.





[IZPACK-1116] "afterpack" listeners launched before applying <executable>, <parsable> and <updatefiles> Created: 23/Jun/14  Updated: 07/Oct/14  Resolved: 23/Jun/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: 1
Labels: 5.0.0-rc3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, "afterpack" listeners launched before applying <executable>, <parsable> and <updatefiles> markers. This is non-intuitive and wrong.

Pre-parsed file with variables replaced and executable UNIX scripts cannot be used for instance in Ant actions this way.

Currently, unpacking a pack executes in this order:

  • "beforepack" listeners
  • "beforefile" listeners
  • unpack file
  • "afterfile" listeners
  • "afterpack" listeners.
  • mark file "parsable"
  • mark file "executable"
  • clean up obsolete files according to <updatefiles>

Unpack packs should execute in the following new order:

  • "beforepack" listeners
  • "beforefile" listeners
  • unpack file
  • "afterfile" listeners
  • mark file "parsable"
  • mark file "executable"
  • clean up obsolete files according to <updatefiles>
  • "afterpack" listeners.


 Comments   
Comment by Rene Krell [ 23/Jun/14 ]

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

Comment by Rene Krell [ 23/Jun/14 ]

Pull request merged.





[IZPACK-1115] Use <executable> and <parsable> with filesets which do not access the filesystem Created: 19/Jun/14  Updated: 19/Jun/14  Resolved: 19/Jun/14

Status: Resolved
Project: IzPack
Component/s: Compiler, Documentation
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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The <parsable> tag currently supports a nested fileset, which requires a dir and a targetDir attribute. Accessing the filesystem a second time here is not a goot choice and this lack has been already commented in the code. Instead, <parsable> should mark files parsable, which are added using the <file>, <singlefile> and <fileset> tags nested against the <pack> definition, the original filesystem access should happen only there (the files are packed into the installer).

The same for the <executable> tag, which currently even doesn't support nested filesets although it is documented.

Furthermore, for all filesets (nested in <pack>, <executable>, <parsable>) the targetDir attribute should be optional and default to "${INSTALL_PATH}".

The dir attribute should no longer been parsed in <fileset> nested to <executable>, <parsable> at all.

Example:

<pack name="Core files" required="yes" id="pack.core" condition="Install">
  <description>Core files</description>
  <fileset dir="@{staging.dir}" override="true">
    <exclude name="*.zip" />
    <exclude name="conf/*.properties" />
    <exclude name="conf/*.xml" />
  </fileset>
  <fileset dir="@{staging.dir}/config_files" targetdir="${INSTALL_PATH}/conf" override="true" overrideRenameTo="*.configbak">
    <include name="*.properties" />
    <include name="*.xml" />
    <exclude name="special.xml" />
  </fileset>
  <parsable encoding="UTF-8">
    <fileset targetdir="${INSTALL_PATH}/conf">
      <include name="wrapper.conf" />
    </fileset>
  </parsable>
  <parsable>
    <fileset>
      <include name="**/*.bat" />
      <include name="**/*.cmd" />
    </fileset>
  </parsable>
  <parsable type="shell">
    <fileset>
      <include name="**/*.sh" />
    </fileset>
  </parsable>
  <executable>
    <fileset>
      <include name="**/*.sh" />
    </fileset>
  </executable>
</pack>


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

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

Comment by Rene Krell [ 19/Jun/14 ]

Merged pull request.





[IZPACK-1114] Next panel not gathered correctly if it depends on panel conditions Created: 17/Jun/14  Updated: 19/Jun/14  Resolved: 19/Jun/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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There is an issue when changing panels using panel conditions:
If a panel depends on conditions based on variables set by a previous panel (like $INSTALL_PATH in TargetPanel), these conditions are not evaluated correctly, because at the evaluation time there are still not updated the variables set in the previous panel. This results in an unexpected panel order although the conditions are shown correctly in trace mode after the panel change (when showing them in trace mode the variable update has been already passed, in difference to the moment when gathering the next panel based on conditions).



 Comments   
Comment by Rene Krell [ 17/Jun/14 ]

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

Comment by Rene Krell [ 17/Jun/14 ]

Pull request merged.

Comment by Rene Krell [ 19/Jun/14 ]

This has got to recieve a post-fix: Still not working perfectly (although already better)...

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

Comment by Rene Krell [ 19/Jun/14 ]

Pull request merged.





[IZPACK-1113] TreePacksPanelConsole Enhancements, Respect Parent Packs, onSelect onDeselect Attributes Created: 16/Jun/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

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

Type: Improvement 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

Attachments: XML File conditions.xml     XML File packs.xml     XML File panels.xml    
Patch Submitted:
Yes
Number of attachments : 3

 Description   

1. Bug where TreePacksPanelConsole does not allow you to select any packs when all your packs are parent packs.
2. Ensure packs check for internationalized strings first.
3. Ensure that the TreePacksPanel and TreePacksConsolePanel are responsible only for the view
4. Data of what packs are selected/deselected are contained within PacksModel
5. Add "onSelect" and "onDeselect" attributes to have packs selected/deselected based on if a pack was chosen to be selected or deselected.
6. Improve console UI (see below)
NOTE: Whitespace is not being preserved
Press 1 to continue, 2 to quit, 3 to redisplay
1
1 [x] [independent.pack] (41 bytes)
>> Required
2 [ ] [a.pack] (2 bytes)
3 [ ] [b.pack] (2 bytes)
4 [x] [c.pack] (2 bytes)
5 [x] [d.pack] (2 bytes)
6 [x] [e.pack] (2 bytes)
7 [x] [g.h.container] (0 bytes)
>> Children: g.pack, h.pack
8 [x] [g.pack] (2 bytes)
9 [x] [h.pack] (2 bytes)
10 [ ] [i.pack] (2 bytes)
11 [ ] [j.pack] (2 bytes)
>> Dependencies: i.pack
12 [x] [unix.pack] (5 bytes)
13 [ ] [chaining.test] (0 bytes)
14 [ ] [dependency.test] (0 bytes)
Total space required: 56 bytes
Press 0 to confirm your selections.
Please select which packs you want to install.



 Comments   
Comment by Miles Tjandrawidjaja [ 16/Jun/14 ]

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

Comment by Miles Tjandrawidjaja [ 18/Jun/14 ]

Working some more with packs I realize that the console is not utilizing the PacksModel class. I think user interation/input should be handled by TreePacksPanel and TreePacksConsolePanel, while the logic of what packs are dependent, selected/deselected, etc. should be handled by the PacksModel or elsewhere. We should centralize how we handle the logic for packs. I am currently looking into PacksModel and refactoring.

Comment by Miles Tjandrawidjaja [ 23/Jun/14 ]

Some specification files to test out.

Comment by Rene Krell [ 07/Jul/14 ]

Pull request merged.





[IZPACK-1112] Added Persistency to Panels Created: 13/Jun/14  Updated: 07/Jul/14  Resolved: 04/Jul/14

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

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

Patch Submitted:
Yes
Number of attachments : 0

 Description   

Persistence across panels is not consistent.
For example radio and text fields retain their values when hitting previous.
Passwords, File and Directory fields do not retain their exact values when hitting previous.



 Comments   
Comment by Miles Tjandrawidjaja [ 13/Jun/14 ]

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

Comment by Rene Krell [ 04/Jul/14 ]

Pull request merged

Comment by Rene Krell [ 07/Jul/14 ]

Post-fix: https://github.com/izpack/izpack/pull/222





[IZPACK-1111] processors are triggered twice Created: 10/Jun/14  Updated: 10/Jun/14

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

Type: Bug Priority: Major
Reporter: Michael Schnupp 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   

In GUIPasswordGroupField:

                String value = field.process(values);
                field.setValue(value);]

In Field:

    public void setValue(String value)
    {
        value = process(value);

This combination makes sure the processor is triggered twice. Especially a PasswordEncryptionProcessor would double encrypt the password.

Independently the back button would fill the already encrypted password in the field and encrypt it a second time as soon as you hit the next button. This will also lead to doubly encrypted fields. (Or even 4 times encrypted in combination of the two bugs.)






[IZPACK-1110] UserInputPanel - "revalidate" attribute does not longer work on radio choices Created: 09/Jun/14  Updated: 09/Jun/14  Resolved: 09/Jun/14

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

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

Issue Links:
Related
is related to IZPACK-1069 Allow revalidation of current panel Resolved
Number of attachments : 0

 Description   

There is an undocumented feature of dynamically revalidating the user input panel contents if a radio button choice changes:

<panel>
    <field type="radio" variable="installConfig">
         <description align="left" txt="Select Standard installation or
select Advanced to make changes"
            id="installConfig.text"/>
         <spec>
           <choice txt="Standard" revalidate="yes"
id="installConfig.radio.standard" value="standard"  set="true"/>
           <choice txt="Advance" revalidate="yes" id="installConfig.radio.advanced" value="advanced" />
         </spec>
      </field>
      <field type="divider" align="center"/>
      <field type="staticText" conditionid="advanced" align="left"
id="installConfig.note"
         txt="This text is only displayed if advanced if checked" />
</panel>

This feature got lost after some refactoring with choices fields, especially commit 6b7cf37558e4386423eafe4190f9b28b26f73eb2.

This should be restored and documented.



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

The behavior has been refactored, revalidation is now be done by default on all fields.





[IZPACK-1109] Panel conditions throw NPE when some condition does not exist in AND statement Created: 06/Jun/14  Updated: 29/Apr/15  Resolved: 29/Apr/15

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-rc3, 5.0.0-rc5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There is an issue with evaluating conditions.

Example:

<panel classname="UserInputPanel" id="panel.one" />
<panel classname="UserInputPanel" id="panel.two" condition="ConditionDoesNotExist">

In this case a warning is logged on panel.one that condition ConditionDoesNotExist does not exist, which is weird, because the condition should be evaluated on panel.two, instead.

Next example:

<panel classname="UserInputPanel" id="panel.one" />
<panel classname="UserInputPanel" id="panel.two" condition="ConditionDoesNotExist+ConditionThatExists">

This throws a NPE on panel.one additionally:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at com.izforge.izpack.core.rules.logic.AndCondition.isTrue(AndCondition.java:64)
        at com.izforge.izpack.core.rules.RulesEngineImpl.isConditionTrue(RulesEngineImpl.java:351)
        at com.izforge.izpack.core.rules.RulesEngineImpl.isConditionTrue(RulesEngineImpl.java:338)
        at com.izforge.izpack.installer.panel.AbstractPanelView.canShow(AbstractPanelView.java:266)
        at com.izforge.izpack.installer.panel.AbstractPanels.canShow(AbstractPanels.java:540)
        at com.izforge.izpack.installer.panel.AbstractPanels.getNext(AbstractPanels.java:332)
        at com.izforge.izpack.installer.gui.DefaultNavigator.configureVisibility(DefaultNavigator.java:466)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:340)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:317)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.navigate(DefaultNavigator.java:552)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.access$0(DefaultNavigator.java:543)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler$1$1.run(DefaultNavigator.java:535)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:727)
        at java.awt.EventQueue.access$200(EventQueue.java:103)
        at java.awt.EventQueue$3.run(EventQueue.java:688)
        at java.awt.EventQueue$3.run(EventQueue.java:686)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:697)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)


 Comments   
Comment by Thomas Hauser [ 17/Jul/14 ]

Hello Rene,

I've been looking into the first part of this issue, and the culprit here is the configureVisibility() method in the DefaultNavigator class; it evaluates whether or not to display the next / previous navigation buttons by looking at the next panel from the current index and calling canShow(), which evaluates the conditions. (which is why the warning is printed on panel one). I don't think this amounts to a problem per se, because it's good to see the warning.

I will return to this tomorrow for the second part, and submit a PR shortly after that.

Noteworthy comments:
Conditions are being checked 4 times upon switching panels, may look into that.
The NPE is an error in the getConditionByExpr() method in RulesEngineImpl class.

Comment by Rene Krell [ 18/Jul/14 ]

Thank you for your analyze, you are welcome.

Please don't forget to always merge from latest izpack/izpack master, there is currently heavy development going on towards to RC3.

Comment by Thomas Hauser [ 18/Jul/14 ]

Submitted PR here: https://github.com/izpack/izpack/pull/246

New log example:
'Simple' expression:
Jul 18, 2014 4:44:22 PM WARNING: Condition: NotExist+True contains reference to undefined condition: NotExist
Jul 18, 2014 4:44:22 PM WARNING: Condition NotExist+True not found

'Complex' expression:
Jul 18, 2014 4:45:54 PM WARNING: Complex condition: True&&NotExist contains undefined condition: NotExist
Jul 18, 2014 4:45:54 PM WARNING: Condition @True&&NotExist not found

The NPEs no longer occur; instead, the condition containing the undefined condition is evaluated as false.

Let me know if the logging level / the messages should be adjusted.

Comment by Rene Krell [ 22/Jul/14 ]

Thank you for this contribution.

Comment by Rene Krell [ 29/Apr/15 ]

The error reoccured for some usecase.
This should be additionally prevented at compile time. It should not be allowed to use undefined conditions.

Comment by Rene Krell [ 29/Apr/15 ]

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

Comment by Rene Krell [ 29/Apr/15 ]

PR #343 merged.





[IZPACK-1108] Use Preferences API for writing installation information Created: 06/Jun/14  Updated: 06/Jun/14

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

Type: Task 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   

The Java Preferences API makes it possible to save system- and user-wide key-value pairs to an OS-dependent storage in an OS-independent view.

A typical usecase would be saving and gaining installation target paths of an IzPack installation. Later, on launching an update installer of the same application again, it could find the target installation path automatically and suggest it in the target panel as default value. In this case the user would not have to care about Windows drive letters, specific paths and there could be also ensured that there is or is not an IzPack installation in a dedicated paths.

Another usecase is again updates for instance of an existing database schema. Alle the connection information from the installer could be found again and used with or without re-presenting user input masks to the user.

This could also replace writing the .installationinformatiion file with information about installed packages. With .informationinformation there must be still known the $INSTALL_PATH of the original installation, with Preferences would be sufficient to know the application ID.






[IZPACK-1107] Flexible panel condition validator implementation Created: 04/Jun/14  Updated: 04/Jun/14

Status: Open
Project: IzPack
Component/s: Installer
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   

Currently, the ConditionValidator can be used to validate whether a panel can be left. This implementation works but has design issues.

There should be a more flexible implementation. Example:

<panel ...>
  <validator condition="condition.id.1" message="translation.id.1"/>
  <validator condition="condition.id.2" message="translation.id.2"/>
  ...
</panel>

where condition refers to the ID of an existing condition defined in the regular <conditions> element and message to a translation of a message, that should be shown in a messagebox if the validation fails.

The validators should be evaluated in the order how they are defined. All nested validators must succeed. In case the first validator fails there should be shown just the messagebox for this specific one and the panel which the user wanted to leave should be refocused without processing the following validators to not get a bunch of messageboxes to close at once.

This would replace the existing ConditionValidator, which can be marked deprecated and removed in some version > 5.0.






[IZPACK-1106] Disable Next button on PacksPanel if no visible pack is selected Created: 04/Jun/14  Updated: 05/Jun/14  Resolved: 05/Jun/14

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

Type: Improvement 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

Number of attachments : 0

 Description   

Currently it is possible to unselect all packs in the PacksPanel and switching to the next panel. This is not intuitive and makes no sense from the user's point of view, even if there are hidden packs.
There should be at least one visible pack selected on the packPanel, either by the user or a required one, to show the user that something will be installed when he presses Next.
Disable the Next button as long as there is no pack selected.



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

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

Comment by Tom Helpstone [ 04/Jun/14 ]

"hidden panel" and "visible panel" should be "pack" instead, shouldn't it?

Comment by Rene Krell [ 04/Jun/14 ]

Of course, thanks. It has been a typo day today...

Comment by Rene Krell [ 05/Jun/14 ]

Pull request merged.





Eclipse does show several warnings (IZPACK-1103)

[IZPACK-1105] Class is a raw type. References to generic type Class<T> should be parameterized Created: 04/Jun/14  Updated: 02/Oct/14  Resolved: 02/Oct/14

Status: Resolved
Project: IzPack
Component/s: None
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: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

To reduce numbver of warnings



 Comments   
Comment by Tom Helpstone [ 04/Jun/14 ]

started work in https://github.com/Helpstone/izpack/tree/IZPACK-1105a

Pull request https://github.com/izpack/izpack/pull/278 does remove 16 warnings by paramterizing the Classes

Comment by Rene Krell [ 02/Oct/14 ]

Merged pull request #278.

Thanks for contributing.





Eclipse does show several warnings (IZPACK-1103)

[IZPACK-1104] unused code in boolean expressions Created: 03/Jun/14  Updated: 06/Oct/14  Resolved: 06/Oct/14

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

Type: Sub-task Priority: Trivial
Reporter: Tom Helpstone Assignee: Unassigned
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   

In /izpack-core/src/test/java/com/izforge/izpack/core/rules/RulesEngineImplTest.java there is unused code in the regular expressions. For example:

        condition = engine.getCondition("@false && false");
        assertEquals(false && false, condition.isTrue());

The intention is clear: The expression used in the method call is reused in the assert-Check. This is a good decision

In order to get rid of the warnings, I want to add a

 @SuppressWarnings("unused")

Question: Will be the existing Annotation

 @SuppressWarnings("PointlessBooleanExpression")

still be needed? It seems to belong to IntelliJ IDEA ?



 Comments   
Comment by Tom Helpstone [ 16/Sep/14 ]

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

Comment by Tom Helpstone [ 18/Sep/14 ]

Have to reapply this fix, because I did remove it with PR #275 yesterday

Comment by Tom Helpstone [ 06/Oct/14 ]

Pull Request has been merged Oct 2nd





[IZPACK-1103] Eclipse does show several warnings Created: 03/Jun/14  Updated: 03/Jun/14

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

Type: Bug Priority: Trivial
Reporter: Tom Helpstone Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
? Remaining Estimate: 1 hour, 15 minutes Remaining Estimate: Not Specified
? Time Spent: Not Specified Time Spent: Not Specified
? Original Estimate: 1 hour, 15 minutes Original Estimate: Not Specified
Environment:

Spring Tool Suite 3.5.0 / Eclipse 4.3.2


Sub-Tasks:
Key
Summary
Type
Status
Assignee
IZPACK-1104 unused code in boolean expressions Sub-task Resolved  
IZPACK-1105 Class is a raw type. References to ge... Sub-task Resolved Rene Krell  
IZPACK-1164 unused imports Sub-task Resolved Rene Krell  
IZPACK-1175 Class is a raw type. References to ge... Sub-task Resolved Rene Krell  
Number of attachments : 0

 Description   

The IDE shows a lot of warnings about dead code and references to generic type classes






Refactor generation and processing of installation records (auto-install, unattended installations) (IZPACK-1098)

[IZPACK-1102] Bundle installers - allow building super installers that call subinstallers and partly share common information in auto-install.xml Created: 02/Jun/14  Updated: 02/Jun/14

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

Type: Sub-task 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 needs a concept first:

There are requests to build super installers (of a whole product) that call subinstallers (of single product components). The subinstallers partly might flexibly share common information, like an installation root path, a database schema and master connection, a webserver deployment connection and many more.

The following things would be nice to have:

  • auto-extract common auto-install information from several installers automatically, for instance certain user input variables with the same name, and show them just once for all at the beginning of a bundle installation,
  • in case of missing information in auto-install.xml just this missing inputs should be automatically asked in the according panel, the rest should be hidden or read-only.

This way could be combined several installers to a global one, as far as possible automatically.






Refactor generation and processing of installation records (auto-install, unattended installations) (IZPACK-1098)

[IZPACK-1101] Support creation of installation records without installing Created: 31/May/14  Updated: 24/Sep/14

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

Type: Sub-task Priority: Major
Reporter: Rene Krell Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It should be possible to generate a full auto-install.xml with all possible entries without installing first. The resulting file can be processed later manually or by some other tool.

This needs a concept, can be discussed here.



 Comments   
Comment by Tom Helpstone [ 24/Sep/14 ]

I think this would be a useful feature.

For example for generating an appropriate auto-install.xml on the build server, which does match to the installer.xml. Real installation is not wanted on the buld server of course.

User input is not wanted on the build server. A possible solution could be:

  • mark all packs as selected
  • user input (e.g. TargetPath) is filled with a symbolic name, e.g. the internal name of the variable
  • the target path should not be checked for existence and beeing writeable
    So you would get a auto-install.xml, which has the correct semantic and you can replace the real data for user input with your build tool.

The benefit would be, that a changed installer.xml (e.g. additionial or removed panels) will be reflected in the auto-install.xml.





Refactor generation and processing of installation records (auto-install, unattended installations) (IZPACK-1098)

[IZPACK-1100] Support creation of installation records from FinishPanel for console installers Created: 31/May/14  Updated: 16/Jul/14  Resolved: 16/Jul/14

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

Type: Sub-task Priority: Major
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Fixed Votes: 1
Labels: 5.0.0-rc3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File izpack5_hierarchy.graphml     PDF File izpack5_hierarchy.pdf    
Number of attachments : 2

 Description   

Add the implementation for creating an installation record after at the end of a console installation to FinishPanel.



 Comments   
Comment by Miles Tjandrawidjaja [ 09/Jul/14 ]

Hello,

I see the status is not yet "In Progress" so I might have a look at this.
If in fact there is work currently being done for this, please let me know to prevent overlapping progress.

Thank you

Comment by Rene Krell [ 11/Jul/14 ]

@Miles: I've began with it but unfortunately I got stuck with some other work. I would be glad if you had some time. You can assign it to yourself if you think you get it implemented.

Comment by Miles Tjandrawidjaja [ 11/Jul/14 ]

@Rene: No problem. I don't believe I have permissions to assign issues to myself, unless am just not able to find the button to let me do this. Okay I'll probably have a go at this, thanks for updating me.

Comment by Rene Krell [ 11/Jul/14 ]

Ok, great. Please update to the current master. There have been changes in the last couple of weeks also regarding the output format of the auto-install.xml for Swing installers (IzPanel, InstallerFrame).
Maybe you find additionally a better way of generalizing this with the AutomationHelpers. Anyway it would be fine to see this working. Thanks so far.

Comment by Miles Tjandrawidjaja [ 15/Jul/14 ]

Aside

While thinking of how to generate the automatic installation file through console installer, I was also trying to think of a way to better unify the Console and GUI panels. The problem I'm running into is that the GUI panels eventually extend the JPanels, and the control flow of the program is different from GUI vs Console. The only thing I could think of is using a helper class for each panel to unify any common methods, but doesn't seem that clean. I wonder what you think about the organization of the Console vs GUI installs.

Attached is a really rough diagram I made when trying to find the best way to structure the installer. If it just looks confusing feel free to ignore! II used yEd (http://www.yworks.com/en/products_yed_about.html) to generate the diagram. Graph doesn't really use any standard convention I know of, was more for personal use. Maybe you might find it useful. (Warning: pdf is large so you'll have to zoom in)

Comment by Miles Tjandrawidjaja [ 15/Jul/14 ]

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

Comment by Rene Krell [ 16/Jul/14 ]

Pull request #233 merged.
Thank you very much for this great contribution.





Refactor generation and processing of installation records (auto-install, unattended installations) (IZPACK-1098)

[IZPACK-1099] Refactor automated installations as it is (for Swing installers, but more universal) Created: 31/May/14  Updated: 02/Jun/14  Resolved: 02/Jun/14

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

Type: Sub-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

Number of attachments : 0

 Description   

This includes the necessary API changes and the support for Swing installations, and some smaller improvements.



 Comments   
Comment by Rene Krell [ 02/Jun/14 ]

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

Comment by Rene Krell [ 02/Jun/14 ]

Merged the request before.

Sent further pull request with improvement: https://github.com/izpack/izpack/pull/208, which doesn't use or require internal panel indexes any longer in auto-install.xml record.

Comment by Rene Krell [ 02/Jun/14 ]

Please be aware of the following changes, which might break existing environments:

API changes:

  • PanelViews (added definition: void writeInstallationRecord(File file) throws Exception;)
    |- AbstractPanels (added implementation of interface: public void writeInstallationRecord(File file) throws Exception;)
       |- AutomatedPanels
       |- ConsolePanels
       |- IzPanels
    
  • PanelView (added definition: void createInstallationRecord(IXMLElement rootElement);)
    |- AbstractPanelView (added implementation: protected final IXMLElement createPanelRootRecord())
       |- AutomatedPanelView (added implementation of interface: public void createInstallationRecord(IXMLElement panelRoot);)
       |- ConsolePanelView (added implementation of interface: public void createInstallationRecord(IXMLElement panelRoot);)
       |- IzPanelView (added implementation of interface: public void createInstallationRecord(IXMLElement panelRoot);)
    

    The panelRoot element is a pre-created root just for the panel, not its parent like before. Therefore I found it better to rename the methods completely from makeXml to createInstallationRecord for panel developers to notice this change.

  • IzPanel
    IzPanel is now an abstract class.
    Added default implementation public void createInstallationRecord(IXMLElement rootElement). Each panel which needs to add and vice versa to process data to/from the auto-install.xml record, must override this method. The methods called writeXmlTree() and makeXmlData() have been removed directly, all their logic moved to the abstract layer like described above.
    All built-in panels have been migrated.

The format of the auto-install.xml record changed, you cannot use older ones, but got to regenerate one with the latest installer. Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<AutomatedInstallation langpack="eng">
<com.izforge.izpack.panels.hello.HelloPanel id="HelloPanel_0"/>
<com.izforge.izpack.panels.licence.LicencePanel id="LicencePanel_1"/>
<com.izforge.izpack.panels.userinput.UserInputPanel id="panel.service">
<entry key="serviceAction" value="install"/>
</com.izforge.izpack.panels.userinput.UserInputPanel>
<com.izforge.izpack.panels.target.TargetPanel id="TargetPanel_3">
<installpath>/home/rkrell/myapp</installpath>
</com.izforge.izpack.panels.target.TargetPanel>
<com.izforge.izpack.panels.packs.PacksPanel id="PacksPanel_5">
<pack index="0" name="Application" selected="true"/>
<pack index="1" name=Documentation" selected="false"/>
</com.izforge.izpack.panels.packs.PacksPanel>
<com.izforge.izpack.panels.userinput.UserInputPanel id="panel.paths">
<entry key="path1" value=""/>
<entry key="path2" value="/usr/local/myapp"/>
</com.izforge.izpack.panels.userinput.UserInputPanel>
<com.izforge.izpack.panels.summary.SummaryPanel id="SummaryPanel_12"/>
<com.izforge.izpack.panels.install.InstallPanel id="InstallPanel_13"/>
<com.izforge.izpack.panels.finish.FinishPanel id="FinishPanel_14"/>
</AutomatedInstallation>

Panel IDs are now required. If youo don't use explicit <panel id="..."/> it is automatically created during compilation now (classname+"_"+index). It is recommended to choose you're own panel IDs for all panels to have them unique also after adding/removing panels.

The FinishPanel automatically pre-fills the file name auto-install.xml on the file dialog for saving the installation record.

With this change we are now prepared for more implementations regarding auto-install records, for instance adding their generation to console installers.

Comment by Rene Krell [ 02/Jun/14 ]

Pull request https://github.com/izpack/izpack/pull/208 also merged.





[IZPACK-1098] Refactor generation and processing of installation records (auto-install, unattended installations) Created: 30/May/14  Updated: 03/Jun/14

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

Type: Task Priority: Critical
Reporter: Rene Krell Assignee: Rene Krell
Resolution: Unresolved Votes: 2
Labels: None
? Remaining Estimate: Not Specified Remaining Estimate: Not Specified
? Time Spent: Not Specified Time Spent: Not Specified
? Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
IZPACK-1099 Refactor automated installations as i... Sub-task Resolved Rene Krell  
IZPACK-1100 Support creation of installation reco... Sub-task Resolved Rene Krell  
IZPACK-1101 Support creation of installation reco... Sub-task Open  
IZPACK-1102 Bundle installers - allow building su... Sub-task Open  
Number of attachments : 0

 Description   

The generation of auto installation records from within the FinishPanel and replaying them is not consistent from different points of view:

  1. The installation record (auto-install.xml) can be generated just during GUI installations. No support of generating it for console installers.
  2. Adding the generation of auto-install.xml to the FinishConsolePanel is not possible without refactoring the implementation and API in common, because the whole implementation is bound to Swing installer classes (IzPanel).
  3. The created file cannot always be processed especially for createForPack constraints to UserInputPanel. If there are skipped panels due to this constraints and the installer is re-ran in a same environment with the recorded first installation it fails, because the panels with constraints like createForPack are not skipped, but there is expected and validated user input for them.
  4. It should be possible to simulate the installation and create an auto-install.xml without physically installing (skip activating InstallPanel and ProcessPanel). This might be divided to an interactive simulation and the generation of an auto-install record with all possible entries without any interaction.
  5. The installer should flexibly react on missing user inputs from auto-install.xml, not failing but optionally opening a panel asking just for the missing information.
  6. The file dialog on FinishPanel should offer a default file name.





[IZPACK-1097] Analyze and clean up dependencies Created: 30/May/14  Updated: 02/Jun/14  Resolved: 02/Jun/14

Status: Resolved
Project: IzPack
Component/s: Build
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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, on running 'mvn dependency:analyze' there is reported a couple of unused declared dependencies and also used undeclared dependencies. This should be resolved to make the Maven build and order of module builds in the reactor clean.

Furthermore there are dependency conflicts on transitive dependencies. Different versions should be unified or pinned in the dependencyManagement section of the parent POM.



 Comments   
Comment by Rene Krell [ 31/May/14 ]

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

Comment by Rene Krell [ 02/Jun/14 ]

Pull request merged.





[IZPACK-1096] Allow panel validators to be conditional Created: 28/May/14  Updated: 29/May/14  Resolved: 29/May/14

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

Type: New Feature 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   

Add conditional validation to izpack panels.
Also allow to have more than one panel validators. Currently there can be more than one defined, but during compilation just one of them "wins" and the other validators are silently ignored by the compiler parser, which is bad.

Example:

<condition type="variable" id="Install">
    <name>installAction</name>
    <value>install</value>
</condition>
<condition type="variable" id="Update">
    <name>installAction</name>
    <value>update</value>
</condition>
<condition type="variable" id="Uninstall">
    <name>installAction</name>
    <value>remove</value>
</condition>

<panel classname="UserInputPanel" id="panel.example">
    <validator classname="com.mycompany.MyValidator1" condition="Install" />
    <validator classname="com.mycompany.MyValidator2" condition="Update" />
    <validator classname="com.mycompany.MyValidator3" condition="Uninstall" />
</panel>


 Comments   
Comment by Rene Krell [ 29/May/14 ]

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

Comment by Rene Krell [ 29/May/14 ]

Pull request merged.





[IZPACK-1095] TargetConsolePanel out of sync with TargetPanel Created: 22/May/14  Updated: 27/May/14  Resolved: 27/May/14

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

Type: Bug Priority: Major
Reporter: Miles Tjandrawidjaja Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: targetpanel
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Patch Submitted:
Yes
Number of attachments : 0

 Description   

1. TargetConsolePanel does not show/remember user's most recent installation path.

2. TargetConsolePanel does not check if path is writable.

3. Path normalization for TargetConsolePanel is out of sync with functionality in TargetPanel. For example the tilde is not expanded to the the user's home directory on Unix systems.

4. Installer fails when installation path is defined to a file.For example /home/user/example_file



 Comments   
Comment by Miles Tjandrawidjaja [ 22/May/14 ]

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

Comment by Rene Krell [ 27/May/14 ]

Pull request merged, good catch!





[IZPACK-1094] Use Maven Failsafe Plugin for integration tests Created: 22/May/14  Updated: 27/May/14  Resolved: 27/May/14

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

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   

During the build, integration tests are currently handled by the Maven Surefire Plugin in parallel with the Unit tests in the test phase.

This is not convenient and implies in problems maintaining the POMs.

Integration tests need in several cases packaged artifacts from the reactor build, which haven't been available in the test phase. This resulted in occasional build failures, mostly due to a missing samples/izpack/install.xml from izpack-dist-sources for the IzPack integration tests in izpack-test.

The easiest way how to resolve this is using the Maven Failsafe Plugin for the integration tests, which automatically binds to the correct lifecycle phases.



 Comments   
Comment by Rene Krell [ 27/May/14 ]

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

Comment by Rene Krell [ 27/May/14 ]

Pull request merged.





[IZPACK-1093] SummaryPanel shows content of skipped and not relevant panels Created: 22/May/14  Updated: 29/May/14  Resolved: 29/May/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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to IZPACK-1081 Allow UserInputPanel Fields to be dis... Resolved
Number of attachments : 0

 Description   

There is an issue with the SummaryPanel in common - it shows the contents of all panels, even those that have been skipped depending on certain conditions. You might have for instance a PacksPanel choosing just some part of the installation requiring just a part of UserInputPanels for configuration, but SummaryPanel presents them all.

SummaryPanel should show just the content of that panels, that have been actually visited by the user.



 Comments   
Comment by Rene Krell [ 27/May/14 ]

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

This solves the problem of showing contents of skipped panels the user has never visited or that have been deactivated during a sequence of Back, new choices and new panel conditions in SummaryPanel.
Panels are marked visited now if they have been visited, all following panels are marked unvisited, depending on how the are defined in the section.

In relation to this fix there has been also made a cleanup how createForPack, createForUnselectedPack and os constraints are handled for UserInputPanels. Switching a panel from within activatePanel() has not been a good idea and messed up the AbstractPanels handling.

Comment by Rene Krell [ 27/May/14 ]

Pull request merged.

Comment by Rene Krell [ 29/May/14 ]

Pull request https://github.com/izpack/izpack/pull/204 sent with a post-fix:
Panel condition did override createForPack constraint.

When an explicit has been evaluated true, but a createForPack constraint did not allow the UserInputPanel to be activated. In this case it has been shown anyway.

Comment by Rene Krell [ 29/May/14 ]

Pull request #204 merged.





Missing console installer translations for most languages - please help (IZPACK-1001)

[IZPACK-1092] Support for Spanish translation Created: 21/May/14  Updated: 16/Mar/15

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

Type: Sub-task Priority: Minor
Reporter: Rubén Bressler Assignee: Rene Krell
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours

Number of attachments : 0

 Description   

I suffer from lack of translation into Spanish, in my case my application running in console mode is bound to use English language to prevent ConsoleInstaller.continueQuitRedisplay is displayed instead of the internationalized message.
For that reason I offer to add the translation of these messages to the Spanish language.



 Comments   
Comment by Rubén Bressler [ 21/May/14 ]

fixed in https://github.com/izpack/izpack/pull/199

Comment by Rene Krell [ 21/May/14 ]

Thank you for contributing.

Note: Please don't set issues unless they are actually merged. Now it is really fixed, merged your pull request.

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

Hi!
I'm suffering the same problem with the Spanish translation in console mode. Rubén, you said that you have bounded your application to use English. This solution works for me too, but I'm not able to do that. I would like that the application will ignore the console language and always run in English.

Could you please tell my how to do it? Thanks a lot

I hope the next version will work with the new translations!

Comment by Rene Krell [ 18/Feb/15 ]

Ruben's pull request has been merged and released already beginning from 5.0 RC3 last year.
You can give it a try.

IzPack automatically recognizes the used language from your local environment.
For example, in Linux/Bash, something like
export LANG="en_US.UTF-8"
should do the job before launching the installer.

Comment by Rubén Bressler [ 18/Feb/15 ]

I force the language selection through the execution parameters in this way:

java -Duser.language=en -jar /path/to/jarfile.jar

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

We are using 5.0 RC4 and the translation doesn't work properly in spanish, so we have been searched into the code and revisions.

It seems like there were a mistake in a merge operation and some keys for the "spa.xml" file were lost. For example, keys like "ConsoleInstaller.continueQuitRedisplay" was in the revision before this merge. And after it, the key is missing. The same thing occurs with other console keys

The concrete merge is
https://github.com/izpack/izpack/commit/c11402286e59ab7c1bdcefaa7cfaad32431c178b

when there was a conflict with file "izpack-core/src/main/resources/com/izforge/izpack/bin/langpacks/installer/spa.xml"

I hope it will help to solve the issue

Thank you all!

Comment by Rubén Bressler [ 18/Feb/15 ]

True, there is a conflict in the last change to that file. Furthermore, in our project we are using the version 5.0RC4 and do not show internationalized messages properly in Spanish.

Comment by Rene Krell [ 18/Feb/15 ]

Would you be able to fix this in a new pull request?

Comment by Rubén Bressler [ 19/Feb/15 ]

Yes, let me do it.

Comment by Aitor Sánchez [ 19/Feb/15 ]

Thank you!

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

Hi!

Finally I did the pull request for solving this issue:
https://github.com/izpack/izpack/pull/331

All the file has been adapted and modified in order to sort the keys in the
same order than in the english "eng.xml" file





[IZPACK-1091] Have to lock next-button in the custom panel when a radio-button is selected. Created: 19/May/14  Updated: 19/May/14

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

Type: Bug Priority: Major
Reporter: Ilakkiya Sivaraj Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: custom, installers, panel-action
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Izpack rc2,Windows 7


Number of attachments : 0

 Description   

Hi,
I am creating a custom panel for my Installer where I need to lock the next button if a particular radio button is selected. I have all the radio button ids created in my userinputSpec.xml.
When the user choose a particular radio-button, I should be able to lock the next button.
In my custom panel I should get the radio button id and I should lock it,but I don't know how to get the id from the userinputpanel.order0 which is present in my userinputSpec.xml.

The custom input panel will be
<panel classname="com.izforge.izpack.panels.NewUserInputPanel" id="userinputpanel.order0" />

I should get the radio-button id from the userinputpanel.order0 and perform the locking operation in NewUserInputPanel.java

Can somebody help me in resolving this issue.

Thanks,
Ilakkiya,S






[IZPACK-1090] Allow tab completion and password masking in console mode Created: 16/May/14  Updated: 26/Jul/14  Resolved: 26/Jul/14

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

Type: New Feature 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
Environment:

Linux/Windows


Attachments: Zip Archive ConsoleDemo.zip    
Issue Links:
Duplicate
duplicates IZPACK-1134 Password field not working for consol... Resolved
Number of attachments : 1

 Description   

It would be nice to have tab completion when typing out file and directory locations during a console installation. Perhaps we can use an open source library https://github.com/jline/jline2.
It would also be nice to have passwords masked in console mode just like in GUI.



 Comments   
Comment by Miles Tjandrawidjaja [ 24/Jun/14 ]

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

Comment by Rene Krell [ 04/Jul/14 ]

Pull request merged

Comment by Rene Krell [ 07/Jul/14 ]

The tab completion works very well in the console installer.
There is one issue left, probably being caused by the introduction of jline:

On launching console installations I get a couple of

Unable to bind key for unsupported operation

lines like this:

rkrell@rkrell:~> sudo java -jar my-app-installer.jar
root's password:
Jul 7, 2014 3:02:09 PM INFO: Logging initialized at level 'INFO'
Jul 7, 2014 3:02:09 PM INFO: Commandline arguments:
Jul 7, 2014 3:02:10 PM INFO: Detected platform: linux,version=3.15.3-37.g42bf625-desktop,arch=x64,symbolicName=null,javaVersion=1.6.0_45
[INFO] Unable to bind key for unsupported operation: backward-delete-word
[INFO] Unable to bind key for unsupported operation: backward-delete-word
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
Welcome to the installation of My Application 1.1!
...

Seen on OpenSuSE Linux 13.1 / x86_64 with Oracle JRE 1.6.0_45.

I could not encounter any subsequent problem, but it is not very nice.

Can you please have a look at it?

Comment by Miles Tjandrawidjaja [ 07/Jul/14 ]

Alright I'll try to reproduce on a VM and have a look.
Related: https://github.com/jline/jline2/issues/73

So it looks like the issue can be reproduced when the user does not have a ~/.inputrc file.
On my default installation of OpenSuSe the /root/.inputrc file does not exist, thus causing those logging messages. The messages do not appear if you do something like "touch ~/.inputrc".

On my Fedora machine it looks like it does not matter if I have a ~/.inputrc file available or not. I suspect this may be dependent on how your linux distribution packages the readline package. On OpenSuse it looks like it comes from "libreadline6" .

Is there currently a way to run the installer without logging? Another solution could be to fork the jline project and remove that logging information. Please lend me your suggestions we can look further into this if you'd like. Thanks for pointing this out.

Comment by Rene Krell [ 09/Jul/14 ]

Maybe one would not agree, but I'd prefer the most pragmatic way, creating the .inputrc in the installer users home directory automatically when running console installations and if it doesn't already exist. I don't see any risk here.

Forking jline is also an option, but adds unnecessary work for us.

Being able to control installer logging in a more fine-grain manner is still an issue, there also in Jira. It would be better to switch off logging by default for console installations in future.

Comment by Rene Krell [ 14/Jul/14 ]

We got another, more serious problem with the embedded usage of jline on Windows 7. I divided it into two parts:

PART 1

14.7.2014 14:41:59 INFO: Logging initialized at level 'INFO'
14.7.2014 14:41:59 INFO: Commandline arguments: -console
14.7.2014 14:41:59 INFO: Detected platform: windows,version=6.1,arch=x64,symbolicName=WINDOWS_7,javaVersion=1.7.0_51
Exception in thread "main" java.lang.NoClassDefFoundError: org/fusesource/jansi/WindowsAnsiOutputStream
 at java.lang.Class.getDeclaredConstructors0(Native Method)
 at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
 at java.lang.Class.getConstructor0(Unknown Source)
 at java.lang.Class.newInstance(Unknown Source)
 at jline.TerminalFactory.getFlavor(TerminalFactory.java:166)
 at jline.TerminalFactory.create(TerminalFactory.java:81)
 at jline.TerminalFactory.get(TerminalFactory.java:158)
 at jline.console.ConsoleReader.<init>(ConsoleReader.java:229)
 at jline.console.ConsoleReader.<init>(ConsoleReader.java:221)
 at jline.console.ConsoleReader.<init>(ConsoleReader.java:209)
 at com.izforge.izpack.util.Console.<init>(Console.java:65)
 at com.izforge.izpack.util.Console.<init>(Console.java:50)
 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: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: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.InstallerContainer.resolveComponents(InstallerContainer.java:142)
 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.ConsoleInstallerContainer.<init>(ConsoleInstallerContainer.java:56)
 at com.izforge.izpack.installer.bootstrap.Installer.launchConsoleInstaller(Installer.java:249)
 at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:219)
 at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:189)
 at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:68)
Caused by: java.lang.ClassNotFoundException: org.fusesource.jansi.WindowsAnsiOutputStream
 at java.net.URLClassLoader$1.run(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)
 ... 70 more

This part I resolved by adding this line to com.izforge.izpack.compiler.packager.impl.PackagerBase.writeSkeletonInstaller():

        mergeManager.addResourceToMerge("org/fusesource/jansi");

PART 2

[ERROR] Terminal initialization failed; falling back to unsupported
java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32
 at org.fusesource.jansi.internal.WindowsSupport.getConsoleMode(WindowsSupport.java:50)
 at jline.WindowsTerminal.getConsoleMode(WindowsTerminal.java:204)
 at jline.WindowsTerminal.init(WindowsTerminal.java:82)
 at jline.TerminalFactory.create(TerminalFactory.java:101)
 at jline.TerminalFactory.get(TerminalFactory.java:158)
 at jline.console.ConsoleReader.<init>(ConsoleReader.java:229)
 at jline.console.ConsoleReader.<init>(ConsoleReader.java:221)
 at jline.console.ConsoleReader.<init>(ConsoleReader.java:209)
 at com.izforge.izpack.util.Console.<init>(Console.java:65)
 at com.izforge.izpack.util.Console.<init>(Console.java:50)
 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: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: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.InstallerContainer.resolveComponents(InstallerContainer.java:142)
 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.ConsoleInstallerContainer.<init>(ConsoleInstallerContainer.java:56)
 at com.izforge.izpack.installer.bootstrap.Installer.launchAutomatedInstaller(Installer.java:233)
 at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:215)
 at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:189)
 at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:68)
14.7.2014 14:59:51 WARNING: AutomationHelper class not found for panel class: com.izforge.izpack.panels.hello.HelloPanel
14.7.2014 14:59:51 WARNING: AutomationHelper class not found for panel class: com.izforge.izpack.panels.licence.LicencePanel
14.7.2014 14:59:51 WARNING: AutomationHelper class not found for panel class: com.izforge.izpack.panels.summary.SummaryPanel
14.7.2014 15:00:06 WARNING: AutomationHelper class not found for panel class: com.izforge.izpack.panels.finish.FinishPanel
[WARN] Task failed
java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32
 at org.fusesource.jansi.internal.WindowsSupport.setConsoleMode(WindowsSupport.java:60)
 at jline.WindowsTerminal.setConsoleMode(WindowsTerminal.java:208)
 at jline.WindowsTerminal.restore(WindowsTerminal.java:95)
 at jline.TerminalSupport$1.run(TerminalSupport.java:52)
 at jline.internal.ShutdownHooks.runTasks(ShutdownHooks.java:66)
 at jline.internal.ShutdownHooks.access$000(ShutdownHooks.java:22)
 at jline.internal.ShutdownHooks$1.run(ShutdownHooks.java:47)

This is weird. Although all proper subclasses are already compiled into the installer after the fix from PART 1, some JNI classes cannot be loaded. I found the following hints:
https://github.com/fusesource/jansi-native/blob/master/src/main/native-package/
https://groups.google.com/forum/#!topic/jansi-dev/54Z0CNQ2YOE
https://forums.bukkit.org/threads/could-not-initialize-class-org-fusesource-jansi-internal-kernel32.86345/
http://karaf.922171.n3.nabble.com/JLine-issue-with-Karaf-2-2-8-on-windows-2008R2-td4025054.html
--> It seems like jline requires the Microsoft Visual C++ 2008 SP1 Redistributable Package, because there are some JNI mappings compiled against this library.

This is really not good. We cannot expected an optional package to be installed on Windows to prevent the installer from crashing. If the installation would go on with maximum a warning on the way (best at debug level) it would be a way to go, although I'm not sure whether it would be worth the static overhead introduced by jline.
In case there is no way around I'd recommend to revert this feature or to revert or deactivate this feature for Windows meanwhile.

Is there an alternative to jline?
Are the failing classes needed at all for tab completion? Isn't it possible to deactivate those shutdown hooks etc. to not getting accessed JNI classes at all?

Comment by Rene Krell [ 14/Jul/14 ]

I compiled a simple example using jline with file name completion that I found here: http://jeszysblog.wordpress.com/2012/04/14/readline-style-command-line-editing-with-jline/.
Than we tested this simple example on the computer where the above JNI problem occurs in the IzPack console mode.
There are no complaints with this example at all. I will add it as attachment.

Comment by Rene Krell [ 14/Jul/14 ]

Simple, standalone demo of using JLine with file name completion.

Comment by Miles Tjandrawidjaja [ 14/Jul/14 ]

If you are looking for an alternative aesh might be suitable, but I have not used it before so I don't know how it will hold up.
The project seems fairly active, I posted some links below.
http://aeshell.github.io/
https://github.com/aeshell/aesh

If there are plans to release RC3 soon I would opt for disabling for Windows.
I would prefer to keep the auto-completion feature in as I believe Linux users expect this sort of functionality.
I'll also have a look and update you if I find any new information.

Comment by Rene Krell [ 14/Jul/14 ]

The point is that the demo from the attachment runs on the same Windows 7 system the stacktraces have been reported against without any complaints.

Therefore, I made some further tests and found out the following:

If you remove the META-INF/native directory with the DLLs from jline-2.12.jar/ and relaunch ConsoleDemo there happen exceptions of the kind above. Thus, the solution might be adding the DLLs from the jline Maven dependency to IzPack directly, probably directly to the installer's manifest for finding them by the library loader of jline. Alternatively we can adopt the jline library and override its native library loading to be compatible to IzPack library loading.

In each case it should be a robust solution. One variant would be having file name completion optional. If one needs it, he/she got to add the native built-in libraries of his/her choice.

The challenge here is probably finding a way how to replace the jline's native library loading actually done in org.fusesource.hawtjni.runtime.Library by IzPack's com.izforge.izpack.util.Librarian or finding a trick how to get the jansi.dll for the appropriate platform loaded using org.fusesource.hawtjni.runtime.Library from within IzPack. Just adding jline's META.INF/native/ directory recursively to the installer's META.INF does not work.

Comment by Rene Krell [ 15/Jul/14 ]

I'll have a look at this, probably actually needs to reuse the jline2 code and replace the native library loading by the IzPack native kind of ho Librarian does it...

Comment by Rene Krell [ 16/Jul/14 ]

Added and merged pull request https://github.com/izpack/izpack/pull/234.
This is still work in progress, but the fallback should work now if the ConsoleReader cannot be initialized. Running the ConsoleDemo attached works always, so there must be a way. Interrupting work at the moment. I f someone has an idea how to get it work on Windows please drop a note.

Comment by Rene Krell [ 17/Jul/14 ]

The pull request has been reverted, adoption of jline is too dirty.
Still needs a solution for Windows systems.

Comment by Rene Krell [ 17/Jul/14 ]

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

Comment by Rene Krell [ 17/Jul/14 ]

Merged pull request #240.

Still to do:

  • stabilize ConsoleReader initialization on Windows
  • Connect JLine logging to IzPack logging (logging suppressed for now),
    We can create a separate issue and resolve this for RC3 as soon as there pass some more complex tests with this feature.

If the logging would not be silent, there might happen outputs like these:

java -jar my-installer.jar autoinstall.xml

17.7.2014 18:01:20 INFO: Logging initialized at level 'INFO'
17.7.2014 18:01:20 INFO: Commandline arguments: autoinstall.xml
17.7.2014 18:01:27 INFO: Detected platform: windows,version=6.1,arch=x64,symbolicName=WINDOWS_7,javaVersion=1.7.0_51
[ERROR] Terminal initialization failed; falling back to unsupported java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32
at org.fusesource.jansi.internal.WindowsSupport.getConsoleMode(WindowsSupport.java:50)
at jline.WindowsTerminal.getConsoleMode(WindowsTerminal.java:204)
at jline.WindowsTerminal.init(WindowsTerminal.java:82)
at jline.TerminalFactory.create(TerminalFactory.java:101)
at jline.TerminalFactory.get(TerminalFactory.java:158)
at jline.console.ConsoleReader.<init>(ConsoleReader.java:229)
at jline.console.ConsoleReader.<init>(ConsoleReader.java:221)
at com.izforge.izpack.util.Console.<init>(Console.java:64)
at com.izforge.izpack.util.Console.<init>(Console.java:51)
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: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: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.InstallerContainer.resolveComponents(InstallerContainer.java:142)
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.ConsoleInstallerContainer.<init>(ConsoleInstallerContainer.java:56)
at com.izforge.izpack.installer.bootstrap.Installer.launchAutomatedInstaller(Installer.java:239)
at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:221)
at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:193)
at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:72)

...

[ Starting automated installation ]

17.7.2014 18:01:50 WARNING: AutomationHelper class not found for panel class: com.izforge.izpack.panels.hello.HelloPanel
17.7.2014 18:01:50 WARNING: AutomationHelper class not found for panel class: com.izforge.izpack.panels.licence.LicencePanel
17.7.2014 18:01:52 WARNING: AutomationHelper class not found for panel class: com.izforge.izpack.panels.summary.SummaryPanel
[ Starting to unpack ]
[ Unpacking finished ]
17.7.2014 18:01:53 WARNING: AutomationHelper class not found for panel class: com.izforge.izpack.panels.finish.FinishPanel
[ Automated installation done ]
[WARN] Task failed
java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32
at org.fusesource.jansi.internal.WindowsSupport.setConsoleMode(WindowsSupport.java:60)
at jline.WindowsTerminal.setConsoleMode(WindowsTerminal.java:208)
at jline.WindowsTerminal.restore(WindowsTerminal.java:95)
at jline.TerminalSupport$1.run(TerminalSupport.java:52)
at jline.internal.ShutdownHooks.runTasks(ShutdownHooks.java:66)
at jline.internal.ShutdownHooks.access$000(ShutdownHooks.java:22)
at jline.internal.ShutdownHooks$1.run(ShutdownHooks.java:47)

This might be helpful for further analyzing.

Comment by Rene Krell [ 18/Jul/14 ]

Merged another pull request: https://github.com/izpack/izpack/pull/242

In case the ConsoleReader cannot be initialized correctly according to the given OS, the Fallback should work now completely. This has been necessary otherwise the password console input field was broken in that state.

This should be enough for this issue.

We should put the rest as a new issue to the backlog:

  • stabilize ConsoleReader initialization on Windows
    This is still not working reliably on Windows XP and 7
  • In fallback mode, during entering values in the console password input field there should be echoed stars for each character entered. Currently there isn't echoed anything.

Whether the initialization works can be gathered by launching the installer like this:
java -DSTACKTRACE=true installer.jar -console
In case it doesn't work a stacktrace is thrown during the startupof the console installer,

Comment by Miles Tjandrawidjaja [ 25/Jul/14 ]

PR Sent: https://github.com/izpack/izpack/pull/254

I noticed that org/fusesource/hawtjni/ was not being included which is why autocompletion on Windows was not working. I am not sure why on my other Window's machine this was not an issue. Hope this stabilizes Jline for all other Window's user as well. Also make change to allow JLine to handle Ctrl-C during Windows console installation to ensure installer will quit, otherwise Ctrl-C has no feedback for me.

Comment by Rene Krell [ 26/Jul/14 ]

Pull request #254 merged.
Thank you.





[IZPACK-1089] Build does package old artifacts Created: 12/May/14  Updated: 12/May/14  Resolved: 12/May/14

Status: Resolved
Project: IzPack
Component/s: Build
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
Environment:

Eclipse build with maven embedded 3.0.4


Number of attachments : 0

 Description   

When packaging the project the artifacts are created and copied to izpack/target/staging/lib. But in the final step creating the izpack-dist-5.0.0-rc3-SNAPSHOT.jar old artifacts from 5.0.0-rc2-SNAPSHOT get packaged.

Adding the version to the plugin does resolve the issue:

<!-- Launch izpack compilation -->
<plugin>
  <groupId>${project.groupId}</groupId>
  <artifactId>izpack-maven-plugin</artifactId>
  <version>${project.version}</version>
  <configuration>
     <comprLevel>9</comprLevel>
  </configuration>
  <executions>
     <execution>
        <phase>package</phase>
        <goals>
          <goal>izpack</goal>
        </goals>
     </execution>
   </executions>
</plugin>


 Comments   
Comment by Tom Helpstone [ 12/May/14 ]

Pull Request 195 does contain the change

Comment by Rene Krell [ 12/May/14 ]

Pull request merged. Thank you.





[IZPACK-1088] Desktop shortcut is not getting created for Unattended installers created using Izpack-RC2 Created: 12/May/14  Updated: 12/May/14

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

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

Windows 7 , Izpack-RC2 ,java 7


Number of attachments : 0

 Description   

Hi,
I created izpack GUI installer which installs my component perfectly on the user's machine . I tried creating un-attended installers using auto-install.xml which I generated by clicking "Generate an automatic install script" on the Finish Panel.When I run the installer from the command prompt , everything is perfect except for Desktop Shortcut. Even shortcut for Start-Menu is getting created. Below is the ShortcutSpec.xml ,

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<shortcuts>
<programGroup defaultName="Flow Tool" location="applications" />
<shortcut
name="TOOL"
programGroup="yes"
desktop="yes"
applications="no"
startMenu="no"
target="$INSTALL_PATH\Fw.bat"
commandLine=""
workingDirectory="$USER_HOME"
description=" Studio - create and animate!"
iconFile="$INSTALL_PATH\spoon.ico"
iconIndex="0"
initialState="noShow">
<createForPack name=" configuration resources" />
</shortcut>
</shortcuts>

Kindly help me in resolving this issue.

Thanks,
Ilakkiya






Compiler doesn't parse <refpacks> - missing XSD for refpack files (IZPACK-980)

[IZPACK-1087] Update https://izpack.github.io/schema/5.0/izpack-installation-5.0.xsd Created: 07/May/14  Updated: 07/May/14  Resolved: 07/May/14

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

Type: Sub-task Priority: Major
Reporter: Tom Helpstone Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File izpack-installation-5.0.xsd    
Number of attachments : 1

 Description   

Please upload the xsd from Pull-Request 193 onto webserver for Schema validation in XML editors



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

The mentioned pull request has been already merged 2 days ago.
Thank you.

Comment by Tom Helpstone [ 07/May/14 ]

Yes, the pull request has been merged.
But the web site still delivers the old content for the request
https://izpack.github.io/schema/5.0/izpack-installation-5.0.xsd

Comment by Rene Krell [ 07/May/14 ]

You're right, sorry. Finally done, I've just committed this one, no changes to the other XSD's done at the moment.

Comment by Tom Helpstone [ 07/May/14 ]

Now my XML editor and me are happy
Thanks!





[IZPACK-1086] Shortcut panel's start menu and create desktop check boxes aren't independent Created: 29/Apr/14  Updated: 29/Apr/14

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

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

Windows 7,Izpack rc2 maven


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

 Description   

I am using Izpack 5 RC2 for my project .
Below is shortcutSpec.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<shortcuts>
<programGroup defaultName="Tool" location="startMenu" />
<shortcut name="FLOW TOOL"
target="$INSTALL_PATH\F.bat"
workingDirectory="$INSTALL_PATH"
type="Application"
iconFile="$INSTALL_PATH\s.ico"
iconIndex="0"
initialState="noShow"
programGroup="yes"
desktop="yes"
applications="no"
startMenu="yes"
startup="no" />
</shortcuts>
When I compile and run the installer,in the shortcut panel two check-boxes are visible one for the start-menu and the other for desktop shortcut . The check-box for start menu remains checked by default .
1.When both the check-boxes are selected ,shortcuts are created successfully.
2.When Start-Menu option alone is checked and the Desktop shortcut option is not selected ,only the Start menu shortcut is created which is expected.
3.The issue is that when I try to select Desktop shortcut option alone(which means I am unchecking Start Menu option ) .The shortcut for desktop is not getting created.

Is something wrong with my xml file?Kindly help me in resolving this issue as I am in great need of it.






[IZPACK-1085] In Console mode file field cannot be empty dispite "allowEmptyValue=true" Created: 25/Apr/14  Updated: 16/Jul/14  Resolved: 16/Jul/14

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

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

Linux


Number of attachments : 0

 Description   

in com.izforge.izpack.panels.userinput.console.file.AbstractConsoleFileField
there is a method display().
It uses fileFieldView.validate(path) to validate the path.
Although fileFieldView.validate(path) consider value of "allowEmptyValue" parameter, path that is passed to this method from display() is not allowed to be empty.



 Comments   
Comment by Francisco Canas [ 09/Jul/14 ]

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

Comment by Rene Krell [ 16/Jul/14 ]

Pull request #228 merged.
Thanks for your contribution.





[IZPACK-1084] IzPack should leave compiler version in MANIFEST of installer jar Created: 16/Apr/14  Updated: 20/May/14  Resolved: 20/May/14

Status: Resolved
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: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The IzPack compiler leaves currently the following MANIFEST.MF in an installer jar:

Manifest-Version: 1.0
Built-By: IzPack
Main-Class: com.izforge.izpack.installer.bootstrap.Installer

For debugging purposes, there should be more information, at least the

  • release or snapshot version,
  • the GIT footprint / revision.


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

This is the first part, to have at least the POM version of IzPack in the manifest:
Sent pull request https://github.com/izpack/izpack/pull/196

The second part could be adding a buildnumber to it, any suggestions about the appropriate entry key name?

Comment by Rene Krell [ 20/May/14 ]

Merged second oull request https://github.com/izpack/izpack/pull/198 manually.

Comment by Rene Krell [ 20/May/14 ]

Leaving now version and build number in all manifests.
For the Java-compiled jars, they will appear in the default entries:

Implementation-Version: 5.0.0-rc3-SNAPSHOT
Implementation-Build: d2b20

For the IzPack-compiled jars, like for example izpack-dist-5.0.0-rc3-SNAPSHOT.jar, there is used now:

Created-By: 5.0.0-rc3-SNAPSHOT-d2b20 (IzPack)

Any opinions and improvements welcome.





[IZPACK-1083] IzPack 5.0.0 RC2 when built using ant throws "Could not create type izpack as the class class com.izforge.izpack.event.ConfigurationActionTask has no compatible constructor " error Created: 10/Apr/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

Type: Bug Priority: Major
Reporter: Ilakkiya Sivaraj Assignee: Unassigned
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


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

 Description   

I am using IzPack 5 RC1,as I have noticed the latest release IzPack 5.0.0 RC2 , I tried upgrading my project .But I am getting the below error when I built it using ant.

Apache Ant(TM) version 1.8.2 compiled on December 20 2010
Buildfile: C:\Workspace\Izpack_5_rc2\build.xml
parsing buildfile C:\Workspace\Izpack_5_rc2\build.xml with URI = file:/C:/Workspace/Izpack_5_rc2/build.xml
Project base dir set to: C:\Workspace\Izpack_5_rc2
parsing buildfile jar:file:/C:/Users/311771/Desktop/Eclipse_3.7.1/plugins/org.apache.ant_1.8.2.v20110505-1300/lib/ant.jar!/org/apache/tools/ant/antlib.xml with URI = jar:file:/C:/Users/311771/Desktop/Eclipse_3.7.1/plugins/org.apache.ant_1.8.2.v20110505-1300/lib/ant.jar!/org/apache/tools/ant/antlib.xml from a zip file
Build sequence for target(s) `install' is [install]
Complete build sequence is [install, ]
install:

BUILD FAILED
C:\Workspace\Izpack_5_rc2\build.xml:16: Could not create type izpack as the class class com.izforge.izpack.event.ConfigurationActionTask has no compatible constructor
at org.apache.tools.ant.AntTypeDefinition.createAndSet(AntTypeDefinition.java:285)
at org.apache.tools.ant.AntTypeDefinition.icreate(AntTypeDefinition.java:219)
at org.apache.tools.ant.AntTypeDefinition.create(AntTypeDefinition.java:206)
at org.apache.tools.ant.ComponentHelper.createComponent(ComponentHelper.java:286)
at org.apache.tools.ant.ComponentHelper.createComponent(ComponentHelper.java:264)
at org.apache.tools.ant.UnknownElement.makeObject(UnknownElement.java:417)
at org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:163)
at org.apache.tools.ant.Task.perform(Task.java:347)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.eclipse.ant.internal.launching.remote.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.eclipse.ant.internal.launching.remote.InternalAntRunner.run(InternalAntRunner.java:424)
at org.eclipse.ant.internal.launching.remote.InternalAntRunner.main(InternalAntRunner.java:138)

Total time: 3 seconds

Please help resolving the issue.



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

The buildfile is totally wrong from what I see:

<taskdef name="izpack" classpathref="build.classpath" classname="com.izforge.izpack.event.ConfigurationActionTask"/>

cannot work, because ConfigurationActionTask is no Ant task.
This is just a class used as part of the implementation of the ConfigurationInstallerListener. If you want to use it, use the configuration actions like described.

Comment by Rene Krell [ 15/Apr/14 ]

There is another possibility, this is probably what you actually wanted, see http://docs.codehaus.org/display/IZPACK/Compiling+using+Ant.
You got to include several jar files from artifacts from the IzPack build, like izpack-ant.jar, izpack-compiler.jar and many more, partly depending on what your installer contains.
The usage of the Maven IzPack plugin saves you from this.

This has nothing in common with differences between RC1 and RC2.





[IZPACK-1082] Make "location" filter on dynamic variables format the basedir according to the OS Created: 10/Apr/14  Updated: 10/Apr/14

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

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

Number of attachments : 0

 Description   

For dynamic variables there can be used a location filter to resolve relational directories against a certain base directory.
Currently, if the value of the basedir is not formatted like usual on a certain OS, for example:

<variable name="jarFile" checkonce="true" value="lib/app.jar" condition="haveRootPath>
  <filters>
    <location basedir="C:\folder"/>
  </filters>
</variable>

results in "C:\folder/lib/app.jar" instead of "C:\folder\lib\app.jar" when installing on Windows.

This should be changed.






[IZPACK-1081] Allow UserInputPanel Fields to be displayed in the Summary Panel Created: 09/Apr/14  Updated: 22/May/14  Resolved: 19/May/14

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

Type: New Feature Priority: Minor
Reporter: Miles Tjandrawidjaja Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Issue Links:
Related
is related to IZPACK-1093 SummaryPanel shows content of skipped... Resolved
Patch Submitted:
Yes
Number of attachments : 0

 Description   

Seems like most panel contents are able to be summarized by the SummaryPanel, but the UserInputPanel currently does not have this ability. It would be great for the user to be able to configure what contents of their UserInputPanel can be displayed on the SummaryPanel.



 Comments   
Comment by Miles Tjandrawidjaja [ 09/Apr/14 ]

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

Comment by Rene Krell [ 09/May/14 ]

Pull request merged.
Thank you.

Comment by Rene Krell [ 12/May/14 ]

The implementation works. One more note: From our testing and my point of view it would be better summaryKey to refer to the translation key instead of a static string? This would make this feature fully internationalizable.

Comment by Miles Tjandrawidjaja [ 16/May/14 ]

Hello, I think I am referring to a translation key instead of a static string. Isn't it if I do installData.getMessages().get(<string_key_here>), then it would refer to my translation file? I am using English strings in CustomLangPack.xml and the SummaryPanel seems to be pulling the correct values. I just defined another file CustomLangPack.xml_fra to test, and it also seems to be pulling correct values. Let me know if I am missing some case.

Comment by Rene Krell [ 19/May/14 ]

Yes, you're right my fault. Sorry.

Comment by Rene Krell [ 22/May/14 ]

There is still another issue with the SummaryPanel in common - it shows the contents of all panels, even those that have been skipped depending on certain conditions. You might have for instance a PacksPanel choosing just some part of the installation requiring just a part of UserInputPanels for configuration, but SummaryPanel presents them all.
I have already a solution for it, this belongs to a separate issue, does not depend on this here so much. It rather cames up after your fix, because there is in most cases more than one UserInputPanel and making UserInputPanels visible depends on certain conditions in more complex installers.





[IZPACK-1080] Slow unpacking of files during the installation when using packfile references to a different pack Created: 09/Apr/14  Updated: 14/Nov/14

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

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

Number of attachments : 0

 Description   

There is a performance leak when using packfile references to files in a different pack.
Packfile references are used to not pack the same file twice in case it occurs in the list of files to be installed of another pack. In this case there is created a reference:

Packager.writePacks():

// use a back reference if file was in previous pack, and in
// same jar
Object[] info = storedFiles.get(file);
if (info != null && !packSeparateJars())
{
    packFile.setPreviousPackFileRef((String) info[0], (Long) info[1]);
    addFile = false;
}

During unpacking such referenced files, the unpacker gets very slow and unpacks files of a few KBytes in a time of about 2-3 seconds per file. The installer Java process consumes 100% CPU time in this situation.

Here's a threaddump I made during such a situation on Windows XP, JRE 1.6.0_45:

Full thread dump Java HotSpot(TM) Client VM (20.45-b01 mixed mode, sharing):

"IzPack - Unpacker thread" prio=6 tid=0x0347d800 nid=0xca0 runnable [0x0342f000]
   java.lang.Thread.State: RUNNABLE
        at java.util.zip.Inflater.inflateBytes(Native Method)
        at java.util.zip.Inflater.inflate(Unknown Source)
        - locked <0x2808dac8> (a java.util.zip.ZStreamRef)
        at java.util.zip.InflaterInputStream.read(Unknown Source)
        at java.util.zip.InflaterInputStream.skip(Unknown Source)
        at java.io.FilterInputStream.skip(Unknown Source)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.skip(UnpackerBase.java:1186)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.extract(UnpackerBase.java:585)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:554)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:446)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:406)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:260)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.run(UnpackerBase.java:242)
        at java.lang.Thread.run(Unknown Source)

"TimerQueue" daemon prio=6 tid=0x03138c00 nid=0xd7c in Object.wait() [0x033bf000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x280c5580> (a javax.swing.TimerQueue)
        at javax.swing.TimerQueue.run(Unknown Source)
        - locked <0x280c5580> (a javax.swing.TimerQueue)
        at java.lang.Thread.run(Unknown Source)

"DestroyJavaVM" prio=6 tid=0x003b6c00 nid=0xbec waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"AWT-EventQueue-0" prio=6 tid=0x02fbe000 nid=0xb08 in Object.wait() [0x0333f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x27ef0428> (a java.awt.EventQueue)
        at java.lang.Object.wait(Object.java:485)
        at java.awt.EventQueue.getNextEvent(Unknown Source)
        - locked <0x27ef0428> (a java.awt.EventQueue)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)

"AWT-Windows" daemon prio=6 tid=0x02fbc800 nid=0x6f8 runnable [0x032af000]
   java.lang.Thread.State: RUNNABLE
        at sun.awt.windows.WToolkit.eventLoop(Native Method)
        at sun.awt.windows.WToolkit.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

"AWT-Shutdown" prio=6 tid=0x02fbb000 nid=0x308 in Object.wait() [0x0325f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x27ef0570> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:485)
        at sun.awt.AWTAutoShutdown.run(Unknown Source)
        - locked <0x27ef0570> (a java.lang.Object)
        at java.lang.Thread.run(Unknown Source)

"Java2D Disposer" daemon prio=10 tid=0x02fba400 nid=0xf6c in Object.wait() [0x0320f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x27ef0608> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(Unknown Source)
        - locked <0x27ef0608> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(Unknown Source)
        at sun.java2d.Disposer.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

"Low Memory Detector" daemon prio=6 tid=0x02c82000 nid=0x8f0 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread0" daemon prio=10 tid=0x02c73400 nid=0xdec waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" daemon prio=10 tid=0x02c71c00 nid=0xd3c runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x02c70400 nid=0x110 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=8 tid=0x02c6bc00 nid=0xd78 in Object.wait() [0x02dff000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x27ef0860> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(Unknown Source)
        - locked <0x27ef0860> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(Unknown Source)
        at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)

"Reference Handler" daemon prio=10 tid=0x02c67000 nid=0xe2c in Object.wait() [0x02daf000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x27ef0270> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
        - locked <0x27ef0270> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x02c2a800 nid=0xd84 runnable

"VM Periodic Task Thread" prio=10 tid=0x02c95800 nid=0xa8c waiting on condition

JNI global references: 2472

Heap
 def new generation   total 24448K, used 10573K [0x229a0000, 0x24420000, 0x27ef0000)
  eden space 21760K,  36% used [0x229a0000, 0x23153788, 0x23ee0000)
  from space 2688K, 100% used [0x23ee0000, 0x24180000, 0x24180000)
  to   space 2688K,   0% used [0x24180000, 0x24180000, 0x24420000)
 tenured generation   total 54168K, used 51302K [0x27ef0000, 0x2b3d6000, 0x329a0000)
   the space 54168K,  94% used [0x27ef0000, 0x2b109b38, 0x2b109c00, 0x2b3d6000)
 compacting perm gen  total 12288K, used 9143K [0x329a0000, 0x335a0000, 0x369a0000)
   the space 12288K,  74% used [0x329a0000, 0x3328dcf8, 0x3328de00, 0x335a0000)
    ro space 10240K,  51% used [0x369a0000, 0x36ed3000, 0x36ed3000, 0x373a0000)
    rw space 12288K,  55% used [0x373a0000, 0x37a3e4f8, 0x37a3e600, 0x37fa0000)





[IZPACK-1079] Custom listeners - "afterpack" actions executed before <parsable> files get parsed Created: 09/Apr/14  Updated: 07/Oct/14  Resolved: 07/Oct/14

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

Type: Bug Priority: Major
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   

If custom listeners, like the AntActionInstallerListener, use actions with ordering "afterpack" (not "afterpacks"), and there files in the according pack marked <parsable>, parsing those files takes place after executing the "afterpack" actions.

This is not intended. The "afterpack" actions should take place after all unpacker operations, which includes parsing and substituting variables in text files.
The ordering should be fixed, for producing pre-processed input files to the afterpack action.



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

Development hint after a shot analysis:

Parsing is executed here:
com.izforge.izpack.installer.unpacker.UnpackerBase.postUnpack(List<Pack>, FileQueue, List<ParsableFile>, List<ExecutableFile>, List<UpdateCheck>)
but the afterpack actions are called here
com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(List<Pack>, FileQueue, List<ParsableFile>, List<ExecutableFile>, List<UpdateCheck>)

Comment by Rene Krell [ 07/Oct/14 ]

Duplicate of IZPACK-1116, solved.





[IZPACK-1078] Expand items in TreePacksPanel Created: 08/Apr/14  Updated: 08/Apr/14

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

Type: New Feature Priority: Trivial
Reporter: Mark Heinze 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 may sometimes be useful to have the tree view expanded for the TreePacksPanel. The quick fix for me was to create a new panel that extends the TreePacksPanel (instead of trying to add an attribute to the XML, modifying TreePacksPanel, etc).

I thought it might be useful for someone else so I wanted to provide the source code.



 Comments   
Comment by Mark Heinze [ 08/Apr/14 ]

I'm terrible at git but I tried to make a pull request:

https://github.com/izpack/izpack/pull/188





[IZPACK-1077] Setting compile time options for the installer Created: 07/Apr/14  Updated: 09/Apr/14

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

Type: Improvement Priority: Major
Reporter: Michael Schnupp 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   

For the current project we need to support three variants of installation:

  • ask all questions and install
  • don't ask the questions, take the answers from the file and install (--options)
  • don't install, ask only the questions and write the answers into a file (IZPACK-1073 would be helpful)

I am currently using a system property (IZPACK-1076) to switch between the first and the third mode of operation, which works fine.

Now the request is to be able to set the default mode at compile time.

When building the installer like this:

  <plugin>
    <groupId>org.codehaus.izpack</groupId>
    <artifactId>izpack-maven-plugin</artifactId>
    <extensions>true</extensions>
    <configuration>
      <classifier>foo</classifier>
    </configuration>
  </plugin>

Is there any way to access the classifier from within izpack?

Alternatively, is there another way to set compile-time parameters which can be checked at install time?



 Comments   
Comment by Rene Krell [ 08/Apr/14 ]

I'd not call this a bug, but a question

There can be used classifiers. See http://docs.codehaus.org/display/IZPACK/IzPack+Maven+Plugin+Reference

In particular, use this combination:

<configuration>
      <enableOverrideArtifact>false</enableOverrideArtifact>
      <enableAttachArtifact>true</enableAttachArtifact>
      <classifier>foo</classifier>
</configuration>
Comment by Rene Krell [ 08/Apr/14 ]

To use Maven properties in the install descriptor, just define them in Maven and access them by @{propertyname} from within your descriptor.
A nice usecase for this is using paths to Maven dependencies produced by the properties goal of the maven-dependency-plugin.
See http://docs.codehaus.org/display/IZPACK/Properties for more details and examples.

Comment by Michael Schnupp [ 08/Apr/14 ]

Oops, sorry for the bug. (Did not pay attention at this field.) It is more like a feature request or idea for improvement as I currently do not see a way to accomplish this.

I am aware of the classifier option in the maven plugin. The question is, whether IzPack itself (i.e. configuration.xml or some class called from it) is able to determine which classifier was requested.

I was thinking of a condition like this:

<condition type="classifier" id="isFooRequested">
    <classifier>foo</classifier>
</condition>

Alternatively I was thinking of some custom flag like this:

  <plugin>
    <groupId>org.codehaus.izpack</groupId>
    <artifactId>izpack-maven-plugin</artifactId>
    <extensions>true</extensions>
    <configuration>
      <custom>foo</custom>
    </configuration>
  </plugin>

Which could be accessed as a property or like this:

<condition type="custom" id="isCustomFlagFoo">
    <value>foo</value>
</condition>

Even some completely other way would be fine, as long as I can check some maven configurable value from within my installer. I am currently not aware of such a possibility.
(But as the plugin already supports classifiers, exposing it's value as a property is probably the easiest way.)

Therefore my FeatureRequest: Please expose the classifier as a property to the installer.

Comment by Rene Krell [ 09/Apr/14 ]

I would not say necessarily no, the question is how many users would really have an advantage of it, and not to blow up the installer with specialized features.

Just a hint of how this could be achieved already now:
Can't you use submodules for it, each IzPack build in a separate multi-module? You can expose the build descriptors as resource artifact from the parent module and set a Maven property per submodule, which is automatically exposed to the installer descriptor and can be accessed in the manner described above. Maybe this would it make a bit more transparent, for the case you have a limited number of possible classifiers, of course





[IZPACK-1076] System properties are no longer in -rc2 Created: 03/Apr/14  Updated: 04/Apr/14

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

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

Number of attachments : 0

 Description   

We used to use conditions like these:

    <condition type="exists" id="real">
      <variable>SYSTEM_real</variable>
    </condition>

Those worked fine with -rc1 but no longer with -rc2.

A bit of debugging showed that system properties are no longer exposed to the installer. Is this a bug or a feature?



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

Pardon, this has been introduced with IZPACK-1066, seems to need a post-fix.

Yes, there are not all system properties exposed by the installer by default, but the should be read just on demand, instead. Will have a look at it, why the system variable resolution in the condition is broken.

Comment by Rene Krell [ 04/Apr/14 ]

In the meantime, you might try the following workaround:

<dynamicvariables>
  <variable name="realFlag" value="${SYSTEM[real]}" checkonce="true"/>
</dynamicvariables>
...
<conditions>
  <condition type="variable" id="real">
    <name>realFlag</name>
    <value>true</value>
  </condition>
</conditions>
Comment by Rene Krell [ 04/Apr/14 ]

The system vars aren't even resolved in this expression:

<variables>
  <variable name="realFlag" value="${SYSTEM[real]}"/>
</variables>

but work with dynamic variables:

<dynamicvariables>
  <variable name="realFlag" value="${SYSTEM[real]}" checkonce="true"/>
</dynamicvariables>
Comment by Rene Krell [ 04/Apr/14 ]

Just for the development record after analyzing:
There is some work to do at the following places:

  • com.izforge.izpack.core.substitutor.VariableSubstitutorImpl.getValue(String)
  • com.izforge.izpack.core.data.DefaultVariables.get(...) methods
  • Move parsing of ENV and SYSTEM prefixes from com.izforge.izpack.core.substitutor.VariableSubstitutorBase.substitute(Reader, Writer, SubstitutionType) to the above class. This should be catched already when reading the variable value rather then just during substitutions.

This will make it consistent.

There should be used the Variable and Value interfaces instead of the plain Properties class for IzPack variables in future.





[IZPACK-1075] AntInstallerActionListener - reading jars for taskdefs fails in rare cases - update Ant dependency to 1.9.4 on its release Created: 27/Mar/14  Updated: 27/Mar/14

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

Type: Task 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

Number of attachments : 0

 Description   

Due to a bug in Apache Ant including 1.9.3 -https://issues.apache.org/bugzilla/show_bug.cgi?id=54473 - in some cases fails the loading of further libraries from the file system.

The suggested patch got merged in, but for target milestone 1.9.4.
As soon as Ant 1.9.4 is released, compile with it and recommend it as dependency when using AntActionInstallerListener.






[IZPACK-1074] Several bugs related to choices Created: 27/Mar/14  Updated: 27/May/14  Resolved: 27/May/14

Status: Resolved
Project: IzPack
Component/s: Installer
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: choice, choices, revalidation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Patch Submitted:
Yes
Number of attachments : 0

 Description   

1. Null values of a comboBox or radioButton can be set in the installer.
If the associated variable for the comboBox or radioButton has not been defined, or if the choice fields do not contain the "set" attribute. This is a problem as it can produce unexpected NPE during the installation process.

To reproduce just add a comboBox or radioButton without defining a "set" attribute and without setting its variable in the <variables> tags of the install.xml

Solution: In the ComboFieldReader and RadioFieldReader set the "selected" variable to 0 rather than -1

2. During console installation the radioButton field does not remember what the user has selected. If radioButton has default value of A you have choices A,B,C and choose B, then at the end of the panel hit rediplay, you will see that the radioButton is still marked as A instead of B. Problem lies in the RadioFieldReader.java file, where it does not compute the correctly selected radio button.

To reproduce follow the workflow as described above.

Solution: Compute the selected radio like how the selected comboBox is computed in the ComboFieldReader

3. Notice high similarity between ComboField and RadioField, code duplication can lead to inconsistent changes towards choice fields.

Solution: Create a SimpleChoiceReader (Similar to the idea of the SimpleFileReader) to abstract common features between the ComboFieldReader and RadioFieldReader. Later completely generalize and remove the ComboFieldReader and RadioFieldReader so that choices use the SimpleChoiceReader.

4. Notice that the RadioChoice IS a Choice but with the additional feature of revalidation. Swapping between choices and with the notion of revalidation it should be intuitive that you may also want to revalidate a panel based on the selection of a comboBox.

Solution: Remove the radioChoice and just add the revalidation features to the Choice. Now we can think of comboBoxes and radioButtons consisting of "choices" rather than two seperate types of choices.

5. Currently I believe its intuitive to developers and users that their applications are reactive and should respond immediately. So I would suggest that the revalidation feature not be an option but rather just part of the installer and on by default. Having the revalidation on does not hurt users that do not require it, and helps other produce less bug prone installers. (This can always be reverted if you don't agree)

Solution: Add the actionListeners to the components by default

6. If the a checkboxes variable isn't set, set it to the initialValue. This will ensure that if some condition depends on a checkbox, and a checkbox is "set" to true, that any component that depends on this condition will be shown when on the same panel. Previously a component wasn't shown if the above situation was true.

To reproduce "set" checkbox to true.
Have a component on the same panel of the checkbox with a conditionID which is based on the checkbox being true.
Notice the component is not shown.

Solution: Set the variable when checkbox is decided to set itself as selected or not.



 Comments   
Comment by Miles Tjandrawidjaja [ 27/Mar/14 ]

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

Comment by Rene Krell [ 27/May/14 ]

Pull request merged, good work!





[IZPACK-1073] Generate options file Created: 26/Mar/14  Updated: 26/Mar/14

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

Type: Improvement Priority: Major
Reporter: Michael Schnupp 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   

IzPack has a "-options-template" option generating an options file with all the keys, but without any values.

The FinishPanel generates an xml file with both keys and values, after asking all questions.

Would it be possible to add support for generating an options file with both keys and values, after asking all questions?
(This would be quite handy for the current project.)

Is there a good reason why the FinishPanel generates the whole xml stuff instead of a simple options file?






[IZPACK-1072] Unset dynamic variables if they cannot be validated any longer for some reason Created: 25/Mar/14  Updated: 26/Mar/14  Resolved: 26/Mar/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-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If a dynamic variable has been successfully evaluated and received a value, but for some reason cannot be reevaluated, for example this one:

Mar 25, 2014 3:46:07 PM com.izforge.izpack.core.data.DynamicVariableImpl evaluate
FINE: Error evaluating dynamic variable 'previous.version.4': java.lang.Exception: Error opening jar file /home/rkrell/myapp/lib/server.jar

the variable should be rather unset than left on this value. This should just happen if failOnError="false" in case of evaluation failures of the "natural" kind in the above example.

A second usecase for this is the multiple definition of a dynamic variable with one and the same name, but bound to different conditions each time, for example:

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

For this case, the dynamic variable thechoice should be unset if neither of both conditions, cond1 and cond2, is true, even if there is already a previous value, because a condition became true at an earlier time.

With this approach, there is an increasing sense using checkonce="true" in case you want to fix a value set once for the rest of the installation time. This has been the original meaning of the checkonce attribute.

Furthermore, all IOExceptions occuring during dynamic variable evaluation should be logged on DEBUG level (FINE), not as WARN nor INFO, like this one during gathering a dynamic variable value from the output of a command execution:

Mar 25, 2014 3:56:46 PM WARNING: java.io.IOException: Cannot run program "/home/rkrell/jre/sun/1.6.0_21/bin/java": java.io.IOException: error=2, No such file or directory


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

Sent pull request with the code changes: https://github.com/izpack/izpack/pull/185

Comment by Rene Krell [ 26/Mar/14 ]

Pull request merged and documentation added (Lifecycle of Dynamic Variables section).

Comment by Rene Krell [ 26/Mar/14 ]

Merged another pull request with post-fixes after extensive tests with real-world installers:
https://github.com/izpack/izpack/pull/186





[IZPACK-1071] Header Image Does not Appear on TreePacksPanel Created: 24/Mar/14  Updated: 27/May/14  Resolved: 27/May/14

Status: Resolved
Project: IzPack
Component/s: Installer
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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Number of attachments : 0

 Description   

1. Use a header Image
GuiPrefs

     <modifier key="useHeadingPanel" value="yes"/>
      <modifier key="headingImageOnLeft" value="yes"/>
      <modifier key="headingImageBorderSize" value="0"/>

Include image as resource

<res id="Heading.image" src="images/heading.png"/>

2. Use the TreePacksPanel

Reason:
TreePacksPanel is missing the TreePacksPanel.headline string from the installer langpacks.

        String headline = view.getI18nStringForClass("headline");
        if (headline == null)
        {
            headingPanel.setVisible(false);
            return;
        }


 Comments   
Comment by Rene Krell [ 27/May/14 ]

Pull request merged manually after resolving one conflict.





[IZPACK-1070] Automated installer does not create folder from UserInpuPanel Created: 24/Mar/14  Updated: 24/Mar/14

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

Type: Bug Priority: Major
Reporter: Wilfrid Fresne Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: automated
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

build with Maven 3.1.1 on CentOs 6.3


Number of attachments : 0

 Description   

The user input panel contains :
<field type="dir" align="left" variable="INSTALL_PUBLIC_DATA_PATH" mustExist="false" create="true">
<spec txt="Public data path" set="$

{INSTALL_PATH}

/public_data" size="40" mustExist="false" create="true" />
</field>

When the installer is run with GUI, the GUI shows a popup to confirm the creation of the directory. Then the directory is created by the installer.

When the installer is run with a replay scenario (automatic install), the directory is not created.



 Comments   
Comment by Wilfrid Fresne [ 24/Mar/14 - Visible by: LoggedIn ]

In the Jira list of component, maybe a "automated installer" component should be usefull





[IZPACK-1069] Allow revalidation of current panel Created: 21/Mar/14  Updated: 09/Jun/14  Resolved: 25/Mar/14

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

Type: Improvement Priority: Minor
Reporter: Miles Tjandrawidjaja Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Issue Links:
Related
relates to IZPACK-1110 UserInputPanel - "revalidate" attribu... Closed
Number of attachments : 0

 Description   

Currently fields on a userInputPanel that have a conditionId that is dependent on another field on the same userInputPanel, are not displayed even when the dependent field satisfies the condition. For example you may have a checkbox on a panel that when checked shows additional fields, and when unchecked hides those additional fields.

Below is an example snippet of what can go into your userInputSpec.
It should demonstrate how checkboxes can be used to show/hide elements.
The following should also work with radioButtons in replacement of checkboxes.

The topBuffer is pretty high value. This is just to demonstrate the the JScrollPanel still works correctly. Naturally we need to add a rigid option so that the components stay in place when using dynamic components, rather than moving around everywhere.

Note that we should not validate when revalidating the panel. We only need the validate the information when pressing the Next button. This feature will also help when deciding the add persistency between panels. For example if you fill in a text field and then press the previous followed by pressing the next button, what the user has type should be retained.

Note: You may see something funny with the multiFile, where it covers the fields below it. This is a bug in Izpack.

 <userInput>
    <!-- Dyanmic Panel -->
    <panel id="dynamic.panel" topBuffer="200" rigid="true">
        <field type="title" bold="true" size="2" id="dynamic.panel.title"/>

        <!-- TODO: Why is true value and false value required? Why not have a default a true/false? -->
        <field type="check" variable="dynamic.checkbox.text">
            <spec txt="Show text field" id="dynamic.checkbox.text" true="true" false="false" revalidate="yes"/>
        </field>
        <field type="text" variable="dynamic.text" conditionid="dynamic.checkbox.text">
            <description align="left" txt="Dynamic text field" id="dynamic.text.info"/>
            <spec txt="Enter some text:" id="dynamic.text" size="15"/>
        </field>

        <field type="check" variable="dynamic.checkbox.combo">
            <spec txt="Show combobox" id="dynamic.checkbox.combo" true="true" false="false" revalidate="yes"/>
        </field>
        <field type="combo" variable="dynamic.combo" conditionid="dynamic.checkbox.combo">
            <description align="left" txt="Dynamic combobox" id="dynamic.combo.info"/>
            <spec>
                <choice txt="Choice 1" id="dynamic.combo.1" value="1"/>
                <choice txt="Choice 2" id="dynamic.combo.2" value="2"/>
            </spec>
        </field>

        <field type="check" variable="dynamic.checkbox.radio">
            <spec txt="Show radio button" id="dynamic.checkbox.radio" true="true" false="false" revalidate="yes"/>
        </field>
        <field type="radio" variable="dynamic.radio" conditionid="dynamic.checkbox.radio">
            <description align="left" txt="Dynamic Radio" id="dynamic.combo.info"/>
            <spec>
                <choice txt="Radio 1" id="dynamic.radio.1" value="1" />
                <choice txt="Radio 2" id="dynamic.radio.2" value="2" />
            </spec>
        </field>

        <field type="check" variable="dynamic.checkbox.password">
            <spec txt="Show password field" id="dynamic.checkbox.password" true="true" false="false" revalidate="yes"/>
        </field>
        <field type="password" align="left" variable="dynamic.password" conditionid="dynamic.checkbox.password">
            <spec>
                <pwd txt="Dynamic Password:" id="dynamic.password" size="15" />
                <pwd txt="Retype Dynamic Password:" id="dynamic.password.confirm" size="15" />
            </spec>
        </field>

        <field type="check" variable="dynamic.checkbox.file">
            <spec txt="Show field field" id="dynamic.checkbox.file" true="true" false="false" revalidate="yes"/>
        </field>
        <field type="file" align="left" txt="Dynamic File" id="dynamic.file" variable="dynamic.file" conditionid="dynamic.checkbox.file">
            <spec txt="" size="25" allowEmptyValue="true" set=""/>
        </field>

        <field type="check" variable="dynamic.checkbox.multifile">
            <spec txt="Show multifile field" id="dynamic.checkbox.multifile" true="true" false="false" revalidate="yes"/>
        </field>
        <field type="multifile" align="left" txt="Dynamic MultiFile" id="dynamic.multifile" variable="dynamic.multifile" conditionid="dynamic.checkbox.multifile">
            <spec txt="" size="25" allowEmptyValue="true" set=""/>
        </field>

        <field type="check" variable="dynamic.checkbox.dir">
            <spec txt="Show directory choice" id="dynamic.checkbox.dir" true="true" false="false" revalidate="yes"/>
        </field>
        <field type="dir" align="left" txt="Dynamic DirectoryChooser" id="dynamic.dir" variable="dynamic.dir" conditionid="dynamic.checkbox.dir">
            <spec txt="" size="25" mustExist="false" set=""/>
        </field>

        <field type="check" variable="dynamic.checkbox.rule">
            <spec txt="Show Rule Field" id="dynamic.checkbox.rule" true="true" false="false" revalidate="yes"/>
        </field>
        <field type="rule" variable="dynamic.rule" conditionid="dynamic.checkbox.rule">
          <description align="left" txt="Dynamic Rule" id="dynamic.rule"/>
          <spec id="url.address.label" txt="Connection:" layout="O:15:U : N:5:5" resultFormat="displayFormat"/>
        </field>

        <field type="check" variable="dynamic.checkbox.search">
            <spec txt="Show Search Field" id="dynamic.checkbox.search" true="true" false="false" revalidate="yes"/>
        </field>
        <field type="search" variable="java_sdk_home" conditionid="dynamic.checkbox.search">
            <description align="left" txt="This is a description for a search input field." id="description.java_sdk_home"/>
            <spec txt="Path to Java SDK:" type="file" result="directory">
                <choice value="/usr/lib/java/" os="unix" />
            </spec>
        </field>
    </panel>
</userInput>

Remember to add conditions!

    <condition type="variable" id="dynamic.checkbox.text">
        <name>dynamic.checkbox.text</name>
        <value>true</value>
    </condition>
    <condition type="variable" id="dynamic.checkbox.combo">
        <name>dynamic.checkbox.combo</name>
        <value>true</value>
    </condition>
    <condition type="variable" id="dynamic.checkbox.radio">
        <name>dynamic.checkbox.radio</name>
        <value>true</value>
    </condition>
    <condition type="variable" id="dynamic.checkbox.password">
        <name>dynamic.checkbox.password</name>
        <value>true</value>
    </condition>
    <condition type="variable" id="dynamic.checkbox.file">
        <name>dynamic.checkbox.file</name>
        <value>true</value>
    </condition>
    <condition type="variable" id="dynamic.checkbox.multifile">
        <name>dynamic.checkbox.multifile</name>
        <value>true</value>
    </condition>
    <condition type="variable" id="dynamic.checkbox.dir">
        <name>dynamic.checkbox.dir</name>
        <value>true</value>
    </condition>
    <condition type="variable" id="dynamic.checkbox.rule">
        <name>dynamic.checkbox.rule</name>
        <value>true</value>
    </condition>
    <condition type="variable" id="dynamic.checkbox.search">
        <name>dynamic.checkbox.search</name>
        <value>true</value>
    </condition>

Example panels

    <panel classname="LicencePanel" />
    <panel classname="TargetPanel" />
    <panel classname="PacksPanel" />
    <panel classname="UserInputPanel" id="dynamic.panel" />
    <panel classname="SummaryPanel" />
    <panel classname="InstallPanel" />
    <panel classname="FinishPanel" />

Let me know if more information is needed or if something is unclear.



 Comments   
Comment by Miles Tjandrawidjaja [ 21/Mar/14 ]

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

Comment by Tim Anderson [ 25/Mar/14 ]

Pull request merged thanks.





[IZPACK-1068] NPE when trying to input empty multifile component when allowEmptyValue is set to true Created: 20/Mar/14  Updated: 21/Mar/14  Resolved: 21/Mar/14

Status: Resolved
Project: IzPack
Component/s: Installer
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-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Number of attachments : 0

 Description   

1. Create a UserInputPanel that has a MultiFile component.

<field type="multifile"
  align="left" txt="Some MultiFile"
  id="some.multifile"
  variable="some.multifile">
      <spec txt="" size="25" allowEmptyValue="true" set=""/>
</field>

2. Press next, and installer crashes.

at com.izforge.izpack.panels.userinput.field.file.MultipleFileField.setValues(MultipleFileField.java:113)
at com.izforge.izpack.panels.userinput.gui.file.GUIMultipleFileField.updateField(GUIMultipleFileField.java:85)



 Comments   
Comment by Miles Tjandrawidjaja [ 20/Mar/14 ]

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

Comment by Rene Krell [ 21/Mar/14 ]

Pull request merged.
Thank you for contributing.





[IZPACK-1067] ConfigurationInstallerListener - action for dedicated xpath expression does not work Created: 20/Mar/14  Updated: 21/Mar/14  Resolved: 21/Mar/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-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If I have two XML files:

maps.xml.configbak:

<?xml version="1.0" encoding="UTF-8"?>
<maps
  enabled="false"
  handler="client"
>
  <proxy
    enabled="false"
    address="proxy"
    port="3128"
  />

  <geo-position-providers
    use="MapQuest"
  >
    <geo-position-provider
      id="MapQuest"
      geo-class="com.mysoft.util.maps.geo.GeoPositionProviderMapQuest"
    >
      <param name="key" value="123456789ABCDEFG%$§$)(=)"/>
    </geo-position-provider>
  </geo-position-providers>

  <tile-providers
    use="Open Street Maps"
  >
    <tile-provider
      id="Open Street Maps"
      tile-class="com.mysoft.client.ui.maps.tile.OSMTileFactoryInfo"
    />
  </tile-providers>

  <address-source
    street="information.properties/STREET"
    city="information.properties/CITY"
    zip="information.properties/ZIP"
    state="information.properties/COUNTRY"
  />

maps.xml:

<?xml version="1.0" encoding="UTF-8"?>
<maps enabled="false" handler="client">
  <address-source street="information.properties/STREET" city="information.properties/CITY" zip="information.properties/ZIP" state="information.properties/COUNTRY" federal_state="information.properties/FEDERAL_STATE" />
  <caches>
    <compressed-image-cache size="10000" />
    <image-cache size="20000" />
  </caches>
  <geo-position-providers use="MapQuest">
    <geo-position-provider id="MapQuest" geo-class="com.mysoft.util.maps.geo.GeoPositionProviderMapQuest">
      <param name="key" value="123456789ABCDEFG%$§$)(=)" />
    </geo-position-provider>
  </geo-position-providers>
  <!-- Enter Cache Sizes in kB -->
  <proxy enabled="false" address="proxy" port="3128" />
  <tile-providers use="Open Street Maps">
    <tile-provider id="Open Street Maps" tile-class="com.mysoft.client.ui.maps.tile.OSMTileFactoryInfo" />
  </tile-providers>
</maps>

and I want to patch the latter one with the first one in this action:

<configurable type="xml" cleanup="false"
  patchfile="${INSTALL_PATH}/config/maps.xml.configbak"
  tofile="${INSTALL_PATH}/config/maps.xml">
    <xpathproperty key="action.default" value="COMPLETE"/>
    <xpathproperty key="xpath.path1" value="/maps/address-source"/>
    <xpathproperty key="matcher.path1" value="TAG"/>
    <xpathproperty key="action.path1" value="REPLACE"/>
</configurable>

the result is:

<?xml version="1.0" encoding="UTF-8"?>
<maps enabled="false" handler="client">
  <address-source street="information.properties/STREET" city="information.properties/CITY" zip="information.properties/ZIP" state="information.properties/COUNTRY" />
  <address-source street="information.properties/STREET" city="information.properties/CITY" zip="information.properties/ZIP" state="information.properties/COUNTRY" federal_state="information.properties/FEDERAL_STATE" />
  <caches>
    <compressed-image-cache size="10000" />
    <image-cache size="20000" />
  </caches>
  <geo-position-providers use="MapQuest">
    <geo-position-provider id="MapQuest" geo-class="com.mysoft.util.maps.geo.GeoPositionProviderMapQuest">
      <param name="key" value="Fmjtd%7Cluub2g6r2l%2C25%3Do5-9ualha" />
    </geo-position-provider>
  </geo-position-providers>
  <proxy enabled="false" address="proxy" port="3128" />
  <!-- Enter Cache Sizes in kB -->
  <tile-providers use="Open Street Maps">
    <tile-provider id="Open Street Maps" tile-class="com.mysoft.client.ui.maps.tile.OSMTileFactoryInfo" />
  </tile-providers>
</maps>

but should be:

<?xml version="1.0" encoding="UTF-8"?>
<maps enabled="false" handler="client">
  <address-source street="information.properties/STREET" city="information.properties/CITY" zip="information.properties/ZIP" state="information.properties/COUNTRY" federal_state="information.properties/FEDERAL_STATE" />
  <caches>
    <compressed-image-cache size="10000" />
    <image-cache size="20000" />
  </caches>
  <geo-position-providers use="MapQuest">
    <geo-position-provider id="MapQuest" geo-class="com.mysoft.util.maps.geo.GeoPositionProviderMapQuest">
      <param name="key" value="Fmjtd%7Cluub2g6r2l%2C25%3Do5-9ualha" />
    </geo-position-provider>
  </geo-position-providers>
  <proxy enabled="false" address="proxy" port="3128" />
  <!-- Enter Cache Sizes in kB -->
  <tile-providers use="Open Street Maps">
    <tile-provider id="Open Street Maps" tile-class="com.mysoft.client.ui.maps.tile.OSMTileFactoryInfo" />
  </tile-providers>
</maps>

Apparently, the REPLACE action does not take place for TAG-matching merge of the XPath expression "/maps/address-source".



 Comments   
Comment by Rene Krell [ 21/Mar/14 ]

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

Comment by Rene Krell [ 21/Mar/14 ]

Pull request merged.





[IZPACK-1066] Improve usability of resolving system properties as IzPack variables Created: 20/Mar/14  Updated: 20/Mar/14  Resolved: 20/Mar/14

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

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

Number of attachments : 0

 Description   

Currently it is possible to resolve variables with the syntax ${SYSTEM_variablename} from system variables, in that case would be variablename resolved from the Java system properties as IzPack variable SYSTEM_variablename.

The implementation is very limited. For example the following code doesn't currently work at all:

<variables>
  <variable name="featureEnabled" value="${SYSTEM_featureEnabled}" />
</variables>

<conditions>
  <condition type="variable" id="isFeatureEnabled">
    <name>featureEnabled</name>
    <value>true</value>
  </condition>
</conditions>

but must be written as:

<conditions>
  <condition type="variable" id="isFeatureEnabled">
    <name>SYSTEM_featureEnabled</name>
    <value>true</value>
  </condition>
</conditions>

Furthermore, variables starting on the prefix SYSTEM_ are not really dynamically resolved, but all system variables are expanded at IzPack variables by default. This takes just time and resources during installing. System properties should be resolved on demand like all other variable types.



 Comments   
Comment by Rene Krell [ 20/Mar/14 ]

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

Added syntax ${SYSTEM[variable.Name]} for parsing system properties.
Marking old syntax ${SYSTEM_variable_Name} as obsolete, to be removed in one of the next major versions. Leaving it now in 5.0.x for backward compatibility.

Comment by Rene Krell [ 20/Mar/14 ]

Pull request merged.
The documentation (http://docs.codehaus.org/display/IZPACK/Variables) has been updated accordingly.





[IZPACK-1065] Inconsistent artifact extension for deploy Created: 18/Mar/14  Updated: 20/Mar/14  Resolved: 20/Mar/14

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

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

Number of attachments : 0

 Description   

Should the generated artifact file have a .jar or .izpack-jar extension?
Currently the file is locally explicitly generated as .jar:

file = new File(outputDirectory, finalName + localClassifier + ".jar");

But deploying an artifact with packaging type "izpack" will result in a file with an izpack extension on my nexus.

Is it possible to always deploy the file as "jar" even when build with packaging "izpack-jar"?



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

I didn't get the message:

  • "izpack-jar" is the Maven packaging type, not a file name extension.
  • There is also a packaging type "jar", but anyway, this doesn't refer to file name or output conventions in common.
  • Your are not restricted to use "izpack-jar". It is just for convenience, to not being forced to call an explicit execution in the package phase. Another option is using the packaging type "pom" and adding an <execution> block to the Izpack Maven plugin.

The packaging type is more a less a plan of which Maven plugins are executed by default during the build in each phase (Maven Lifecycle Mapping). For these plugins you don't need an explicit execution. The packaging type izpack-jar is a special lifecycle mapping that can be used with the Izpack Maven plugin.

Comment by Rene Krell [ 18/Mar/14 ]

Please sent the relevant contents of your POM.
The Izpack Maven plugin does just generate jars, nothing else. The bad naming must be a local problem in your POM.

Comment by Michael Schnupp [ 18/Mar/14 ]

To reproduce:

  • create any project with packaging type "izpack-jar" and enableOverrideArtifact = true
  • call "mvn deploy" (this should create a local .jar file and upload that file to your nexus)
  • use "mvn dependency:copy" to download the file from nexus (Now you need to specify type=izpack-jar and the file should have a .izpack-jar extension.)

My pom looks like this:

  <packaging>izpack-jar</packaging>

  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.izpack</groupId>
        <artifactId>izpack-maven-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
          <baseDir>${project.build.directory}</baseDir>
          <enableOverrideArtifact>true</enableOverrideArtifact>
        </configuration>
      </plugin>

After deploy mvn dependency:copy -Dartifact=group:artifact:version:jar fails but mvn dependency:copy -Dartifact=group:artifact:version:izpack-jar succeeds and generates a .izpack-jar file

Comment by Michael Schnupp [ 19/Mar/14 ]

My current workaround is substituting <enableOverrideArtifact>true</enableOverrideArtifact> by <classifier>izpack</classifier>.
This reliably creates an "-izpack.jar" file, but requires me to explicitly specify the classifier when referring to that artifact.

Comment by Rene Krell [ 19/Mar/14 ]

Ok, you are right, the default extension should be configured to jar. Will have a look at it.

Comment by Rene Krell [ 19/Mar/14 ]

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

If you have the local source from izpack/izpack cloned, you can give it a try, also.
I've verified the fix by comparing the results of an 'mvn install' in my local $M2_HOME, the default extension has been .izpack-jar and is .jar now.

Comment by Rene Krell [ 20/Mar/14 ]

Pull request merged. Thanks for reporting

Comment by Rene Krell [ 20/Mar/14 ]

I deployed the new 5.0.0-rc2-SNAPSHOT to the repositories, please give it a try.





[IZPACK-1064] UserInput directory fields are automatically populated by the application's working directory Created: 18/Mar/14  Updated: 27/May/14  Resolved: 27/May/14

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

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

Windows


Attachments: GZip Archive IZPACK-1064.tar.gz     Zip Archive Radhika_Installer.zip    
Number of attachments : 2

 Description   

I am using Izpack 5 for my project.

I use a set of text and directory fields in my user input panel. My requirement is to get the user given text fields and directories and use them.
I notice a bug: If the directory field is not populated prior, then when I enter some value in the text field, the directory fields are getting automatically populated with the installer’s current working directory. As a workaround I tried to separate the text fields and directory fields into two separate user panels. The issue gets resolved for other directory fields except one which uses a Validator.
The user given directory is validated if it contains a specific file.

Problem is if I run the installer say from C:/IzPack/MyInstaller folder, then the directory fields gets populated with this value.

install.xml

<izpack:installation version="5.0"
  xmlns:izpack="https://izpack.github.io/schema/installation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="https://izpack.github.io/schema/installation https://izpack.github.io/schema/5.0/izpack-installation-5.0.xsd">
  <info>
        <appname>My Tool</appname>
        <appversion>1.0</appversion>
    </info>
  <conditions>
    <condition type="or" id="installon-windows-linux-mac">
</condition>
      </conditions>
<resources>
    <res id="userInputSpec.xml" src="userInputSpec.xml" />
  </resources>
    <jar src="IzPackNEW/bin/customfilecheck.jar" stage="both"/>
<panels>
    <panel classname="LicencePanel" />
    <panel classname="TargetPanel"/>
    <panel classname="UserInputPanel"  id="userinputpanel.order0" />
    <panel classname="UserInputPanel"  id="userinputpanel.order1" />
    <panel classname="InstallPanel" />
    <panel classname="FinishPanel" />
  </panels>
</izpack:installation>

userInputSpec.xml

<izpack:userInput version="5.0"
  xmlns:izpack="https://izpack.github.io/schema/userinput" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="https://izpack.github.io/schema/userinput https://izpack.github.io/schema/5.0/izpack-userinput-5.0.xsd">
<panel order="0" id="userinputpanel.order0" >
    <field type="staticText" align="left"  txt="My Software Default Configuration:"
      id="staticText.text" />
    <field  type="text" txt="Default Cluster" id="clust"  variable="def.clus">
      <spec txt="Default Cluster"  id="DBLogin" size="25" />
    </field>
    <field type="space" />
    <field type="text" txt="Default Host" variable="def.host">
      <spec txt="Default Host" size="25" />
    </field>
    <field type="space" />
    <field type="text" txt="Default Port" variable="def.port">
      <spec txt="Default Port" size="25" />
    </field>
    <field type="space" />
    <field type="text" txt="Default Location of mysoftware*" variable="def.loca.mysoftware" conditionid="installon-windows-linux-mac">
      <spec txt="Default Location of mysoftware*"  set="${APPLICATIONS_DEFAULT_ROOT}mysoftware" allowEmptyValue="true" size="25" />
      <validator class="com.izforge.izpack.panels.userinput.validator.MLValidator" txt="mysoftware is not installed!!! Download it from http://mysoftware.com" id="mysoftware" />
    </field>
    <field type="space" />
    <field type="text" align="left" txt="Default user"
      variable="def.user">
      <spec txt="Default user" size="25" />
    </field>
  </panel>
<panel order="1" id="userinputpanel.order1" >

    <field  type="dir" txt="Default Location of mysoftware*"  variable="def.loca.mysoftware"  conditionid="!installon-windows-linux-mac">
      <spec txt="Default Location of mysoftware*"   allowEmptyValue="true"   id="mysoftware" size="25" />
      <validator class="com.izforge.izpack.panels.userinput.validator.MLValidator" txt="mysoftware is not installed!!! Download it from http://mysoftware.com/" id="mysoftware" />
    </field>
    <field type="space" />
    <field type="dir"  txt="Default related s/w Location"  variable="def.rel.loc">
      <spec txt="Default related s/w Location"   mustExist="false"  size="25" />
    </field>
    <field type="space" />
    <field type="dir" txt="Default related s/w Location 2"   variable="def.rel.loc.2">
      <spec txt="Default related s/w Location 2"   allowEmptyValue="true"  size="25" />
    </field>
    <field type="space" />
    <field type="dir"  align="left" variable="def.loc" >
      <spec txt="Default Location"   allowEmptyValue="true"  size="25" />
    </field>
  </panel>
</izpack:userInput>

Please help on this.

Thanks,
Radhika.



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

Which version of IzPack you are using in particular, 5.0.0-rc1, or the latest snapshot of 5.0.0-rc2-SNAPSHOT ? If not the snapshot, please retry the latest one, first.

Comment by Rene Krell [ 18/Mar/14 ]

I can't see any real bug here, expanding relational directories from the working directory is actually the best choice, commonly spoken, not just for your special usecase.

if you want different base directories, you can remove the set attribute and initialize the variables dynamically based on the root path, for example:

install.xml

...
<conditions xmlns:xi="http://www.w3.org/2001/XInclude">
  <!-- Update test -->
  <condition type="exists" id="haveInstallPath">
      <!-- This can be used as soon as the TargetPanel is validated, not before that -->
      <variable>INSTALL_PATH</variable>
  </condition>
</conditions>

<dynamicvariables>
  <variable name="install.parentpath.canonical" value="${INSTALL_PATH}/.." condition="haveInstallPath">
      <filters>
        <location basedir="${INSTALL_PATH}"/>
        <regex regexp="[\\/]+$" replace=""/><!--Remove trailing path separators to allow path comparison as strings-->
      </filters>
  </variable>
  <variable name="othercomponents.home" value="othercomponents_dirname">
      <filters>
        <location basedir="${INSTALL_PATH}/.."/>
      </filters>
  </variable>
  <variable name="othercomponents.someapp.home" value="someapp_dirname">
      <filters>
        <location basedir="${othercomponents.home}"/>
      </filters>
  </variable>
</dynamicvariables>
...

and than use them in the UserInputPanel spec directly:

userInputSpec.xml:

  ...
  <panel id="othercomponents.integration.paths.panel">
    <field type="title" txt="Other Components - Paths" id="othercomponents.integration.paths.panel.title"/>
    <field type="dir" align="left" variable="othercomponents.someapp.home">
      <spec txt="Application Home Path:" id="othercomponents.someapp.home.label" size="25" mustExist="true" create="false"/>
    </field>
  </panel>

Would that be an option for you?

Comment by Vedavalli Radhika [ 25/Mar/14 ]

Rene, Thanks a lot for your response.

The above option is not helping on my requirement.

I have multiple directory fields. They do not have a common basedirectory. Each one will be a unique path on the drive to be choosen by the user (which he only knows).
I do not want the user's current working directory to be auto-populated. This would mislead him.

Is it possible to set the directory field's value to be empty unless the user populates it?

I tried to use your code to set the basedir to be empty rather than the INSTALL_PATH, but this does not seem to work. If I set the basedir to be empty, then it stays empty(I actually get these user values and populate them onto a properties file. The value does not show up in the properties file.) always irrespective of whether user chooses a path or not.

Please help.

Comment by Rene Krell [ 25/Mar/14 ]

Would you mind to provide a fully compilable Maven project including POM and compilable IzPack descriptors, please?
I made one of your file contents you initially sent, but I can't still recognize the problem.
I'll send you an attachment, how I made it runnable here.

Comment by Rene Krell [ 25/Mar/14 ]

I attached a minimum project IZPACK-1064.tar.gz which is fully compilable based on your example content, no other improvements I would make otherwise (except of removing the "order" attribute from the panel definitions, which are no longer used). I compile it by 'mvn package'.

After that I launch the installer in normal mode:

java -jar target/example-IZPACK-1064-1-SNAPSHOT-installer.jar

or in TRACE mode to see conditions and variables (you must maybe choose a higher resolution to make the directory chooser buttons accessable by the mouse):

java -DTRACE=true -jar target/example-IZPACK-1064-1-SNAPSHOT-installer.jar

from a directory: /home/rkrell/test/IZPACK-1064

  • Licensing Agreements: I accept...
  • Target path offered: /home/rkrell/My Tool (OK)
  • 1st User Data panel:
    There is one input field:
    Default location of mysoftware: /home/rkrell/mysoftware
  • 2nd User Data panel:
    All input fields are empty.

Please make your version of the project, attach it and tell us,

  • from which directory and how you launch the installer
  • what you would expect as initial value in which input field and how it differs.
  • what do you enter (change) in which input field
  • what you expect in the appropriate variables set in the panel and how it differs (you can see the current values in TRACE mode directly in the installer)

Please use real-world values, no abstraction, this makes it easier to discuss and avoids misunderstandings.

Please notice that there is the latest 5.0.0-rc2-SNAPSHOT used for testing.

Comment by Vedavalli Radhika [ 01/Apr/14 ]

Rene, I have packaged a sample installer (built using Ant). The attachment contains the installer(jar file) and the related files used to build the installer(build.xml, installnew.xml, UserInputSpec.xml and hp.properties file).
This has a,
1. License Agreement panel
2. Target path selection panel
3. User Data panel - This has one text field and two directory fields.
4. Install Progress Panel
5. Behind scene, a properties file will be populated with the values provided in the user data panel
6. Finish Panel

My issue is the directory fields are automatically populated with the user's current working directory.

There are multiple scenarios to reproduce the issue,
1. If the text field(Default Cluster) is populated with some value and tabbed out to choose something from the directory field,the dir field automatically populates with the current working directory. If the user desires to provide value only for the text field, the directory fields will be automatically populated which is not as per the user expectation. The hp.properties file is also populated with the current working directory.
hpcc.cluster=abcd
m.lib=C:\\Users\\123
Desktop (Current working directory)
s.exe=C:\\Users\\123
Desktop (Current working directory)
2. If the text field is left empty and if the user provides value for the first directory field(Default Library Location) alone and leaves the other directory field(Default Executable Location) empty, then the hp.properties file populates the Default Executable Location automatically with the Current working directory which is not desirable.
hpcc.cluster=
m.lib=D:
Program Files\\tool
lib (User Selected Value)
s.exe=C:\\Users\\123
Desktop (Current working directory)
3. Even if all the fields are left empty and clicked Next, the directory fields are automatically populated with the current working directory.
hpcc.cluster=
m.lib=C:\\Users\\123
Desktop (Current working directory)
s.exe=C:\\Users\\123
Desktop (Current working directory)

Comment by Vedavalli Radhika [ 08/Apr/14 ]

Hi Rene, Is there any other details required from my end?
I am awaiting your response.

Thanks,
Radhika.

Comment by Rene Krell [ 08/Apr/14 ]

Hi, I saw it, thanks.
Currently I have not enought time for it, will return to it as soon as I can.

Comment by Vedavalli Radhika [ 15/Apr/14 ]

Rene,
Meanwhile, I was trying to run using the latest 5.0.0-rc2-SNAPSHOT version.
However, I am stuck in running the ant task as reported - http://jira.codehaus.org/browse/IZPACK-1083

Your response is crucial for us to deliver the installers to the client.
If Izpack has limitations, I might have to check other installer softwares.

Can you help me on this?

Comment by Rene Krell [ 15/Apr/14 ]

Hi, I commented IZPACK-1083.

Just a common note, although it actually doesn't belong here:
Nevertheless, don't forget that IzPack is work made by volunteers. If you want fast changes, the only reliable way is making an own repository and changing it as needed.
The better way for the project would be pull requests. Nobody from the team neither gets nor wants any donations, work is done in our spare time. I assume all users, contributors and team members are interested in an increasing development speed but with the manpower there is at the moment we simply can't be faster.
If these principles don't fit your need feel free to look for an alternative.

Comment by Vedavalli Radhika [ 22/Apr/14 ]

Hey Rene, I tried to use v 5 rc2 and built the installer via maven. The issue got resolved.
Thanks. Kindly close this ticket.

Comment by Rene Krell [ 27/May/14 ]

Ok thank you for the note. Using the latest version is always a good choice
Good luck!





[IZPACK-1063] NPE When pressing the quit button Created: 18/Mar/14  Updated: 18/Mar/14

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

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

Linux


Number of attachments : 0

 Description   

NPE occurs when pressing the quit button on the license panel, if the "I do not accept the terms of this license agreement." is selected, and installation path has not yet been set. This can occur when choosing to show the license panel first, and user does not agree statement and wants to quit the installer.



 Comments   
Comment by Miles Tjandrawidjaja [ 18/Mar/14 ]

I have sent a PR, please refer to https://github.com/izpack/izpack/pull/175





[IZPACK-1062] Dynamic variables using checkonce="true" cannot be overwritten by internal variables with the same name Created: 13/Mar/14  Updated: 14/Mar/14  Resolved: 14/Mar/14

Status: Resolved
Project: IzPack
Component/s: Documentation, 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-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Dynamic variables using checkonce="true" cannot be overwritten by internal variables with the same name, but the appropriate IzPack variable is reset to the value from the first (and last) evaluation of that variable.

During refreshing dynamic variables, for instance on a panel change, those with checkonce="true" should be mapped to a normal internal IzPack variable and be usable for instance in UserInputPanels as default value to be shown in edit fields.

Example:

install.xml:

<dynamicvariables>
  <variable name="address" file="${INSTALL_PATH}/" type="options"
    key="server.address"
    condition="haveInstallPath" checkonce="true"/>
</dynamicvariables>

Resource userInputSpec.xml:

<userInput>

  <panel id="configuration.panel">
    <field type="title" txt="Network Configuration" id="configuration.panel.title"/>
    <field type="rule" variable="address">
      <description align="left" id="address.description"/>
      <spec id="address.label" txt="Network address:" layout="O:15:U : N:5:5" resultFormat="displayFormat"/>
    </field>
  </panel>

</userInput>

In the above example, as soon as the condition haveInstallPath evaluates true and the dynamic variables are refreshed (for instance after leaving the TargetPanel), the value of the variable address can never receive the value the user entered on the user input panel, because it is overwritten with the frozen value of the appropriate dynamic variable.

Instead, overwriting a variable defined as dynamic variable with checkonce="true" should be possible from other sources, like user input fields.

This does not have effect on dynamic variables which should be always renewed, thus, with checkonce="false" (default for dynamic variables).



 Comments   
Comment by Rene Krell [ 13/Mar/14 ]

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

Comment by Rene Krell [ 14/Mar/14 ]

Fix merged.





[IZPACK-1061] UserInputPanel: Installer crashes on missing 'set' attribute for RuleInputFields Created: 12/Mar/14  Updated: 24/Mar/14  Resolved: 14/Mar/14

Status: Resolved
Project: IzPack
Component/s: Documentation, 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-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Testcase included: yes
Number of attachments : 0

 Description   

Initially having a user input panel sepcification like this:

<field type="rule" variable="address">
      <description align="left" id="address.label"/>
      <spec id="url.address.label" txt="Address and port:" layout="O:15:U : N:5:5" resultFormat="displayFormat" set="0: 1: "/>
      <validator class="com.izforge.izpack.panels.userinput.validator.RegularExpressionValidator" id="address.fail">
        <param name="pattern" value="\b.*\:(6553[0-5]|655[0-2]\d|65[0-4]\d{2}|6[0-4]\d{3}|[1-5]\d{4}|[1-9]\d{0,3})\b"/>
      </validator>
    </field>

So far it works as expected.
With the intention to display a preset value of the 'address' variable in the field (as it is possible for the text input field) I left out the 'set' attribute:

<field type="rule" variable="address">
      <description align="left" id="address.label"/>
      <spec id="url.address.label" txt="Address and port:" layout="O:15:U : N:5:5" resultFormat="displayFormat"/>
      <validator class="com.izforge.izpack.panels.userinput.validator.RegularExpressionValidator" id="address.fail">
        <param name="pattern" value="\b.*\:(6553[0-5]|655[0-2]\d|65[0-4]\d{2}|6[0-4]\d{3}|[1-5]\d{4}|[1-9]\d{0,3})\b"/>
      </validator>
    </field>

The installer crashes with this:

Mar 12, 2014 2:42:49 PM SEVERE: Error when switching panel
java.lang.NullPointerException
        at java.util.StringTokenizer.<init>(StringTokenizer.java:182)
        at java.util.StringTokenizer.<init>(StringTokenizer.java:219)
        at com.izforge.izpack.panels.userinput.field.rule.RuleField.parseSet(RuleField.java:330)
        at com.izforge.izpack.panels.userinput.field.rule.RuleField.<init>(RuleField.java:85)
        at com.izforge.izpack.panels.userinput.field.FieldFactory.create(FieldFactory.java:149)
        at com.izforge.izpack.panels.userinput.field.UserInputPanelSpec.createFields(UserInputPanelSpec.java:213)
        at com.izforge.izpack.panels.userinput.UserInputPanel.init(UserInputPanel.java:291)
        at com.izforge.izpack.panels.userinput.UserInputPanel.panelActivate(UserInputPanel.java:159)
        at com.izforge.izpack.installer.gui.InstallerFrame.switchPanel(InstallerFrame.java:610)
        at com.izforge.izpack.installer.gui.InstallerFrame$5.switchPanel(InstallerFrame.java:408)
        at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:128)
        at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:36)
        at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:418)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:238)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:334)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:317)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.navigate(DefaultNavigator.java:552)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.access$100(DefaultNavigator.java:515)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler$1$1.run(DefaultNavigator.java:535)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:672)
        at java.awt.EventQueue.access$400(EventQueue.java:81)
        at java.awt.EventQueue$2.run(EventQueue.java:633)
        at java.awt.EventQueue$2.run(EventQueue.java:631)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:642)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

This should not happen, NPE should be avoided all over the place. At least the compound input fields should be left empty in that case, instead.

Furthermore, in addition to avoiding this crash, instead of parsing a static default value there should be tokenized the current value of 'address' and displayed in the several input fields (in case this is a valid expression due to the rule field's layout). In case of invalid layouts of the incoming variable value leave them just empty.



 Comments   
Comment by Rene Krell [ 13/Mar/14 ]

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

Comment by Rene Krell [ 14/Mar/14 ]

Fix merged.

Comment by Rene Krell [ 24/Mar/14 ]

Merged post-fix from this pull request: https://github.com/izpack/izpack/pull/184





[IZPACK-1060] testCustomLangPack fails if the default locale is fr Created: 07/Mar/14  Updated: 14/Mar/14  Resolved: 10/Mar/14

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

Type: Bug Priority: Minor
Reporter: Sébastien Christy Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When running mvn install, the test testCustomLangPack fails. The console displays:

Tests in error:

testCustomLangPack(com.izforge.izpack.installer.container.provider.AutomatedInstallDataProviderTest): Cannot find messages for locale: fr



 Comments   
Comment by Sébastien Christy [ 07/Mar/14 ]

Patch proposed in pull request #170
https://github.com/izpack/izpack/pull/170

Comment by Tim Anderson [ 10/Mar/14 ]

Pull request merged thanks.





[IZPACK-1059] AntActionInstallerListener - use graphical InputHandler instead of Ant's DefaultInputHandler in GUI environments Created: 28/Feb/14  Updated: 18/Mar/14  Resolved: 18/Mar/14

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-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

For AntActionInstallerListener/AntActionUninstallerListener there is currently used org.apache.tools.ant.input.DefaultInputHandler as input handler if the <input> Ant command is used. The default input handler offers just a simple prompt on the command line.

Use a graphical input handler which pops up a dialog, or fall back to DefaultInputHandler on headless devices automatically.



 Comments   
Comment by Rene Krell [ 14/Mar/14 ]

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

Comment by Rene Krell [ 18/Mar/14 ]

Pull request merged.





[IZPACK-1058] Empty file field not allowed Created: 28/Feb/14  Updated: 14/Mar/14  Resolved: 04/Mar/14

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

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

Linux/Ubuntu


Number of attachments : 0

 Description   

On line 134 of FileInputField.java the text of the File Field is filled in with the current directory if the field is blank. This prevents the validator from detecting the field is empty.

Should only set the text if the path contains characters.

I'll try to figure out how to submit a patch.



 Comments   
Comment by Mark Heinze [ 28/Feb/14 ]

Well, this is a little more complicated than I originally guessed.
The File object uses the "empty abstract pathname" which is system dependent.

This means you will get a File object whenever FileInputField.getSelectedFile() is called.

Due to this when the "updateField" method is called in AbstractGuiFileField you will not get an empty string but instead a system dependent result. Therefore it is not possible to detect the user left the field empty.

It looks like the getSelectedFile() method in FileInputField should return null if the user didn't enter a file path. However, the code in AbstractGuiFileField (line 67) expects a non-null File object and will throw an exception if null is returned. I haven't researched where else a NullPointerException would be thrown.

Comment by Mark Heinze [ 03/Mar/14 ]

Possible solution in pull request #168.

https://github.com/izpack/izpack/pull/168

Comment by Rene Krell [ 04/Mar/14 ]

Pull request merged. Thank you





[IZPACK-1057] Export of user input record for automated installations (auto-install.xml) broken for radio buttons Created: 28/Feb/14  Updated: 28/Feb/14

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

Type: Bug 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   

At least on Linux, I don't get currently run automated installations using an auto-install.xml which should contain settings from radio buttons:

Feb 28, 2014 3:41:45 PM INFO: [ Starting automated installation ]
Feb 28, 2014 3:41:45 PM WARNING: AutomationHelper class not found for panel: com.izforge.izpack.panels.hello.HelloPanel
com.izforge.izpack.api.exception.InstallerException: Missing userInput element on line 37
com.izforge.izpack.api.exception.InstallerException: Missing userInput element on line 37
        at com.izforge.izpack.panels.userinput.UserInputPanelAutomationHelper.runAutomated(UserInputPanelAutomationHelper.java:135)
        at com.izforge.izpack.installer.automation.AutomatedPanels.switchPanel(AutomatedPanels.java:90)
        at com.izforge.izpack.installer.automation.AutomatedPanels.switchPanel(AutomatedPanels.java:40)
        at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:418)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:238)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:218)
        at com.izforge.izpack.installer.automation.AutomatedInstaller.doInstall(AutomatedInstaller.java:154)
        at com.izforge.izpack.installer.bootstrap.Installer.launchAutomatedInstaller(Installer.java:236)
        at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:215)
        at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:189)
        at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:68)
[ Automated installation FAILED! ]

The user input has been exported from the unchanged installer, before.

Line 37 in auto-install.xml contains:

<com.izforge.izpack.panels.userinput.UserInputPanel id="db.type.setup.panel"/>

The according panel definition is:

  <panel id="db.type.setup.panel">
    <field type="title" txt="Database Type Selection" id="db.type.setup.panel.title"/>
    <field type="radio" variable="db.server">
      <description align="left" txt="Database type" id="db.server.radio.description"/>
        <spec>
          <choice txt="Microsoft SQL Server" id="db.server.radio.label.mssql" value="mssql" set="true" />
          <choice txt="Oracle" id="db.server.radio.label.oracle" value="oracle" />
          <choice txt="SAP HANA" id="db.server.radio.label.hdb" value="hdb" />
        </spec>
    </field>
    <field type="space"/>
    <field type="radio" variable="db.operation">
      <description align="left" txt="Database operation" id="db.operation.description"/>
      <spec>
        <choice txt="Update only (without admin permission)" id="db.operation.radio.label.upgrade" value="update" set="true"/>
        <choice txt="Structure creation only (without admin permission)" id="db.operation.radio.label.structure" value="structure"/>
        <choice txt="Instance and structure creation (requires admin permission)" id="db.operation.radio.label.instance" value="rebuild"/>
      </spec>
    </field>
  </panel>

It seems like the radiobutton setting isn't saved any longer.






[IZPACK-1056] izpack-maven-plugin does work in relationship with installing artifacts Created: 28/Feb/14  Updated: 19/Mar/14  Resolved: 19/Mar/14

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

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

all


Number of attachments : 0

 Description   

I have setup a demo project which contains a multi-module build with two module.
If i do a mvn clean package it produces an installer in demo-assembly/target but if i do a mvn install it results into the following:

Copying the skeleton installer
Copying 5 files into installer
Merging 0 jars into installer
Writing 3 Packs into installer
Writing Pack 0: izpack-demo01 all Platforms
Writing Pack 1: izpack-demo01 fÌr Windows
Writing Pack 2: izpack-demo01 fÌr Linux

[ End ]
[INFO]
[INFO] --- maven-install-plugin:2.5.1:install (default-install) @ demo-assembly ---
[INFO] Installing com.soebes.tools.izpack:demo-assembly:0.1.0-SNAPSHOT at end
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] IZPack Demo :: Root ............................... SUCCESS [0.903s]
[INFO] IZPack Demo :: Install Routines ................... SUCCESS [0.958s]
[INFO] IZPack Demo :: Assembly ........................... SUCCESS [3.222s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

It will not install any artifact into my local repository (deploy the same).
If i simply comment out the izpack-maven-plugin from the demo project i got the following:

[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ demo-assembly ---
[INFO] Building jar: /Users/kama/ws-git/izpack-demo/demo-assembly/target/demo-assembly-0.1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @ demo-assembly ---
[INFO]
[INFO] --- maven-install-plugin:2.5.1:install (default-install) @ demo-assembly ---
[INFO] Installing /Users/kama/ws-git/izpack-demo/pom.xml to /Users/kama/.m2/repository/com/soebes/tools/izpack/izpack-demo-parent/0.1.0-SNAPSHOT/izpack-demo-parent-0.1.0-SNAPSHOT.pom
[INFO] Installing /Users/kama/ws-git/izpack-demo/demo-install-routines/target/demo-install-routines-0.1.0-SNAPSHOT.jar to /Users/kama/.m2/repository/com/soebes/tools/izpack/demo-install-routines/0.1.0-SNAPSHOT/demo-install-routines-0.1.0-SNAPSHOT.jar
[INFO] Installing /Users/kama/ws-git/izpack-demo/demo-install-routines/pom.xml to /Users/kama/.m2/repository/com/soebes/tools/izpack/demo-install-routines/0.1.0-SNAPSHOT/demo-install-routines-0.1.0-SNAPSHOT.pom
[INFO] Installing /Users/kama/ws-git/izpack-demo/demo-assembly/target/demo-assembly-0.1.0-SNAPSHOT.jar to /Users/kama/.m2/repository/com/soebes/tools/izpack/demo-assembly/0.1.0-SNAPSHOT/demo-assembly-0.1.0-SNAPSHOT.jar
[INFO] Installing /Users/kama/ws-git/izpack-demo/demo-assembly/pom.xml to /Users/kama/.m2/repository/com/soebes/tools/izpack/demo-assembly/0.1.0-SNAPSHOT/demo-assembly-0.1.0-SNAPSHOT.pom
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] IZPack Demo :: Root ............................... SUCCESS [1.688s]
[INFO] IZPack Demo :: Install Routines ................... SUCCESS [1.100s]
[INFO] IZPack Demo :: Assembly ........................... SUCCESS [0.771s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.978s
[INFO] Finished at: Fri Feb 28 10:50:27 CET 2014
[INFO] Final Memory: 27M/981M

which brings me to the conclusing that the izpack-maven-plugin has a problem.



 Comments   
Comment by Rene Krell [ 28/Feb/14 ]

This probably depends on the usage of the packaging type izpack-jar, which follows a modified lifecycle mapping and implicitly binds the execution of the izpack-maven-plugin to the package phase and replaces the packaging invoked in the packaging type "jar".
Furthermore there are configuration options of izpack-maven-plugin to replace the current artifact wiht the installer jar itself or making classified additional artifacts, all optionally depending on your needs.

In your case you might consider not to use the packaging type "izpack-jar" (use "jar" instead) and call the izpack-maven-plugin execution explicitly.

Comment by Rene Krell [ 28/Feb/14 ]

You're missing also a well-formed POM for the izpack-jar packaging type:

<plugin>
        <groupId>org.codehaus.izpack</groupId>
        <artifactId>izpack-maven-plugin</artifactId>
        <extensions>true</extensions>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>izpack</goal>
            </goals>
            <configuration>
              <classifier>installer</classifier>
            </configuration>
          </execution>
        </executions>
</plugin>

is a bad combination for the izpack-jar packaging type. Please remove the explicit execution, because this is already part of the izpack-jar lifecycle mapping or consider using pom, instead. See also http://docs.codehaus.org/display/IZPACK/IzPack+Maven+Plugin+Reference

Comment by Karl Heinz Marbaise [ 28/Feb/14 ]

It will not change a thing if i remove the explicit executions and of course i have tested that as well (github project). But the result is still the same. I'm asking on the maven-dev list (may be other maven-dev's execpt myself can give me hint or having an idea what's going wrong).

Comment by Rene Krell [ 28/Feb/14 ]

There is minimum one difference, you have a execution-local configuration, which should not get respected in the izpack-jar lifecycle execution. The usage as currently seen in your repository is obviously ambigous.

To transform this you should have something like:

<plugin>
        <groupId>org.codehaus.izpack</groupId>
        <artifactId>izpack-maven-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
            <classifier>installer</classifier>
        </configuration>
</plugin>
Comment by Karl Heinz Marbaise [ 28/Feb/14 ]

May be i mistaken something...but do you mean the classifier ? This is defined in the parent pom via pluginManagement.

  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>org.codehaus.izpack</groupId>
          <artifactId>izpack-maven-plugin</artifactId>
          <version>${izpack-release.version}</version>
          <configuration>
            <mkdirs>true</mkdirs>
            <classifier>installer</classifier>
          </configuration>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>

which i can see if i do {{mvn -X ..} like this:

[DEBUG] -----------------------------------------------------------------------
[DEBUG] Goal:          org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc1:izpack (default-izpack)
[DEBUG] Style:         Regular
[DEBUG] Configuration: <?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <autoIncludeDevelopers default-value="false"/>
  <autoIncludeUrl default-value="false"/>
  <baseDir default-value="${project.build.directory}/staging"/>
  <classifier>installer</classifier>
  <comprFormat default-value="default"/>
  <comprLevel default-value="-1"/>
  <enableAttachArtifact default-value="true"/>
  <enableOverrideArtifact default-value="false"/>
  <finalName default-value="${project.build.finalName}">${jar.finalName}</finalName>
  <installFile default-value="${basedir}/src/main/izpack/install.xml"/>
  <kind default-value="standard"/>
  <mkdirs default-value="false">true</mkdirs>
  <outputDirectory default-value="${project.build.directory}"/>
  <project default-value="${project}">${project}</project>
</configuration>

and finally...

[DEBUG] Configuring mojo org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc1:izpack from plugin realm ClassRealm[plugin>org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc1, parent: sun.misc.Launcher$AppClassLoader@3f610944]
[DEBUG] Configuring mojo 'org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc1:izpack' with basic configurator -->
[DEBUG]   (f) autoIncludeDevelopers = false
[DEBUG]   (f) autoIncludeUrl = false
[DEBUG]   (f) baseDir = /Users/kama/ws-git/izpack-demo/demo-assembly/target/staging
[DEBUG]   (f) classifier = installer
[DEBUG]   (f) comprFormat = default
[DEBUG]   (f) comprLevel = -1
[DEBUG]   (f) enableAttachArtifact = true
[DEBUG]   (f) enableOverrideArtifact = false
[DEBUG]   (f) finalName = demo-assembly-0.1.0-SNAPSHOT
[DEBUG]   (f) installFile = /Users/kama/ws-git/izpack-demo/demo-assembly/src/main/izpack/install.xml
[DEBUG]   (f) kind = standard
[DEBUG]   (f) mkdirs = true
[DEBUG]   (f) outputDirectory = /Users/kama/ws-git/izpack-demo/demo-assembly/target
[DEBUG]   (f) project = MavenProject: com.soebes.tools.izpack:demo-assembly:0.1.0-SNAPSHOT @ /Users/kama/ws-git/izpack-demo/demo-assembly/pom.xml
[DEBUG] -- end configuration --

But just to be sure i have added the explicit configuration with the classifier in my demo-assembly module but it does not change a thing as i expected.

Comment by Rene Krell [ 14/Mar/14 ]

I did not mean merging of the configurations from the parent and the module's POM, but the explicit execution of the izpack-maven-plugin within an izpack-jar lifecycle mapping. This is the same like explicitly executing the maven-jar plugin in a POM with a jar packaging type. With izpack-jar, the izpack-maven-plugin should just be configured, not executed explicitly, because according to your source it is probably executed twice, implicitly by the packaging type's lifecycle mapping and your explicit execution, probably each time with a different configuration, which might confuse things and isn't consistent for sure.

If you want to use explicit execution please use a different packaging type (in this case you must NOT enable overriding the default artifact, of course, which is done by the jar plugin than).
Or remove the executions block like previously described, which is the better way, IMHO.

Thus, izpack-demo/demo-assembly/pom.xml should have

<plugin>
        <groupId>org.codehaus.izpack</groupId>
        <artifactId>izpack-maven-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
            <classifier>installer</classifier>
        </configuration>
</plugin>

instead of

<plugin>
        <groupId>org.codehaus.izpack</groupId>
        <artifactId>izpack-maven-plugin</artifactId>
        <extensions>true</extensions>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>izpack</goal>
            </goals>
            <configuration>
              <classifier>installer</classifier>
            </configuration>
          </execution>
        </executions>
</plugin>

regardless of the plugin management in the parent POM, if you want to make usage of the izpack-jar packaging.

Comment by Rene Krell [ 14/Mar/14 ]

Anyway, if you see some obvious implementation error, maybe with a newer Maven version, feel free to send a pull request.
Nobody intents to violate good practices

Comment by Rene Krell [ 18/Mar/14 ]

Changed priority to Minor - easy workaround is present.

Comment by Rene Krell [ 19/Mar/14 ]

Just to find a final statement here:

Currently I don't see a better alternative than the way the plugin behaves now. Making an IzPack installer jar an artifact is just a gimmick, you can't even decompile it or use in a meaningful manner to be used as dependency to other modules or projects.

There should not be an artifact attached by default, because:

  • local and remote Maven repositories get crowded of installers jars, which should be offered on special download sites elsewhere,
  • the IzPack plugin can be also used in modules utilizing the jar and other different packaging types to not conflict with their main artifact produced during the according lifecycle,

Making a classified attached artifact by default isn't a better choice, IMHO, due to the above reasons and the limitation of freedom of configuration.

In any case there should be an option to prevent making artifacts of IzPack installer jars. The current choice is preventing it by default.

If there are good reasons to change this, one might reopen this issue, and make a detailed suggestion.

Maybe in a next version we can adapt the behavior of the Maven Assembly Plugin, to give an ID, which is automatically attached using a classifier with the same name. But even there attaching can be prevented by special options. And the Assembly Plugin usually produces archives which are really usable as Maven dependency, which is a difference.





[IZPACK-1055] Compiler doesn't complain about bad "order" attribute in action listener resources Created: 27/Feb/14  Updated: 27/Feb/14

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

Type: Bug 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   

In a listener's resource, for instance for AntActionInstallerListener, if I define a bad order attribute for some Ant action like this:

<antcall order="beforePacks" buildresource="antBuild_Backup.xml">
...
</antcall>

instead of

<antcall order="beforepacks" buildresource="antBuild_Backup.xml">
...
</antcall>

I get the following exception during installing:

Feb 27, 2014 12:47:49 PM SEVERE: java.lang.Exception: Bad value for order.
com.izforge.izpack.api.exception.InstallerException: java.lang.Exception: Bad value for order.
        at com.izforge.izpack.event.AntActionInstallerListener.readAntCall(AntActionInstallerListener.java:348)
        at com.izforge.izpack.event.AntActionInstallerListener.beforePacks(AntActionInstallerListener.java:167)
        at com.izforge.izpack.installer.event.InstallerListeners.beforePacks(InstallerListeners.java:169)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.preUnpack(UnpackerBase.java:382)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:259)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.run(UnpackerBase.java:242)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.Exception: Bad value for order.
        at com.izforge.izpack.event.ActionBase.setOrder(ActionBase.java:191)
        at com.izforge.izpack.event.AntActionInstallerListener.readAntCall(AntActionInstallerListener.java:343)
        ... 6 more

along with the message box: "java.lang.Exception: Bad value for order."

This should not happen during the installation, but the compiler should catch this. Just another missing compiler cross-check between the installation descriptor and the resources.






[IZPACK-1054] NPE in case of missing conditions which are part of complex conditions Created: 26/Feb/14  Updated: 26/Feb/14

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

Type: Bug 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   

In the resource ConfigurationActionsSpec.xml (for example) I have defined a complex condition like

<configurable type="options" tofile="${INSTALL_PATH}/some/file.properties" condition="a+b">
  ..
</configurable>

If for example condition 'a' is not defined in the installation descriptor (install.xml), the installation aborts with the following stacktrace (with -DSTACKTRACE=true):

Feb 26, 2014 5:55:16 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.afterPacks(ConfigurationInstallerListener.java:282)
        at com.izforge.izpack.installer.event.InstallerListeners.afterPacks(InstallerListeners.java:306)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.postUnpack(UnpackerBase.java:693)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:261)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.run(UnpackerBase.java:242)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NullPointerException
        at com.izforge.izpack.core.rules.logic.AndCondition.isTrue(AndCondition.java:64)
        at com.izforge.izpack.core.rules.RulesEngineImpl.isConditionTrue(RulesEngineImpl.java:350)
        at com.izforge.izpack.core.rules.RulesEngineImpl.isConditionTrue(RulesEngineImpl.java:337)
        at com.izforge.izpack.event.ConfigurationActionTask.execute(ConfigurationActionTask.java:68)
        at com.izforge.izpack.event.ConfigurationAction.performInstallAction(ConfigurationAction.java:59)
        at com.izforge.izpack.event.ConfigurationInstallerListener.performAllActions(ConfigurationInstallerListener.java:353)
        ... 6 more

This should be fixed.
The compiler should ensure this cannot happen by cross checking even complex conditions.






[IZPACK-1053] Links in wiki to picocontainer.org not working Created: 26/Feb/14  Updated: 27/Feb/14  Resolved: 27/Feb/14

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

Type: Bug Priority: Major
Reporter: Karl Heinz Marbaise 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   

The site picocontainer.org does not exist anymore. Found several links referencing picocontainer.org.



 Comments   
Comment by Rene Krell [ 26/Feb/14 ]

You are right. Can you correct them, please?

I found just:

Comment by Karl Heinz Marbaise [ 26/Feb/14 ]

So i fixed many of them hopfully all.

The following is in my opinion the correct one:
http://picocontainer.codehaus.org/

Comment by Karl Heinz Marbaise [ 26/Feb/14 ]

Fixed the links in Wiki.

Comment by Tim Anderson [ 27/Feb/14 ]

According to http://permalink.gmane.org/gmane.comp.java.picocontainer.user/1495 picocontainer.org had to be switched to picocontainer.com when the domain expired and was snapped up by someone else.

Comment by Rene Krell [ 27/Feb/14 ]

Yes, picocontainer.com offers the latest versions.

Comment by Karl Heinz Marbaise [ 27/Feb/14 ]

Updated the wiki accordingly.

Comment by Karl Heinz Marbaise [ 27/Feb/14 ]

Changed the links to picocontainer.com.





[IZPACK-1052] Windows test should not require Administrator privileges Created: 26/Feb/14  Updated: 27/Feb/14

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

Type: Wish Priority: Minor
Reporter: Michael Schnupp 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   

Tests really should not require Administrator privileges:

Results :

Failed tests:
  testMultipleInstallation(com.izforge.izpack.integration.windows.WindowsConsoleInstallationTest): This test must be run as administrator, or with Windows UAC turned off
Feb 26, 2014 11:33:28 AM com.izforge.izpack.util.DefaultTargetPlatformFactory$Parser warning
  testNonDefaultUninstaller(com.izforge.izpack.integration.windows.WindowsConsoleInstallationTest): This test must be run as administrator, or with Windows UAC turned off
  testInstallation(com.izforge.izpack.integration.windows.WindowsConsoleInstallationTest): This test must be run as administrator, or with Windows UAC turned off
Warnung: Ignoring duplicate implementation=com.izforge.izpack.util.os.Win_Shortcut for platform=windows,version=null,arch=unknown,symbolicName=null,javaVersion=null from jar:file:/C:/Users/schnupM/svn/izpack/izpack-test/target/test-classes/samples/windows/out0.686760710885567.jar!/com/izforge/izpack/util/TargetPlatformFactory.properties
  testRejectMultipleInstallation(com.izforge.izpack.integration.windows.WindowsConsoleInstallationTest): This test must be run as administrator, or with Windows UAC turned off

Because of this I need to skip all test in order to build IzPack.



 Comments   
Comment by Tim Anderson [ 26/Feb/14 ]

They test facilities of the Windows installation support that require administrator privileges.
They could be placed in a profile that excluded them by default, but I don't really see the point; they'd never get run.

Comment by Michael Schnupp [ 26/Feb/14 ]

Currently you have to disable all tests to be able to build the project.

Is there some user area in the registry, which is writable without administrator privileges?
Do you really want to use a unit test to test whether the registry is working correctly?
Maybe you could simply mock the actual write to the registry.

Comment by Tim Anderson [ 27/Feb/14 ]

Mocking the test objective is no substitute for actually testing it.
In the short term you can either

  • run the tests with administrative privileges. On Windows, this just means launching your development environment or shell prompt with the "Run As Administrator" option.
  • skip the tests with -DskipTests

In the longer term, the tests can be restructured using one of the techniques described here: http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing

Comment by Karl Heinz Marbaise [ 27/Feb/14 ]

The point here is that checkin out the source and do a simple mvn clean package does not work which is against the Maven principle to unify the build and make it easy.
And the suggestion to use -DskipTests is not recommended.
Just runing with administrative privlieges is not always an option cause in commerical environment you usually you don't have administrative privileges. So better is to run unit tests which work on every platform and only in case you really like to run (in the integration-test phase) then use a profile like run-its which prerequisites a special environment.
Apart from that if you have such tests which need administrator permission they are by default integration tests which means usually to define a profile like run-its which has been accepted as best practice for plugins etc. Of course the classes must be tested and of course mocking is not a replacement for real testing, but this should be done a defined continious integration environment.





[IZPACK-1051] Using wrong maven-site-plugin version in profile Created: 26/Feb/14  Updated: 14/Mar/14  Resolved: 26/Feb/14

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

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

Number of attachments : 0

 Description   

The maven-site-plugin version for the maven3 profile is wrong.



 Comments   
Comment by Karl Heinz Marbaise [ 26/Feb/14 ]

Pull request send.

Comment by Rene Krell [ 26/Feb/14 ]

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





[IZPACK-1050] Maven Plugin throws AssertionError Created: 26/Feb/14  Updated: 26/Feb/14  Resolved: 26/Feb/14

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

Type: Bug Priority: Critical
Reporter: Michael Schnupp Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The izPack maven plugin catches all exceptions and throws an AssertionError instead.

However maven does not handle Errors. Therefore maven does not stop building in that case as expected.

Please throw one of the declared exceptions instead of the AssertionError.

(see also MNG-5593)



 Comments   
Comment by Michael Schnupp [ 26/Feb/14 ]

IZPACK-1048





[IZPACK-1049] Defining the same Panels without Id twice times Created: 25/Feb/14  Updated: 25/Feb/14

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

Type: Bug Priority: Major
Reporter: Karl Heinz Marbaise 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   

If have defined two panels exactly the same like this in my install.xml file:

<panel classname="HelloPanel"/>

If run my project the compiler does not complain about this and produces an installer.
If i start the installer i got exceptions exactly complaining about the identical panels.
I would have expected to get a compiler error during the compilation.






[IZPACK-1048] Wrong Handling of Exceptions in izpack-maven-plugin Created: 25/Feb/14  Updated: 14/Mar/14  Resolved: 26/Feb/14

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

Type: Bug Priority: Major
Reporter: Karl Heinz Marbaise Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Number of attachments : 0

 Description   

The current implementation throws an AssertionError() in case of any exception which is emitted by the compiler.
In contradiction to the above a maven plugin should produce a MojoFailureExecption or MojoExecutionException.
For example if the compiler find a problem it should throw a MojoFailureException in other case it should produce a MojoExeuctionException.

The handling of the exeption in the code could look like:

  try {
      compilerConfig.executeCompiler();
  } catch (CompilerExeption e) {
     throw new MojoFailureException(e);
  } catch (Exception e) {
     throw new MojoExecutionException(e);
  }

I can provide a patch for that.



 Comments   
Comment by Karl Heinz Marbaise [ 25/Feb/14 ]

Pull request send.

Comment by Rene Krell [ 26/Feb/14 ]

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





[IZPACK-1047] Build on Debian Created: 24/Feb/14  Updated: 14/Mar/14  Resolved: 24/Feb/14

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

Type: Bug Priority: Blocker
Reporter: Karl Heinz Marbaise Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux
wheezy main


Number of attachments : 0

 Description   

Currently the build will fail like the following:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.697 s
[INFO] Finished at: 2014-02-24T14:34:52+01:00
[INFO] Final Memory: 10M/25M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:2.3.1:test-jar (default) on project izpack: Error assembling JAR: Failed to read filesystem attributes for: /home/michas/izpack/pom.xml: Failed to retrieve numeric file attributes using: '/bin/sh -c ls -1nlad /home/michas/izpack/pom.xml' -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[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/MojoExecutionException

The problem is located in to old plugin versions.



 Comments   
Comment by Karl Heinz Marbaise [ 24/Feb/14 ]

Pull request send.

Comment by Rene Krell [ 24/Feb/14 ]

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





[IZPACK-1046] Console uninstaller launches relaunches GUI uninstaller if it doesn't have administrative privileges Created: 24/Feb/14  Updated: 24/Feb/14

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

Type: Bug Priority: Major
Reporter: Tim Anderson 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   

If the uninstaller needs administrative privileges, it relaunches itself using PrivilegedRunner. However, if the console uinstaller was being run, it is the GUI uninstaller that is relaunched.

Note that this is related to IZPACK-1045, in that whatever solution is chosen should also be applied to the console uninstaller.






[IZPACK-1045] run-privileged ignored for console and automated installation Created: 22/Feb/14  Updated: 11/Aug/14  Resolved: 11/Aug/14

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

Type: Bug Priority: Major
Reporter: Tim Anderson 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   

The <run-privileged/> element is being ignored for console and automated installation.
There's a few things preventing console and automated installations elevating priivileges at present:

  • the InstallDataConfiguratorWithRules class currently responsible for elevating privileges uses JOptionDialog
  • the PrivilegedRunner class uses:
    • wscript in conjunction with elevate.js on Windows. The elevate.js script uses the ShellExecute Windows API which doesn't support passing the parent stdout/stdin/stderr to the child process
    • xterm with sudo on Unix which is not desirable for a console installer; it should run in the same console

For Windows, the http://www.codeproject.com/Articles/19165/Vista-UAC-The-Definitive-Guide provides a .dll and .exe that might work as a replacement for wscript/elevate.js



 Comments   
Comment by Tim Anderson [ 24/Feb/14 ]

Actually, the http://www.codeproject.com/Articles/19165/Vista-UAC-The-Definitive-Guide doesn't provide a x64 version, nor does it provide the complete source to be able to produce one, so its a non-starter.
So I think there's a couple of alternatives:

  • when forking the elevated child, use a socket to handle I/O between the parent and child. The parent is then responsible for doing the console input and output, but the child does the installation.
  • abort installation if the installer requires privileges but the current user doesn't have admin rights.
    At present, it just displays a warning dialog:

    The installer could not launch itself with administrator permissions.
    The installation will still continue but you may encounter problems due to insufficient permissions.

    I think this behaviour is a little optimistic. The installer aborts if it fails to install files - I think it should abort if it needs admin permissions to run.

Comment by Miles Tjandrawidjaja [ 28/Jul/14 ]

I have sent a PR to help address this issue https://github.com/izpack/izpack/pull/256

I agree that installer should abort if user doesn't have admin rights, changes have been made so that installation cannot continue unless the proper permissions are met. On window's machine the UAC prompt dialog box should appear to ask if they want to allow administrative permissions. On Unix/Other machines the user is informed to re-run the application as an administrative (root) user. It no longer should try to launch xterm, I think it is normal for Unix users just to be prompted to re-run their command with admin privileges. This avoids the problem if the user does not have xterm installed.

Although I like the idea of prompting for sudo in console/automatic installations and spawning the process in the same terminal, this brings up some complications. One is that if you want to run the application in the same terminal, we would have to manually mange the input and output streams to the new process. Also this may conflict with the jline dependency as by default the terminal is line buffered, so the process does not respond per character pressed but rather every time a new line is entered (needed for tab-completion). I tried settings the terminal to character buffered (raw) but for me the output ended up badly formatted, and to use a raw terminal we might have to cover different cases for different operating systems. That is why as I stated above, we rather just inform to user to re-run the installer with administrative privileges.

I've also made changes so that the uninstaller can only run with correct privileges also.

Comment by Rene Krell [ 11/Aug/14 ]

Pull request #256 merged.





[IZPACK-1044] Drop Maven 2.2.X Support Created: 18/Feb/14  Updated: 19/Feb/14

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

Type: Task Priority: Minor
Reporter: Karl Heinz Marbaise 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   

Based on the decision has been made on the maven developers list. The Maven 2.X line will not be continued or updated anymore which means only Maven 3.X is the way to go.

No artifacts any more from Maven 2.X line (maven-project, maven-settings, maven-model, maven-artifact) only fomr 3.X line.

Furthemore check the izpack-maven-plugin:
It might be a way to support the runtime but not the build time anymore with Maven 2.X. This can be checked by appropriate integration tests by using maven-invoker-plugin.
Maybe other cleanups in the Plugin code as well.



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

I do not fully share the argumentation end of support -> end of using. This cannot be always automatically applied.
The same thing with the JDK 6, which ended up in being supported quite a long time ago, but many productive environments do still use it anyway. I know several environments still even running JDK 5.
Nevertheless, since Maven is just a developer tool, we might do a migration, but I would suggest IzPack 5.1 for this.

Comment by Karl Heinz Marbaise [ 19/Feb/14 ]

That's what i suggested. Only change the build requirement but not the runtime requirement (runtime can be checked as mentioned by appropriate integration test using maven-invoker-plugin), cause they are different. Apart from that's why i set the *FIX version to 5.1*





[IZPACK-1043] izpack-maven-plugin integration tests are failing Created: 14/Feb/14  Updated: 14/Feb/14

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

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

all


Number of attachments : 0

 Description   

The integration tests of the izpack-maven-plugin are failing

0:00:51.668 [INFO]
00:00:51.687 [INFO] sample     RUNNING
00:00:51.688 [INFO] izpack-172 RUNNING
00:00:52.787 [INFO] izpack-172 FAILURE (0:00:01.062) Java returned: 1
00:00:55.869 [INFO] sample     FAILURE (0:00:04.141) Java returned: 1
00:00:55.870 [INFO]
00:00:55.870 [INFO] -------------------------------------------------------------------------------
00:00:55.870 [INFO] Test Summary (0:00:04.201)
00:00:55.871 [INFO]     Passed: 0
00:00:55.871 [INFO]     Failed: 2
00:00:55.871 [INFO] -------------------------------------------------------------------------------
00:00:55.871 [INFO]
00:00:55.872 [INFO] The following tests failed:
00:00:55.874 [INFO]     * izpack-172 - /home/build/.jenkins/workspace/izpack-maxtrix-master/jdk/JDK-1.7-u40/izpack-maven-plugin/src/it/izpack-172/build.log
00:00:55.874 [INFO]     * sample - /home/build/.jenkins/workspace/izpack-maxtrix-master/jdk/JDK-1.7-u40/izpack-maven-plugin/src/it/sample/build.log
00:00:55.874 [INFO]
00:00:55.880 [INFO] ------------------------------------------------------------------------
00:00:55.880 [ERROR] BUILD ERROR
00:00:55.880 [INFO] ------------------------------------------------------------------------
00:00:55.885 [INFO] 2 of 2 tests failed
00:00:55.885 [INFO] ------------------------------------------------------------------------
00:00:55.885 [INFO] For more information, run Maven with the -e switch
00:00:55.885 [INFO] -----------------


 Comments   
Comment by Karl Heinz Marbaise [ 14/Feb/14 ]

If i could assign myself to the issue i could take care of it. So the buildhive build does not run the integration tests.





[IZPACK-1042] Get rid of WARNING Messages during izpack-maven-plugin Created: 12/Feb/14  Updated: 14/Mar/14  Resolved: 13/Feb/14

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

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

Number of attachments : 0

 Description   

During the build the following messages appear

[WARNING] org.izpack.mojo.IzPackNewMojo#finalName:
[WARNING]   The syntax
[WARNING]     @parameter expression="${property}"
[WARNING]   is deprecated, please use
[WARNING]     @parameter property="property"
[WARNING]   instead.
[WARNING] org.izpack.mojo.IzPackNewMojo#project:
[WARNING]   The syntax
[WARNING]     @parameter expression="${property}"
[WARNING]   is deprecated, please use
[WARNING]     @parameter property="property"
[WARNING]   instead.


 Comments   
Comment by Karl Heinz Marbaise [ 12/Feb/14 ]

Pull request send.

Comment by Rene Krell [ 12/Feb/14 ]

Thank you, merged.

Comment by Rene Krell [ 12/Feb/14 ]

Unfortunately, it causes a build failure on one of the automatic build systems:
https://buildhive.cloudbees.com/job/izpack/job/izpack/349/
Can you please have a look at it?

Comment by Karl Heinz Marbaise [ 12/Feb/14 ]

Of course i can take a look.

Comment by Karl Heinz Marbaise [ 13/Feb/14 ]

Now looks better sorry

Comment by Rene Krell [ 13/Feb/14 ]

Well done, thanks.





[IZPACK-1041] Registry updates using $OLD_KEY_VALUE can break Windows PATH Created: 12/Feb/14  Updated: 12/Feb/14

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

Type: Bug Priority: Major
Reporter: Cris Stanza 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   

Registry updates using $OLD_KEY_VALUE can potentially break Windows PATH environment variable.

For example, in registry.xml:
<pack name="Lorem">
<value
name="PATH"
root="HKLM"
keypath="SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
string="$INSTALL_PATH\bin;$OLD_KEY_VALUE" />
</pack>

If one performs a update (install over a previous installation), there will be two paths "$INSTALL_PATH\bin" inside registry value PATH.

This is specially harmful because Windows PATH env. var. is size limited, and when it exceeds, the PATH for all system gets broken.


Workaround:

--- a/izpack-installer/src/main/java/com/izforge/izpack/util/os/Win_RegistryHandler.java
+++ b/izpack-installer/src/main/java/com/izforge/izpack/util/os/Win_RegistryHandler.java
@@ -22,6 +22,12 @@

package com.izforge.izpack.util.os;

+import java.util.ArrayList;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Properties;
+import java.util.Set;
+
import com.coi.tools.os.izpack.Registry;
import com.coi.tools.os.win.RegDataContainer;
import com.izforge.izpack.api.exception.NativeLibException;
@@ -30,9 +36,6 @@ import com.izforge.izpack.core.os.RegistryHandler;
import com.izforge.izpack.core.substitutor.VariableSubstitutorImpl;
import com.izforge.izpack.util.Librarian;

-import java.util.List;
-import java.util.Properties;
-
/**
* This is the Microsoft Windows specific implementation of <code>RegistryHandler</code>.
*
@@ -90,6 +93,23 @@ public class Win_RegistryHandler extends RegistryHandler
{
// ignore
}
+ if(key.equals("SYSTEM\\CurrentControlSet\\Control
Session Manager
Environment") && value.equals("PATH")) {
+ String[] subPaths = contents.split(";");
+ List<String> fixedSubPaths = new ArrayList<String>();
+ for (String subPath : subPaths) {
+ if (subPath.length() > 0 && !fixedSubPaths.contains(subPath)) {
+ fixedSubPaths.add(subPath);
+ }
+ }
+ StringBuilder fixedContents = new StringBuilder();
+ if ( fixedSubPaths.size() > 0 ) {
+ fixedContents.append(fixedSubPaths.get(0));
+ for (int i = 1 ; i < fixedSubPaths.size() ; i++) {
+ fixedContents.append(";").append(fixedSubPaths.get(i));
+ }
+ }
+ contents = fixedContents.toString();
+ }
}
}
getRegistry().setValue(key, value, contents);






[IZPACK-1040] maven-assembly-plugin is not pined in the build Created: 11/Feb/14  Updated: 14/Mar/14  Resolved: 12/Feb/14

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

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

Number of attachments : 0

 Description   

Currently the maven-assembly-plugin is used in serveral areas but no version is defined in an appropriate pluginManagement area.



 Comments   
Comment by Karl Heinz Marbaise [ 11/Feb/14 ]

Send pull request.

Comment by Rene Krell [ 12/Feb/14 ]

Thank you





[IZPACK-1039] Build Requirement Maven 2.0 / 2.2.1 / 3.0.X / 3.1.X / 3.2.X ? Created: 11/Feb/14  Updated: 14/Mar/14  Resolved: 12/Feb/14

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

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

Number of attachments : 0

 Description   

In the wiki it's stated out that to build IZPack you need Maven 2 but it's not defined if this means Maven 2.0.11 or Maven 2.2.1...

The question is: Should IZPack be buildable with Maven 2.0.11, 2.2.1 or Maven 3.0.X, 3.1.X or 3.2(currently comming around the corner) ?



 Comments   
Comment by Rene Krell [ 12/Feb/14 ]

It should be Maven 2.2.1, which seems to work fine at the moment.
If there will be a good reason one might check the possible migration, but personally I'd leave this for 5.1 or later.

Comment by Karl Heinz Marbaise [ 12/Feb/14 ]

Send pull request which makes sure Maven 3 will work also.

Comment by Rene Krell [ 12/Feb/14 ]

Thank you, this change should be ok for 5.0, merged.

Comment by Karl Heinz Marbaise [ 12/Feb/14 ]

This change will only make sure to require really Maven 2.2.1 at least. Furthermore it will make sure the requirements will work with Maven 3.X as well based on the deprecation of prerequisites for Maven 3.





[IZPACK-1038] Purpose of izpack-listener module - No source etc. Created: 11/Feb/14  Updated: 14/Mar/14  Resolved: 12/Feb/14

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

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

Number of attachments : 0

 Description   

I have taken a look into the module izpack-listener but i don't see the intention of that module cause it does not contain any code only a pom file ? I my opinion this module can be removed.



 Comments   
Comment by Karl Heinz Marbaise [ 11/Feb/14 ]

Pull request send.

Comment by Rene Krell [ 12/Feb/14 ]

Good catch, thanks.





[IZPACK-1037] Removing debug warning of maven-resources-plugin Created: 11/Feb/14  Updated: 14/Mar/14  Resolved: 12/Feb/14

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

Type: Improvement Priority: Trivial
Reporter: Karl Heinz Marbaise Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following warning is created during the build:

[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ izpack-native ---
[debug] execute contextualize

This can simple be solved by using maven-resources-plugin 2.6.



 Comments   
Comment by Karl Heinz Marbaise [ 11/Feb/14 ]

Pull request send.

Comment by Rene Krell [ 12/Feb/14 ]

Thank you.





[IZPACK-1036] Removing warning modell for izpack-dist during the build Created: 11/Feb/14  Updated: 14/Mar/14  Resolved: 12/Feb/14

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

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

Number of attachments : 0

 Description   

Currently the build produces the following warning at the beginning:

[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.codehaus.izpack:izpack-dist:jar:5.0.0-rc2-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for ${project.groupId}:izpack-maven-plugin is missing. @ line 118, column 21
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]


 Comments   
Comment by Karl Heinz Marbaise [ 11/Feb/14 ]

Send pull request.

Comment by Rene Krell [ 12/Feb/14 ]

Thanks for this cleanup.





[IZPACK-1035] Using the plugin defaults instead manually defining them Created: 11/Feb/14  Updated: 14/Mar/14  Resolved: 11/Feb/14

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

Type: Improvement Priority: Minor
Reporter: Karl Heinz Marbaise Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5.0.0-rc1


Number of attachments : 0

 Description   

The build defines <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> but plugins already have that default but in contradiction to that they define the encoding separately.



 Comments   
Comment by Karl Heinz Marbaise [ 11/Feb/14 ]

Send pull request.

Comment by Rene Krell [ 11/Feb/14 ]

Thank you





[IZPACK-1034] Change the name of izpack-utils module Created: 11/Feb/14  Updated: 14/Mar/14  Resolved: 11/Feb/14

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

Type: Improvement Priority: Minor
Reporter: Karl Heinz Marbaise Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5.0.0-rc1


Number of attachments : 0

 Description   

I would suggest to change the name of the module izpack-utils into izpack-wrapper cause it will represent better the content in relationship to the name.



 Comments   
Comment by Karl Heinz Marbaise [ 11/Feb/14 ]

Send pull request.

Comment by Rene Krell [ 11/Feb/14 ]

That's ok. Thank you





[IZPACK-1033] Create a version in JIRA 5.0.0-rc1 to assign tickets to the correct version Created: 11/Feb/14  Updated: 11/Feb/14

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

Type: Wish Priority: Minor
Reporter: Karl Heinz Marbaise 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 would be good to add the version 5.0.0-rc1 to JIRA cause the most up-to-date version of IZPack is 5.0.0-rc1 so it should be listed in the Affects Version/s entry which is currently not the case.






[IZPACK-1032] Support of tar.gz for unpack Created: 11/Feb/14  Updated: 11/Feb/14

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

Type: Improvement Priority: Minor
Reporter: Karl Heinz Marbaise Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5.0.0-rc1


Number of attachments : 0

 Description   

It would be nice to support tar.gz archives in relationship with file tag:

<file unpack="true" src="whatever-bin-unix.tar.gz" targetdir="$INSTALL_PATH"/>

The reason for that is having tar.gz archives are more or less natural on linux system and already building them by maven. But currently it seemed that i can't integrate them into the installer. The tar.gz contains shell scripts whereas the .zip contains batch files.






[IZPACK-1031] Plugin does not add artifacts to project Created: 06/Feb/14  Updated: 14/Mar/14

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

Type: Bug Priority: Blocker
Reporter: Karl Heinz Marbaise Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all Using izpack-maven-plugin 5.0.0-rc1


Number of attachments : 0

 Description   

I have setup a project which produces a executable jar installer..(windows/unix) works.
But currently i've stumbled over the following problem. I have defined the packaging type izpack-jar and created other steps but if i try to do a mvn install or mvn deploy i get the following error message:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:2.5.1:install (default-install) on project izpack-demo01: The packaging for this project did not assign a file to the build artifact -> [Help 1]


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

Can you attach the usage of the izpack-maven-plugin, a pom.xml snippet or something similar?
Can you activate stack traces on the command line?

Anyway, I would not call this a blocker, since you an attach a jar file in the build directoy additionally by other facilities.

Comment by Rene Krell [ 06/Feb/14 ]

Do you use a classifier? Otherwise, have you tried the configuration setting enableOverrideArtifact=true?

Comment by Rene Krell [ 06/Feb/14 ]

Example usage:


  <packaging>izpack-jar</packaging>
...
  <build>

    <plugins>

      <plugin>
        <groupId>org.codehaus.izpack</groupId>
        <artifactId>izpack-maven-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
          <descriptorEncoding>UTF-8</descriptorEncoding>
          <baseDir>${staging.dir.app}</baseDir>
          <installFile>${izpack.dir.app}/install.xml</installFile>
          <outputDirectory>${project.build.directory}</outputDirectory>
          <finalName>${project.build.finalName}-installer</finalName>
          <enableOverrideArtifact>true</enableOverrideArtifact>
          <mkdirs>true</mkdirs>
          <autoIncludeUrl>false</autoIncludeUrl>
          <autoIncludeDevelopers>false</autoIncludeDevelopers>
        </configuration>
      </plugin>
Comment by Karl Heinz Marbaise [ 08/Feb/14 ]

So after diving into the code of the plugin i found out that without a classifier no artifact is attached to the project which is weird, cause all other plugins like maven-jar-plugin, maven-assembly-plugin, maven-shade or rpm-maven-plugin only to mentioned a few of them have a default for classifier (or working without them) which is not good practice for a maven-plugin. So the question why does izpack-maven-plugin behave like that?

For example a good default value for the classifier could be installer ?

Apart from that your example contains configuration parameters which are not supported by the izpack-maven-plugin (descriptorEncoding) furthermore i would assume having much of the parameter using default values which reduces the size of my pom in particular if that plugin claims created it's own lifecycle to reduce the size of the pom.
For example for the descriptorEncoding might be a good idea have a default value like this: {{$

{project.build.sourceEncoding}

.}}

Comment by Rene Krell [ 14/Mar/14 ]

A default artifact is attached, if you set enableOverrideArtifact=true. This is for not automatically override the default artifact. I know projects which just might want to generate an installer file to a dedicated storage and not crowding repositories with the compiled result.
Otherwise there must be used a classifier, to make it different from the default artifact name.
This seems quite consistent to me. Am I wrong?

Since the result is just an installer jar, attaching it as artifact isn't even a natural way. How much use cases do people have to need an installer in another POM's dependency list? It is rather an end product than some library.

If you see mistakes in the implementation, please send a pull request with your suggestion.
Maybe it will be enough to change the default of enableOverrideArtifact true (which I personally wouldn't like that much), but there should be the possibility of preventing attaching of anything.

Another way of getting on with this would be an example project showing the problem for reproducing.





[IZPACK-1030] UserInputPanel checkbox revalidation doesn't trigger panel redisplay Created: 05/Feb/14  Updated: 14/Mar/14  Resolved: 07/Feb/14

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

Type: Bug Priority: Major
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If a user input panel configuration contains a check box that triggers revalidation, fields that are conditionally displayed aren't hidden e.g. given the condition:

    <dynamicvariables>
        <variable name="deploy.tomcat" value="true"/>
    </dynamicvariables>

and the following fragment from userInputSpec.xml:

    <panel id="tomcatpanel" topBuffer="0">
        <field type="check" variable="deploy.tomcat">
            <spec txt="Deploy to Apache Tomcat?" true="true" false="false" revalidate="true"/>
        </field>
        <field type="space"/>
        <field type="staticText" align="left" txt="Enter the Apache Tomcat installation path:"
               conditionid="cond.deploy.tomcat"/>
        <field type="dir" variable="tomcat.home" conditionid="cond.deploy.tomcat">
            <spec size="35" mustExist="true"/>
        </field>
    </panel>

Unchecking the check field does nothing.



 Comments   
Comment by Tim Anderson [ 07/Feb/14 ]

Pull request containing the fix here: https://github.com/izpack/izpack/pull/155





[IZPACK-1029] Add maven archetype for a simple izPack installer skeleton Created: 27/Jan/14  Updated: 27/Jan/14

Status: Open
Project: IzPack
Component/s: Documentation, Maven plugin, Public infrastructures, Showcases
Affects Version/s: 5.0
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Paul Bors 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   

We should have an archetype for izPack that's the simplest working compiled installer (perhaps using all modes of installation) which simply installs a readme file or shortcut to the project's home page.

This should aid people get up and going with new installers as well as easily reporting bugs via a "quick start". A small installer with the least code that demonstrates the bug at hand which can be attached to a Jira ticket.

As an example see Wicket's quick-start at:
http://wicket.apache.org/start/quickstart.html



 Comments   
Comment by Paul Bors [ 27/Jan/14 ]

See the Introduction to archetypes and the Guide to creating archetypes.

The new archetype should be in line with the izPack maven plugin.

I never wrote one before, but If time permits I will attach something to this ticket in the future.





[IZPACK-1028] ShortcutPanel "defaultName" variables are replaced only at the first time Created: 13/Jan/14  Updated: 13/Jan/14

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

Type: Bug Priority: Major
Reporter: Cris Stanza 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   

Variables used on ShortcutPanel to set "defaultName" are being replaced only at the first time the panel is shown.

Steps to reproduce the bug:

  • in you "shortcuts.xml", put something like: <programGroup defaultName="$SOME_VARIABLE"...;
  • the value of $SOME_VARIABLE must be conditionally set in any kind of panel BEFORE ShortcutPanel;
  • after you reach ShortcutPanel, use "previous" button to go back to the panel that changes the value of $SOME_VARIABLE;
  • when you reach ShortcutPanel again, the default name will still show the previous (outdated) value of $SOME_VARIABLE.


Workaround:

--- a/izpack-panel/src/main/java/com/izforge/izpack/panels/shortcut/ShortcutPanel.java
+++ b/izpack-panel/src/main/java/com/izforge/izpack/panels/shortcut/ShortcutPanel.java
@@ -334,6 +334,14 @@ public class ShortcutPanel extends IzPanel implements ActionListener, ListSelect
{
if (shortcutPanelLogic != null)
{
+ try {
+ shortcutPanelLogic.createAndRegisterShortcutsBugFix();
+ if (programGroup != null) {
+ programGroup.setText(shortcutPanelLogic.getSuggestedProgramGroup());
+ }
+ } catch ( Exception exc ) {
+ throw new RuntimeException(exc.getMessage(), exc);
+ }
if (!initialised)
{
initialised = true;

--- a/izpack-panel/src/main/java/com/izforge/izpack/panels/shortcut/ShortcutPanelLogic.java
+++ b/izpack-panel/src/main/java/com/izforge/izpack/panels/shortcut/ShortcutPanelLogic.java
@@ -361,6 +361,18 @@ public class ShortcutPanelLogic implements CleanupClient
addToUninstaller();
}

+ public void createAndRegisterShortcutsBugFix() throws Exception
+ {
+ String groupName = this.groupName;
+ boolean createShortcuts = this.createShortcuts;
+ boolean createDesktopShortcuts = this.createDesktopShortcuts;
+ readShortcutSpec(); // need to re-read the specs now as variable replacement needs to be done
+ analyzeShortcutSpec();
+ this.groupName = groupName;
+ this.createShortcuts = createShortcuts;
+ this.createDesktopShortcuts = createDesktopShortcuts;
+ }
+






[IZPACK-1027] Wrong font on InstallationGroupPanel's description field Created: 13/Jan/14  Updated: 13/Jan/14

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

Type: Bug Priority: Minor
Reporter: Cris Stanza 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   

InstallationGroupPanel's description field is using a wrong/unnecessary content type and it's not using the default font family.


Workaround:

--- a/izpack-panel/src/main/java/com/izforge/izpack/panels/installationgroup/InstallationGroupPanel.java
+++ b/izpack-panel/src/main/java/com/izforge/izpack/panels/installationgroup/InstallationGroupPanel.java
@@ -317,7 +317,7 @@ public class InstallationGroupPanel extends IzPanel
descriptionField.setEditable(false);
descriptionField.setOpaque(false);
descriptionField.setText("<b>Install group description text</b>");
- descriptionField.setContentType("text/html");
+ descriptionField.setFont(getControlTextFont());
descriptionField.setBorder(
new TitledBorder(getString("PacksPanel.description")));
gridBagConstraints = new java.awt.GridBagConstraints();






[IZPACK-1026] No font family definition on SummaryPanel's textArea (JEditorPane) Created: 13/Jan/14  Updated: 13/Jan/14

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

Type: Bug Priority: Minor
Reporter: Cris Stanza 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   

There's no font-family definition on SummaryPanel HTML content. The default html font differs from the default font in the panels.

This html content can be found in class SummaryProcessor.java


Workaround:

--- a/izpack-installer/src/main/java/com/izforge/izpack/installer/util/SummaryProcessor.java
+++ b/izpack-installer/src/main/java/com/izforge/izpack/installer/util/SummaryProcessor.java
@@ -53,8 +53,8 @@ public class SummaryProcessor
buffer.append("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\">\n").append(
"<html>\n" + "<meta http-equiv=\"content-type\" content=\"text/html; charset=UTF-8\">" +
"<head>\n<STYLE TYPE=\"text/css\" media=screen,print>\n").append(
- "h1{\n font-size: 100%;\n margin: 1em 0 0 0;\n padding: 0;\n}\n").append(
- "div.body {\n font-size: 100%;\n margin: 0mm 2mm 0 8mm;\n padding: 0;\n}\n")
+ "h1{\n font-size: 100%;\n margin: 1em 0 0 0;\n padding: 0;\n font-family: \"Arial\";}\n").append(
+ "div.body {\n font-size: 100%;\n margin: 0mm 2mm 0 8mm;\n padding: 0;\n font-family: \"Arial\";}\n")
.append("</STYLE>\n</head>\n<body>\n");
HTML_HEADER = buffer.toString();
}






[IZPACK-1025] Uninstaller window i18n Created: 13/Jan/14  Updated: 13/Jan/14

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

Type: Bug Priority: Major
Reporter: Cris Stanza 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   

Uninstaller window title is not internationalized. The window is created with a hard coded message:

super("IzPack - Uninstaller");


Workaround:

--- a/izpack-uninstaller/src/main/java/com/izforge/izpack/uninstaller/gui/UninstallerFrame.java
+++ b/izpack-uninstaller/src/main/java/com/izforge/izpack/uninstaller/gui/UninstallerFrame.java
@@ -130,7 +130,7 @@ public class UninstallerFrame extends JFrame
public UninstallerFrame(Destroyer destroyer, InstallLog log, Housekeeper housekeeper, Messages messages)
throws Exception
{
- super("IzPack - Uninstaller");
+ super(messages.get("uninstaller.uninstall"));
this.destroyer = destroyer;
this.log = log;
this.housekeeper = housekeeper;






[IZPACK-1024] Console panel implementations use PanelView<Console> instead of PanelView<ConsolePanel> Created: 12/Jan/14  Updated: 14/Mar/14  Resolved: 15/Jan/14

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

Type: Bug Priority: Major
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The ConsolePanel implementations that extend AbstractConsolePanel use Console as the type parameter to PanelView when they should be using ConsolePanel.



 Comments   
Comment by Tim Anderson [ 15/Jan/14 ]

Applied pull request: https://github.com/izpack/izpack/pull/152





[IZPACK-1023] Unable to mask password when IzPack is run under Command line on Windows as well as Linux CUI mode Created: 23/Dec/13  Updated: 23/Dec/13

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

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

Windows 7 64-bit and Redhat Linux (CUI mode)


Number of attachments : 0

 Description   

While working on IzPack (version 4.3.5) installer creation. I have requirement where i need to provide a text box which will take input as password. I have made use of userInputSpec.xml and called into Install.xml.

Following is the code that i have added inside userInputSpec.xml

<field type="space"/>
<field type="password" align="left" variable="password">
<spec>
<pwd txt="Password:" size="25" set=""/>
</spec>
<validator class="com.izforge.izpack.util.NotEmptyValidator" txt="password is a required field"></validator>
</field>

And i am calling this userInputSpec.xml into Install.xml in the following code:

<resources>
<res id="userInputSpec.xml" src="E:..\userInputSpec.xml"/>
</resources>

<panels>
<panel classname="HelloPanel"/>
<panel classname="UserInputPanel" id="Base-Feature">
<help iso3="eng" src="..\Sources\Help.html" />
</panel>
<panel classname="UserInputPanel" id="Base-Feature"/>
<panel classname="InstallPanel"/>
<panel classname="SimpleFinishPanel"/>
</panels>

When i run this installer on Linux (Red Hat Enterprise Linux Server release 5.4 (Tikanga) ) machine in CUI mode (Console Mode, since we have not installed X windows and client will work only in console mode).

The password field is getting displayed when i enter password and in general case it should not show any passwords when users enter. Please let me know on how to go ahead on this.

In addition when i run it on Windows 7 64-bit IzPack Wizard (GUI Mode)will show the userInputSpec Panel with password field and when i enter the text as password, password is getting masked.

When i run the same installer in console mode by passing -Console parameter i am facing same issue i.e. actual characters will be shown instead of masking.

Thanks,
Chetan






[IZPACK-1022] Missing i18n key Created: 20/Dec/13  Updated: 20/Dec/13

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

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

Attachments: PNG File missing-key-ITA.png    
Number of attachments : 1

 Description   

There's no "installer.uninstall.writefailed" key for Italian language (and many others). The key only exists for "eng" and "deu" XML files.






[IZPACK-1021] NullPointerException in SummaryPanel when you have a conditionally unshown panel. Created: 19/Dec/13  Updated: 19/Dec/13

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

Type: Bug Priority: Major
Reporter: Cris Stanza 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   

If you have more than one InstallationGroupPanel (or PacksPanel) defined in your install-script, SummaryPanel will ask for summary - calling .getSummaryBody() - from all InstallationGroupPanels, even from those who had a condition evaluated to false. There will be a NullPointerException in method getSummaryBody() of the panels who weren't shown due the false condition.






[IZPACK-1020] AntActionInstallerListener - add option to map log priority level to the native log levels of Ant Created: 28/Nov/13  Updated: 14/Mar/14  Resolved: 29/Nov/13

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

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

Number of attachments : 0

 Description   

Currently, in AntActionSpec.xml there can be added just two attributes to each AntAction:

  • quiet="true": maps to Ant log level Project.MSG_WARN
  • verbose="true": maps to Ant log level Project.MSG_DEBUG
    Default Ant log level without any of these attributes is Project.MSG_INFO

There is nothing in between, to log on level MSQ_ERR or MSG_VERBOSE.

MSG_DEBUG is a security problem for many cases, because Ant logs the values of all project properties including plain passwords in this case.
MSG_INFO might hide important information for analyzing problems.

Add the possibility of setting the Ant log priority level directly using the new attribute loglevel="[1-5]", directly mapping to Ant log levels. As this attribute conflicts with quiet and verbose it must not be used in combination with them.

Also set MSG_VERBOSE as project level in case of verbose="true" instead of MSG_DEBUG to avoid the mentioned security problem for cases logging of project property values with secret information is not wanted.



 Comments   
Comment by Rene Krell [ 29/Nov/13 ]

Fix offered in pull request https://github.com/izpack/izpack/pull/148

Comment by Rene Krell [ 29/Nov/13 ]

Added attribute loglevel = "error|warning|info|verbose|debug" to antactions.
The previous attributes verbose and quiet have higher priority, if they are used, and "win" over loglevel.





[IZPACK-1019] Make Language Selection write the language selected somwhere so accessible from outside Izpack Created: 26/Nov/13  Updated: 26/Nov/13

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

Type: Improvement Priority: Major
Reporter: Paul Taylor 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   

User selects an install language in the first panel of Izpack.
When I start my application first-time I want to configure it to chose the language selected during install rather than just defaulting to the default locale of the computer as they may be different.

I realize that there is a langcode variable available during the Izpack installation and that could be used by a custom panel to write the langcode to a file but this requires me to write a custom panel, and that is difficult. And as this would be useful for any install it would make much more sense to put it into the core product.






[IZPACK-1018] ConfigurationInstallerListener - installation fails with embedded DTDs in XML Created: 22/Nov/13  Updated: 14/Mar/14  Resolved: 29/Nov/13

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

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

izpack-5.0.0-rc1


Number of attachments : 0

 Description   

There is an ugly messagebox shown in case an embedded DTD file for XML merging in ConfigurationListener cannot be found: "Doctype input does not appear to be valid: <!-- Exception scanning External DTD Subset. True contents of DTD cannot be determined. Processing will continue as XMLInputFactory.IS_VALIDATING == false. -->"

Stacktrace:

SEVERE: java.lang.Exception: com.izforge.izpack.util.xmlmerge.ParseException: org.jdom2.JDOMException: Doctype input does not appear to be valid: <!-- Exception scanning External DTD Subset.  True contents of DTD cannot be determined.  Processing will continue as XMLInputFactory.IS_VALIDATING == false. -->
com.izforge.izpack.api.exception.InstallerException: java.lang.Exception: com.izforge.izpack.util.xmlmerge.ParseException: org.jdom2.JDOMException: Doctype input does not appear to be valid: <!-- Exception scanning External DTD Subset.  True contents of DTD cannot be determined.  Processing will continue as XMLInputFactory.IS_VALIDATING == false. -->
        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:408)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:260)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.run(UnpackerBase.java:242)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.Exception: com.izforge.izpack.util.xmlmerge.ParseException: org.jdom2.JDOMException: Doctype input does not appear to be valid: <!-- Exception scanning External DTD Subset.  True contents of DTD cannot be determined.  Processing will continue as XMLInputFactory.IS_VALIDATING == false. -->
        at com.izforge.izpack.util.config.SingleXmlFileMergeTask.execute(SingleXmlFileMergeTask.java:202)
        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
Caused by: com.izforge.izpack.util.xmlmerge.ParseException: org.jdom2.JDOMException: Doctype input does not appear to be valid: <!-- Exception scanning External DTD Subset.  True contents of DTD cannot be determined.  Processing will continue as XMLInputFactory.IS_VALIDATING == false. -->
        at com.izforge.izpack.util.xmlmerge.merge.DefaultXmlMerge.merge(DefaultXmlMerge.java:233)
        at com.izforge.izpack.util.xmlmerge.config.ConfigurableXmlMerge.merge(ConfigurableXmlMerge.java:85)
        at com.izforge.izpack.util.config.SingleXmlFileMergeTask.execute(SingleXmlFileMergeTask.java:200)
        ... 9 more
Caused by: org.jdom2.JDOMException: Doctype input does not appear to be valid: <!-- Exception scanning External DTD Subset.  True contents of DTD cannot be determined.  Processing will continue as XMLInputFactory.IS_VALIDATING == false. -->
        at org.jdom2.input.stax.DTDParser.parse(DTDParser.java:392)
        at org.jdom2.input.StAXStreamBuilder.process(StAXStreamBuilder.java:149)
        at org.jdom2.input.StAXStreamBuilder.build(StAXStreamBuilder.java:561)
        at com.izforge.izpack.util.xmlmerge.merge.DefaultXmlMerge.merge(DefaultXmlMerge.java:229)
        ... 11 more

This should be catched and replaced by a shorter one. Especially there should be shown the appropriate missing file.

Optionally being able to disable validation at all could be also an option.



 Comments   
Comment by Rene Krell [ 29/Nov/13 ]

Fix offered in pull request https://github.com/izpack/izpack/pull/147





[IZPACK-1017] The LanguageSelection frame (without image attached) isn't wide enough to display the title Created: 14/Nov/13  Updated: 14/Nov/13

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

Type: Bug Priority: Minor
Reporter: Paul Taylor 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 LanguageSelection frame (without image attached) isn't wide enough to display the title, as this is the first screen shown it provides the user with a poor first impression of the application they are installing






[IZPACK-1016] There is an extra space at top of every panel screen between 'Installation of' and 'ProgramName' Created: 14/Nov/13  Updated: 14/Nov/13

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

Type: Bug Priority: Minor
Reporter: Paul Taylor 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   

At the top of the panel screen it says Izpack - Installation of ProgramName
There are two spaces between 'of' and 'ProgramName' , this isn't a user error or problem just with my installer, the Izpack installer itself has the same issue.



 Comments   
Comment by Paul Bors [ 14/Nov/13 ]

I trace this to GUIInstallerContainer#getTitle() line ~127 where the title from the language pack (which already has a tailing space) is appended to the app name as extracted from the installer.xml via the install data:

message = messages.get("installer.title") + " " + installData.getInfo().getAppName();

This can either be fixed by removing the empty string in the concatenation or the tailing string of the language packs for the "installer.title" key default value of:

<str id="installer.title" txt="IzPack - Installation of "/>

@Paul Taylor,

You can fix this in all of the language packs you might be using until this gets fixed in the installer.

Just add this entry to your CustomLangPack.eng.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<!-- The English langpack -->

<izpack:langpack version="5.0"
                 xmlns:izpack="https://izpack.github.io/schema/langpack"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:schemaLocation="https://izpack.github.io/schema/langpack https://izpack.github.io/schema/5.0/izpack-langpack-5.0.xsd">
...
    <!-- Override installer's defaults -->
    <str id="installer.title" txt="Installation of"/> <!-- Notice the space after of has been removed -->
    <str id="installer.madewith" txt=""/>             <!-- If you don't want the annoying "(Made with IzPack - https://izpack.github.io/)" -->
...
</izpack:langpack>

Read more about it in the Confluence at Internationalizing resources.





[IZPACK-1015] Error with the automatic JDK lookup Created: 13/Nov/13  Updated: 27/Mar/14  Resolved: 17/Mar/14

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

Type: Bug Priority: Major
Reporter: Miguel Moquillon Assignee: Tim Anderson
Resolution: Fixed Votes: 1
Labels: 5.0.0-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8 with JDK 1.6


Number of attachments : 0

 Description   

When installing our product with izpack 5.0.0-beta11, we doesn't encounter any problems.
Once izpack updated to the version 5.0.0-rc1, the installation of our product with izpack fails with the following error message (displayed within a popup window that appears two times): "The chosen directory does not contain the required product", just before the displaying of the JDK setting panel.
And we have the following exceptions in the console:
com.izforge.izpack.api.exception.NativeLibException
at com.izforge.izpack.util.os.Win_RegistryHandler.getRegistry(Win_Regist
ryHandler.java:385)
at com.izforge.izpack.util.os.Win_RegistryHandler.getRoot(Win_RegistryHa
ndler.java:288)
at com.izforge.izpack.panels.jdkpath.JDKPathPanel.resolveInRegistry(JDKP
athPanel.java:306)
at com.izforge.izpack.panels.jdkpath.JDKPathPanel.panelActivate(JDKPathP
anel.java:264)
at com.izforge.izpack.installer.gui.InstallerFrame.switchPanel(Installer
Frame.java:610)
at com.izforge.izpack.installer.gui.InstallerFrame$5.switchPanel(Install
erFrame.java:408)
at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:1
28)
at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:3
6)
at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(Abstrac
tPanels.java:418)
at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels
.java:238)
at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigat
or.java:334)
at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigat
or.java:317)
at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.n
avigate(DefaultNavigator.java:552)
at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.a
ccess$100(DefaultNavigator.java:515)
at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler$1
$1.run(DefaultNavigator.java:535)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:672)
at java.awt.EventQueue.access$400(EventQueue.java:81)
at java.awt.EventQueue$2.run(EventQueue.java:633)
at java.awt.EventQueue$2.run(EventQueue.java:631)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessCo
ntrolContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:642)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThre
ad.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.
java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
ad.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)

at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: java.lang.UnsatisfiedLinkError: Failed to load library: COIOSHelper
at com.izforge.izpack.util.Librarian.loadLibrary(Librarian.java:133)
at com.coi.tools.os.izpack.COIOSHelper.addDependant(COIOSHelper.java:102
)
at com.coi.tools.os.izpack.Registry.<init>(Registry.java:53)
at com.izforge.izpack.util.os.Win_RegistryHandler.getRegistry(Win_Regist
ryHandler.java:381)
... 28 more

PS: the problem is also encountered when installing on GNU/Linux (Ubuntu 13.10) but without any trace of the exception in the terminal.

You can download our installer for tests at http://www.silverpeas.org/files/Silverpeas-5.13.1-izpack-5.0.0-beta1-installer.jar



 Comments   
Comment by Sébastien Christy [ 28/Feb/14 ]

I have a similar problem. When entering the JDK panel, the message "The chosen directory does not contain the required product" is displayed and then the panel is displayed with the correct path of the JDK. There is no exception in the console and the message is displayed only one.
My environment is : Windows 7 64 bit with a JDK 7 64 bit and a JDK 6 32 bit.

I have downloaded the source code from GitHub today (from master) and launched the installer in debug mode. In JDKPathPanel.panelActivate(), installData.getVariable("JAVA_HOME") returns "C:\Program Files\Java\jre7" and then checkRequiredFilesExist() checks if this directory contains "lib\tools.jar". This file does not exist in the JRE and an error is emitted. Then resolveInRegistry() is called and it returns "C:\Program Files\Java\jdk1.7.0_15" which passes the check successfully.

Note: in the system environment variables, I have JAVA_HOME=C:\Program Files (x86)\Java\jdk1.6.0_38; in the Java part of the configuration panel, the list of JREs contains only the JRE 7.

I don't know how to go further but I can do more tests and more debug this can help you.

Comment by Sébastien Christy [ 10/Mar/14 ]

I have compared the sources of the 5.0.0-beta11 and 5.0.0-rc1 versions and I have found that the change of behavior between these two versions has been introduced by the following commit: "Refactored PathInputPanel to allow subclasses to override aspects of path validation."

The check that was done in pathIsValid() (in the PathInputPanel class) is now done in checkRequiredFilesExist(). The code is quite the same except that checkRequiredFilesExist() calls emitError() to display an error message if a required file does not exist.

Removing this line (line 404 in PathInputPanel.java on master) would fix this bug but I don't know if this could have any undesired side-effect.

Comment by Tim Anderson [ 10/Mar/14 ]

There's two competing requirements. PathInputPanel needs to display an error message within pathIsValid() if the path is invalid, whereas for JDKPathPanel this should not occur when pathIsValid() is invoked within panelActivate(), but should occur when invoked from isValidated().
I think the easiest approach is to change JDKPathPanel.panelActivate() to call a different method to validate the path. It can't override pathIsValid() as that would change the behaviour of the parent isValidated() method.

Comment by Tim Anderson [ 10/Mar/14 ]

Actually, someone has had a go at fixing this here: https://github.com/izpack/izpack/pull/128

Comment by Tim Anderson [ 17/Mar/14 ]

I've cherry picked the relevant changes into a new pull request here: https://github.com/izpack/izpack/pull/174

Comment by Tim Anderson [ 17/Mar/14 ]

Applied pull request





[IZPACK-1014] Frequent build failures after fresh Codehaus deployments Created: 04/Nov/13  Updated: 14/Mar/14  Resolved: 26/Nov/13

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

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

Number of attachments : 0

 Description   

Frequently, after a new snapshot or release of IzPack have been deployed to Codehaus, I get failures building on it:

10:28:44 [INFO] [izpack:izpack {execution: default-izpack}]
10:28:44 [FATAL ERROR] org.izpack.mojo.IzPackNewMojo#execute() caused a linkage error (java.lang.NoClassDefFoundError) and may be out-of-date. Check the realms:
10:28:45 [FATAL ERROR] Plugin realm = app0.child-container[org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc1]
10:28:45 urls[0] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-maven-plugin/5.0.0-rc1/izpack-maven-plugin-5.0.0-rc1.jar
10:28:45 urls[1] = file:/var/lib/hudson-slave/workspace/my-app/.repository/com/my-company/myapp/myapp-installer-tools/01.05.00/myapp-installer-tools-01.05.00.jar
10:28:45 urls[2] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-api/5.0.0-rc1/izpack-api-5.0.0-rc1.jar
10:29:51 urls[3] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/apache/ant/ant/1.9.2/ant-1.9.2.jar
10:29:51 urls[4] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/apache/ant/ant-launcher/1.9.2/ant-launcher-1.9.2.jar
10:29:51 urls[5] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-tools/5.0.0-rc1/izpack-tools-5.0.0-rc1.jar
10:30:56 urls[6] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/picocontainer/picocontainer/2.14.1/picocontainer-2.14.1.jar
10:30:56 urls[7] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-core/5.0.0-rc1/izpack-core-5.0.0-rc1.jar
10:30:56 urls[8] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-util/5.0.0-rc1/izpack-util-5.0.0-rc1.jar
10:30:57 urls[9] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/jdom/jdom2/2.0.5/jdom2-2.0.5.jar
10:30:57 urls[10] = file:/var/lib/hudson-slave/workspace/my-app/.repository/commons-io/commons-io/2.4/commons-io-2.4.jar
10:30:57 urls[11] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/plexus/plexus-utils/2.0.7/plexus-utils-2.0.7.jar
10:30:57 urls[12] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/apache/maven/shared/maven-filtering/1.0/maven-filtering-1.0.jar
10:30:57 urls[13] = file:/var/lib/hudson-slave/workspace/my-app/.repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
10:30:57 urls[14] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar
10:30:57 urls[15] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-compiler/5.0.0-rc1/izpack-compiler-5.0.0-rc1.jar
10:30:57 urls[16] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-native/5.0.0-rc1/izpack-native-5.0.0-rc1.jar
10:30:57 urls[17] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-panel/5.0.0-rc1/izpack-panel-5.0.0-rc1.jar
10:30:57 urls[18] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-listener/5.0.0-rc1/izpack-listener-5.0.0-rc1.jar
10:30:57 urls[19] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-event/5.0.0-rc1/izpack-event-5.0.0-rc1.jar
10:30:57 urls[20] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-installer/5.0.0-rc1/izpack-installer-5.0.0-rc1.jar
10:30:57 urls[21] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-gui/5.0.0-rc1/izpack-gui-5.0.0-rc1.jar
10:30:57 urls[22] = file:/var/lib/hudson-slave/workspace/my-app/.repository/jakarta-regexp/jakarta-regexp/1.4/jakarta-regexp-1.4.jar
10:30:57 urls[23] = file:/var/lib/hudson-slave/workspace/my-app/.repository/bsf/bsf/2.4.0/bsf-2.4.0.jar
10:30:57 urls[24] = file:/var/lib/hudson-slave/workspace/my-app/.repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
10:30:57 urls[25] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/izpack/izpack-uninstaller/5.0.0-rc1/izpack-uninstaller-5.0.0-rc1.jar
10:30:57 urls[26] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/apache/maven/shared/maven-shared-jar/1.1/maven-shared-jar-1.1.jar
10:30:57 urls[27] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/plexus/plexus-digest/1.0/plexus-digest-1.0.jar
10:30:57 urls[28] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/apache/bcel/bcel/5.2/bcel-5.2.jar
10:30:57 urls[29] = file:/var/lib/hudson-slave/workspace/my-app/.repository/commons-collections/commons-collections/3.1/commons-collections-3.1.jar
10:30:57 urls[30] = file:/var/lib/hudson-slave/workspace/my-app/.repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar
10:30:57 urls[31] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/apache/commons/commons-compress/1.3/commons-compress-1.3.jar
10:30:57 urls[32] = file:/var/lib/hudson-slave/workspace/my-app/.repository/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.jar
10:30:58 urls[33] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/java/net/substance/substance/6.0/substance-6.0.jar
10:30:58 urls[34] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/pushing-pixels/trident/1.2/trident-1.2.jar
10:30:58 urls[35] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/eclipse/swt/win32/win32/x86/3.3.0-v3346/x86-3.3.0-v3346.jar
10:30:58 urls[36] = file:/var/lib/hudson-slave/workspace/my-app/.repository/net/java/dev/laf-widget/laf-widget/5.0/laf-widget-5.0.jar
10:30:58 urls[37] = file:/var/lib/hudson-slave/workspace/my-app/.repository/asm/asm-all/2.2.3/asm-all-2.2.3.jar
10:30:58 urls[38] = file:/var/lib/hudson-slave/workspace/my-app/.repository/net/java/dev/laf-plugin/laf-plugin/1.1/laf-plugin-1.1.jar
10:30:59 urls[39] = file:/var/lib/hudson-slave/workspace/my-app/.repository/be/cyberelf/nanoxml/lite/2.2.3/lite-2.2.3.jar
10:30:59 urls[40] = file:/var/lib/hudson-slave/workspace/my-app/.repository/com/incors/kunstoff-laf/2.0.2/kunstoff-laf-2.0.2.jar
10:30:59 urls[41] = file:/var/lib/hudson-slave/workspace/my-app/.repository/com/jgoodies/looks/2.2.2/looks-2.2.2.jar
10:30:59 [FATAL ERROR] Container realm = plexus.core.maven
10:30:59 urls[0] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/mojo/maven-extensions/wagon-cifs/1.0-alpha-1/wagon-cifs-1.0-alpha-1.jar
10:30:59 urls[1] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.jar
10:30:59 urls[2] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/samba/jcifs/jcifs/1.2.6/jcifs-1.2.6.jar
10:30:59 urls[3] = file:/var/lib/hudson-slave/workspace/my-app/.repository/com/my-company/maven/maven-sca-handler/1.1/maven-sca-handler-1.1.jar
10:30:59 urls[4] = file:/var/lib/hudson-slave/workspace/my-app/.repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
10:30:59 [JENKINS] Archiving /var/lib/hudson-slave/workspace/my-app/trunk/myapp-installer/pom.xml to /var/lib/hudson-server/jobs/my-app/modules/com.my-company.myapp$myapp-installer/builds/2013-11-04_09-56-44/archive/com.my-company.myapp/myapp-installer/04.06.00-SNAPSHOT/myapp-installer-04.06.00-SNAPSHOT.pom
10:30:59 [INFO] ------------------------------------------------------------------------
10:30:59 [ERROR] FATAL ERROR
10:30:59 [INFO] ------------------------------------------------------------------------
10:30:59 [INFO] com/izforge/izpack/api/data/Info
10:30:59 com.izforge.izpack.api.data.Info
10:30:59 [INFO] ------------------------------------------------------------------------
10:30:59 [INFO] Trace
10:30:59 java.lang.NoClassDefFoundError: com/izforge/izpack/api/data/Info
10:30:59  at org.izpack.mojo.IzPackNewMojo.initCompilerData(IzPackNewMojo.java:258)
10:30:59  at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:167)
10:30:59  at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
10:30:59  at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
10:30:59  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
10:30:59  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
10:30:59  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
10:30:59  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
10:30:59  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
10:30:59  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
10:30:59  at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
10:30:59  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
10:30:59  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
10:30:59  at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
10:30:59  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:30:59  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10:30:59  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10:30:59  at java.lang.reflect.Method.invoke(Method.java:597)
10:30:59  at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
10:30:59  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
10:30:59  at hudson.maven.agent.Main.launch(Main.java:185)
10:30:59  at hudson.maven.MavenBuilder.call(MavenBuilder.java:154)
10:30:59  at hudson.maven.Maven2Builder.call(Maven2Builder.java:79)
10:30:59  at hudson.maven.Maven2Builder.call(Maven2Builder.java:55)
10:30:59  at hudson.remoting.UserRequest.perform(UserRequest.java:118)
10:30:59  at hudson.remoting.UserRequest.perform(UserRequest.java:48)
10:30:59  at hudson.remoting.Request$2.run(Request.java:326)
10:30:59  at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
10:30:59  at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
10:30:59  at java.util.concurrent.FutureTask.run(FutureTask.java:138)
10:30:59  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
10:30:59  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
10:30:59  at java.lang.Thread.run(Thread.java:662)
10:30:59 Caused by: java.lang.ClassNotFoundException: com.izforge.izpack.api.data.Info
10:30:59  at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
10:30:59  at java.security.AccessController.doPrivileged(Native Method)
10:30:59  at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
10:30:59  at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
10:30:59  at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
10:30:59  at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
10:30:59  at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
10:30:59  at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
10:31:00  at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
10:31:00  at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
10:31:00  ... 33 more

It would be worth to investigate, whether this cannot be fixed in the POMs or code itself.



 Comments   
Comment by Rene Krell [ 04/Nov/13 ]

One issue I actually found it that the izpack-maven-plugin has not an explicit dependency to izpack-api, which should be corrected.

Comment by Rene Krell [ 28/Nov/13 ]

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





[IZPACK-1013] ProcessPanel - add job switch to ignore failures Created: 04/Nov/13  Updated: 04/Nov/13

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

Type: Improvement 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   

In a ProcessPanel.spec.xml, there should be added an attribute onFailure to either enable generally ignore execution failures or ask the user whether to do so.

Example:

<processing>
  <!-- Abort the installation, same as now (also to be treated as default) -->
  <job name="job1" onFailure="abort">
    ...
  </job>
  <!-- Ignore an execution failure but print a warning to the ProcessPanel log window -->
  <job name="job1" onFailure="warn">
    ...
  </job>
  <!-- Ignore an execution failure without any warning -->
  <job name="job2" onFailure="ignore">
    ...
  </job>
  <!-- Pop up a "The execution of <jobname> failed. Do you wish to continue the installation?" YesAbort messagebox -->
  <job name="job3" onFailure="ask">
    ...
  </job>
</processing>





[IZPACK-1012] Skip InstallPanel execution on pressing Previous from a subsequent panel Created: 04/Nov/13  Updated: 04/Nov/13

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

Type: Bug 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   

Currently it is possible to configure whether the Previous and Next buttons have to set enabled or disabled for the ProcessPanel, for example:

<processing>
  <logfiledir>$INSTALL_PATH/setup/log</logfiledir>
  <job name="...">
    ...
  </job>
  <onFail previous="true" next="false" />
  <onSuccess previous="true" next="true" />
</processing>

In this case, on pressing Previous after a failure, we got to skip the InstallPanel with its progressbars and automatic execution completely to not re-execute it twice, but rather switch to the panel defined as the previous one in front of InstallPanel.






[IZPACK-1011] ConfigurationInstallerListener - <configurable operator="..."> override does not work Created: 03/Nov/13  Updated: 05/Nov/13

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

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

izpack-5.0.0-rc1


Number of attachments : 0

 Description   

The ConfigurationInstallerListener doesn't respect the operator overrides in the following spec:

    <configurationaction order="afterpack">

      <configurable type="options" escape="false" overwrite="true" operator="="
                    tofile="${INSTALL_PATH}/bin/linux-x86-32/wrapper.conf"
                    condition="haveInstallPath+izpack.linuxinstall">
        <entry key="set.JAVA_HOME" value="${java.home.dir}"/>
        <entry key="set.ACTIVEMQ_HOME" value="${INSTALL_PATH}"/>
        <entry key="wrapper.java.command" value="%JAVA_HOME%/bin/java"/>
      </configurable>

      <configurable type="options" escape="false" overwrite="true" operator="="
                    tofile="${INSTALL_PATH}/bin/linux-x86-64/wrapper.conf"
                    condition="haveInstallPath+izpack.linuxinstall">
        <entry key="set.JAVA_HOME" value="${java.home.dir}"/>
        <entry key="set.ACTIVEMQ_HOME" value="${INSTALL_PATH}"/>
        <entry key="wrapper.java.command" value="%JAVA_HOME%/bin/java"/>
      </configurable>

      <configurable type="options" escape="false" operator="="
                    tofile="${INSTALL_PATH}/bin/win32/wrapper.conf"
                    condition="haveInstallPath+izpack.windowsinstall">
        <entry key="set.JAVA_HOME" value="${java.home.dir}"/>
        <entry key="set.ACTIVEMQ_HOME" value="${INSTALL_PATH}"/>
        <entry key="wrapper.java.command" value="%JAVA_HOME%\bin\java.exe"/>
      </configurable>

    </configurationaction>

There are still used the operator defaults for option files, " = " (= embedded in spaces, which does not work for the expected configuration file, because it is not parsed as a property file but in a special manner.



 Comments   
Comment by Rene Krell [ 03/Nov/13 ]

This seems to be due to the usage of the global ini4j-like Config class, com.izforge.izpack.util.config.SingleConfigurableTask.execute():

    @Override
    public void execute() throws Exception
    {
        Config.getGlobal().setHeaderComment(headerComment);
        Config.getGlobal().setEmptyLines(emptyLines);
        Config.getGlobal().setAutoNumbering(autoNumbering);
        Config.getGlobal().setEscape(escape);
        Config.getGlobal().setEscapeNewline(escapeNewLine);
        Config.getGlobal().setOperator(operator);
        checkAttributes();
        readConfigurable();
        readSourceConfigurable();
        patchConfigurable();
        executeNestedEntries();
        writeConfigurable();
    }

which is not thread-safe. Each configurable should receive a real private clone of the global configuration.





[IZPACK-1010] Modify the behaviour of windows uninstall registry key Created: 28/Oct/13  Updated: 28/Oct/13

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

Type: Improvement Priority: Major
Reporter: Chris Stylianou Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: izpack
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Number of attachments : 0

 Description   

On windows, you can define:

<!-- Add registry key on installation -->
<listener classname="RegistryInstallerListener" stage="install">
<os family="windows"/>
</listener>
<!-- Remove registry key on uninstallation -->
<listener classname="RegistryUninstallerListener" stage="uninstall">
<os family="windows"/>
</listener>

This puts a registry key in "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" with the key name "APP_NAME APP_VER".

By including the APP_VER in the key name, it makes it impossible to perform an upgrade when an APP_VER is changed. Could this be excluded from the key name, so just APP_NAME is used?






[IZPACK-1009] Extending OS tag Created: 26/Oct/13  Updated: 26/Oct/13

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

Type: Bug Priority: Major
Reporter: Aleksander Ro?man Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Anywhere


Number of attachments : 0

 Description   

I think that OS tag in xml could be extended. We can set only one name to current OS tag. Which would require to duplicate files in install file, instead of just adding additional names or architectures (this would be main reason for having this).
I have for example files, that need to be installed with amd64 and x86_64 architecture. I need to duplicate this entries, to cover all. Also good option would be to negate architecture or even name.






[IZPACK-1008] Add operating system options to Shortcuts Created: 25/Oct/13  Updated: 25/Oct/13

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

Type: Wish Priority: Minor
Reporter: Aleksander Ro?man Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any


Number of attachments : 0

 Description   

Shortcuts should also have option to be "installed" only on specific platform, something like options in Packs about Operating system.






[IZPACK-1007] Improve the implementation of the FileUtils.createNewFile() methods to call getAbsoluteFile() on the installation path Created: 25/Oct/13  Updated: 25/Oct/13

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

Type: Improvement Priority: Minor
Reporter: Paul Bors 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 my own version of the InstallPanel and made use of the FileUtils as follows:

    ...
    String chosenPath = pathSelectionPanel.getPath();
    if(!chosenPath.isEmpty()) {
        FileUtils fileUtils = FileUtils.getFileUtils();
        File path = new File(chosenPath);
        try {
            // Check that the path can be created
            if(!path.exists()) {
                fileUtils.createNewFile(path, true);
            }
    ...

However, when the user inputs "Test" in the text box in order to use a relative folder I get a NPE:

java.lang.NullPointerException
  at com.izforge.izpack.util.file.FileUtils.createNewFile(FileUtils.java:831)
  at com.test.installer.panels.target.TargetPanel.isValidated(TargetPanel.java:44)
  ...

Where TargetPanel.java:44 is fileUtils.createNewFile(path, true); from above example of my own InstallPanel.

Can we change the way the FileUtils work by calling f.getAbsoluteFile() such as:

    /**
     * Create a new file, optionally creating parent directories.
     *
     * @param f      the file to be created.
     * @param mkdirs <code>boolean</code> whether to create parent directories.
     * @return true if the file did not exist already.
     * @throws IOException on error.
     */
    public boolean createNewFile(File f, boolean mkdirs) throws IOException
    {
        File parent = f.getAbsoluteFile().getParentFile(); // FIXME: Make use of the absolute file for the parent
        if (mkdirs && !(parent.exists())) // This throws NPE unless we use absolute file for the parent
        {
            parent.mkdirs();
        }
        return f.createNewFile();
    }





[IZPACK-1006] Improve the progress indicator handling - add progress indication also to uninstaller creation and listener execution. Created: 23/Oct/13  Updated: 23/Oct/13

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

Type: Task 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

Issue Links:
Supercedes
supercedes IZPACK-1002 Generate the Uninstaller during the I... Open
Number of attachments : 0

 Description   

During the InstallPanel execution, if there are used listener execution and uninstaller creation, it seems like the installer would be hanging, if the operations take some more time. There is no API and method to integrate listeners and uninstaller generation with the progressbars of the installation.
This gets to be divided into subissues.






[IZPACK-1005] Modularization of installers, reducing installer size, automatically add certain default jars Created: 23/Oct/13  Updated: 23/Oct/13

Status: Open
Project: IzPack
Component/s: Build, Compiler, Installer
Affects Version/s: None
Fix Version/s: 6.0

Type: Task 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 will be a big deal, to be divided into subissues.

Background:

  • Currently, there is still too much unused code compiled into an installer jar, making the overhead big. There should be compiled in as less as possible code, depending on the used conditions, validators etc. and their particular dependencies, maybe also with Maven ways (but this would be a disadvantage for users of the standalone compiler and izpack Ant task, better would be to find the rigth dependencies at the compile time of a final installer). So divide the inclusion into the core code absolutely necessary for an installer and add-ons, still not specifying how in particular.
  • Currently, it is not very comfortable to find the right jars to add using the <jar> tag. For instance AntActionInstallerListener requires to be explicitely added ant.jar and ant-launcher.jar and this optimally for the Ant version it has been built against. The required versions might change with new IzPack releases. Better would be to make this inclusion implicit and check for accidental conflicts when including them twice.





[IZPACK-1004] Add the possibility of skipping installation actions just for generating the record of installations for the future Created: 23/Oct/13  Updated: 23/Oct/13

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

Type: Improvement 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   

It would be nice to have a flag for skipping the execution of the InstallPanel, ProcessPanel and all listeners, but just entering the user input data and generating a record for future installer executions somewhere else. Thus, producing an auto-install.xml without actually installing.






[IZPACK-1003] Add a flag to the installer descriptor to make creation of auto-install.xml optional Created: 23/Oct/13  Updated: 23/Oct/13

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

Type: Improvement 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 would be nice for being able to switch off the visibility of the mask for generating a record of the installation. Or alternatively, after a code review, document it, if this feature already xists and is hidden






[IZPACK-1002] Generate the Uninstaller during the InstallPanel Created: 22/Oct/13  Updated: 23/Oct/13

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

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

Issue Links:
Supercedes
is superceded by IZPACK-1006 Improve the progress indicator handli... Open
Number of attachments : 0

 Description   

Is it possible to get the uninstaller to generate itself as part of the InstallPanel process?

I ask this because currently the uninstaller is generated at the end of the installation, which can take several minutes and gives no indication to the user that this process is happening in the background.

If the uninstaller was to be generated at the end of the InstallPanel, then the progress bars can give the user feedback of what is happening.

If this is not possible, could a progress bar atleast be shown to inform the user that the uninstaller is being generated (with a description of the finish page that this is about to happen).



 Comments   
Comment by Rene Krell [ 23/Oct/13 ]

The problem is rather the handling of the progress indicator in common.
This is not just an issue for generating an uninstaller, but also, for executing the listeners, for example, and should be solved in common to always see the installer is still doing its job. This will be a bigger issue for some next major version.





[IZPACK-1001] Missing console installer translations for most languages - please help Created: 19/Oct/13  Updated: 19/Oct/13

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

Type: Task Priority: Major
Reporter: Rene Krell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
? Remaining Estimate: 2 hours Remaining Estimate: Not Specified
? Time Spent: Not Specified Time Spent: Not Specified
? Original Estimate: 2 hours Original Estimate: Not Specified

Issue Links:
Supercedes
supercedes IZPACK-988 Console mode installation (Linux) - n... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
IZPACK-1092 Support for Spanish translation Sub-task Reopened Rene Krell  
Number of attachments : 0

 Description   

The following translations get to be translated in more languages, please help if you are a native speaker:

<!-- ConsolePrompt strings -->
<str id="ConsolePrompt.okCancel" txt="Eingabe O (OK), A (Abbrechen): "/>
<str id="ConsolePrompt.yesNo" txt="Eingabe J (Ja), N (Nein): "/>
<str id="ConsolePrompt.yesNoCancel" txt="Eingabe J (Ja), N (Nein), A (Abbrechen): "/>
<str id="ConsolePrompt.ok" txt="O"/>
<str id="ConsolePrompt.cancel" txt="A"/>
<str id="ConsolePrompt.yes" txt="J"/>
<str id="ConsolePrompt.no" txt="N"/>

<!-- ConsoleInstaller strings -->
<str id="ConsoleInstaller.continueQuitRedisplay" txt="Eingabe 1 (Weiter), 2 (Beenden), 3 (Erneut anzeigen)"/>
<str id="ConsoleInstaller.acceptRejectRedisplay" txt="Eingabe 1 (Bestätigen), 2 (Ablehnen), 3 (Erneut anzeigen)"/>
<str id="ConsoleInstaller.redisplayQuit" txt="Eingabe 1 (Erneut anzeigen), 2 (Beenden)"/>





[IZPACK-1000] Create console implementation of SummaryPanel Created: 18/Oct/13  Updated: 19/Oct/13  Resolved: 18/Oct/13

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

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

Issue Links:
Supercedes
supercedes IZPACK-871 Console installation support for all ... Reopened
Number of attachments : 0




[IZPACK-999] Create console implementation of SimpleFinishPanel Created: 18/Oct/13  Updated: 19/Oct/13  Resolved: 18/Oct/13

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

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

Issue Links:
Supercedes
supercedes IZPACK-871 Console installation support for all ... Reopened
Number of attachments : 0




[IZPACK-998] Create console implementation of ShortcutPanel Created: 18/Oct/13  Updated: 19/Oct/13  Resolved: 18/Oct/13

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

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

Issue Links:
Supercedes
supercedes IZPACK-871 Console installation support for all ... Reopened
Number of attachments : 0




[IZPACK-997] Create console implementation of HTMLInfoPanel Created: 18/Oct/13  Updated: 19/Oct/13  Resolved: 18/Oct/13

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

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

Issue Links:
Supercedes
supercedes IZPACK-871 Console installation support for all ... Reopened
Number of attachments : 0




[IZPACK-996] Create console implementation of HTMLHelloPanel Created: 18/Oct/13  Updated: 19/Oct/13  Resolved: 18/Oct/13

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

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

Issue Links:
Supercedes
supercedes IZPACK-871 Console installation support for all ... Reopened
Number of attachments : 0




[IZPACK-995] installation.dtd missing information about "run-privileged" Created: 18/Oct/13  Updated: 18/Oct/13

Status: Open
Project: IzPack
Component/s: Compiler, Utilities
Affects Version/s: 4.3.5
Fix Version/s: None

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

All platforms


Number of attachments : 0

 Description   

The installation.dtd located in sr/dtd/installation.dtd is missing the information about the element 'run-privileged' in the 'info' element. A XML validation will therefore fail when using the elevation mechanism in an install.xml file.



 Comments   
Comment by Alex [ 18/Oct/13 ]

Added github pull request for fix. #144





[IZPACK-994] Debugging and/or Headless mode for privileged installations Created: 18/Oct/13  Updated: 18/Oct/13

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

Type: Wish Priority: Major
Reporter: Alex Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All platforms


Number of attachments : 0

 Description   

IT would really help to have Debugging and/or a console mode when running an installer in privileged mode.

Currently, the elevation is done by starting a seperate process (not java) that in turn starts java with privileges. Due to this feature, the output of the java process is lost to the void of the intermediate process to start up java which has already died at that moment. (At least on Windows..)

It would also be nice to have start-up parameters passed on to the elevated process, i.e. "-console". This posts the problem that headless mode only works with interaction on the console, which is not available due to the intermediate process.

Supposed solution: Find a way to start an elevated Java Process directly in the current Process to gain full control of it.






[IZPACK-993] Dynamic variables - add configuration attribute to control whether to escape backslashes when reading from option and INI files Created: 15/Oct/13  Updated: 19/Oct/13  Resolved: 15/Oct/13

Status: Resolved
Project: IzPack
Component/s: Compiler, 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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, it is not possible to read Windows filenames with backslashes from option or INI file entries into a dynamic variable.

Example:

test.properties:

my.path = C:\dir\file

install.xml:

<dynamicvariables>
  <variable name="my.path.var" checkonce="true" file="${INSTALL_PATH}/test.properties" type="options" key="my.path"/>
<dynamicvariables>

results in assigning the variable my.path.var the value
C:dirfile
instead of the original value.

The reason is the automatic escape handling of the core utilities for reading those files.

For dynamic variables, add an option
escape=true|false
to the variable element in <dynamicvariables> to override this behavior.
Default: true (like before to not break existing environments - backslashes are escaped)



 Comments   
Comment by Rene Krell [ 15/Oct/13 ]

Solved in pull request https://github.com/izpack/izpack/pull/143





[IZPACK-992] ConfigurationInstallerListener - Update to JDom 2, increase XML parser speed Created: 13/Oct/13  Updated: 19/Oct/13  Resolved: 15/Oct/13

Status: Resolved
Project: IzPack
Component/s: 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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by IZPACK-989 ConfigurationInstallerListener - XML ... Resolved
Number of attachments : 0

 Description   

There are the following main reasons for updating to JDOM 2:

  • Be prepared for XPath 2.0 in future (although jdom 2.0 still supports just Jaxen with XPath 1.0, but 2.1 should support more frameworks).
  • Increase the speed of XML parsing by using the JRE StaX stream parser instead of SaxBuilder.
  • Xerces XML parser no longer required for using XML merging, leave optional.
  • Use a maintained version.

The Jaxen dependency version will be automatically increased to 1.1.4. Jaxen is optional just in case XPath 1.0 queries will be used along with XML merging in ConfigurationInstallerListener.






[IZPACK-991] ConfigurationInstallerListener - result of xml merge should be grouped by element name Created: 11/Oct/13  Updated: 19/Oct/13  Resolved: 15/Oct/13

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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by IZPACK-989 ConfigurationInstallerListener - XML ... Resolved
Number of attachments : 0

 Description   

The ConfigurationInstallerListener can currently deliver something like that as result:

<a>
  <b name="name1"/>
  <c>
    <d id="id1"/>
  </c>
  <b name="name2"/>
<a>

This is syntactically correct but in several environments which rely on grouped elements this can cause problems.
Furthermore it is confusing alternate element names at one and the same level.

The order of elements should be grouped by the element name.






[IZPACK-990] Merge action properties do not work - always full XML merge assumed for each xpath Created: 11/Oct/13  Updated: 19/Oct/13  Resolved: 15/Oct/13

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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by IZPACK-989 ConfigurationInstallerListener - XML ... Resolved
Number of attachments : 0

 Description   

Example:

ConfigurationActionsSpec.xml resource:

<configurable type="xml" cleanup="true"
              patchfile="${INSTALL_PATH}/config/resources.xml.configbak"
              tofile="${INSTALL_PATH}/config/resources.xml">
  <xpathproperty key="action.default" value="COMPLETE"/>
  <xpathproperty key="xpath.path1" value="/el1/el2">
  <xpathproperty key="matcher.path1" value="NAME_ATTRIBUTE">
  <xpathproperty key="action.path1" value="COMPLETE">
  <xpathproperty key="xpath.path2" value="/el1/el3/el4">
  <xpathproperty key="matcher.path2" value="ATTRIBUTE">
  <xpathproperty key="action.path2" value="DELETE">
</configurable>

The several action.path<number> configuration properties don't have any effect, FULLMERGE is assumed implicitely by mistake.
The same happens for the matchers.






[IZPACK-989] ConfigurationInstallerListener - XML merge fixes and improvements Created: 11/Oct/13  Updated: 19/Oct/13  Resolved: 15/Oct/13

Status: Resolved
Project: IzPack
Component/s: Documentation, 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: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
supercedes IZPACK-990 Merge action properties do not work -... Resolved
supercedes IZPACK-991 ConfigurationInstallerListener - resu... Resolved
supercedes IZPACK-992 ConfigurationInstallerListener - Upda... Resolved
Number of attachments : 0

 Description   

I've collected a couple of pitfalls in using the ConfigurationInstallerListener with merging XML files. This is a task, which will collect several subissues regarding this.



 Comments   
Comment by Rene Krell [ 15/Oct/13 ]

Solved in pull request: https://github.com/izpack/izpack/pull/142





[IZPACK-988] Console mode installation (Linux) - no translations are shown if LC_CTYPE="de_DE.UTF-8" Created: 10/Oct/13  Updated: 19/Oct/13  Resolved: 10/Oct/13

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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by IZPACK-1001 Missing console installer translation... Open
Number of attachments : 0

 Description   

After setting the Linux environment to german localization:

export LC_CTYPE="de_DE.UTF-8"

there are no translations available for basic console mode installer prompts. Example: "ConsoleInstaller.continueQuitRedisplay" instead of "Press 1 to continue, 2 to quit, 3 to redisplay":

java -jar installer.jar -console
31.07.2013 15:59:03 INFO: Logging initialized at level 'INFO'
31.07.2013 15:59:03 INFO: Commandline arguments:
31.07.2013 15:59:05 INFO: Detected platform: linux,version=3.0.13-0.27-default,arch=x64,symbolicName=null,javaVersion=1.6.0
Willkommen zur Installation von My Great Application!
Der(die) Autor(en) dieser Software ist(sind):
 - My Company <info@my-company.com>
Die Homepage fÃŒr diese Software: http://www.my-company.com

ConsoleInstaller.continueQuitRedisplay

After setting the localization to english:

export LC_CTYPE="en_US.UTF-8"

the correct english message is displayed.



 Comments   
Comment by Rene Krell [ 10/Oct/13 ]

This might concern many other translation, just investigated for the german language so far.
There is a missing german translation for the console installer prompts.

Comment by Rene Krell [ 10/Oct/13 ]

Fix available in pull request https://github.com/izpack/izpack/pull/141





[IZPACK-987] Cross-check existance of referenced resources from listeners at compile time Created: 30/Sep/13  Updated: 30/Sep/13

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

Type: Improvement 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   

Several resources are referenced from listeners like for example AntActionListener:

<antactions>
  <pack name="MyApp Core">

    <antcall order="afterpacks" buildresource="antBuild_Postinstall.xml">
        ...
    </antcall>
  ..

If the resource antBuild_Postinstall.xml isn't defined as <res> element in install.xml, the compiler doesn't complain, but the installation fails, later:

Sep 30, 2013 4:43:43 PM SEVERE: I/O error during writing resource antBuild_Postinstall.xml to a temporary buildfile

The compiler should check the definition of referenced resources from the listener descriptors and fail on the first mismatch to not generate nonfunctional installation jars.






[IZPACK-986] DynamicInstallerRequirements are broken Created: 27/Sep/13  Updated: 02/Apr/15

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

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

Patch Submitted:
Yes
Number of attachments : 0

 Description   

DynamicInstallerRequirements are broken in accordance with the current online documentation. The schema instructs that one should use the attribute "status" with the declaration of the requirements, but the official documentation says to use Status. The source code clearly looks for severity however.

Not to mention that the documentation regarding how to use the dynamic installer requirements (as a validator child of a panel) is just not right.

The listed example shows an interface. I dug through the container code and no where is there a registered mapping between DynamicInstallerRequirementValidator and DynamicInstallerRequirementValidatorImpl, so of course the installer throws an exception that the interface cannot be instantiated.

I tried changing the classname attribute to com.izforge.izpack.core.data.DynamicInstallerRequirementValidatorImpl, but then I received a PicoContainer error about an unmet dependency on the DataValidator.Status class.

I am creating a patch for the first issue by changing the the parsed "severity" to "status" in accordance with the published schema.

As for the second issue, I spent a few hours digging through the container logic, but I could not find anywhere where interface->concrete class mappings actually were in use yet, so I'm not sure where to inject them. And since the affected implementation has no default constructor it requires a factory similar to the one in CompilerConfig.

A note: leaving the <validator classname="DynamicInstallerRequirementValidator"/> out of the panel declaration causes the dynamic installer requirement to be executed anyway after the first attempt to hit the Next button. Maybe that's the desired behavior? I did find that these defined dynamic requirements are checked as conditions, validating a panel prior to transition. Perhaps the documentation is just out of date?



 Comments   
Comment by Andrew Kutz [ 27/Sep/13 ]

FWIW, this is the stack trace when using the DynamicInstallerRequirementValidatorImpl:

Exception in thread "AWT-EventQueue-0" com.izforge.izpack.api.exception.IzPackException: com.izforge.izpack.api.exception.ContainerException: org.picocontainer.injectors.AbstractInjector$UnsatisfiableDependenciesException: com.izforge.izpack.core.data.DynamicInstallerRequirementValidatorImpl has unsatisfied dependency 'class com.izforge.izpack.api.installer.DataValidator$Status' for constructor 'public com.izforge.izpack.core.data.DynamicInstallerRequirementValidatorImpl(java.lang.String,com.izforge.izpack.api.installer.DataValidator$Status,java.lang.String)' from org.picocontainer.DefaultPicoContainer@6cdb8b48:3<[Immutable]:org.picocontainer.DefaultPicoContainer@2261adb8:48<|
  at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:64)
  at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
  at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:727)
  at java.awt.EventQueue.access$200(EventQueue.java:103)
  at java.awt.EventQueue$3.run(EventQueue.java:688)
  at java.awt.EventQueue$3.run(EventQueue.java:686)
  at java.security.AccessController.doPrivileged(Native Method)
  at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
  at java.awt.EventQueue.dispatchEvent(EventQueue.java:697)
  at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
  at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
  at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
  at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
Caused by: com.izforge.izpack.api.exception.ContainerException: org.picocontainer.injectors.AbstractInjector$UnsatisfiableDependenciesException: com.izforge.izpack.core.data.DynamicInstallerRequirementValidatorImpl has unsatisfied dependency 'class com.izforge.izpack.api.installer.DataValidator$Status' for constructor 'public com.izforge.izpack.core.data.DynamicInstallerRequirementValidatorImpl(java.lang.String,com.izforge.izpack.api.installer.DataValidator$Status,java.lang.String)' from org.picocontainer.DefaultPicoContainer@6cdb8b48:3<[Immutable]:org.picocontainer.DefaultPicoContainer@2261adb8:48<|
  at com.izforge.izpack.core.container.AbstractContainer.getComponent(AbstractContainer.java:135)
  at com.izforge.izpack.core.factory.DefaultObjectFactory.create(DefaultObjectFactory.java:74)
  at com.izforge.izpack.core.factory.DefaultObjectFactory.create(DefaultObjectFactory.java:102)
  at com.izforge.izpack.installer.panel.AbstractPanelView.getView(AbstractPanelView.java:193)
  at com.izforge.izpack.installer.gui.IzPanels.initialise(IzPanels.java:80)
  at com.izforge.izpack.installer.gui.InstallerFrame.buildGUI(InstallerFrame.java:402)
  at com.izforge.izpack.installer.gui.InstallerController$1.run(InstallerController.java:35)
  at com.izforge.izpack.installer.gui.InstallerController.run(InstallerController.java:64)
  at com.izforge.izpack.installer.gui.InstallerController.buildInstallation(InstallerController.java:30)
  at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:60)
  ... 14 more
Caused by: org.picocontainer.injectors.AbstractInjector$UnsatisfiableDependenciesException: com.izforge.izpack.core.data.DynamicInstallerRequirementValidatorImpl has unsatisfied dependency 'class com.izforge.izpack.api.installer.DataValidator$Status' for constructor 'public com.izforge.izpack.core.data.DynamicInstallerRequirementValidatorImpl(java.lang.String,com.izforge.izpack.api.installer.DataValidator$Status,java.lang.String)' from org.picocontainer.DefaultPicoContainer@6cdb8b48:3<[Immutable]:org.picocontainer.DefaultPicoContainer@2261adb8:48<|
  at org.picocontainer.injectors.ConstructorInjector.getGreediestSatisfiableConstructor(ConstructorInjector.java:197)
  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)
  ... 23 more

Comment by Andrew Kutz [ 27/Sep/13 ]

I submitted a pull request for the severity/status issue at https://github.com/izpack/izpack/pull/140.

Comment by Rene Krell [ 27/Sep/13 ]

I can't see the difference between documentation and the source code from here. In both, documentation and source code "severity" is used. I see no reason to change something.
Looking at the original repository development HEAD:
https://github.com/izpack/izpack/blob/master/izpack-compiler/src/main/java/com/izforge/izpack/compiler/CompilerConfig.java#L2411
the attribute is still the documented one.
Your diff comes from your local one.

Comment by Rene Krell [ 27/Sep/13 ]

I believe I know what you mean now - the XSD validation fails due to a bad XSD. In this case, the XSD should be fixed, not the interface changed, IMHO.
Thus, the problem is in this line:
https://github.com/izpack/izpack/blob/master/izpack-dist/src/main/resources/schema/5.0/izpack-installation-5.0.xsd#L162

Comment by Andrew Kutz [ 27/Sep/13 ]

Yes, that is what I mean. I guess I always defer to the schema first. I'm happy for whichever to be changed; it's not my code : ) Like I said, when in doubt, I refer to the contract.

Comment by Andrew Kutz [ 27/Sep/13 ]

Feel free to close my pull request. Will you be updating the schema, or should I and then issue a second pull request? Also, I updated the WIKI to note the discrepancy. When either decision has been made I will update the WIKI to note the accepted patch.

Comment by Rene Krell [ 27/Sep/13 ]

You can repush the corrected changes, the pull request will be automatically refreshed. No need to close it. Just leave the actually effective changes, revert the one from CompilerConfig to the latest state of izpack/izpack.
In any case, a good catch, this is a bug. And the code is community code, not a personal one

Comment by Andrew Kutz [ 27/Sep/13 ]

All good regarding the schema, but it still doesn't solve the problem of why the dynamic installer requirements are not working the way they are advertised.

  1. I cannot add the DynamicInstallerRequirementValidator to the panel.
  2. If I define them simply in the dynamicinstallerrequirements section they are still evaluated, but logically in opposition to the desired behavior. That is if they are false they prevent validation of a panel's transition. The documentation states that if they are true (a condition that must not happen) they should be triggered. For now they are being treated as normal validators it seems.

I believe the problem starts here AbstractInstallDataProvider.java#L383, where the dynamic requirements are being handled as simply dynamic conditions.

It continues to AbstractPanelView.java#L341.

Finally though the root of the problem, I think, is probably the result of some copy/paste logic. DynamicInstallerRequirementValidatorImpl.java#L58 has the requirement validating if the condition is NOT true. And the documentation states that these conditions are triggered when the condition evaluates to true.

What would you like changed? The documentation or the code?

Per the docs:

The severity the validator should apply in case of the condition gets true.

Comment by S Chaudhari [ 29/Mar/15 ]

Currently in rc5 version we get below error, any idea how to fix this

Adding panel: JDKPathPanel_4 :: Classname : com.izforge.izpack.panels.jdkpath.JDKPathPanel
-> Fatal error :
Class 'DynamicInstallerRequirementValidator' not found
com.izforge.izpack.api.exception.IzPackClassNotFoundException: Class 'DynamicInstallerRequirementValidator' not found
at com.izforge.izpack.compiler.util.CompilerClassLoader.loadClass(CompilerClassLoader.java:110)
at com.izforge.izpack.compiler.CompilerConfig.addPanels(CompilerConfig.java:1651)
at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:332)
at com.izforge.izpack.compiler.bootstrap.CompilerLauncher.main(CompilerLauncher.java:52)
Caused by: java.lang.ClassNotFoundException: DynamicInstallerRequirementValidator
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at com.izforge.izpack.compiler.util.CompilerClassLoader.findClass(CompilerClassLoader.java:136)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at com.izforge.izpack.compiler.util.CompilerClassLoader.loadClass(CompilerClassLoader.java:98)





[IZPACK-985] The UserInputPanel's RadioButton field's individual choices don't actually respect their associateed conditionid Created: 26/Sep/13  Updated: 27/Sep/13  Resolved: 27/Sep/13

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

Type: Bug Priority: Major
Reporter: Andrew Kutz Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: Condition, RadioButton, UserInputPanel
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File trace.png    
Issue Links:
Related
is related to IZPACK-972 UserInputPanel - Add conditionId attr... Resolved
Number of attachments : 1

 Description   

Per the documentation you should be able to do something like this:

<userInput>
    <panel id="userinputpanel.installtype">
        <field  type="radio"
                variable="installtype">
            <spec>
                <description
                    id="installtype.panel.field.description"
                    txt="Select the installation type" />
                <choice
                    txt="Local Installation"
                    id="installtype.panel.radio.choice.local.label"
                    value="local"
                    conditionid="izpack.beosinstalls" />
                <choice
                    txt="Remote Installation"
                    id="installtype.panel.radio.choice.remove.label"
                    value="remote" />
            </spec>
        </field>
    </panel>
</userInput>

The first choice should be disabled on any system since I do not believe that izpack has a built-in condition for detecting BeOS.

On my system (see attached image), with TRACE enabled, that condition does not exist and yet the choice is still enabled.

That's because at the last tagged release of 5.0, beta 11, no where in UserInputPanel.java, where the radio buttons are processed, does the radio button actually check its condition.

Now, the UserInputPanel on the master branch of izpack appears to no longer update its fields in that class. Instead it uses a GUIFieldFactory which in turn instantiates a GUIRadioField.

The question becomes - where should the patch be applied? On a hotfix off the beta 11 tag, or on a branch of master? I've found so much stuff in beta 11 to be broken or not work according to the WIKI that I'm tempted to build master and incorporate my patches there.

What are your thoughts?



 Comments   
Comment by Andrew Kutz [ 27/Sep/13 ]

I've confirmed that this is fixed in the 5.0.0 RC1 after building it from source.

Comment by Andrew Kutz [ 27/Sep/13 ]

This works in 5.0.0 RC1 after I built it from source and changed my installer's dependency to match the snapshot version.

Comment by Rene Krell [ 27/Sep/13 ]

Yes, at the moment try always the latest development version, the documentation is mostly updated along with the snapshot deployments made to Codehaus snapshots.
The feature has been implemented recently see IZPACK-972.





[IZPACK-984] AntActionInstallerListener - add working directory attribute to <antaction> Created: 24/Sep/13  Updated: 19/Oct/13  Resolved: 25/Sep/13

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

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

Number of attachments : 0

 Description   

In some cases, it is useful to override the basedir set in specific Ant buildfiles or simply redirect the buildfile resource to a certain directory of interest. The Ant API allows this also explicitly.

Make it possible to use in ActActionSpec.xml constructs like:

<antcall dir="..."/>

for doing so.



 Comments   
Comment by Rene Krell [ 25/Sep/13 ]

Solved in https://github.com/izpack/izpack/pull/139





[IZPACK-983] IzPack 5 does not provide standalone-compiler.jar Created: 23/Sep/13  Updated: 23/Sep/13

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

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

Windows, Linux


Number of attachments : 0

 Description   

The standalone-compiler.jar file is not provided as part of the IzPack 5 distribution. Our project has been using the standalone-compiler.jar and izpack Ant task that is provided in version 4.x within the project's Ant build scripts. If we upgrade to 5, this will break our current build.

If the intent is to no longer provide standalone-compiler.jar, please provide documentation on how one can use IzPack 5 within Ant build scripts that does not require the use of Maven.

Sample of how our project calls izpack today:

  <target name="izpack-installer"
          depends="izpack-xml,build-install-ext,create-install-tree">
    <taskdef name="izpack"
             classname="com.izforge.izpack.ant.IzPackTask">
      <classpath>
        <pathelement location="${project.build.rc-install}"/>
        <pathelement
location="${project.build.lib-install}/${install-ext.jarfile.name}"/>
        <pathelement location="${contrib.izpack.dir}/standalone-compiler.jar"/>
      </classpath>
    </taskdef>
    <mkdir dir="${project.dist}"/>
    <izpack input="${project.build}/izpack.xml"
            output="${project.dist}/${project.name.brief}-${project.version}-install.jar"
            installerType="standard"
            inheritAll="true"
            basedir="${project.build.install}"/>
  </target>





[IZPACK-982] Improve previous installation detection and handling in CheckedHelloPanel Created: 20/Sep/13  Updated: 24/Sep/13

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

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

Testcase included: yes
Patch Submitted:
Yes
Number of attachments : 0

 Description   

To improve the handling of subsequent (i.e. upgrade) installations, new features can be added to CheckedHelloPanel. Config params could switch the behaviour of the panel. Instead of optionally installing a new copy with a unique uninstall key, the option to uninstall the existing copy could be given. For example:

  • uninstallexisting
    instead of allowing multiple copies, installer optionally runs uninstall command
  • keepexistinginstallpath
    where an existing installation is detected, optionally set INSTALL_PATH to the existing installation path
  • fuzzymatch
    instead of using APP_NAME + APP_VER to determine the registry uninstall key name, just use startsWith(APP_NAME)

This addresses issues raised previously in IZPACK-655. See also IZPACK-981.



 Comments   
Comment by Daniel Abson [ 23/Sep/13 ]

The fuzzymatch functionality is less straightforward than I thought. It's easy to use the parameter to modify the registry search (see current state of GitHub branch), but sending the name of the matched install key back to get the installation directory and the uninstaller command would be more of a hack. I'd like to make the 'previous version detector' pluggable, which would also allow for non-Windows detection methods in the future. The current functionality would be something like RegistryInstallationFinder, and the new 'fuzzymatch' search would be implemented by a subclass FuzzyRegistryInstallationFinder.

An InstallationFinder interface would define basic behaviour.

  • isInstalled - returns boolean (i.e. found/not found)
  • getInstallationPath - returns String (File?)
  • getUninstaller - returns String (File?)
  • getUninstallerCommand - returns String[]

AbstractInstallationFinder would provide a skeleton implementation, including

  • initialise - looks for previous versions, install path, uninstaller, etc; called from constructor




[IZPACK-981] Allow files to be excluded from uninstaller Created: 20/Sep/13  Updated: 23/Sep/13

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

Type: New Feature Priority: Major
Reporter: Daniel Abson 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   

Add an attribute uninstall="yes|no|optional" to all children of <pack>. The default "yes" is the current behaviour where everything is uninstalled. Setting "no" would always preserve the installed file(s); setting "optional" would give the user the choice in the uninstaller to "Remove all files?". See also IZPACK-982.



 Comments   
Comment by Daniel Abson [ 23/Sep/13 ]

Actually, this duplicates IZPACK-631.





[IZPACK-980] Compiler doesn't parse <refpacks> - missing XSD for refpack files Created: 16/Sep/13  Updated: 16/May/14  Resolved: 16/May/14

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: None
? Remaining Estimate: Not Specified Remaining Estimate: Not Specified
? Time Spent: Not Specified Time Spent: Not Specified
? Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
IZPACK-1087 Update https://izpack.github.io/schema/5.0/i... Sub-task Resolved Rene Krell  
Number of attachments : 0

 Description   

In IzPack 4, there has been the possibility od defining a reference to an external XML files containing the package definitions, for example:

<packs>
  <refpack file="refpacks/refpacks.xml" />
</packs>

refpacks.xml:

  <packs>
    <!--<refpack file="refpacks/refpacks.xml" />-->
    <pack name="My Application" required="yes" id="pack.application">
    ...
    </pack>
  </packs>

This isn't parsed any long due to a missing XSD for refpack files:

Stacktrace:

[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] com.izforge.izpack.api.exception.CompilerException: /home/rkrell/IzPack_Installer/trunk/src/main/izpack/install.xml:6: this is not an IzPack XML installation file
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.AssertionError: com.izforge.izpack.api.exception.CompilerException: /home/rkrell/IzPack_Installer/trunk/src/main/izpack/install.xml:6: this is not an IzPack XML installation file
        at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:184)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
        at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
        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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: com.izforge.izpack.api.exception.CompilerException: /home/rkrell/IzPack_Installer/trunk/src/main/izpack/install.xml:6: this is not an IzPack XML installation file
        at com.izforge.izpack.compiler.helper.AssertionHelper.parseError(AssertionHelper.java:61)
        at com.izforge.izpack.compiler.CompilerConfig.readRefPackData(CompilerConfig.java:1380)
        at com.izforge.izpack.compiler.CompilerConfig.addPacksSingle(CompilerConfig.java:846)
        at com.izforge.izpack.compiler.CompilerConfig.addPacks(CompilerConfig.java:703)
        at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:325)
        at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:180)
        ... 19 more


 Comments   
Comment by Tom Helpstone [ 06/May/14 ]

The xsd has been updated with Pull-Request 193.

The xsd is not used inside the installer, they cause of the message above is different:
com.izforge.izpack.compiler.CompilerConfig line 1379:

if (!"installation".equalsIgnoreCase(refXMLData.getName()))
{
    assertionHelper.parseError(refXMLData, "this is not an IzPack XML installation file");
}

So the xml file to include is not allowed to have the namespace prefix izpack:
Possible Solutions:

  1. Use getLocalName() instead of getName()
    • has to change the Interface
    • should probably check also that the prefix is either null or izpack
  2. Allow installation and izpack:installation as valid result
Comment by Tom Helpstone [ 07/May/14 ]

The namespace prefix izpack can optionally be used with Pull-Request 194.

Comment by Rene Krell [ 16/May/14 ]

Pull request merged.





[IZPACK-979] Distribution does not contain any IzPack JARs or izpack-utils resources Created: 12/Sep/13  Updated: 19/Oct/13  Resolved: 12/Sep/13

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

Type: Bug Priority: Blocker
Reporter: Daniel Abson Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Patch Submitted:
Yes
Number of attachments : 0

 Description   

The izpack-dist (release installer) JAR does not contain any actual IzPack JARs or resources.

The izpack-dist/pom.xml has a typo in the dependency executions for "Unpack izpack utils" and "Copy libs". The Maven phase given is pre-package, which does not exist in the Maven default lifecycle. The correct phase name is prepare-package.



 Comments   
Comment by Daniel Abson [ 12/Sep/13 ]

Pull request submitted.

Comment by Rene Krell [ 12/Sep/13 ]

Thank you.





[IZPACK-978] ConfigurationInstallerListener - setting explicit <entry> in property file: single backslashes disappear resulting file Created: 11/Sep/13  Updated: 11/Sep/13

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

Type: Bug 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

Testcase included: yes
Number of attachments : 0

 Description   

I have a ConfigurationInstallerListener specification (simplified):

<configurable type="options" cleanup="true" keepOldKeys="false" keepOldValues="false" patchfile="${INSTALL_PATH}/old.wrapper.conf" tofile="${INSTALL_PATH}/conf/new.wrapper.conf">
  <entry key="set.JAVA_HOME" value="${previous.wrapper.java.home.canonical}"/>
</configurable>

If the value of ${previous.wrapper.java.home.canonical} is for example:
C:\JRE\1.6.0_21

the resulting entry in new.wrapper.conf is
C:JRE1.6.0_21
with the backslashes missing.

The backslashes should not disappear, this should be fixed (unescape those strings).



 Comments   
Comment by Rene Krell [ 11/Sep/13 ]

Workaround at the moment: Define the previous.wrapper.java.home.canonical variable as filtered value and replace the single backslashes by a slash or double backslash (replace filter must be the last one in the sequence), for example:

<dynamicvariables>
  <variable name="previous.wrapper.java.home.canonical" value="${previous.wrapper.java.home}"
            condition="!isSetWrapperJAVA_HOME+isSetPreviousJavaHome+haveInstallPath+isCompatibleUpgrade+haveWrapperJavaCmd">
    <filters>
      <regex regexp="([^%]*)%JAVA_HOME%(.*)" replace="\1${env.JAVA_HOME}\2"/>
      <location basedir="${INSTALL_PATH}"/>
      <regex regexp="[/\\]+" replace="/" global="true"/>
    </filters>
  </variable>
<dynamicvariables>




[IZPACK-977] Add ContainsCondition Created: 29/Aug/13  Updated: 19/Oct/13  Resolved: 30/Aug/13

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

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

Number of attachments : 0

 Description   

I'd like to add a ContainsCondition which might be used to check whether string, variable value or file content contains a given pattern.

The pattern can be a plain string or a regular expression.

Example:

<condition type="contains" id="...">
    <string>a string</string>
    <value>a substring</string>
</condition>

<condition type="contains" id="...">
    <variable>a variable</variable>
    <value>a substring</string>
</condition>

<condition type="contains" id="...">
    <file>a string</file>
    <value byLine="true" caseInsensitive="false" regex="false">a substring</string>
</condition>


 Comments   
Comment by Rene Krell [ 29/Aug/13 ]

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

The documentation goes here:
http://docs.codehaus.org/display/IZPACK/Contains+Condition





[IZPACK-976] AntActionListener - make <target> execution conditional Created: 29/Aug/13  Updated: 29/Aug/13

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

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

Number of attachments : 0

 Description   

Using AntActionInstallerListener (and AntActionUninstallerListener), it would be convenient to make target execution conditional.

Example:

<antcall order="afterpacks" condition="isUpdate" buildresource="antBuild" logfile="${INSTALL_PATH}/setup/log/setup_updatedatabase.log" verbose="yes">
  <property name="install.path" value="${INSTALL_PATH}"/>
  <target name="backup" conditionid="backup.enabled"/>
  <target name="update"/>
</antcall>

Currently, it is possible to add a condition just to the <antcall> tag.






[IZPACK-975] Blank Summary Panel Created: 29/Aug/13  Updated: 04/Sep/13

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

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

izpack-compiler, version rc1-SNAPSHOT
Windows 7/8 and Linux Ubuntu 12.04 and higher


Number of attachments : 0

 Description   

When include SummaryPanel into panels section and build installer, Summary panel content is absent.



 Comments   
Comment by Rocker Irwin [ 04/Sep/13 ]

I was just about to write the same issue. Summary Panel shows empty page when built from code.

Comment by Eugene Ustimenko [ 04/Sep/13 ]

Rocker, if this bug is DUPLICATE, change status, please, and add link to original issue.





[IZPACK-974] HTML panels problem with css style and $APP_NAME, $APP_VER in console installer Created: 26/Aug/13  Updated: 27/Aug/13

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

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

Linux Ubuntu 12.10, MS Windows 7


Attachments: JPEG File pic1.jpg    
Number of attachments : 1

 Description   

Step to reproduce:
1. Create hello.html with the following content
<html>
<head>
<title>Welcome</title>
<style>

  • { font-family: Calibri, Candara, Segoe, "Segoe UI", Optima, Arial, sans-serif;}

    h1

    { font-size: 20pt; }

    span.text

    { font-size: 14pt; }

    span.footer

    { display: block; font-size: 12pt; }

    body

    { background-color: #EDEDED; }

    </style>
    </head>
    <body>
    <table width="100%" cellpadding=10 border=0>
    <tr>
    <td align="right" valign="top">
    <h1>Welcome to $APP_NAME $APP_VER</h1>
    </td>
    </tr>
    </table>
    </body>
    </html>

2. Add this file like a resource of HTMLHelloPanel into install.xml
<resources>
<res id="HTMLHelloPanel.info" src="resources/hello.html" />
</resources>

3. Add HTMLHelloPanel into panels section
<panels>
<panel classname="HTMLHelloPanel" id="HTMLHelloPanel" />
</panels>

4. Build installer

5. Launch jar with console key

The console installation looks odd, see pic1.jpg (attached to this issue).

But when installer is started without console mode, all is ok.



 Comments   
Comment by Eugene Ustimenko [ 27/Aug/13 ]

Version of izpack, which I used is 5.0.0-rc1-SNAPSHOT





[IZPACK-973] Custom panel translations - add possibility to use the panel ID as translation key prefix for headline/headinfo localization Created: 15/Aug/13  Updated: 19/Oct/13  Resolved: 20/Aug/13

Status: Resolved
Project: IzPack
Component/s: None
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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

This is especially necessary because the UserInputPanel order attribute is no longer read from the installation descriptor and can't therefore used any longer as part of the translation id.

Example of the desired behaviour:

install.xml:

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

<panels>
  <panel classname="TargetPanel"/>
</panels>

CustomLangPack.xml_eng

<langpack>
  <str id="com.izforge.izpack.panels.target.TargetPanel.headline" txt="Please select the installation directory"/>
</langpack>

Example 2:

install.xml:

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

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

CustomLangPack.xml_eng:

<langpack>
  <str id="target.panel.headline" txt="Please select the installation directory"/>
</langpack>


 Comments   
Comment by Rene Krell [ 16/Aug/13 ]

Pull request for this: https://github.com/izpack/izpack/pull/131

Comment by Rene Krell [ 19/Aug/13 ]

Still some issues with old default translations

Comment by Rene Krell [ 20/Aug/13 ]

Post-fixes in https://github.com/izpack/izpack/pull/132





[IZPACK-972] UserInputPanel - Add conditionId attribute to radio/combo choice to be able to make particular choices conditionally visible Created: 14/Aug/13  Updated: 19/Oct/13  Resolved: 15/Aug/13

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

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

Issue Links:
Related
relates to IZPACK-985 The UserInputPanel's RadioButton fiel... Closed
Number of attachments : 0

 Description   

There is a small lack of functionality to to just make a field of type "combo"/"radio" visible as a whole depending on a condition, but also some its single choices.

Therefore I added the optional conditionid attribute to the <choice> elements of this field specs.

Example:

  <field type="radio" variable="database.operation">
    <description align="left" txt="Database Operation" id="database.operation.panel.field.description"/>
    <spec>
      <choice txt="Update existing database (without admin permission)"
              id="database.operation.panel.radio.choice.upgrade.label"
              value="update"
              conditionid="database.operation.panel.radio.choice.upgrade.enabled"/>
      <choice txt="Structure creation only (without admin permission)"
              id="database.operation.panel.radio.choice.create_structure.label"
              value="create_structure"
              conditionid="database.operation.panel.radio.choice.create_structure.enabled"/>
      <choice txt="Instance and structure creation (requires admin permission)"
              id="database.operation.panel.radio.choice.create_instance_and_structure.label"
              value="create_instance_and_structure"
              conditionid="database.operation.panel.radio.choice.create_instance_and_structure.enabled"/>
      <choice txt="Configure database later"
              id="database.operation.panel.radio.choice.noop.label"
              value="noop"
              conditionid="database.operation.panel.radio.choice.noop.enabled"/>
    </spec>
  </field>

I can see no side effect to existing installers.



 Comments   
Comment by Rene Krell [ 14/Aug/13 ]

Pull request available for this: https://github.com/izpack/izpack/pull/130





[IZPACK-971] conditions.xml is not loading Created: 12/Aug/13  Updated: 09/Jul/14

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

Type: Bug Priority: Major
Reporter: Rocker Irwin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: conditions
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 7 x64


Number of attachments : 0

 Description   

(this is actually happening in the version 5.0.0-beta11)

When I try to use conditions.xml, the installer does not load the conditions in the conditions.xml file. But when I try to write all conditions in to the install.xml file, the installer sees all the conditions.

When I use DEBUG mode, I see the condition not found ERROR.

In the previous versions, I was able to use conditions.xml file.

here are some example code:

install.xml

<dynamicvariables>
<variable name="dynamicVariableTest" value="whatIf" condition="testCondition"/>
</dynamicvariables>
<resources>
<res id="LicencePanel.licence" src="text/license.text"/>
<res id="conditions.xml" src="conditions.xml"/>
<res id="userInputSpec.xml" src="userInputSpec.xml" parse="yes" type="xml"/>
</resources>

conditions.xml

<condition type="variable" id="testCondition">
<name>testFieldInUserInputSpec</name>
<value>yes</value>
</condition>



 Comments   
Comment by Francisco Canas [ 09/Jul/14 ]

I use the above method for referencing conditions.xml in several installers using izpack v4, but for izpack v5 have started using xi:include instead:

<conditions xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include href="conditions.xml"/>
</conditions>

Is izpack v5 still supposed to support loading conditions from a conditions.xml file listed as a resource as in the example from the original reporter above?





[IZPACK-970] UserInputPanel field od type "rule": validators get unformatted input Created: 09/Aug/13  Updated: 19/Oct/13  Resolved: 29/Aug/13

Status: Resolved
Project: IzPack
Component/s: API, 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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Example:

<panel id="panel.reproduce.it" layout="left">
  <field type="rule" variable="url.address">
    <description align="left" id="url.address.desc"/>
    <spec id="url.address.label" layout="O:15:U : N:5:5" resultFormat="displayFormat" set="0: 1: "/>
    <validator class="com.izforge.izpack.panels.userinput.validator.RegularExpressionValidator" id="url.address.fail">
      <param name="pattern" value="\b.*\:(6553[0-5]|655[0-2]\d|65[0-4]\d{2}|6[0-4]\d{3}|[1-5]\d{4}|[1-9]\d{0,3})\b"/>
    </validator>
  </field>
</panel>

The validator never succeeds here. although there have been entered correct values.

This applies in particular just on the RuleInputField, nothing else.

This is a regression against IzPack 4.3.5.



 Comments   
Comment by Rene Krell [ 09/Aug/13 ]

From a code analysis there could be seen, that the Validator gets just the concatenated, unformatted input.
Thus if the user enters for example:
1st edit field of the rule field: 127.0.0.1
2nd edit field of the rule field: 1234
the Validator got as input: "127.0.0.11234" instead of the expected one: "127.0.0.1:1234".

Comment by Rene Krell [ 09/Aug/13 ]

Fix available in https://github.com/izpack/izpack/pull/129

Comment by Sven Thomas [ 12/Aug/13 ]

The fix has a major drawback: It changes the number of fields to 1.
That's why I'll have to rewrite my IpValidator and MulticastValidator, as they both ask for 4 fields and traverse over them via client.getFieldContents in a for-loop.

Not that complicated, I start with that now.
But you have to consider that the izPack code is inconsistent in that regard now because the methods of ProcessingClient are still based on an unknown number of sub-fields. The standard HostAddressValidator that comes with izPack is also using client.getFieldContents(1) for obtaining the port... I'm not using it, but I guess that it doesn't work in the current state.
You'd have to either

  • remove the obsolete method getNumFields() and remove the parameter from getFieldContents(int arg0) (+ maybe create getContents() and make the old method deprecated), in addition to changing the HostAddressValidator
    or
  • find a way to fix the bug of this issue without removing the use of sub-fields.

If you choose the second version, please leave a comment in this issue so I'd be notified, allowing me to timely reverse my changes to handle a single field.

Comment by Rene Krell [ 13/Aug/13 ]

Rather don't start anything, this should be elaborated. Thanks for the hint. I did not intend to necessarily break an API.

I'm currently not sure, whether it makes sense to someone having the number of fields or keeping one user input field as a whole value. This is worth to be discussed.

Comment by Sven Thomas [ 13/Aug/13 ]

For me it doesn't make that much of a difference. If you expect a single string in your installer and get four strings, you can concatenate them. If it's the other way round, you can split them.
My code can handle both cases now, so I don't have to fix anything if the izPack behaviour changes again

If you'd ask me for a preference, I'd probably choose the multi-field variant, as it's a little easier to concatenate strings than split them.

Comment by Rene Krell [ 29/Aug/13 ]

Left another pull request with a new approach of fixing it without braking existing APIs (hopefully):
https://github.com/izpack/izpack/pull/133

In a custom validator, you can still choose whether to use
ValuesProcessingClient.getText()
or
ValuesProcessingClient.getFieldContents(int).

The API of field validating has been enhanced by the possibility of passing an additional (optional) MessageFormat object, which must be initialized with the correct format. While using this, getText() should return the formatted text from all values in the client. If the MessageFormat object isn't given (or is null), getText() returns the concatenated text like before.

For the RuleField, there is used this new formatting approach to deliver the correct formatted result in getText() instead of just concatenate string values.

There have been also added two unit test which verify this for the RuleField along with the RegularExpressionValidator and HostAddressValidator.





[IZPACK-969] mustExist parameter is ignored by TargetPanel Created: 02/Aug/13  Updated: 21/Mar/14

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

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

Number of attachments : 0

 Description   

In installer xml file, mustExist parameter is ignored on TargetPanel:

<panel classname="TargetPanel" id="TargetPanel">
  <configuration>
    <param name="mustExist" value="true" />
  </configuration>
</panel>

Consequence is: when mustExist is true, and when the target directory already exists, izpack warns the user that "The directory already exists! Are you sure you want to [...] overwrite [...]" instead of just beeing happy that the directory exists, and get silently to the next panel.



 Comments   
Comment by Bruno F [ 02/Aug/13 ]

The "mustExist" parameter does exist in the Panel "parameter" object (in its configuration map actually) that is used to build the TargetPanel (extending PathInputPanel), however it is not read.
I propose this fix in the constructor of izpack-panel/src/main/java/com/izforge/izpack/panels/path/PathInputPanel.java

PathInputPanel.java
        String mustExist;
        if ((mustExist = panel.getConfiguration("mustExist")) != null) {
          try {
            this.mustExist = Boolean.parseBoolean(mustExist);
          } catch (Exception ex) {
            // swallow the exception, don't know if it is permitted to throw something here...
         }
        }

Tested with success on my setup.

Comment by Bruno F [ 05/Aug/13 ]

I issued a github pull request (from the bfreuden/izpack git repository) containing this fix.





[IZPACK-968] Build failures in izpack-dist during unpacking resources from reactor Created: 31/Jul/13  Updated: 19/Oct/13  Resolved: 31/Jul/13

Status: Resolved
Project: IzPack
Component/s: Build
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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to MDEP-98 dependency:unpack: The source must no... Open
is related to MDEP-194 ArchiverException when using maven de... Closed
is related to MDEP-354 dependency:unpack-dependencies fail i... Closed
Number of attachments : 0

 Description   

On my local computer there repeatedly happen failures during building izpack-dist when using 'mvn compile':

Updating the maven-dependency-plugin to 2.5 I get an improved error message for this:

[INFO] Building IzPack dist module
[INFO]    task-segment: [compile]
[INFO] ------------------------------------------------------------------------
[INFO] [enforcer:enforce {execution: enforce-maven}]
[debug] execute contextualize
[INFO] [resources:copy-resources {execution: copy-izpack-resource}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO] Copying 54 resources
[INFO] [assembly:single {execution: make-assembly}]
[INFO] Reading assembly descriptor: src/assembly/assembly.xml
[INFO] Building zip: /home/rkrell/src/github/izpack/izpack/izpack-dist/target/staging/izpack-sources.zip
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO] skip non existing resourceDirectory /home/rkrell/src/github/izpack/izpack/izpack-dist/src/main/schema
[INFO] Copying 54 resources
[INFO] [dependency:unpack-dependencies {execution: Unpack izpack utils}]
[INFO] Unpacking /home/rkrell/src/github/izpack/izpack/izpack-utils/target/classes to /home/rkrell/src/github/izpack/izpack/izpack-dist/target/staging with includes "" and excludes ""
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Artifact has not been packaged yet. When used on reactor artifact, unpack should be executed after packaging: see MDEP-98.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------


 Comments   
Comment by Rene Krell [ 31/Jul/13 ]

izpack-test is also affected from similar build failures, after fixing izpack-dist.

Comment by Rene Krell [ 31/Jul/13 ]

Sent pull request https://github.com/izpack/izpack/pull/123.
The problem occured due to badly chosen execution phases of the maven-dependency-plugin. 'mvn compile' and 'mvn verify' works now as expected for me locally.

Comment by Rene Krell [ 31/Jul/13 ]

Merged pull request





[IZPACK-967] "Autodetect" button on <field type="search"> is not intuitive Created: 30/Jul/13  Updated: 30/Jul/13  Resolved: 30/Jul/13

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

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

GUI


Issue Links:
Duplicate
is duplicated by IZPACK-965 Browse button on the SearchInputField... Resolved
Patch Submitted:
Yes
Number of attachments : 0

 Description   

When I saw the "Autodetect" button on the search input, I assumed that it would automatically detect which of the proposed <choice>s was the most appropriate on my machine. I later discovered that it processes/expands paths with wildcards eg:

<choice value="C:\Java*" os="windows" />

With the following modification the Autodetect button selects the first <choice> that returns true from pathMatches():

  // Try all of <choice> options - see if any are valid
  for (int x = 0; x < pathComboBox.getItemCount(); x++)
  {
    if( pathMatches( (String)pathComboBox.getItemAt(x) ) ) {
      pathComboBox.setSelectedIndex(x);
      break;
    }
  }





[IZPACK-966] "set" attribute of <field type="search"> appears to be broken Created: 30/Jul/13  Updated: 30/Jul/13  Resolved: 30/Jul/13

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

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

GUI


Issue Links:
Duplicate
is duplicated by IZPACK-965 Browse button on the SearchInputField... Resolved
Patch Submitted:
Yes
Number of attachments : 0

 Description   

in SearchFieldReader, the current code checks the <spec> element for a "set" attribute and expects it to be "true" or "false". This doesn't make any sense:

  for (IXMLElement element : spec.getChildrenNamed("choice")) {
    ...
    String value = config.getString(element, "value", null);
    boolean set = config.getBoolean(spec, "set", false);
    if( set ) {
      selected = result.size();
    }

It should be possible to provide the most likely option in the "set" attribute of the <spec> element:

  String set = config.getString(spec, "set", null);
  for (IXMLElement element : spec.getChildrenNamed("choice")) {
    ...
    String value = config.getString(element, "value", null);
    if( value.equals(set) ) {
      selected = result.size();
    }

Alternatively, to allow a default option to be specified for either OS, the "set" attribute should belong to the <choice> elements:

  for (IXMLElement element : spec.getChildrenNamed("choice")) {
    ...
    String value = config.getString(element, "value", null);
    boolean set = config.getBoolean(element, "set", false);
    if( set ) {
      selected = result.size();
    }





[IZPACK-965] Browse button on the SearchInputField always starts in the same arbitrary location Created: 30/Jul/13  Updated: 19/Oct/13  Resolved: 30/Jul/13

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

Type: Improvement Priority: Trivial
Reporter: Nicholas Albion Assignee: Rene Krell
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GUI


Issue Links:
Duplicate
duplicates IZPACK-967 "Autodetect" button on <field type="s... Resolved
duplicates IZPACK-966 "set" attribute of <field type="searc... Resolved
Patch Submitted:
Yes
Number of attachments : 0

 Description   

When a user clicks on the "browse" button of a SearchInputField, it would be nice if it opened up at the directory currently indicated by the input field.



 Comments   
Comment by Rene Krell [ 30/Jul/13 ]

Merged https://github.com/izpack/izpack/pull/119.
Thank you





[IZPACK-964] Template generation cannot be run headless when a panel validator fails Created: 03/Jul/13  Updated: 03/Jul/13

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

Type: Bug Priority: Minor
Reporter: Paul Bors 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   

Attempting to run '-options-template' with izPack 5.0.0-beta11 for an installer that has a panel validator based on the user input will have the installer enter an infinite loop showing the error message over and over again.

Perhaps all validators should be bypassed when the '-options-template' is used.



 Comments   
Comment by Paul Bors [ 03/Jul/13 ]

Also see:

  • IZPACK-493 "Installation from template and template generation cannot be run headless"
  • IZPACK-368 "Implement functionalities for complex installers in console mode"

HOT-FIX

Temporarily remove all your panel validators, compile and run the installer with -options-template to generate a template.





[IZPACK-963] Localize the error message for the single instance Created: 28/Jun/13  Updated: 28/Jun/13

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

Type: Improvement Priority: Minor
Reporter: Paul Bors 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   

com.izforge.izpack.installer.requirement.LockFileChecker#lockFileExists() has hardcoded english error message.



 Comments   
Comment by Paul Bors [ 28/Jun/13 ]

Also see IZPACK-10 "Single Instance".





[IZPACK-962] TreePacksPanel First pack is always greyed Created: 28/Jun/13  Updated: 28/Jun/13

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

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

IzPack 5.0.0-beta11, Windows XP. jre1.6.0_35


Number of attachments : 0

 Description   

When I use TreePacksPanel, I cannot unselect the first pack, even if it is flagged as required="no".

It is not the case with PacksPanel.

It us related to http://jira.codehaus.org/browse/IZPACK-623 but I cannot re-open it.






[IZPACK-961] IzPack 5 unable to create web installer Created: 21/Jun/13  Updated: 29/Mar/15

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

Type: Bug Priority: Blocker
Reporter: Kryvenko Dmytro Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Patch Submitted:
Yes
Number of attachments : 0

 Description   

I've tried to create a web installation, and the maven build is failed.

Exception in thread "main" java.lang.AssertionError: java.io.IOException: Stream Closed
        at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:184)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
        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:84)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.io.IOException: Stream Closed
        at java.io.RandomAccessFile.writeBytes(Native Method)
        at java.io.RandomAccessFile.write(RandomAccessFile.java:499)
        at org.apache.tools.zip.ZipOutputStream.writeOut(ZipOutputStream.java:1027)
        at org.apache.tools.zip.ZipOutputStream.writeOut(ZipOutputStream.java:1012)
        at org.apache.tools.zip.ZipOutputStream.writeLocalFileHeader(ZipOutputStream.java:734)
        at org.apache.tools.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:520)
        at com.izforge.izpack.compiler.stream.JarOutputStream.putNextEntry(JarOutputStream.java:145)
        at com.izforge.izpack.compiler.packager.impl.Packager.writePacks(Packager.java:144)
        at com.izforge.izpack.compiler.packager.impl.PackagerBase.writeInstaller(PackagerBase.java:452)
        at com.izforge.izpack.compiler.packager.impl.PackagerBase.createInstaller(PackagerBase.java:404)
        at com.izforge.izpack.compiler.Compiler.createInstaller(Compiler.java:143)
        at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:332)
        at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:180)
        ... 21 more

I've made a hack fix: https://github.com/llibicpep/izpack/commit/bb3d70be2b58c2c9eb99aec540732373363965ef

This hack should be completely rewritten (so I wont create a pull request). As I am a newbie in IzPack 5 - I can't do it myself. If somebody can give me some explanation how it's can be fixed in the right way - I will try to fix it.



 Comments   
Comment by Kryvenko Dmytro [ 21/Jun/13 ]

PS: It is something different with #IZPACK-774

Comment by Rene Krell [ 14/Mar/14 ]

Is it still the case with 5.0.0-rc2-SNAPSHOT?

If yes, can you attach or link to a full simple example showing this, please?

Comment by S Chaudhari [ 29/Mar/15 ]

Hi Rene,

I tried with latest https://github.com/izpack/izpack/pull/327 refer IZPACK-1225

When trying to create web installer this gives below error.

Writing Pack 1: Purge Databases
-> Fatal error :
Stream has already been finished
java.io.IOException: Stream has already been finished
at org.apache.tools.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:635)
at com.izforge.izpack.compiler.stream.JarOutputStream.putNextEntry(JarOutputStream.java:145)
at com.izforge.izpack.compiler.packager.impl.Packager.writePacks(Packager.java:144)
at com.izforge.izpack.compiler.packager.impl.PackagerBase.writeInstaller(PackagerBase.java:413)
at com.izforge.izpack.compiler.packager.impl.PackagerBase.createInstaller(PackagerBase.java:365)
at com.izforge.izpack.compiler.Compiler.createInstaller(Compiler.java:144)
at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:341)
at com.izforge.izpack.compiler.bootstrap.CompilerLauncher.main(CompilerLauncher.java:52)

Any idea how to resolve this.. as this is related to this issue.

Regards,
Sumeet





[IZPACK-960] Library cleanup fails with when spaces in the path Created: 02/Jun/13  Updated: 19/Oct/13  Resolved: 05/Jun/13

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

Type: Bug Priority: Minor
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_21"


Number of attachments : 0

 Description   

Due to changes in Runtime.exec() in JDK 1.7 update 21 (http://www.oracle.com /technetwork/java/javase/7u21-relnotes-1932873.html#jruntime ) the LibraryRemover fails if the path contains spaces. E.g.:

Jun 02, 2013 8:28:51 PM com.izforge.izpack.util.Librarian cleanUp
WARNING: Cleanup failed for native libraries: Cannot run program "C:\Program": CreateProcess error=2, The system cannot find the file specified
java.io.IOException: Cannot run program "C:\Program": CreateProcess error=2, The system cannot find the file specified
  at java.lang.ProcessBuilder.start(ProcessBuilder.java:1042)
  at java.lang.Runtime.exec(Runtime.java:615)
  at java.lang.Runtime.exec(Runtime.java:448)
  at java.lang.Runtime.exec(Runtime.java:345)
  at com.izforge.izpack.util.LibraryRemover.initJavaExec(LibraryRemover.java:145)
  at com.izforge.izpack.util.LibraryRemover.<init>(LibraryRemover.java:112)
  at com.izforge.izpack.util.LibraryRemover.invoke(LibraryRemover.java:130)
  at com.izforge.izpack.util.Librarian.cleanUp(Librarian.java:168)
  at com.izforge.izpack.util.Housekeeper.shutDown(Housekeeper.java:112)


 Comments   
Comment by Tim Anderson [ 05/Jun/13 ]

Fixed by https://github.com/izpack/izpack/pull/108





[IZPACK-959] izPack 5 crashes when input field initialized with variable with a colon Created: 31/May/13  Updated: 19/Oct/13  Resolved: 07/Jun/13

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

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

5.0.0-rc1-snapshot
Ubuntu 12.04 64bit
Java 7u21


Attachments: Java Archive File setup-5.0.0-beta11.jar     Java Archive File setup-5.0.0-rc1.jar     Zip Archive setup-files.zip    
Number of attachments : 3

 Description   

I have a variable where I store the default value for an ldap server URL.

<variable name="ldap.url" value="ldap://ldapserver:389" />
<variable name="ldap.login" value="" />

I have a user input panel for that variable:

    <userInput>
        <panel id="user-1">
            <field type="title" align="right"  txt="LDAP-Server" bold="true" size="1"/>
            <field type="rule" variable="ldap.url">
                <spec txt="URL of the LDAP-Server"
                      id="ldap.url"
                      layout="O:20:U"
                      set="0:${ldap.url}" />
            </field>
            <field type="rule" variable="ldap.login">
                <spec txt="Login"
                      id="ldap.login"
                      layout="O:20:U"
                      set="0:${ldap.login}" />
            </field>
        </panel>
         <panel id="user-2">
            <field type="title" align="center"  txt="Ready?" bold="true" size="1"/>
        </panel>
   </userInput>

When I generate the setup with the current SNAPSHOT (5.0.0-rc1-SNAPSHOT) amd run it, I have the following problems which I did not have with izPack-5.0.0-beta11:

  • both input fields are initially empty and the following warnings are printed:
    PM WARNING: Expected 2..3 fields in '0:ldap://ldapserver:389' in 'set' attribute: '0:ldap://ldapserver:389' but got 4
    PM WARNING: Expected 2..3 fields in '0:' in 'set' attribute: '0:' but got 1
    

    When I type in the input fields the values "ldap://localhost" and "mylogin" and click next and then back, then the setup shows en empty panel and prints a severe problems:

    PM SEVERE: Error when switching panel
    

As I already mentioned, these problems were not observed with the version 5.0.0-beta11.
I think the reason for this problem, is that the fields get analysed after the substitution of the variables.



 Comments   
Comment by Samir Chouaieb [ 05/Jun/13 ]

The problem is indeed the early replacement of the variables.
In the constructor of the class com.izforge.izpack.panels.userinput.field.rule.RuleField the defined attribute 'set' returned by getSet() gets parsed.

Line 84
this.defaultValues = parseSet(getSet(), factory);

If this attribute is initialized with a variable, then value that should be parsed is "0:${ldap.url}" and not "0:ldap://ldapserver:389" if the variable "ldap.url" was initialized with the value "ldap://ldapserver:389".

set="0:${ldap.url}"
Comment by Samir Chouaieb [ 05/Jun/13 ]

I have fixed the problem by letting getSet() return the raw value without replacing the variables.
Of course I adapted some other code parts to maintain the current behaviour for other use cases.

So please review my changes in my pull request #109.

Comment by Rene Krell [ 07/Jun/13 ]

Thank you, merged on Github.





[IZPACK-958] Navigation back to the target panel resets the already chosen installation path to the default value Created: 31/May/13  Updated: 19/Oct/13  Resolved: 02/Jun/13

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

Type: Bug Priority: Minor
Reporter: Samir Chouaieb Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

IzPack 5.0.0-beta11
Ubuntu 12.04 64bit
Java 7u21


Number of attachments : 0

 Description   

When the user visits the target panel the first time, he gets the default installation path suggested as target directory.
When the user chooses another directory and navigates forward to other panels and then gets back to the target panel, the he sees the default installation path instead of the directory he has chosen.

I think that the user awaits that the directory he has chosen gets displayed and not the default one.
Please correct me if the current behaviour is seen as more user friendly.



 Comments   
Comment by Samir Chouaieb [ 31/May/13 ]

I have fixed the bug in my pull request #106

Comment by Tim Anderson [ 01/Jun/13 ]

The TargetPanelHelper.getPath() method was intended to return the platform-specific installation path, not the current installation path if present.
This change would be better placed within TargetPanel.panelActivate().

Something like:

    @Override
    public void panelActivate()
    {
        // load the default directory info (if present)
        String path = installData.getInstallPath();
        if (path == null)
        {
            path = TargetPanelHelper.getPath(installData);
        }
        if (path != null)
        {
            pathSelectionPanel.setPath(path);
        }

        super.panelActivate();
    }
Comment by Samir Chouaieb [ 01/Jun/13 ]

When the method TargetPanelHelper.getPath() should always return the default target path even if the user has already chosen another one, then it should be renamed to getDefaultPath() or getInitialPath().
Besides that, I cannot found a use case where we are interested in having the default path after having chosen another one.
For these two reasons I have made the change where it is now

On the other hand your suggestion is good because we could better separate the concerns.
If you agree, I would like to rename the method to TargetPanelHelper.getDefaultPath() and move the fix to the place that you have suggested.

Comment by Samir Chouaieb [ 01/Jun/13 ]

Moved change to TargetPanel.panelActivate() as suggested by Tim Anderson without renaming the method TargetPanelHelper.getPath().

Comment by Tim Anderson [ 02/Jun/13 ]

Thanks - changes applied.





[IZPACK-957] IzPack 5 fails to generate auto install script with DOMException Created: 31/May/13  Updated: 19/Oct/13  Resolved: 02/Jun/13

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

Type: Bug Priority: Major
Reporter: Samir Chouaieb Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

IzPack 5.0.0-beta11
Ubuntu 12.04 64Bit
Oracle Java 7u21


Attachments: Text File exception.txt     PNG File popup.png    
Number of attachments : 2

 Description   

At the last setup Panel when generating an automatic installation script, a DOMException is raised and a GUI pop comes up indicating that problem.

The generated xml file is empty.



 Comments   
Comment by Samir Chouaieb [ 31/May/13 ]

I have fixed the bug in my branch and added it to my already placed pull request.
In my fix I have also added a unit test that checks adding XML-Nodes to XML-Nodes of other documents.

So aaccept my pull request and have a bug less

Comment by Tim Anderson [ 02/Jun/13 ]

Thanks - changes applied.





[IZPACK-956] Compiler doesn't package superclasses of custom console panels in different packages Created: 26/May/13  Updated: 19/Oct/13  Resolved: 26/May/13

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

Type: Bug Priority: Minor
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The compiler is not packaging superclasses of custom console panels that reside in different packages to the custom panels.
This is due to the compiler not using the correct class loader to locate the console classes - its using the system class loader rather than the CompilerClassLoader.



 Comments   
Comment by Tim Anderson [ 26/May/13 ]

Fix is at https://github.com/izpack/izpack/pull/105

Comment by Rene Krell [ 29/May/13 ]

I've made a new snapshot deployment 5.0.0-rc1-SNAPSHOT containing this fix, it is available on Codehaus Nexus from now on.





[IZPACK-955] Dialogs blurred on retina display Created: 24/May/13  Updated: 24/May/13

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

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

Attachments: PNG File Screen Shot 2013-05-24 at 1.34.10 PM.png    
Number of attachments : 1




[IZPACK-954] NoClassDefFoundError running executable when install drive is different than installer location Created: 13/May/13  Updated: 13/May/13

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

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

Microsoft Windows, Java JDK 1.6.0.37


Number of attachments : 0

 Description   

Occurs when running a custom executable jar file (specified by an <executable> in the XML configuration) in the postinstall phase. The jar installer was on a shared network drive, and the install destination was on the C: drive. The installer fails with a NoClassDefFoundError and prompts to continue the installation or not. On another environment it just gets a popup "Error: Could not find or load main class ..." and does not display the stack trace.

If the jar installer is copied to the C: drive before running, there are no issues.

The jar installer was built using the Maven plugin org.codehaus.izpack:izpack-maven-plugin version 1.0-alpha-5.






[IZPACK-953] Izpack 5.0.0 standalone jar does not provide ant task Created: 03/May/13  Updated: 03/May/13

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

Type: Bug Priority: Major
Reporter: Niklaus Giger 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 tried to upgrade to 5.0.0-beta11 but I cannot find the com.izforge.izpack.ant.IzPackTask inside the standalone installer downloaded from http://dist.codehaus.org/izpack/releases/5.0.0-beta11/izpack-dist-5.0.0-beta11-installer.jar



 Comments   
Comment by Paul Bors [ 03/May/13 ]

See also IZPACK-690 "Version 5.0 does not have Ant task"





[IZPACK-952] Avoid functional dependency on TargetPanel - allow installers without TargetPanel Created: 30/Apr/13  Updated: 01/May/13

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

Type: Task 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
depends upon IZPACK-875 No TargetPanel - GUI disappears & Jav... Open
depends upon IZPACK-918 Unable to display packs in packs pane... Open
depends upon IZPACK-919 Installer without target panel causes... Open
depends upon IZPACK-853 PacksPanel empty without activating T... Reopened
Number of attachments : 0

 Description   

There have been reported several functional dependencies on the execution of TargetPanel. Skipping TargetPanel in an installation seems to result in several problems, functional and hanging installers.

The requirement to have a TargetPanel should be generally removed.

I created this task for the implementer to see all at one place, although installers without a TargetPanel is still a rare case, IMHO.






[IZPACK-951] Refactor serialization of installer resources to use a compatible format Created: 29/Apr/13  Updated: 30/Apr/13

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

Type: Task 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

Issue Links:
Related
relates to IZPACK-950 Installer does not resolve user condi... Resolved
Number of attachments : 0

 Description   

There have been found accidental compatibility problems with Java deserialization during installing, when the installer has been compiled with a JRE of a different vendor, in particular the installer has been compiled with Oracle JRE and launched using an IBM JRE, later. In fact, serialized objects in Java follow one and the same format, but problems occur, if there are serialized recursive references (Java imports) to Oracle/Sun's internal classes, which IBM JRE's classloader can't resolve during deserialization, because those classes doesn't usually have in its classpath.

See issue IZPACK-950 for an example - the problem here are classes from subpackages of com.sun.org.apache.xerces.internal, which gets in during serializing IXmlElement by the Oracle JRE 1.6. IBM uses its own parser, those import shouldn't get in for it, but they are serialized.

Serialization should be refactored to serialize objects in a compatible format, ideally XML and if possible using a standard Java way, like JAXB, not blowing up installers with another 3rd-party framework (for the compiler it wouldn't matter so much, though).






[IZPACK-950] Installer does not resolve user conditions with IBM JRE 1.6.0 Created: 24/Apr/13  Updated: 19/Oct/13  Resolved: 29/Apr/13

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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.6.0"
Java(TM) SE Runtime Environment (build pxa6460sr13fp1-20130325_01(SR13 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr13-20130114_134867 (JIT enabled, AOT enabled)
J9VM - 20130114_134867
JIT - r9_20130108_31100
GC - 20121212_AA)
JCL - 20130315_01


Issue Links:
Related
is related to IZPACK-951 Refactor serialization of installer r... Open
Number of attachments : 0

 Description   

Running IzPack 5.0 installer using a IBM 1.6.0 JVM doesn't work reliably.

In my case, several masks are skipped due to not fulfilled user conditions. In debug mode, just the izpack.* conditions are shown, nothing else.



 Comments   
Comment by Rene Krell [ 24/Apr/13 ]

Just for the record - with a temporarily enhanced code I figured out the root cause:

com.izforge.izpack.api.exception.ResourceException: Failed to read resource: rules
        at com.izforge.izpack.core.resource.AbstractResources.getObject(AbstractResources.java:185)
        at com.izforge.izpack.installer.container.provider.RulesProvider.readConditions(RulesProvider.java:106)
        at com.izforge.izpack.installer.container.provider.RulesProvider.provide(RulesProvider.java:69)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:611)
        at org.picocontainer.injectors.MethodInjector.invokeMethod(MethodInjector.java:141)
        at org.picocontainer.injectors.MethodInjector.access$000(MethodInjector.java:37)
        at org.picocontainer.injectors.MethodInjector$2.run(MethodInjector.java:125)
        at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:272)
        at org.picocontainer.injectors.MethodInjector.decorateComponentInstance(MethodInjector.java:132)
        at org.picocontainer.injectors.CompositeInjector.decorateComponentInstance(CompositeInjector.java:58)
        at org.picocontainer.injectors.Reinjector.reinject(Reinjector.java:142)
        at org.picocontainer.injectors.ProviderAdapter.getComponentInstance(ProviderAdapter.java:96)
        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:98)
        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:43)
        at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:48)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:220)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:684)
        at java.awt.EventQueue.access$400(EventQueue.java:93)
        at java.awt.EventQueue$2.run(EventQueue.java:645)
        at java.awt.EventQueue$2.run(EventQueue.java:643)
        at java.security.AccessController.doPrivileged(AccessController.java:250)
        at com.ibm.oti.security.CheckedAccessControlContext.securityCheck(CheckedAccessControlContext.java:30)
        at sun.misc.JavaSecurityAccessWrapper.doIntersectionPrivilege(JavaSecurityAccessWrapper.java:41)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:654)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:280)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:195)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:185)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:180)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:172)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:133)
Caused by: java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.ElementNSImpl
        at java.lang.Class.forName(Class.java:217)
        at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:616)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1590)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1511)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1747)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1344)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1968)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1892)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1344)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1968)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1892)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1344)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:363)
        at java.util.HashMap.readObject(HashMap.java:957)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:611)
        at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1039)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1344)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:363)
        at com.izforge.izpack.core.resource.AbstractResources.getObject(AbstractResources.java:181)
        ... 52 more

During deserialization of the binary "rules" resource, there is needed an XML parser implementation, which doesn't come with an IBM JRE 1.6.0 per default.

In general, there appears to be an incompatible serialization between java.io.ObjectOutputStream.writeObject(Object) of an Oracle/Sun JRE (the installer has been generated with) and java.io.ObjectInputStream.readObject() of an IBM JRE (the installer is executed with).

Comment by Rene Krell [ 29/Apr/13 ]

Fixed by pull request https://github.com/izpack/izpack/pull/102:

Prevented the serialization of IXmlElement in NotCondition, which led to the import of references to classes available just in Oracle/Sun JRE (Xerces parser).

The serialization of installation objects should be improved in future, see IZPACK-951.

Comment by Rene Krell [ 29/Apr/13 ]

Additional note: BTW fixed also logging of serialization failures, especially to get stacktraces like the above one dumped using -DSTACKTRACE=true without any intervention in the source code.





[IZPACK-949] strandalone-compiler 4.3.5 artifact misses some izpack classes Created: 22/Apr/13  Updated: 22/Apr/13

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

Type: Bug Priority: Major
Reporter: Mickael Istria 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   

Izpack-standalone-compiler 4.3.5 artifact that we can find it on Maven central ( http://mvnrepository.com/artifact/org.codehaus.izpack/izpack-standalone-compiler/4.3.5 ) does not contain some classes that are necessary to build custom panels with Maven (example ShortcutPanel, HTMLInfoPanel...) whereas those classes are documented in the javadoc artifact.
It would make sense to have a complete compiler 4.3.x including those panels, since they are part of the API when using Ant and users are able to write custom panels using those ones as API.

FYI, use case is that we are trying to move JBoss Developer Studio installer from a big Ant script to some Maven artifacts and we'd like to first migrate a 4.3.x version to Maven, and then migrate to 5.0.0.

If there is anything I can do to help on this issue, and encourage a 4.3.6 release with the fix, please tell me






[IZPACK-948] Reading a windows registry key via a dynamic variable takes a very long time Created: 19/Apr/13  Updated: 18/Oct/13  Resolved: 29/Jul/13

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

Type: Bug Priority: Major
Reporter: Paul Bors Assignee: Rene Krell
Resolution: Fixed Votes: 1
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Apr 19, 2013 4:32:21 PM INFO: Detected platform: windows,version=6.1,arch=x64,symbolicName=WINDOWS_7,javaVersion=1.6.0_38


Attachments: PNG File ProcessExplorer.png     PNG File RegQueryThreadStack.png    
Number of attachments : 2

 Description   

Expected Behavior

One should be able to read a windows registry key using dynamic variables as documented at:
http://docs.codehaus.org/display/IZPACK/Dynamic+Variables

Actual Outcome

Once an attempt is made to read a windows registry key using dynamic variables the installer starts executing and it takes quite a long time for the installer window frame to appear (I did not have enough patience to wait longer than 20 mins).

Steps to Reproduce

  1. Add the following to your install.xml:
    <dynamicvariables>
        <variable name="A_READ_TEST" checkonce="true" ignorefailure="false"
                  regkey="HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\NET Framework Setup"
                  regvalue=""/>
    </dynamicvariables>
    
  2. Start the installer in TRACE mode and notice the variable is never created
  3. Now edit your dynamic variable declaration and define the regroot as follows:
    <dynamicvariables>
        <variable name="A_READ_TEST" checkonce="true" ignorefailure="false"
                  regroot="HKEY_LOCAL_MACHINE"
                  regkey="SOFTWARE\Microsoft\NET Framework Setup"
                  regvalue=""/>
    </dynamicvariables>
    
  4. Start the installer in TRACE mode and notice that the installer starts to perform its work but the main GUI window frame takes a very long time to appear

This is where my installer gets stuck at and after 20 mins I terminated the process:

C:\src\installer>java -DTRACE=TRUE -jar target\installer-7.1.3-SNAPSHOT.jar
Apr 19, 2013 4:32:21 PM INFO: Logging initialized at level 'INFO'
Apr 19, 2013 4:32:21 PM INFO: Commandline arguments:
Apr 19, 2013 4:32:21 PM INFO: Detected platform: windows,version=6.1,arch=x64,symbolicName=WINDOWS_7,javaVersion=1.6.0_38



 Comments   
Comment by Paul Bors [ 20/Apr/13 ]

See also:

  • IZPACK-519 "Dynamic variable enhancements"
  • IZPACK-693 "izpack-ini4j junit test failures on windows"

Equivalent dos command when run on my desktop results in:

C:\>reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup" /v ""
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup
(Default) REG_SZ (value not set)

Comment by Rene Krell [ 20/Apr/13 ]

I can only imagine that this long time comes from an awaited input of the 'reg' command. This could be best seen in a debug session or a threaddump. Are you able to send a threaddump from the JVM the installer runs with while it is hanging such a long time?

Comment by Paul Bors [ 20/Apr/13 ]

I'll look at it again on Monday and let you, but I think it might be just my workstation since I get the same behavior when I use ini4j's API.

For now I have a Java condition using 'reg query' which is working just fine as follows:

public class DotNetCondition {
    private static final transient Logger logger = Logger.getLogger(DotNetCondition.class.getName());

    public static boolean dotNetInstalled = false;

    static {
        String queryDotNet = "";
        try {
            regQuery("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\NET Framework Setup", "");
            dotNetInstalled = queryDotNet.contains("REG_SZ") && !queryDotNet.startsWith("ERROR");
        } catch(Throwable t) {
            dotNetInstalled = false;
            logger.warning("An error occurred while checking for Microsoft .NET: " + t.getMessage());
        }
    }

    static public String regQuery(String key, String value) {
        boolean debug = (System.getProperty("TRACE") != null);
        List<String> params = new ArrayList<String>(
            Arrays.asList("cmd.exe", "/c", "reg", "query", key)
        );
        if(value != null) {
            params.add("/v");
            params.add("\"" + value + "\"");
        }
        String output = new ProcessUtil(debug).runCommand(new File("."), true, params.toArray(new String[params.size()]));
        if(debug) {
            System.out.println(output);
        }
        return output;
    }
}
Comment by Paul Bors [ 22/Apr/13 ]

Below is a stack trace of the AWT-EventQueue-0 thread as extracted via the jConsole.

Name: AWT-EventQueue-0
State: RUNNABLE
Total blocked: 31  Total waited: 31

Stack trace:
 java.lang.ProcessImpl.waitFor(Native Method)
com.izforge.izpack.util.config.base.Reg.exec(Reg.java:263)
com.izforge.izpack.util.config.base.Reg.regExport(Reg.java:293)
com.izforge.izpack.util.config.base.Reg.read(Reg.java:182)
com.izforge.izpack.util.config.base.Reg.<init>(Reg.java:64)
com.izforge.izpack.core.variable.RegistryValue.resolve(RegistryValue.java:138)
com.izforge.izpack.core.data.DynamicVariableImpl.evaluate(DynamicVariableImpl.java:131)
com.izforge.izpack.core.data.DefaultVariables.refresh(DefaultVariables.java:316)
   - locked com.izforge.izpack.core.data.DefaultVariables@3c40f0
com.izforge.izpack.api.data.AutomatedInstallData.refreshVariables(AutomatedInstallData.java:222)
com.izforge.izpack.installer.panel.PanelView.canShow(PanelView.java:246)
com.izforge.izpack.installer.panel.AbstractPanels.canShow(AbstractPanels.java:476)
com.izforge.izpack.installer.panel.AbstractPanels.getNext(AbstractPanels.java:324)
com.izforge.izpack.installer.gui.DefaultNavigator.configureVisibility(DefaultNavigator.java:459)
com.izforge.izpack.installer.gui.DefaultNavigator.<init>(DefaultNavigator.java:118)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
java.lang.reflect.Constructor.newInstance(Unknown Source)
org.picocontainer.injectors.AbstractInjector.newInstance(AbstractInjector.java:147)
org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:348)
org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:272)
org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:370)
org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:646)
org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:632)
org.picocontainer.parameters.BasicComponentParameter$1.resolveInstance(BasicComponentParameter.java:105)
org.picocontainer.parameters.ComponentParameter$1.resolveInstance(ComponentParameter.java:136)
org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:75)
org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:315)
org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:341)
org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:272)
org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:370)
org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:646)
org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:671)
com.izforge.izpack.installer.container.impl.GUIInstallerContainer.resolveComponents(GUIInstallerContainer.java:98)
com.izforge.izpack.installer.container.impl.InstallerContainer.fillContainer(InstallerContainer.java:79)
com.izforge.izpack.core.container.AbstractContainer.initialise(AbstractContainer.java:303)
com.izforge.izpack.core.container.AbstractContainer.initialise(AbstractContainer.java:283)
com.izforge.izpack.installer.container.impl.GUIInstallerContainer.<init>(GUIInstallerContainer.java:43)
com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:48)
java.awt.event.InvocationEvent.dispatch(Unknown Source)
java.awt.EventQueue.dispatchEventImpl(Unknown Source)
java.awt.EventQueue.access$400(Unknown Source)
java.awt.EventQueue$2.run(Unknown Source)
java.awt.EventQueue$2.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.run(Unknown Source)

It looks like izPack is stuck waiting on the reg process as invoked by Reg.exec(Reg.java:263) via:

cmd /c reg  export "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup" C:\Users\pbors\AppData\Local\Temp\reg-3094435123075258389.reg

As seen via the Process Explorer:

When you take a closer look at what the reg.exe process is doing it gives the following call stack which appears to be fetching a wide character:

The reg-3094435123075258389.reg file itself is empty and invoking the above reg export command via dos executes fine.

My own similar implementation is based on "reg query" and called via new ProcessBuilder(args[]).start() which should be no different from how the izPack is invoking the same executable.

Comment by Rene Krell [ 23/Apr/13 ]

For comparison, did you try the example from the documentation:

<dynamicvariables>
    <variable name="RegistryReadTest" checkonce="true"
              regkey="HKLM\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Environment"
              regvalue="Path"/>
</dynamicvariables>

?

Comment by Paul Bors [ 23/Apr/13 ]

Yes, as per the ticket description the documentation's code is not working for me with izPack 5.0.0-beta11.
Without the "regroot" attribute the installer would never create the "RegistryReadTest" variable.

I glimpsed over RegistryValue.resolve(VariableSubstitutor) and there are different code paths taken when the "regroot" is not defined which seems to be using the default configuration VS when the "regroot" is defined which in turn runs the 'reg export' that hangs with the above stack trace.

Comment by Paul Bors [ 03/May/13 ]

Hey Rene,

Let me know how I can assist further.

Comment by Nicholas Albion [ 25/Jul/13 ]

Should be resolved by https://github.com/izpack/izpack/pull/118

In the example below, "regkey" should include the regroot. "regvalue" should be taken from the "Name" column in the right-hand pane of regedit.

Note: regroot is optional - actually it seems pointless because once loaded, the registry data is not cached for reuse by other registry <variables>. If provided, a longer (more precise) path makes for a faster execution.

Comment by Rene Krell [ 29/Jul/13 ]

Thank you! Pull request merged.
Please reopen in case of related problems.





[IZPACK-947] AntInstallerListener - <exec> task requires system property ant.home to be set Created: 17/Apr/13  Updated: 11/Dec/13  Resolved: 11/Dec/13

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: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Using the <exec> task in an buildfile called by the AntInstallerListener leads to failures, because ant.home isn't set (used Ant libraries 1.8.4)

Calling ANT with buildfile: /tmp/buildfile_resource3219120870689246836xml
Apr 17, 2013 3:33:11 PM SEVERE: com.izforge.izpack.api.exception.IzPackException: The following error occurred while executing this line:
/tmp/buildfile_resource3219120870689246836xml:71: Execute failed: java.io.IOException: Cannot locate antRun script: Property 'ant.home' not found
com.izforge.izpack.api.exception.InstallerException: com.izforge.izpack.api.exception.IzPackException: The following error occurred while executing this line:
/tmp/buildfile_resource3219120870689246836xml:71: Execute failed: java.io.IOException: Cannot locate antRun script: Property 'ant.home' not found
        at com.izforge.izpack.event.AntActionInstallerListener.performAllActions(AntActionInstallerListener.java:314)
        at com.izforge.izpack.event.AntActionInstallerListener.afterPacks(AntActionInstallerListener.java:233)
        at com.izforge.izpack.installer.event.InstallerListeners.afterPacks(InstallerListeners.java:306)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.postUnpack(UnpackerBase.java:693)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:261)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.run(UnpackerBase.java:242)
        at java.lang.Thread.run(Thread.java:662)
Caused by: com.izforge.izpack.api.exception.IzPackException: The following error occurred while executing this line:
/tmp/buildfile_resource3219120870689246836xml:71: Execute failed: java.io.IOException: Cannot locate antRun script: Property 'ant.home' not found
        at com.izforge.izpack.event.AntAction.performAction(AntAction.java:182)
        at com.izforge.izpack.event.AntAction.performInstallAction(AntAction.java:106)
        at com.izforge.izpack.event.AntActionInstallerListener.performAllActions(AntActionInstallerListener.java:309)
        ... 6 more
Caused by: The following error occurred while executing this line:
/tmp/buildfile_resource3219120870689246836xml:71: Execute failed: java.io.IOException: Cannot locate antRun script: Property 'ant.home' not found
        at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:551)
        at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:444)
        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.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:392)
        at org.apache.tools.ant.Target.performTasks(Target.java:413)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
        at com.izforge.izpack.event.AntAction.performAction(AntAction.java:178)
        ... 8 more
Caused by: /tmp/buildfile_resource3219120870689246836xml:71: Execute failed: java.io.IOException: Cannot locate antRun script: Property 'ant.home' not found
        at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:675)
        at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:498)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        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.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
        at net.sf.antcontrib.logic.Switch$Case.execute(Switch.java:171)
        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.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at net.sf.antcontrib.logic.Switch.execute(Switch.java:138)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        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.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
        at net.sf.antcontrib.logic.IfTask.execute(IfTask.java:197)
        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.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.TaskAdapter.execute(TaskAdapter.java:154)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        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.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:392)
        at org.apache.tools.ant.Target.performTasks(Target.java:413)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
        at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
        at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
        ... 19 more
Caused by: java.io.IOException: Cannot locate antRun script: Property 'ant.home' not found
        at org.apache.tools.ant.taskdefs.Execute$ScriptCommandLauncher.exec(Execute.java:1070)
        at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:481)
        at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:495)
        at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:631)
        at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:672)
        ... 64 more

There should be ant.home defined in the execution environment of AntInstallerListener, since Ant requires it by definition (although it is almost senseless here).



 Comments   
Comment by Rene Krell [ 11/Dec/13 ]

The cause is an inconvenient implementation of the Ant <exec> task, which requires the system property ant.home to be set to a valid installation path of the whole Ant distribution, to find some wrapper laucnh scripts (antRun*). This takes place just in case there is used the attribute vmlauncher="false". This is inconvenient for embedded launches of Ant using ant-launcher.jar, as AntActionInstallerListener does.

Workaround: Don't use vmlauncher="false" at all in build files launched from within AntActionInstallerListener in case of launching shell scripts, but use the OS shell as executable attribute, followed by the appropriate arguments to call your script, e.g. "cmd" and "/c" + "script.cmd".





[IZPACK-946] Some of the /com/izforge/izpack/img/ icons are not declared in the icons.xml library forcing the client to define them via customicons.xml Created: 16/Apr/13  Updated: 16/Apr/13

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

Type: Improvement Priority: Minor
Reporter: Paul Bors Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File izPack jar packaged icons.png    
Number of attachments : 1

 Description   

Expected Behavior

All of the icons packaged in the installer jar at installer-#.#.#.jar\com\izforge\izpack\img\ should be made available to the custom panels via the IconsProvider by their respective IDs.

Actual Outcome

Not all of the 33 icons in izPack 5.0.0-beta11 installer are declared in the icons.xml of the izpack-installer project under the com.izforge.izpack.installer.container.provider.icons.xml

Steps to Reproduce

  1. Create a custom panel
  2. Add a label trying to use the following icons:
    • flag.png
    • wizard.png
      (there might be more)

HOT-FIX

  1. Declare your own customicons.xml and add the following to it:
    <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
    <icons>
    ...
        <icon res="/com/izforge/izpack/img/flag.png" id="flag"/>
        <icon res="/com/izforge/izpack/img/wizard.png" id="wizard"/>
    ...
    </icons>
    
  2. Create your own custom panel and use the above icon IDs


 Comments   
Comment by Paul Bors [ 16/Apr/13 ]

Attached izPack jar packaged icons.png shows the 33 current available icons in izPack 5.0.0-beta11 which are not all defined inside the icons.xml.





[IZPACK-945] Uninstaller always written Created: 12/Apr/13  Updated: 02/May/13  Resolved: 29/Apr/13

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

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

Windows XP


Number of attachments : 0

 Description   

I use Izpack 5-beta11 and its izpack-maven-plugin.

Even if I add <uninstaller>write="no"</uninstaller> in my <info> part, there is a "[ Writing the uninstaller data ... ]" in the console at the end of my installation.
And this uninstaller write takes a long time.



 Comments   
Comment by Rene Krell [ 29/Apr/13 ]

According to this page: http://docs.codehaus.org/pages/viewpage.action?pageId=148865523, the syntax you reported here can't work.
Please use write="no" as attribute to the <uninstaller> element, not as embedded content.

Comment by Rene Krell [ 29/Apr/13 ]

Please reopen in case it still won't work for you. Thank you.

Comment by Rene Krell [ 29/Apr/13 ]

BTW, there is one issue, which is really buggy, but more in general - IzPack compiles this without any complaints and makes an installer of it. This got to be changed in the future, we've already thought about an improved XML parsing for some later version.

Comment by Nicolas Durand [ 02/May/13 ]

You are right, thank you very much
And yes, an improved XML parsing would be a useful feature.





[IZPACK-944] Unix shortcut and Unix Uninstaller Created: 10/Apr/13  Updated: 12/Apr/13

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

Type: Bug Priority: Major
Reporter: Sreram Balasubramaniyan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: exception
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu (Linux) 10.04 LTS with JRE 1.7.0_17 and IzPack 5.0.0 b11


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

 Description   

Experiencing two different problems.

When trying to install as administrator in Ubuntu (with <run-priviledged condition="izpack.linuxinstall" />), at the time of shortcut creation, am getting a FileNotFoundException. Although the installation and creation of shortcuts succeeds, the files are not linked properly because of the exception, and the shortcuts does not work. It does not work even for a root user, (Opened nautilus as sudo and double-clicked the .desktop entry. Doesn't display anything.), while my requirement is all the users must be able to run the application.

When a normal user executes the uninstaller (Have provided a shell script which launches the jar), the uninstaller successfully asks for sudo password in console (as it has been installed by administrator), but the GUI for uninstaller never appears. It creates a log in /tmp folder and exits. If and only if the uninstaller jar is launched in command prompt as administrator (sudo java -jar <uninstaller>.jar), GUI appears.

Attaching stacktrace for the problems.



 Comments   
Comment by Sreram Balasubramaniyan [ 12/Apr/13 ]

Any updates for the issue?





[IZPACK-943] NullPointerException thrown if icon doesn't exist Created: 25/Mar/13  Updated: 14/Mar/14  Resolved: 10/Mar/14

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

Type: Bug Priority: Minor
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

From the mailing list:

java.lang.NullPointerException
  at
com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:64)
  at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:226)
  at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:673)
  at java.awt.EventQueue.access$300(EventQueue.java:96)
  at java.awt.EventQueue$2.run(EventQueue.java:634)
  at java.awt.EventQueue$2.run(EventQueue.java:632)
  at java.security.AccessController.doPrivileged(Native Method)
  at
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:105)
  at java.awt.EventQueue.dispatchEvent(EventQueue.java:643)
  at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
  at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
  at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
  at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)
Caused by: 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:43)
  at
com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:48)
  ... 14 more
Caused by: java.lang.NullPointerException
  at javax.swing.ImageIcon.<init>(ImageIcon.java:204)
  at
com.izforge.izpack.installer.container.provider.IconsProvider.parseXML(IconsProvider.java:99)
  at
com.izforge.izpack.installer.container.provider.IconsProvider.loadCustomIcons(IconsProvider.java:77)
  at
com.izforge.izpack.installer.container.provider.IconsProvider.provide(IconsProvider.java:35)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:616)
  at
org.picocontainer.injectors.MethodInjector.invokeMethod(MethodInjector.java:141)
  at
org.picocontainer.injectors.MethodInjector.access$000(MethodInjector.java:37)
  at
org.picocontainer.injectors.MethodInjector$2.run(MethodInjector.java:125)
  at
org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:272)
  at
org.picocontainer.injectors.MethodInjector.decorateComponentInstance(MethodInjector.java:132)
  at
org.picocontainer.injectors.CompositeInjector.decorateComponentInstance(CompositeInjector.java:58)
  at org.picocontainer.injectors.Reinjector.reinject(Reinjector.java:142)
  at
org.picocontainer.injectors.ProviderAdapter.getComponentInstance(ProviderAdapter.java:96)
  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.installer.container.impl.GUIInstallerContainer.initFrame(GUIInstallerContainer.java:105)
  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)
  ... 17 more

This is occuring due to these lines in IconsProvider:

url = InstallerFrame.class.getResource(icon.getAttribute("res"));
img = new ImageIcon(url);

The URL needs to be checked for null.



 Comments   
Comment by Sébastien Christy [ 07/Mar/14 ]

Patch proposed in pull request #169
https://github.com/izpack/izpack/pull/169

Comment by Tim Anderson [ 10/Mar/14 ]

Merged https://github.com/izpack/izpack/pull/169





[IZPACK-942] NoClassDefFoundError for TargetPanelHelper when using DefaultTargetPanel Created: 24/Mar/13  Updated: 18/Oct/13  Resolved: 24/Mar/13

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

Type: Bug Priority: Minor
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

From the mailing list:

 java.lang.NoClassDefFoundError: com/izforge/izpack/panels/target/TargetPanelHelper
        at com.izforge.izpack.panels.defaulttarget.DefaultTargetPanel.panelActivate(DefaultTargetPanel.java:68)
        at com.izforge.izpack.installer.gui.InstallerFrame.switchPanel(InstallerFrame.java:610)
        at com.izforge.izpack.installer.gui.InstallerFrame$5.switchPanel(InstallerFrame.java:408)
        at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:128)
        at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:36)
        at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:418)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:238)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:334)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:317)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.navigate(DefaultNavigator.java:552)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.access$100(DefaultNavigator.java:515)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler$1$1.run(DefaultNavigator.java:535)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.awt.EventQueue.access$200(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: com.izforge.izpack.panels.target.TargetPanelHelper
        at java.net.URLClassLoader$1.run(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)
        ... 26 more

This is because the TargetPanelHelper class is not being merged into the installer by the compiler. The panelDependencies.properties file needs to be changed to include:

DefaultTargetPanel=com.izforge.izpack.panels.target

A workaround for the time being would be to explicitly reference the izpack-panel jar in install.xml e.g.:

<jar src="../somepath/izpack-panel-5.0.0-rc1-SNAPSHOT.jar"/>





[IZPACK-941] ConsolePanel Refactoring incomplete Created: 15/Mar/13  Updated: 18/Oct/13  Resolved: 24/Mar/13

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

Type: Bug Priority: Trivial
Reporter: Sven Thomas Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Occurs in 5.0.0-rc-SNAPSHOT:
The recent refactoring from PanelConsole(-Helper) to ConsolePanel(-Helper) - see latest comments at https://jira.codehaus.org/browse/IZPACK-871 - did not include the check of class names. They still have to end with *PanelConsoleHelper.java, or else the console installer will abort because of missing console implementations.



 Comments   
Comment by Tim Anderson [ 17/Mar/13 ]

Shouldn't do. They can either end in ConsolePanel, or for backwards compatibility, Console, or ConsoleHelper.
The IzPack console implementations have all been renamed to use the ConsolePanel form e.g.:

  • HelloConsolePanel
  • InstallConsolePanel
  • SimpleFinishConsolePanel

You may need to pull the latest master from git and build it to get the changes.

Comment by Rene Krell [ 17/Mar/13 ]

... or wait for the next RC1 snapshot deployment, will do one for further testing, soon

Comment by Sven Thomas [ 18/Mar/13 ]

Well, ConsolePanel, Console and ConsoleHelper may work, but ConsolePanelHelper does not. For me it seems to be the most logical name, though, because
a) the JIRA issue said that PanelConsole has been refactored to ConsolePanel, nothing was said about Helper (my classes end with PanelConsoleHelper)
b) I extend ConsolePanelHelper in my classes, which works fine. If it wouldn't, the user could suspect that it doesn't work as the class ending.

Comment by Sven Thomas [ 18/Mar/13 ]

And I forgot
c) The Automation classes of izpack still end with PanelAutomationHelper. If I rename my classes to AutomationPanel to be in line with ConsolePanel, they cannot be found. Even AutomationHelper, which is suggested by the warning when the installer checks the class names, does not work. It has to be PanelAutomationHelper.
So for consistency reasons I went back to PanelConsoleHelper.

May the confusion be with you

Comment by Tim Anderson [ 18/Mar/13 ]

I may be missing something key here, but the old class naming convention had PanelConsoleHelper as a suffix, not ConsolePanelHelper. I haven't added ConsolePanelHelper as it wasn't supported in the past.
The AutomationPanel classes haven't changed; no-ones got round to refactoring them. If I were to do it, they would implement an AutomatedPanel interface.

Comment by Sven Thomas [ 18/Mar/13 ]

My point is that if you refactor PanelConsole to ConsolePanel, it would be more consistent if the same would be done with PanelConsoleHelper to ConsolePanelHelper. And it is actually an existing class, as stated in b), but the naming check just doesn't accept it.

Comment by Tim Anderson [ 18/Mar/13 ]

The Helper suffix is a misnomer; the console implementations aren't helpers, they are panel implementations for console-based installation.
When the deprecated PanelConsole interface is removed, so will the support for the Helper suffix.
The ConsolePanelHelper class was accidently renamed from PanelConsoleHelper. I'll revert the rename and deprecate it; its not used by IzPack.

Comment by Tim Anderson [ 24/Mar/13 ]

ConolePanelHelper has been renamed back to PanelConsoleHelper and deprecated





[IZPACK-940] Validators of Rule Input Fields can be ignored in the console installer Created: 15/Mar/13  Updated: 18/Oct/13  Resolved: 27/Mar/13

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

Type: Bug Priority: Minor
Reporter: Sven Thomas Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

W7


Number of attachments : 0

 Description   

The newest 5.0.0-rc-SNAPSHOT in the repository https://nexus.codehaus.org/content/repositories/snapshots/ changed the behavior of validators in the console mode:
Previously they were completely ignored, which was pretty bad.
Now they are being checked, and if the result is false, the in the userInputSpec.xml defined "txt" gets displayed, but then the text "Press 1 to continue, 2 to quit, 3 to redisplay" appears and you can skip the panel, potentially leading to variables with bad content.

The current behaviour is slightly better, but it should be mandatory to insert a valid value before being able to continue.



 Comments   
Comment by Tim Anderson [ 25/Mar/13 ]

True. However even with that change I don't think the behaviour is right.
Currently, all console panels are validated after continue is selected.
I think it should be:

  1. display panel
  2. validate panel
  3. if valid, prompt to continue/quit/redisplay
  4. if invalid, prompt to quit/redisplay




[IZPACK-939] "set" attribute of Rule Input Fields no longer optional Created: 15/Mar/13  Updated: 15/Mar/13

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

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

W7


Number of attachments : 0

 Description   

The newest 5.0.0-rc-SNAPSHOT in the repository https://nexus.codehaus.org/content/repositories/snapshots/ changed the behavior of Rule Input Fields (defined in the userInputSpec.xml):
Previously the "set" attribute of the "spec" element was optional, now it is mandatory and throws an exception at runtime when not being defined.

The documentation says: "Like all other input fields the rule input field can also be pre-filled with data and as usual, this is accomplished thought the set attribute."

The word "can" suggests that the previous behavior was intended, so it should be fixed or the documentation altered.






[IZPACK-938] Console installation - labels in UserInputPanels must be explicitly confirmed by the user Created: 14/Mar/13  Updated: 14/Mar/13

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

Type: Improvement 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   

In a UserInputPanel, on using staticText fields, like:

<field type="staticText" align="left"
       txt="This is just a static label!"
       id="some.id"/>

and launching this later with -console, the user must confirm this label:

Note: This is just a static label!
Press 1 to continue, 2 to quit, 3 to redisplay

This is not necessary, there can be a simple output and the installer can go on.
Panel switching must be in each case confirmed, so this output can't get lost.






[IZPACK-937] Swing installer - focus gets accidentally lost in UserInputPanels Created: 13/Mar/13  Updated: 18/Oct/13  Resolved: 01/May/13

Status: Resolved
Project: IzPack
Component/s: Installer, 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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

izpack-5.0.0-rc1-SNAPSHOT


Number of attachments : 0

 Description   

It seems that we've introduced some Swing focus problem in UserInputPanels. If the panel is opened and I overwrite a bunch of values in several input fields and navigatin pressing TAB the focus gets sometimes lost. But if I retry this on the changed values, it cannot be simulated again.

When the panel is opened after editing the first field, I get

Mar 13, 2013 12:52:21 PM WARNING: Condition izpack.input.db.host already registered
Mar 13, 2013 12:52:21 PM WARNING: Condition izpack.input.db.port already registered
Mar 13, 2013 12:52:21 PM WARNING: Condition izpack.input.db.oracle.sid already registered
Mar 13, 2013 12:52:21 PM WARNING: Condition izpack.input.db.user already registered
Mar 13, 2013 12:52:21 PM WARNING: Condition izpack.input.db.pass already registered
Mar 13, 2013 12:52:21 PM WARNING: Condition izpack.input.db.oracle.manual.url already registered
Mar 13, 2013 12:52:21 PM WARNING: Condition izpack.input.db.oracle.url already registered

and the focus gets lost from the UserInputPanel. After re-editing the same field it doesn't happen again.

Just for the record:
After a discussion, Tim found that it may be to do with this code:

        // process all field nodes. Each field node is analyzed
        // for its type, then an appropriate member function
        // is called that will create the correct UI elements.
        // ----------------------------------------------------
        GUIFieldFactory viewFactory = new GUIFieldFactory(installData, this, parent, delegatingPrompt);
        UpdateListener listener = new UpdateListener()
        {
            @Override
            public void updated()
            {
                updateDialog();
            }
        };

        List<Field> fields = userInputModel.createFields(spec);
        for (Field field : fields)
        {
            GUIField view = viewFactory.create(field);
            view.setUpdateListener(listener);
            views.add(view);
        }

"I suspect the workaround is to change updateDialog to determine what field has the focus prior to calling init() and then find the field after the repaint() and set the focus to it ...
not at all sure why updateDialog() needs to blow away the UI by calling init() tho. Seems a bit brute force"



 Comments   
Comment by Rene Krell [ 30/Apr/13 ]

The pull request https://github.com/izpack/izpack/pull/103 should solve this.

Comment by Rene Krell [ 01/May/13 ]

Further changes herewith:

  • added auto-selection of text in text input fields, if they get focus,
  • removed these silly warnings of already existing conditions of type "izpack.input.*" during navigating or re-entering a panel.




[IZPACK-936] ConfigurationInstallerListener - add auto-escaping of values in property files Created: 13/Mar/13  Updated: 13/Mar/13

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

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

Number of attachments : 0

 Description   

In ConfigurationInstallerListener there is no possibility of automatically escaping ':' and '#' characters in property values, as defined for Java property values. For getting the right format, one has to set <configurable escape="false"/> and overgive the pre-formatted value with escapes as value to an entry.

<configurable> should be enhanced to auto-format property files.






[IZPACK-935] Create console implementation of the XInfoPanel Created: 13/Mar/13  Updated: 13/Mar/13

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

Type: Task Priority: Minor
Reporter: Tim Anderson 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-871 Console installation support for all ... Reopened
Number of attachments : 0

 Description   

There is no console implementation of the XInfoPanel






[IZPACK-934] Create console implementation of the UserPathPanel Created: 13/Mar/13  Updated: 13/Mar/13

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

Type: Task Priority: Minor
Reporter: Tim Anderson 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-871 Console installation support for all ... Reopened
Number of attachments : 0

 Description   

There is no console implementation of the UserPathPanel






[IZPACK-933] Create console implementation of SudoPanel Created: 13/Mar/13  Updated: 13/Mar/13

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

Type: Task Priority: Minor
Reporter: Tim Anderson 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-871 Console installation support for all ... Reopened
Number of attachments : 0

 Description   

There is no console implementation of the SudoPanel






[IZPACK-932] Create console implementation of SelectPrinterPanel Created: 13/Mar/13  Updated: 13/Mar/13

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

Type: Task Priority: Minor
Reporter: Tim Anderson 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-871 Console installation support for all ... Reopened
Number of attachments : 0

 Description   

There is no console implementation of the SelectPrinterPanel






[IZPACK-931] Create console implementation of UserPathInputPanel Created: 13/Mar/13  Updated: 30/Apr/13

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

Type: Task Priority: Minor
Reporter: Tim Anderson 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-871 Console installation support for all ... Reopened
Number of attachments : 0

 Description   

There is no console implementation of the UserPathInputPanel






[IZPACK-930] Create console implementation of the InstallationTypePanel Created: 13/Mar/13  Updated: 13/Mar/13

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

Type: Task Priority: Minor
Reporter: Tim Anderson 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-871 Console installation support for all ... Reopened
Number of attachments : 0

 Description   

There is no console implementation of the InstallationTypePanel






[IZPACK-929] Create console implementation of InstallationGroupPanel Created: 13/Mar/13  Updated: 19/Oct/13  Resolved: 30/Jul/13

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

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

Issue Links:
Supercedes
supercedes IZPACK-871 Console installation support for all ... Reopened
Number of attachments : 0

 Description   

There is no console implementation of the InstallationGroupPanel



 Comments   
Comment by Samir Chouaieb [ 21/Jun/13 ]

This should be supported now by IzPack 5.0 after merge of Pull 114.

Comment by Rene Krell [ 29/Jul/13 ]

There is another pull request concerning this: https://github.com/izpack/izpack/pull/120, please test also, who can do so.

Comment by Rene Krell [ 30/Jul/13 ]

Console support merged from https://github.com/izpack/izpack/pull/120.
Thank you for the contribution.





[IZPACK-928] Create console implementation of DataCheckPanel Created: 13/Mar/13  Updated: 13/Mar/13

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

Type: Task Priority: Minor
Reporter: Tim Anderson 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-871 Console installation support for all ... Reopened
Number of attachments : 0

 Description   

There is no console implementation of the DataCheckPanel






[IZPACK-927] Create console implementation of CompilePanel Created: 13/Mar/13  Updated: 13/Mar/13

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

Type: Task Priority: Minor
Reporter: Tim Anderson 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-871 Console installation support for all ... Reopened
Number of attachments : 0

 Description   

There is no console implementation of the CompilePanel






[IZPACK-926] Console installer output gets a mess of log lines when dynamic variables cannot be evaluated Created: 12/Mar/13  Updated: 18/Oct/13  Resolved: 13/Mar/13

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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

IzPack 5.0.0-beta11


Number of attachments : 0

 Description   

There is a lot of warning messages confusing the user durign a console installation when a dynamic variable cannot be evaluated. Since this is not critical, it should be logged just at DEBUG level.

Example:

Mar 7, 2013 11:42:04 AM WARNING: Error evaluating dynamic variable 'info_station': java.io.FileNotFoundException: ${info.home}/contents.txt (No such file or directory)

Mar 7, 2013 11:42:04 AM WARNING: Error evaluating dynamic variable 'info_station': java.io.FileNotFoundException: ${info.home}/contents.txt (No such file or directory)

Mar 7, 2013 11:42:04 AM WARNING: Error evaluating dynamic variable 'info_station': java.io.FileNotFoundException: ${info.home}/contents.txt (No such file or directory)

...


 Comments   
Comment by Rene Krell [ 12/Mar/13 ]

Fixed in https://github.com/izpack/izpack/pull/97





[IZPACK-925] IzPack 5beta11 - Executing a Java Class with ProcessPanel Created: 11/Mar/13  Updated: 25/Mar/13  Resolved: 25/Mar/13

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

Type: Bug Priority: Major
Reporter: Nicolas Durand Assignee: Unassigned
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Hi everyone,

I have an issue trying to upgrade to IzPack 5beta11.
I want to execute a java class with ProcessPanel. It worked with Izpack 4.3.5.

In the documentation it's said to include the standalone-compiler.jar on the classpath : http://docs.codehaus.org/display/IZPACK/Executing+a+Java+Class+with+ProcessPanel

But there is no more standalone-compiler, right ?

Is there another way to do ?

Thank you, and sorry if it's not the good place to ask this, I don't know if it's a bug.






[IZPACK-924] "ShowDirectoryExistingMessage" variable Created: 22/Feb/13  Updated: 22/Feb/13

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

Type: Wish Priority: Minor
Reporter: Sven Thomas 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'd like to suppress the popup dialog "The directory already exsists! Are you sure you want to install here and possibly overwrite existing files?", as my installation path has to be an existing directory every time, therefore this message is unneeded.

P.S.: There already is a "ShowCreateDirectoryMessage" variable which does something similar for the TargetPanel.






[IZPACK-923] Buttons in "Question" dialogs are not in the installer language Created: 22/Feb/13  Updated: 02/Jun/13  Resolved: 02/Jun/13

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

Type: Bug Priority: Trivial
Reporter: Sven Thomas Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7


Number of attachments : 0

 Description   

All of the buttons that appear in the popup dialogs (e.g. wenn quitting the installation, trying to install to an existing path or overwriting a file which has been parameterised as override="asktrue") appear in the german language for me, even though the only locale in the install.xml is "eng".

The questions and dialog headers are correctly in english.



 Comments   
Comment by Samir Chouaieb [ 29/May/13 ]

I think that the l10n of those buttons is not based on the language specified in install.xml.
It is rather based on the default locale on your system.
If you are using shell scripts or batch files to launch your setup, you could specify the language as follows:

java -Duser.language=en -Duser.region=US -jar my-setup.jar

This is of course only a workaround, that can't be used when the setup is launched via double click on the jar file.

The better solution would be to fix the bug in the izPack code by setting the language specified in install.xml as locale. That should not be difficult, I guess.

Comment by Samir Chouaieb [ 29/May/13 ]

I have downloaded the code (commit: 433c81d8ce0b73376dd2ac18623e7f5de888b943) and found another bug concerning L10n of the popup dialogs.
When you try to install your app in an existing path, then you get a warning with "question" as title, even if you have a german locale and a german language in install.xml.

The bug is in the file PromptUIHandler.java: lines 159 and 179:

Option selected = prompt.confirm(QUESTION, question, YES_NO, defaultValue);
//...
Option selected = prompt.confirm(QUESTION, question, YES_NO_CANCEL, defaultValue);

The bug consists of not using the given title, which is already localized.
So please change the code as follows:

Option selected = prompt.confirm(QUESTION, title, question, YES_NO, defaultValue);
//...
Option selected = prompt.confirm(QUESTION, title, question, YES_NO_CANCEL, defaultValue);
Comment by Samir Chouaieb [ 30/May/13 ]

I have reviewed the class com.izforge.izpack.installer.language.LanguageDialog and found the bug.
When more than a language is given in the configuration file, then the user gets a dialog to choose a language.
The chosen language gets then propagated and set as the default language. This is OK.
But when only one language is specified, the languages dialog does not appear and the given language does not get propagated and set as the default language. Thus system language stays the default language.

I have fixed the bug in my branch by propagating the given language, if it is the only given one.

I hope that my pull request will be accepted and this bug will be closed.

Comment by Tim Anderson [ 02/Jun/13 ]

Thanks - changes applied.





[IZPACK-922] When installing on UNIX, the Locale.ENGLISH is forced to be used Created: 21/Feb/13  Updated: 18/Oct/13  Resolved: 12/Mar/13

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

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

Issue Links:
Related
is related to IZPACK-913 Chinese characters displayed as squares Resolved
Number of attachments : 0

 Description   

When installing on UNIX, the Locale.ENGLISH is forced to be used. In the code there is the following comment for this:

// In Linux we will use the English locale, because of a bug in
// JRE6. In Korean, Persian, Chinese, japanese and some other
// locales the installer throws and exception and doesn't load
// at all. See http://jira.jboss.com/jira/browse/JBINSTALL-232.
// This is a workaround until this bug gets fixed.

At first, I can't really reproduce this any longer with JRE 1.6.0_38.
Furthermore, the locale can be set from outside and must not be placed "hardwired" in the installer code. Remove this.



 Comments   
Comment by Rene Krell [ 21/Feb/13 ]

Pull request placed at https://github.com/izpack/izpack/pull/93

Comment by Rene Krell [ 12/Mar/13 ]

Already deployed in 5.0.0-rc1-SNAPSHOT.





[IZPACK-921] Compiler complains about an ambigous definition of a dynamic variable Created: 20/Feb/13  Updated: 18/Oct/13  Resolved: 20/Feb/13

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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In install.xml, if there is defined a dynamic variable:

    <variable name="previous.version.3"
          jarfile="${INSTALL_PATH}/classes/release.jar"
          entry="release.properties" type="options"
          key="release.version"
          checkonce="true" ignorefailure="true" condition="haveInstallPath+!isCompatibleUpgrade.4">
      <filters>
        <regex regexp="([0-9]+(\.[0-9]+){2})" select="\1"/>
      </filters>
    </variable>

just once with that name, but during compiling I get:

[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] com.izforge.izpack.api.exception.CompilerException: /home/rkrell/myapp/trunk/installer/installer-server/src/main/izpack/install.xml:Ambiguous file value definition for dynamic variable previous.version.3
[INFO] ------------------------------------------------------------------------
[DEBUG] Trace
java.lang.AssertionError: com.izforge.izpack.api.exception.CompilerException: /home/rkrell/myapp/trunk/installer/installer-server/src/main/izpack/install.xml:Ambiguous file value definition for dynamic variable previous.version.3
        at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:184)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
        at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
        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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: com.izforge.izpack.api.exception.CompilerException: /home/rkrell/myapp/trunk/installer/installer-server/src/main/izpack/install.xml:Ambiguous file value definition for dynamic variable previous.version.3
        at com.izforge.izpack.compiler.helper.AssertionHelper.parseError(AssertionHelper.java:49)
        at com.izforge.izpack.compiler.CompilerConfig.addDynamicVariables(CompilerConfig.java:2261)
        at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:312)
        at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:180)
        ... 19 more





[IZPACK-920] Failing ProcessPanel without aborting - inconsistency when using Previous/Next buttons Created: 19/Feb/13  Updated: 23/Feb/13

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

Type: Improvement 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   

On using

  • InstallPanel
  • ProcessPanel
    in the given order, if some script called from ProcessPanel fails, a messagebox is shown "Continue anyway?" (untranslated) (Yes/No). If the user chooses to continue, the Previous button is active, if this has been configured in the ProcessPanel spec., for instance:
    <onSuccess previous="true" next="true" condition="mycondition"/>

Now, on pressing Previous, the InstallPanel reappears, which is still right, but the InstallPanel installs again immediately without confirmation - bad:

  • The InstallPanel actions already succeeded with the user input entered before. Rather, the InstallPanel should be skipped and the panel before it should be shown, if there was some.
  • If pressing the Next button in that state on InstallPanel, the ProcessPanel appears again, but still with the error state before, thus, the actions in the ProcessPanel cannot be repeated. This makes no sense.

I'd suggest the following approaches:

  1. On pressing Previous from any panel directly after the InstallPanel, do not re-execute the InstallPanel, but skip it or just show its last contents. Better would be to be able to skip to a certain panel. Even better would be the ability to optionally skip directly to a panel with a given ID on pressing Previous here.
  2. On ProcessPanel, add some action to allow to repeat the failed ProcessPanel actions, some kind of resume. So I would appreciate some Retry or Resume button to repeat the last failed action, not all from the beginning. This button should be configurable.


 Comments   
Comment by Tim Anderson [ 19/Feb/13 ]

This could be done via a marker interface (e.g. OnceOnlyPanel) which may be implemented by a panel (be it IzPanel, PanelConsole or PanelAutomation) to denote that a panel may only be executed once.
This would be used by AbstractPanels.hasPrevious() to determine if the previous panel can be navigated to. If it implements OnceOnlyPanel, then hasPrevious() returns false.

Comment by Rene Krell [ 19/Feb/13 ]

I'm still not sure, what could be the most universal approach.
On the other hand, I can imagine that one might have a robust installation (executed by InstallPanel) and wants the user to go back to some user input panels, change some parameters and retry installing also. For instance if the ProcessPanel depends on some database connection which is configured while InstallPanel is executing (by an InstallerListener or using variable replacements while parsing text files). If ProcessPanel fails because the connection is wrong due to some bad user input, the user could reconfigure the connection in some UserInputPanel, run the InstallPanel again and ProcessPanel works with the right connection, later.
I think it should be customizable in a way which fits to the particular use case.

Comment by Tim Anderson [ 19/Feb/13 ]

How about adding flags to the panel e.g.:

<panel classname="InstallPanel" id="install" runOnce="true"/>

Or:

<panel classname="InstallPanel" id="install">
    <run condition="somecondition"/>
</panel>

Or:

<panel classname="InstallPanel" id="install">
    <run eval="!install.run || packs.changed || userInput.changed"/>
</panel>

I suspect that but for trivial cases, re-running InstallPanel should back out existing changes prior to re-installing.

Comment by Rene Krell [ 21/Feb/13 ]

InstallPanel and the appended installer listener can do too much, and there is currently just a limited control over conditions.
Maybe the best would be the dependency of running InstallPanel on a condition. But <run> is something, what is valid just for the Installpanel, it would not make sense to have an:

<panel classname="UserInputPanel" id="uip1">
    <run condition="somecondition"/>
</panel>

Furthermore, in my opinion there should be the default not to re-run an InstallPanel, even if the user didn't force this.

Comment by Tim Anderson [ 23/Feb/13 ]

There should be some general facility for determining if the previous button is enabled for a particular panel.

This could be done by:

  • the panel implementing an IsRunnable interface
  • specifying additional configuration options on the panel.

The InstallPanel would implement IsRunnable, but respect any configuration options.

The configuration options would be specified as:

<panel classname="CreateDatabasePanel" id="cdbp">
   <run condition="somecondition"/>
</panel>

or:

<panel classname="CreateDatabasePanel" id="cdbp">
   <run once="true"/>
</panel>

For backward compatibility, the "once" attribute would default to "false".

These would be used as follows in the PanelView class:

public abstract class PanelView {

    private boolean hasRun = false;

    public boolean isRunnable() {
        boolean result;

        if (view instanceof IsRunnable) {
            result = ((IsRunnable) view).isRunnable();
        } else if (panel.getRunCondition() != null) {
            result = installData.getRules().isConditionTrue(panel.getRunCondition();
        } else {
            result = (panel.getRunOnce() && !hasRun) || !panel.getRunOnce();
        }
        return result;
    }
}

And used in AbstractPanels:

   public int getPrevious(int index, boolean visibleOnly)
    {
        int result = -1;
        for (int i = index - 1; i >= 0; --i)
        {
            T view = getPanelView(i);
            if (!view.isRunnable()) {
                break;
            }
            if (canShow(view, visibleOnly))
            {
                result = i;
                break;
            }
        }
        return result;
    }




[IZPACK-919] Installer without target panel causes ClassNotFoundException when installer is run. Created: 18/Feb/13  Updated: 12/Aug/13

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

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

Windows XP, Window 7


Attachments: Text File ClassNotFoundException.txt     Java Archive File install_sample.jar     Zip Archive IzPack-NoTargetPanel-sample.zip    
Issue Links:
dependent
is depended upon by IZPACK-952 Avoid functional dependency on Target... Open
Number of attachments : 3

 Description   

If a TargetPanel is not included in the install.xml, there is a ClassNotFoundException when the installer is run. I have used the example that came with 4.3.5 to demonstrate this issue (with minor modifications). To reproduce the issue, I used a command line of (assuming IZPACK home is c:\IZPACK): "c:\IzPack\bin\compile" C:\IzPack\sample\simple\install.xml -h "C:\IzPack" -b "sample\simple" -o install_sample.jar

The install_sample is created and I executed the installer. I have attached the output of building and running the installer in the text file.



 Comments   
Comment by Sven Thomas [ 19/Feb/13 ]

An installer is typically made to install something into a chosen destination, which in this case is defined in the TargetPanel.
If you remove this anchor from the installer, it's expected that it cannot work in it's current specification, therefore it's not a bug.

Can you provide an example for what purpose you'd want to create an IzPack installer without a TargetPanel?

Comment by Rene Krell [ 19/Feb/13 ]

I would not completely deny it, there could be a default path which might not be allowed to change, neither in unattended installations there would be the need of the TargetPanel. Nevertheless, it is a rare use case, maybe it could be also documented in Confluence.
Let's see if someone can have a look at this.

Comment by Joshua Palmer [ 19/Feb/13 ]

I have an existing installer under 4.3.5. We use the installer on Windows and Unix as both an installer (fresh installs) and an updater (existing installs). My software has dependencies on other several very large enterprise scale software packages. It determines where to install the components based on several pre-existing environment variables that are defined before the installer has run. I have custom conditions to check that the dependencies are installed and the required environment variables exist before allowing installation. I would stay at 4.3.5, but I am hoping to upgrade to 5.0.0 to take advantage of the new dynamic variable definitions. I am MUCH more interested in this bug than IZPACK-918.

Comment by Tim Anderson [ 24/Feb/13 ]

You're getting a ClassNotFoundException for com.izforge.izpack.panels.path.PathSelectionPanel which is only included in the installer if the PathInputPanel (or one of its subclasses) is referenced in install.xml

The class itself is referenced within IzPanelLayout which adjusts layouts depending on the type of the component:

   private static int getIntermediarId(Class clazz, Component comp)
   {
            /** snip **/
            if (pathSelectionPanel.isAssignableFrom(clazz)
                || JCheckBox.class.isAssignableFrom(clazz)
                || JRadioButton.class.isAssignableFrom(clazz)
                || USER_PATH_SELECTION_PANEL_CLASS.equals(clazz.getName()))
            {
                return (FULL_LINE_CONTROL_CONSTRAINT);
            }
            /** snip **/

Possible workarounds:

  • change IzPanelLayout to just compare class names, although this would mean that layout of subclasses of PathSelectionPanel would no longer display correctly. There are no such classes within IzPack, but could affect users
  • use DefaultTargetPanel. This isn't displayed, but should set the install path, and also cause the PathSelectionPanel to be merged to the installer. I've never used it so YMMV.
Comment by Rene Krell [ 01/May/13 ]

Can you retry it with the latest 5.0.0-rc1 snapshot or HEAD from github (izpack/izpack)?
Thank you

Comment by Karim de Fombelle [ 12/Aug/13 ]

Reproduced on an installer built with maven plugin version 5.0.0-beta11
Adding the following section in izpack descriptor sounds a workaround <panel classname="TargetPanel" />





[IZPACK-918] Unable to display packs in packs panel if target panel has not already executed Created: 18/Feb/13  Updated: 01/May/13

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

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

Windows XP, Window 7


Attachments: Java Archive File install_sample.jar     Zip Archive IzPack-sample.zip    
Issue Links:
Duplicate
is duplicated by IZPACK-853 PacksPanel empty without activating T... Reopened
dependent
is depended upon by IZPACK-952 Avoid functional dependency on Target... Open
Number of attachments : 2

 Description   

If the target panel is not executed before the packs panel, during install the packs panel is not painted and the following message shows up in the command prompt window: "SEVERE: Error when switching panel". I have used the example that came with 4.3.5 to demonstrate this issue (with minor modifications). To reproduce the issue, I used a command line of (assuming IZPACK home is c:\IZPACK): "c:\IzPack\bin\compile" C:\IzPack\sample\simple\install.xml -h "C:\IzPack" -b "sample\simple" -o install_sample.jar

The install_sample is created and I executed the installer.



 Comments   
Comment by Sven Thomas [ 19/Feb/13 ]

The PacksPanels displays information about the available space on the target partition that has been defined in the TargetPanel, therefore the error message is to be expected.

If you for some reason need to have the PacksPanel before the TargetPanel, the first would have to lose it's disk space feature (unlikely) or an alternative version would have to be added.





[IZPACK-917] Pre-defined Condition: izpack.consoleinstall Created: 18/Feb/13  Updated: 18/Feb/13

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

Type: Wish Priority: Major
Reporter: Sven Thomas 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 would be very handy for me if the installer had a condition which simply returns true when it runs in console mode.
Extra points if you could prevent the check for a ConsoleHelper version of a panel if it has the condition "!izpack.consoleinstall".

I'm sorry if something like this already exists, but I searched quite a bit for such a feature and didn't find a working solution.






[IZPACK-916] Generation of an automatic installation file by the console installer Created: 18/Feb/13  Updated: 18/Feb/13

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

Type: Wish Priority: Major
Reporter: Sven Thomas 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 feature to create a file for automated installations not only by the GUI but also by the console mode would be a great addition to the IzPack installer.

Therefore I'd like to request it, maybe someone has the time for it






[IZPACK-915] Two display errors in the FinishPanel Created: 18/Feb/13  Updated: 18/Feb/13

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

Type: Bug Priority: Trivial
Reporter: Sven Thomas Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7


Number of attachments : 0

 Description   

I spotted two wrong Strings in my Installer:

The first is very minor and can be circumvented in a CustomLangpack.xml_eng (it should regardless be fixed in the eng.xml):
The panel states "An uninstaller program has been created in:", which is wrong at this time... it will be created after the user clicks the "Done" button.

The second one needs a change in the source code:
The panel displays the String "$INSTALL_PATH/Uninstaller", which is fine until you change the path via the <uninstaller path=""/> element in the <info> section of the install.xml.
The uninstaller is put into the correct path, so it's only a display error.

P.S.: Any ETA on a new beta version of 5.0.0? I'd really like to have the bugfix of IZPACK-794



 Comments   
Comment by Sven Thomas [ 18/Feb/13 ]

And another related thing that came to my mind:
"automatic installation script" in the panel is not ideal imho... a script is usually an executable, which doesn't hold true for XML files.
Maybe file or XML instead of script would be better?





[IZPACK-914] Erroneous display of Total space required in PacksPanel Created: 18/Feb/13  Updated: 18/Feb/13

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

Type: Bug Priority: Trivial
Reporter: Sven Thomas Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7


Number of attachments : 0

 Description   

In my installer, there are different installation types for an installation into a JBoss or a standalone Tomcat.
This creates the need for different packs, which are restricted to the corresponding installation type by a condition.

The installation process works fine, but: The display of the "Total space required:" in the PacksPanel is not correct, it totals the needed space for all packs, even those that are deselected.
If I click onto the checkbox of a single pack (regardless if it's grayed or not), the total space display changes to it's correct value, which is the desired behaviour when the Panel is created.






[IZPACK-913] Chinese characters displayed as squares Created: 16/Feb/13  Updated: 21/Feb/13  Resolved: 21/Feb/13

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

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

Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b25), Linux (Xubuntu 12.04)


Attachments: XML File chn_UTF8.xml     PNG File IzPack - Installation of Jajuk_092.png     Java Source File Unicode.java     PNG File Unicode.png    
Issue Links:
Related
relates to IZPACK-922 When installing on UNIX, the Locale.E... Resolved
Number of attachments : 4

 Description   

I added the Chinese langpack into our installer [1] but text is displayed as squares (please see the attachment).

Note that our won swing app provides a Chinese langpack (in UTF-8) that is property displayed (in SANS_SERIF font).

[1]
<?xml version='1.0' encoding='UTF-8'?>
<installation version="5.0"
xmlns:izpack="https://izpack.github.io/schema/installation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://izpack.github.io/schema/installation https://izpack.github.io/schema/5.0/izpack-installation-5.0.xsd">
<info>
<appname>Jajuk</appname>
<appversion>VERSION_REPLACED_BY_ANT</appversion>
<javaversion>1.6</javaversion>
<url>http://jajuk.info</url>
</info>
<guiprefs height='600' resizable='yes' width='800' />

<!-- See ISO3 country codes in /prog/IzPack/bin/langpacks/installer -->
<locale>
<langpack iso3='eng' />
<langpack iso3='cat' />
<langpack iso3='chn' />
<langpack iso3='deu' />
<langpack iso3='ell' />
<langpack iso3='fra' />
<langpack iso3='hun' />
<langpack iso3='ita' />
<langpack iso3='jpn' />
<langpack iso3='pol' />
<langpack iso3='rus' />
<langpack iso3='spa' />
<langpack iso3='swe' />
<langpack iso3='glg' />
</locale>
<native>
<native type='izpack' name='ShellLink.dll' />
<native type="izpack" name="ShellLink_x64.dll" />
<native type="3rdparty" name="COIOSHelper.dll" stage="both">
<os family="windows" />
</native>
</native>
<resources>
<res id='LicencePanel.licence' src='legals/LICENSE-GPL.txt' />
<res id='shortcutSpec.xml' src='/tmp/jajuk-dist/java/shortcutSpec.xml' />
<res id='installer.langsel.img' src='main/resources/images/jajuk-installer.jpg' />
<res id='ImgPacksPanel.img.0' src='main/resources/images/core.png' />
<res id='ImgPacksPanel.img.1' src='main/resources/images/src.png' />
<res id='TargetPanel.dir.unix' src='/tmp/jajuk-dist/java/installDirectory.unix.txt' />
</resources>
<panels>
<panel classname='LicencePanel' />
<panel classname='TargetPanel' />
<panel classname='InstallPanel' />
<panel classname='ShortcutPanel' />
<panel classname='FinishPanel' />
</panels>

<!-- The listeners section for CustomActions -->
<listeners>
<listener classname="RegistryInstallerListener" stage="install">
<os family="windows" />
</listener>
<listener classname="RegistryUninstallerListener" stage="uninstall">
<os family="windows" />
</listener>
</listeners>

<packs>
<pack name='main pack' required='yes'>
<description>Main pack</description>

<!-- Files to include in every platform -->
<file override='true' targetdir='$INSTALL_PATH/bin'
src='/tmp/jajuk-dist/jajuk/bin/jajuk.jar'>
</file>
<fileset override='true' targetdir='$INSTALL_PATH/dist-files'
dir='/tmp/jajuk-dist/jajuk/dist-files' />
<file override='true' targetdir='$INSTALL_PATH'
src='/tmp/jajuk-dist/jajuk/jajuk-icon-shortcut_64x64.png' />
<file override='true' targetdir='$INSTALL_PATH'
src='/tmp/jajuk-dist/jajuk/LICENSE-GPL.txt' />
<file override='true' targetdir='$INSTALL_PATH'
src='/tmp/jajuk-dist/jajuk/DERIVATED.txt' />
<file override='true' targetdir='$INSTALL_PATH'
src='/tmp/jajuk-dist/jajuk/README.html' />

<!-- Windows specific -->
<file override='true' targetdir='$INSTALL_PATH'
src='/tmp/jajuk-dist/windows/jajuk.exe'>
<os family='windows' />
</file>
<file override='true' targetdir='$INSTALL_PATH'
src='/tmp/mplayer/windows/mplayer.exe'>
<os family='windows' />
</file>
<dir override='true' targetdir='$INSTALL_PATH/lib'
src='/tmp/jajuk-dist/jajuk/lib/windows'>
<os family='windows' />
</dir>
<file override='true' targetdir='$INSTALL_PATH'
src='/tmp/jajuk-dist/jajuk/dist-files/images/jajuk-icon.ico'>
<os family='windows' />
</file>
<fileset override='true' targetdir='$INSTALL_PATH/lib'
dir='/tmp/jajuk-dist/jajuk/lib'>
<os family='windows' />
<exclude name="lib*" />
</fileset>
<file override='true' targetdir='$INSTALL_PATH'
src='/tmp/jajuk-dist/jajuk/dist-files/images/jajuk-uninstall.ico'>
<os family='windows' />
</file>
<file override='true' targetdir='$INSTALL_PATH/bin'
src='/tmp/jajuk-dist/jajuk/lib/JIntellitype.dll'>
<os family='windows' />
</file>
<file override='true' targetdir='$INSTALL_PATH'
src='/tmp/jajuk-dist/jajuk/dist-files/images/jajuk-uninstall.png'>
<os family='windows' />
</file>

<!--Unix specific -->
<file override='true' targetdir='$INSTALL_PATH' src='/tmp/jajuk-dist/jajuk/jajuk'>
<os family='unix' />
</file>
<executable targetfile="$INSTALL_PATH/jajuk" stage="never">
<os family='unix' />
</executable>
<fileset override='true' targetdir='$INSTALL_PATH/lib'
dir='/tmp/jajuk-dist/jajuk/lib'>
<os family='unix' />
<exclude name="*/.dll" />
</fileset>

<!--OSX specific -->
<!-- We don't include the mplayer binary here to save space. The binary
will be embedded into the .app only -->
<executable targetfile="$INSTALL_PATH/jajuk" stage="never">
<os family='mac' />
</executable>
</pack>
</packs>
</installation>



 Comments   
Comment by Rene Krell [ 16/Feb/13 ]

Please zip and add your original langPack XML file you reported this for.
Did you check this using the 5.0.0-beta11 release?

Comment by bflorat [ 16/Feb/13 ]

Not sure to get it, I use the unchanged chn.xml file from the izpack-5.0.0beta11 distro [1], I didn't use a custom langpack, I simply added <langpack iso3='chn' /> to my izpack file.

PS : the Greek izpack installer displays correct Greek characters in the contrary of Chinese.

[1] http://git.codehaus.org/gitweb.cgi?p=izpack.git;a=blob;f=izpack-core/src/main/resources/com/izforge/izpack/bin/langpacks/installer/chn.xml;h=0ca615fc3b3cd35c4c96f6673602432e656ae695;hb=HEAD

Comment by Rene Krell [ 16/Feb/13 ]

I see, is the https://github.com/izpack/izpack/blob/master/izpack-core/src/main/resources/com/izforge/izpack/bin/langpacks/installer/chn.xml displayed correctly for you in an editor or browser? Are the lanslations ok, can you recognize this, please?

Comment by Rene Krell [ 16/Feb/13 ]

I attached a the chn.xml file converted to UTF-8 encoding. Can you check it, is it still ok, or can you fix the translations there and send it back, please?

Comment by bflorat [ 17/Feb/13 ]

Both the previous chn.xml file and your UTF-8 converted file Chinese characters are properly displayed in my browser (Firefox). Sorry, I don't read Chinese so I can't tell you if the translation is good or not. I'm just sure that Chinese people can 't read squares

Comment by Rene Krell [ 20/Feb/13 ]

Of course
From my debugging session, I found that the XML file with the translations is encoded and parsed correctly. Instead, this is some Java Swing font problem. I can reproduce this on OpenSUSE 12.2 using the default look-and-feel, too.
You can see this also from the fact, that if you quit the installer, the title of the messagebox whether really to quit is displayed with the chinese characters from the translation.

Comment by bflorat [ 21/Feb/13 ]

I agree, this is probably a font issue, this is why I pointed the fact that my swing app has not this problem using SANS SERIF font, could you please test the installer using this font ?

BTW, do you reproduce under Windows or OSX ?

Thanks

Comment by Rene Krell [ 21/Feb/13 ]

This can't be really universally fixed in IzPack.

I made a lot of tests and example applications.
The problem is making the JRE choose the right font for the right component according to the given locale.

At first, the locale is typically set on the system.
Choosing the font is what typically has to be done by the Look-and-Feel(L&F) chosen. I f no L&F has been forced in <guiprefs>, the JRE default L&F is used.

A small test program showed that for instance

JLabel chineseJLabel = new JLabel("\u6B22\u8FCE\u4F7F\u7528\u0020\u0020Unicode\u0021");
chineseJLabel.setFont(new Font("Droid Sans Fallback", Font.PLAIN, 12));

showed the right chinese Unicode characters in OpenSUSE 12.2, but just when explictly overriding this name.

If we really added a font name we would need to override tenths of several font settings for each kind of component, since each component type can have its own fonts, thus labels, textareas, checkboxes, etc. In this case we'd already modified the original L&F, see http://nadeausoftware.com/node/85.
I wouldn't do this.

Shortly spoken:
A well-configured and localized system should show chines characters at least with the default L&F of the JRE. This means setting the system locale, installing chinese Unicode fonts and in worst case configure the JRE's font.properties.

Comment by Rene Krell [ 21/Feb/13 ]

There is no universal SANS SERIF font, there is a lot of them.
The solution can just be found on the particular target system.

I attached some Java example program for this, which you might compile and launch on the target system. For me it shows the following results:
Console:

Found chinese font: Droid Sans Fallback
Found chinese font: Droid Sans Japanese
chineseJLabel font: java.awt.Font[family=Droid Sans Fallback,name=Droid Sans Fallback,style=plain,size=12]

GUI:
See attached Unicode.png

I'd recommend to try what it does for you. You might report it also here.

Comment by Rene Krell [ 21/Feb/13 ]

If you have a font and an application which works for this, you might try to create your own L&F and call the installer in this way:

java -cp myLaf.jar -Dswing.defaultlaf=my.laf.MyLaf -jar myInstaller.jar

This L&F could be used for both, the installer and the application, but it would be still specific to your case.
And there might still be some effort customizing font.properties of the JRE.

See http://docs.oracle.com/javase/6/docs/api/javax/swing/UIManager.html.





[IZPACK-912] Missing translation of "TargetPanel.incompatibleInstallation" in german language Created: 11/Feb/13  Updated: 18/Oct/13  Resolved: 20/Feb/13

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

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

Attachments: File izpack-patch.diff    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Missing translation of "TargetPanel.incompatibleInstallation" in german language



 Comments   
Comment by Andreas Kuhtz [ 11/Feb/13 ]

Patch from pullrequest here: https://github.com/izpack/izpack/pull/86

Comment by Rene Krell [ 20/Feb/13 ]

Pull request after resolving conflicts with the latest HEAD merged and tested in 5.0.0-rc1-SNAPSHOT.

Thank you!





[IZPACK-911] IzPack should support multi-lingual desktop entry files Created: 08/Feb/13  Updated: 08/Feb/13

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

Type: Improvement Priority: Minor
Reporter: Michael Vehrs Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux


Number of attachments : 0

 Description   

The freedesktop standard defines multi-lingual desktop entry files, which are not supported by IzPack, severely limiting the utility of the feature. IzPack should allow the packager to specify any number of localizations in a single template, for instance by allowing character data in the shortcut element:

<shortcut name="whatever" ...>
Name[vi]=Chương Trình Thao Tác Ảnh GNU
Name[zh_CN]=GNU 囟像倄理皋序
Name[zh_HK]=GNU 圖片處理皋匏
Name[zh_TW]=GNU 圖片處理皋匏
GenericName[ar]=محرر صور
GenericName[ast]=Editor d'imaxe
GenericName[be]=РэЎактар віЎарысаў
GenericName[bg]=РеЎактПр Ма ОзПбражеМОя
</shortcut>






[IZPACK-910] Installer cannot write an Automated Installation File Created: 04/Feb/13  Updated: 22/Jul/14  Resolved: 04/Feb/13

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

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

Win7


Number of attachments : 0

 Description   

Whenever I try to let the FinishPanel create an XML file for automated installations in GUI mode, it throws this exception and makes an empty file:

04.02.2013 14:47:50 WARNUNG: Failed in constructor creating processor instance: java.lang.NullPointerException
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com/izforge/izpack/panels/imgpacks/ImgPacksPanelAutomationHelper
at com.izforge.izpack.panels.packs.PacksPanelBase.makeXMLData(PacksPanelBase.java:330)
at com.izforge.izpack.installer.gui.InstallerFrame.writeXMLTree(InstallerFrame.java:735)
at com.izforge.izpack.panels.finish.FinishPanel.actionPerformed(FinishPanel.java:172)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
at java.awt.Component.processMouseEvent(Component.java:6297)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3275)
at java.awt.Component.processEvent(Component.java:6062)
at java.awt.Container.processEvent(Container.java:2039)
at java.awt.Component.dispatchEventImpl(Component.java:4660)
at java.awt.Container.dispatchEventImpl(Container.java:2097)
at java.awt.Component.dispatchEvent(Component.java:4488)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4575)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4236)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4166)
at java.awt.Container.dispatchEventImpl(Container.java:2083)
at java.awt.Window.dispatchEventImpl(Window.java:2489)
at java.awt.Component.dispatchEvent(Component.java:4488)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:668)
at java.awt.EventQueue.access$400(EventQueue.java:81)
at java.awt.EventQueue$2.run(EventQueue.java:627)
at java.awt.EventQueue$2.run(EventQueue.java:625)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
at java.awt.EventQueue$3.run(EventQueue.java:641)
at java.awt.EventQueue$3.run(EventQueue.java:639)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:638)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: java.lang.ClassNotFoundException: com.izforge.izpack.panels.imgpacks.ImgPacksPanelAutomationHelper
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 41 more

I also tried the console variant -options-template to create an empty properties file template, but this throws a [ Console installation FAILED! ] at me and creates a file with only
InstallType=
INSTALL_PATH=
inside of it. The next element that should show would be the UserPathPanelVariable in my Installer, so I tested the same with a deactivated UserPathPanel.
This time I get a [ Console installation done ] and the elements
InstallType=
INSTALL_PATH=
jrejdkDir=
divider=
hostName=
space=
portSetOptions=
appDsHostName=
space=
appDsPort=
space=
appDsSid=
space=
appDsUser=
space=
appDsCheckConnection=
divider=
space=
confRepDS=
, but
a) there's still one UserInputPanel missing, and
b) running the installer in GUI mode does generate the exception and an empty XML file, again.
Deactivating the last UserInputPanel or the following PacksPanel does not change anything.

I could do an automated installation with izPack4.3.5, but now with izPack5.0.0-beta11 it doesn't work anymore.

P.S.: I also have a related question. When running the installer in console mode, the FinishPanel does not ask the user if he wants to create an automated installation file... should that happen automatically or is it not intended?



 Comments   
Comment by Rene Krell [ 04/Feb/13 ]

This is a duplicate of IZPACK-794 and is solved in 5.0.0-rc1-SNAPSHOT.

Comment by Sven Thomas [ 04/Feb/13 ]

Oh sorry, didn't see that.
Any idea on my P.S., though?

Comment by Rene Krell [ 04/Feb/13 ]

Regarding your P.S.: Unfortunately, for the console mode, creating the file with the installation record isn't implemented at all. You can add a feature request in Jira, hopefully there will be some time to do it or a contributor.

Comment by Rene Krell [ 22/Jul/14 ]

Creating the installation record from the console mode installation should work now, solved by Miles in IZPACK-1100.
Please give it a try and a feedback, whether this works for you. IzPack 5.0.0-rc3-SNAPSHOT needed for this at the moment.

Comment by Sven Thomas [ 22/Jul/14 ]

Now that is weird... we're using 5.0.0-rc2 for a while now, and this version already features the creation of a working automatic installation file in the console mode
The output is as follows:

Generate an automatic installation script <question mark missing>
Enter Y for Yes, N for No: Y
Select the installation script (path must be absolute)[<install_path>\autoInstall.xml]

Generating the file does create some "Unsupported panel: no automated helper associated?" warnings for InfoPanel, HTMLLicencePanel, LicencePanel and FinishPanel (among some self-created panels), though. While it makes sense that these have no automated helper (they are only informative), these warnings should be ignorable as they can confuse users.
Executing the installer with the script seems to work fine and outputs [ Automated installation done ] at the end.

When a newer release version of izPack is ready I can give feedback about whether Miles' solution improves or worsens the 5.0.0-rc2 implementation - we currently don't want to work with SNAPSHOT versions.





[IZPACK-909] Preloaded UserPathPanelVariable cannot be changed Created: 29/Jan/13  Updated: 31/Jan/13  Resolved: 31/Jan/13

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

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

Both SUSE and Win7


Number of attachments : 0

 Description   

Whenever I set the dynamicvariable UserPathPanelVariable in my install.xml - either by directly setting the default path oder by using the Ant property "@

{default.dest.dir.sql}

" as suggested by the official documentation - the installer is unable to change the variable during the installation process, which can also be observed while debugging.

When I remove the UserPathPanelVariable from the install.xml, the installer changes the attribute after the UserPathPanel as expected.

Imho you should be able to preload a default path, but still change it in the Panel... otherwise it's obsolete.

P.S.: I also tried exotic google-solutions like setting "UserPathPanel.dir.windows/unix", but these did not help, as well.



 Comments   
Comment by Rene Krell [ 29/Jan/13 ]

Can you add a handy example which can be run out of the box to avoid misunderstanding?
Are you using 5.0.0-beta11 or later?

Comment by Sven Thomas [ 30/Jan/13 ]

I'm building against 5.0.0-beta11 via the izpack-maven-plugin.

In the <dynamicvariables> the Variable is defined two times:
<variable name="UserPathPanelVariable" value="D:/portalproz" condition="izpack.windowsinstall"/>
<variable name="UserPathPanelVariable" value="~portalproz" condition="izpack.linuxinstall"/>
Changing it to a single occurence with value="@

{default.dest.dir.sql}

" didn't help.

The <panels> section contains amongst others:
<panel classname="TargetPanel" id="target"/>
<!-- Parameters -->
<panel classname="UserPathPanel" id="userpath"/>
<panel classname="UserInputPanel" id="UserInputPanel.1"/>

That's pretty much all I did for this Panel. It gets shown, but changing the String in the edit box doesn't alter the variable. If I delete the dynamicvariables, the installer does change the variable, but then it no longer has a default value, which I'd prefer to set.

Comment by Rene Krell [ 31/Jan/13 ]

I'm sorry, it is still not absolutely clear to me, how you do what.

Where do you define the property default.dest.dir.sql and where do you evaluate/read it? Where is the documentation you refer to? How is your UserInputPanel XML definition?
Instead of the poor snippet I'd appreciate a zipped complete example which is reduced to the problem, which can be compiled out of the box, including POM, install.xml and resources you include, along with the information what do you expect of it to do and what does it do for you currently. Otherwise it takes too much time for me to get the message here.

Please be aware that <properties> is not the same like <variables>, the compiled installer doesn't know property keys any longer and therefore can't replace them, they are replaced with their assigned values by the compiler. See
http://docs.codehaus.org/display/IZPACK/Variables
http://docs.codehaus.org/display/IZPACK/Properties
Properties are replaced at compile time. You can define properties in the POM or in the install.xml itself.

Comment by Sven Thomas [ 31/Jan/13 ]

I defined the default.dest.dir.sql property once for testing purposes in the installer's pom.xml as a property, and it correctly got substituted in the UserPathPanel. Changing it during the installation didn't alter the UserPathPanelVariable though, so please let's forget properties as a whole. I deleted the property and just want to use a variable
Documentation: https://izpack.github.io/documentation/panels.html#userpathpanel or http://docs.codehaus.org/display/IZPACK/The+available+panels, that's pretty much the same.
What has the userInputSpec.xml to do with the UserPathPanel? I thought it's only used by the UserInputPanel.

I cannot really provide the complete installer as it copies a lot of big files via an maven-antrun-plugin before the installer itself compiles and the software is not open source, so I'd have to obfuscate the paths and descriptions.

Let me again try to describe what I expect the UserPathPanel to do:
You define a (dynamic-)variable named UserPathPanelVariable in the install.xml and preset it with a value. During installation, the UserPathPanel displays this default path and lets the user change it. Going to the next panel actually changes the variable.
The last part does not happen unless I completely remove the UserPathPanelVariable from the install.xml.

I thought this should be a very simple process, but either I missed something important or it's bugged in beta11.
Ofc it would be possible to make a regular UserInputPanel to do the same (provide a second directory into which some files get copied), but I wanted to use what izpack already provides.

Comment by Rene Krell [ 31/Jan/13 ]

You can't change a property during installation, just variables. This is a significant difference. The substitution is made during compile time, and @

{key}

doesn't appear in this form any longer in the packaged installer, if key is a valid property already during compilation.
Therefore I'd like to have a running example for this, this should explain a lot.

Comment by Sven Thomas [ 31/Jan/13 ]

Yeah but... I don't use any properties in my installer.

Paste from first comment:
<variable name="UserPathPanelVariable" value="D:/portalproz" condition="izpack.windowsinstall"/>
<variable name="UserPathPanelVariable" value="~portalproz" condition="izpack.linuxinstall"/>

That's it. Using the property was just a test that I already removed both from the pom.xml and the install.xml, that's why I begged you to forget the properties

Comment by Rene Krell [ 31/Jan/13 ]

The documentation you referred to is the old one, for IzPack 4. Please check the new one: http://docs.codehaus.org/display/IZPACK/User+documentation

Explanation;

<variable name="UserPathPanelVariable" value="@{default.dest.dir.sql}"/>

This is a mapping of the properties (static) value at compile time to a static, initial variable value, which applies at installation time. During installation, you can just access variables, which means you must use
variable="UserPathPanelVariable"
in user input panel definitions and
${UserPathPanelVariable}
everywhere you want to access it.

Is this the way you are using it?

Comment by Rene Krell [ 31/Jan/13 ]

Ok, I got the message. Have been just confused because you repeatedly mentioned @

{default.dest.dir.sql}

.

Comment by Rene Krell [ 31/Jan/13 ]

The reason seems probably to be, that you use <dynamicvariables>. This element collects variables which are automatically updated on each panel change. Try using the "classic" <variables>, instead.

If there is really a need to use dynamic variables and not "classic" variables use <variable ... checkonce=true/>, see http://docs.codehaus.org/display/IZPACK/Dynamic+Variables

Comment by Sven Thomas [ 31/Jan/13 ]

Thought so =) I just tested the version with default.dest.dir.sql because I wanted to know if the UserPathPanelVariable value [b]needs[/b] to be set by a property, even though that didn't really make sense to me... but I experimented a lot to fix the problem myself.

Now I am confused because you mention the user input panel a second time... why is that of relevance to the UserPathPanel?

The new documentation doesn't list it under http://docs.codehaus.org/display/IZPACK/Built-in+Panel+Types btw, it's only in the doc for version 4... it's still there though, I checked out izpack5 from git and looked for it.

Edit because of your last comment: Ok I will test that... the regular variables don't allow the use of conditions, though, am I right? That's why I've put it into the dynamic part.

Comment by Rene Krell [ 31/Jan/13 ]

This isn't really a bug, if it still doesn't work for <variables> instead of <dynamicvariables> please reopen.

Comment by Rene Krell [ 31/Jan/13 ]

Unfortunately, "classic" variables don't evaluate conditions, like described in http://docs.codehaus.org/display/IZPACK/Variables. In this case you'll need <dynamicvariables> in combination with the <variable ... checkonce="true"> setting.

If you see some mess in the documentation let me know or you are invited to edit it, too

Comment by Sven Thomas [ 31/Jan/13 ]

Thanks a lot for your help, I could resolve the issue now.

My observations: The UserPathPanelVariable needs to be in the <variables> element if you want to preload it. Putting it under <dynamicvariables> prevents the UserPathPanel from changing it, even if you add the attribute checkonce="true"!

If this is the desired behavior and not a bug (at least not intuitive imho ), this workaround is possible if you have to check for conditions (for example different operating systems):
<variables>
<variable name="UserPathPanelVariable" value="$

{UserPath}

"/>
</variables>
<dynamicvariables>
<variable name="UserPath" value="D:/myDir" condition="izpack.windowsinstall"/>
<variable name="UserPath" value="~myDir" condition="izpack.linuxinstall"/>
</dynamicvariables>

The documentation should contain a page for the UserPathPanel with information on how to preload the variable while also asking for conditions, because I think that this is a common thing to do if you use the Panel in a multiplatform environment.
I'd edit it myself now, but I am really in a hurry to prepare the software for a fair next week

Comment by Rene Krell [ 31/Jan/13 ]

Good clue, how you solved it

You are right, currently dynamic variables are stored separately from "classic" variables. There were some intentions to unite them by keeping the features dynamic variables provide now and using a united element <variables> for them, unfortunately there hasn't been time for it. Anyone can send a pull request if he/she wants

You are also right with the documentation - the panel documentation is still incomplete, the mentioned panel is missing. Anyone can register at Codehaus Confluence and help here.

Thank you!





[IZPACK-908] Uninstaller not written correctly if installer JAR is wrapped with launch4j Created: 25/Jan/13  Updated: 31/Jan/13  Resolved: 25/Jan/13

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

Type: Bug Priority: Major
Reporter: Johan Kaving Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Number of attachments : 0

 Description   

If the installer JAR file produced by IzPack is wrapped using launch4j (http://launch4j.sourceforge.net) to produce a ".exe"-file, the uninstaller will not be written correctly.

This is caused by com.izforge.izpack.merge.jar.JarMerge using JarInputStream to get the resources from the installer JAR (which in this case is a ".exe"-file).
JarInputStream cannot read the ".exe" so no entries are merged from it and the resulting uninstaller will be missing most files.



 Comments   
Comment by Johan Kaving [ 25/Jan/13 ]

Duplicates IZPACK-907.

Some kind of glitch made JIRA not show the newly created issue, so I unfortunately managed to create two.

Comment by Johan Kaving [ 25/Jan/13 ]

I am working on a patch - will provide a pull request on GitHub.





[IZPACK-907] Uninstaller not written correctly if installer JAR is wrapped with launch4j Created: 25/Jan/13  Updated: 18/Oct/13  Resolved: 28/Jan/13

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

Type: Bug Priority: Major
Reporter: Johan Kaving Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Number of attachments : 0

 Description   

If the installer JAR file produced by IzPack is wrapped using launch4j (http://launch4j.sourceforge.net) to produce a ".exe"-file, the uninstaller will not be written correctly.

This is caused by com.izforge.izpack.merge.jar.JarMerge using JarInputStream to get the resources from the installer JAR (which in this case is a ".exe"-file).
JarInputStream cannot read the ".exe" so no entries are merged from it and the resulting uninstaller will be missing most files.



 Comments   
Comment by Johan Kaving [ 25/Jan/13 ]

I have created a pull request containing a fix here:
https://github.com/izpack/izpack/pull/83

Comment by Rene Krell [ 28/Jan/13 ]

Thank you!





[IZPACK-906] Optional user input panel type which is self-rendering from HTML/XML using some standard framework Created: 25/Jan/13  Updated: 25/Jan/13

Status: Open
Project: IzPack
Component/s: None
Affects Version/s: 6.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   

Just an idea: introduce new type of user input panels which do self rendering from a HTML/XML template using a standard framework like:






[IZPACK-905] Add support to set the"Run As Administrator" flag on Windows shortcuts Created: 22/Jan/13  Updated: 18/Oct/13  Resolved: 05/Feb/13

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

Type: New Feature Priority: Minor
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

On Windows Vista, XP, Windows 7 and Windows 8, it should be possible to set the "Run As Administrator" flag on Windows shortcuts at installation.



 Comments   
Comment by Tim Anderson [ 04/Feb/13 ]

Pull request is at https://github.com/izpack/izpack/pull/84

The flag is set by adding runAsAdministrator="true" to the shortcut specification e.g.:

    <shortcut name="Start"
              target="$INSTALL_PATH\bin\start.bat"
              iconFile="$INSTALL_PATH\bin\foo.ico"
              iconIndex="0"
              workingDirectory="$INSTALL_PATH"
              commandLine="start"
              description="Start Foo"
              initialState="normal"
              programGroup="yes"
              desktop="no"
              startMenu="no"
              runAsAdministrator="true"/>
Comment by Philip Donner [ 08/May/13 ]

...





[IZPACK-904] Installer not able to start in privileged mode under Windows 8 Created: 21/Jan/13  Updated: 31/Mar/14

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

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

Windows 8


Attachments: PNG File Image174.png    
Number of attachments : 1

 Description   

An installer generated with IzPack 5.0.0-beta11 to run in privileged mode under Windows 8 does not start in privileged mode. Receives a "Microsoft Windows Based Script Host" error. See attached screen shot.

Installer configuration:
<run-privileged condition="izpack.windowsinstall.vista|izpack.windowsinstall.7|izpack.windowsinstall.8" />

See attached screenshot.



 Comments   
Comment by Sébastien Christy [ 31/Mar/14 ]

I don't reproduce this bug (tested with IzPack 5.0.0-beta11 and rc2).





[IZPACK-903] Installer file name has too many hyphens when generated with a Maven classifier Created: 21/Jan/13  Updated: 18/Oct/13  Resolved: 22/Jan/13

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

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

Apache Maven 3.0.3 (r1075438; 2011-02-28 10:31:09-0700)
Maven home: C:\Users\mvsoder\Programs\maven\3.0.3
Java version: 1.7.0_10, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_10\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"


Number of attachments : 0

 Description   

When using the IzPack 5.0.0-beta11 Maven plugin to generate an installer using a classifier ( two hyphens were inserted into the file name of the deployed artifact. Expected: escape-2.0.0-SNAPSHOT-install.jar but was: escape-2.0.0-SNAPSHOT--install.jar. When I remove the classifier, the name is simply escape-2.0.0-SNAPSHOT.jar

The IzPack plugin configuration for Maven:
<plugin>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-maven-plugin</artifactId>
<version>5.0.0-beta11</version>
<executions>
<execution>
<id>izpack.deploy</id>
<phase>package</phase>
<goals>
<goal>izpack</goal>
</goals>
<configuration>
<installFile>$

{basedir}

/target/main/izpack/installer.xml</installFile>
<baseDir>$

{project.build.directory}

</baseDir>
<classifier>install</classifier>
</configuration>
</execution>
</executions>
</plugin>



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

Successfully tested and merged your pull request in 5.0.0-rc1-SNAPSHOT.
Nice work. Thank you, Mark!





[IZPACK-902] HTML User Input Panels with JavaScript to modify variables Created: 17/Jan/13  Updated: 17/Jan/13

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

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 the static user input panels as they exist now there could be HTML user input panels with JavaScript support which might set IzPack variables or conditions directly.

Just a rough idea at the moment. Not relevant for 5.0.






[IZPACK-901] Maven plugin documentation and usage site builds broken Created: 16/Jan/13  Updated: 16/Jan/13

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

Type: Bug 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   

The auto-generated sites
http://izpack.codehaus.org/izpack-maven-plugin/
and
http://izpack.codehaus.org/izpack-maven-plugin/usage.html
are not up to date. Site building seems to be broken with the current builds






[IZPACK-900] Izpack 5.0 installer doesnt let you overwrite an Izpack 1.0 installer (Izpack 4.3.6) Created: 16/Jan/13  Updated: 16/Jan/13

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

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

Windows 7


Number of attachments : 0

 Description   

The way Izpack 4.3.6 worked was that when a new version of my application was available users could just install the new version over the top of the older version. However with Izpack 5.0 although I can install over another Izpack 5.0 installation I am unable to install over a 4.3.6 installation it gives the error

'Incompatible Installation detected:Uninstall first or choose another directory to install to'.

What is the point of this restriction ?

The problem is particulary bad for me because my 4.3.6 version of my application does not comes with a uninstaller installed in Program and Features because I couldn't undertsand how to do that when I wrote the installer.






[IZPACK-899] Unable to add to Windows Registry with 64bit installtion Created: 16/Jan/13  Updated: 16/Jan/13  Resolved: 16/Jan/13

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

Type: Bug Priority: Major
Reporter: Paul Taylor Assignee: Unassigned
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Number of attachments : 0

 Description   

Using Izpack 5 beta 11 all I needed to do to get my application added to Program and Features on Windows 7 was to add the following to my install.xml

<listeners>
<listener classname="RegistryInstallerListener" stage="install"/>
<listener classname="RegistryUninstallerListener" stage="uninstall"/>
</listeners>

(Note:despite what wiki says no longer seems requirement to add COCOIHelper.DLL which I cannot find anyway)

Unfortunately if I install a 64bit version, using a wrapper (from launch4j) and 64bit JVM so it correctly puts the application in C:/Program Files rather than C:/Program Files (x86) I get the following exception:

Internal error ocurred:com.izforge.izpack.api.exception.WrappedNativeLibException



 Comments   
Comment by Paul Taylor [ 16/Jan/13 ]

Sorry, fund the issue i did need to do

<natives>
<native type="3rdparty" name="COIOSHelper.dll" stage="both">
</native>
</natives>

after all for 32-bit, and chnage to

<natives>
<native type="3rdparty" name="COIOSHelper_x64.dll" stage="both">
</native>
</natives>

for 64-bit, now working.





[IZPACK-898] Console installations - floods output with warnings due to undefined conditions Created: 16/Jan/13  Updated: 16/Jan/13

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   

If the installer is called with -console, there a mess of warnings kind of

...
[ Starting to unpack ]
Jan 16, 2013 10:46:21 AM WARNING: Condition isCompatibleUpgrade not found
[ Processing package: My Application Core (1/2) ]
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade+previous.version.3.set not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade+previous.version.3.set not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade+previous.version.4.set not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade+previous.version.4.set not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade not found
Jan 16, 2013 10:46:22 AM WARNING: Condition isCompatibleUpgrade not found
[ Processing package:  (2/2) ]
Jan 16, 2013 10:46:25 AM INFO: Cleaning up the target folder ...
Calling ANT with buildfile: /tmp/buildfile_resource2053168693175672295xml
[ Unpacking finished ]
...

The level of this message should be shifted to DEBUG, this is very annoying.






[IZPACK-897] maven plug-in documentation site shows version 5.0 but sample is 4.3.1 Created: 15/Jan/13  Updated: 15/Jan/13

Status: Open
Project: IzPack
Component/s: Documentation
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

Number of attachments : 0

 Description   

The maven plug-in site says that it is 5.0.10 but the samples are 4.3.1
Would it be possible to add a 5.0 version in the samplesÉ






[IZPACK-896] Maven plug-in default install.xml location needs to be outside target Created: 15/Jan/13  Updated: 15/Jan/13

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

Type: Improvement 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

Number of attachments : 0

 Description   

maven clean wipes out install.xml.
This is not a good thing. Not even the first time!
Could the documentation and examples move install.xml to some other place that is a bit saferÉ






[IZPACK-895] Folders specified in pack have to be specified with full path with Izpack 5 Created: 13/Jan/13  Updated: 13/Jan/13

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

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

Windows 7, Izpack 5.0.0 beta 11


Number of attachments : 0

 Description   

Folders specified in pack have to be specified with full path (individual files can continue to use relative path) when I moved form Izpack 4 to Izpack 5.

i.e I had to change
<file src="../../target/Jaikoz/activebuild/buildWindows/lib" targetdir="$INSTALL_PATH"/>

to

<file src="C:/Code/Jaikoz/target/Jaikoz/activebuild/buildWindows/lib" overwrite="true" targetdir="$INSTALL_PATH"/>

othewrwise it just created an empty folder.






[IZPACK-894] overwrite="true" now reuired in install.xml to overwrite existing files Created: 13/Jan/13  Updated: 13/Jan/13

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

Type: Bug Priority: Major
Reporter: Paul Taylor 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   

overwrite="true" now required in install.xml to overwrite existing files, in Izpack 4 it was the default. It should be the default because if installing an application over an older version you would expect all files to be updated to the most recent version.






[IZPACK-893] Unpacking Multiple Zip Files With Similar Folder Structure Fails Created: 20/Dec/12  Updated: 18/Oct/13  Resolved: 02/Aug/13

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

Type: Bug Priority: Major
Reporter: John Mitchell Assignee: Rene Krell
Resolution: Fixed Votes: 1
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: Java Source File CompilerConfig.java     Java Source File CompilerConfigTest.java     Zip Archive JRE7_10-64bit - Copy.zip     PNG File UnZipedFoldersGetCreatedInBaseDir.png    
Number of attachments : 4

 Description   

When trying to package apache-tomcat-7.0.34-64bit.zip, and JRE7_10-64bit.zip using the unpack="true" option I am reviving this error:

Exception in thread "main" java.lang.AssertionError: com.izforge.izpack.api.exception.CompilerException: Failed to creat
e directory: bin
        at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:184)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
        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:84)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: com.izforge.izpack.api.exception.CompilerException: Failed to create directory: bin
        at com.izforge.izpack.compiler.CompilerConfig.processFileChildren(CompilerConfig.java:1101)
        at com.izforge.izpack.compiler.CompilerConfig.addPacksSingle(CompilerConfig.java:816)
        at com.izforge.izpack.compiler.CompilerConfig.addPacks(CompilerConfig.java:704)
        at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:321)
        at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:180)
        ... 21 more
Caused by: com.izforge.izpack.api.exception.CompilerException: Failed to create directory: bin
        at com.izforge.izpack.compiler.CompilerConfig.addArchiveContent(CompilerConfig.java:1480)
        at com.izforge.izpack.compiler.CompilerConfig.processFileChildren(CompilerConfig.java:1084)
        ... 25 more

I believe this is due to the unpacking being performed for both files in the basedir directory. When CompilerConfig.addArchiveContent(CompilerConfig.java:1480) tries to create folders for the second zip it will fail on any same named folder.

Pom:

<dependency>
  <groupId>org.codehaus.izpack</groupId>
  <artifactId>izpack-maven-plugin</artifactId>
  <version>5.0.0-beta11</version>
</dependency>

Install.xml:

<?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
<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 https://izpack.github.io/schema/5.0/izpack-installation-5.0.xsd">

  <info>
    <appname>Test Project</appname>
    <appversion>1.0</appversion>
  </info>

  <locale>
    <langpack iso3="eng" />
  </locale>

  <panels>
    <panel classname="InstallPanel" id="InstallPanel.1"/>
  </panels>

  <packs>
    <pack name="Update" required="yes" id="Update">
      <description>Test Pack</description>
      <file unpack="true"
        src="target/artifacts/installer/apache-tomcat-7.0.34-64bit-custom.zip"
        targetdir="$INSTALL_PATH/.server"
        override="true"/>
      <file unpack="true"
        src="target/artifacts/installer/JRE7_10-64bit.zip"
        targetdir="$INSTALL_PATH/.java"/>
    </pack>
  </packs>

</izpack:installation>


 Comments   
Comment by John Mitchell [ 20/Dec/12 ]

It also looks like if you just try the JRE7_10-64bit.zip it will error out on any nested folders. For example there is a root/bin folder that has other folders. When trying to unpack it will fail on the bin folder. If i remove all sub folders within the root/bin folder it will then fail on the next folder that has sub folders.

Please let me know if you need any additional information.

Comment by John Mitchell [ 07/Jan/13 ]

File to use for quick unit test

Comment by John Mitchell [ 07/Jan/13 ]

I'm not sure the best way to get this information to you, so if there is a preferred way I'm not using please let me know.

I have found that when the index for the zip file lists subfolders before root folders it will cause the izpack unzip to fail. Adding a simple sort before the attempt corrects the issue.

Index that will cause the unzip to fail:
bin/server
bin

Index that will work:
bin
bin/server

UnitTest added to com.izforge.izpack.compiler.CompilerConfigTest

    @Test
    public void shouldUnPackNestedFolders() throws IOException{
      PackInfo packInfo = new PackInfo("Main Application", "Test App", "Test App", true, false, null, false, 0);
      File baseDir = new File("C://");
     File archive = new File("C://development//BuildStuff//JRE7_10-64bit - Copy.zip");
     String targetDir = "C://";

      compilerConfig.addArchiveContent(baseDir, archive, targetDir, null, OverrideType.OVERRIDE_UPDATE, "",
          Blockable.BLOCKABLE_NONE, packInfo, null, null);

    }

Code that corrects the issue in CompilerConfig:

        // This corrects issues that could arise due to subfolders
        Collections.sort(allDirList);
        for (String dirName : allDirList)
        {
            File tmp = new File(dirName);
            if (!tmp.mkdirs()) { throw new CompilerException("Failed to create directory: " + tmp); }
            tmp.deleteOnExit();
            String target = targetdir + "/" + dirName;
            logger.info("Adding file: " + tmp + ", as target file=" + target);
            pack.addFile(baseDir, tmp, target, osList, override, overrideRenameTo, blockable,
                    additionals, condition);
        }
Comment by John Mitchell [ 07/Jan/13 ]

The updated CompilerConfig

Comment by John Mitchell [ 07/Jan/13 ]

Sample test. I would not commit this, but it was just a simple test.

Comment by Bruno F [ 01/Aug/13 ]

Thank you John for reporting the bug and pointing out the problematic source file. I hit the same bug as well with my setup.
Your fix is not enough, here is what I did to make it work:

Before (your fix):

CompilerConfig.java
        // This corrects issues that could arise due to subfolders
        Collections.sort(allDirList);
        for (String dirName : allDirList)
        {
            File tmp = new File(dirName);
            if (!tmp.mkdirs()) { throw new CompilerException("Failed to create directory: " + tmp); }
            tmp.deleteOnExit();
            String target = targetdir + "/" + dirName;
            logger.info("Adding file: " + tmp + ", as target file=" + target);
            pack.addFile(baseDir, tmp, target, osList, override, overrideRenameTo, blockable,
                    additionals, condition);
        }

After (your fix and mine):

CompilerConfig.java
        // This corrects issues that could arise due to subfolders
        Collections.sort(allDirList);
        for (String dirName : allDirList)
        {
            File tmp = new File(dirName);
            // File.mkdirs() returns false when called on a directory that already exists
            if (!tmp.exists()) {
                if (!tmp.mkdirs()) { throw new CompilerException("Failed to create directory: " + tmp); }
                tmp.deleteOnExit();
            }
            String target = targetdir + "/" + dirName;
            logger.info("Adding file: " + tmp + ", as target file=" + target);
            pack.addFile(baseDir, tmp, target, osList, override, overrideRenameTo, blockable,
                    additionals, condition);
        }
Comment by Rene Krell [ 01/Aug/13 ]

Hi Bruno, can you please make a pull request against the current HEAD containing your pre-tested fix?

Comment by Bruno F [ 01/Aug/13 ]

Hi Rene, I'd love to but I don't know how to do so. I just downloaded a tarball of the code from https://github.com/izpack/izpack
Is there a procedure described somewhere? Or alternatively shall I attach the source code to the JIRA?

Comment by Rene Krell [ 01/Aug/13 ]

In this issue it is just a small change, I can apply it manually. For the future, if you'd like to make more contributions, it would make sense to register on Github, for the izpack/izpack repository there and make your local copy and push you local changes as pull request to izpack/izpack. There are several manuals on Github and elsewhere, for example here: https://help.github.com/articles/using-pull-requests and here: https://help.github.com/articles/fork-a-repo.
You should be familar with the basics of Git to work with pull requests. For us its the best way to keep track of changes and contributors.

Please make a local branch with the name IZPACK-893, check it out and make just the changes for the according issue in this branch, nothing else, to have a clean changelog. After it, send the changes in the branch as pull request. On accepting the reuqest the branch is remotely automatically deleted and you can delete it also in your local copy if you want.

Please let me know, whether I should apply your change for now manually or whether you try to make already a pull request for it.

Comment by Bruno F [ 01/Aug/13 ]

Thanks for the clear explanations! I created a github account, forked and cloned the repo, created an IZPACK-893 local branch, built izpack (mvn install), tested it on my own setup (works), commited and pushed changes back to github. In the github web interface, I switched to my branch, clicked the "review" button (changes are what I expected), click the "Initiate pull request" button and now I see a "Send pull request" green button and something telling me that I a about to do an action on the following branches:
izpack:master ... bfreuden:IZPACK-893
Does it sound OK to you? Shall I click the "Send pull request" button?
I apologize for requesting your help for so stupid things... Just the first time for me on github... :-\

Comment by Rene Krell [ 02/Aug/13 ]

I suppose yes Give it a try, the developers are automatically informed on incoming pull requests, and an automatic verification is automatically launched by the build system to ensure compilation, unit and integration tests work on defined platforms.

I created a Confluence page: http://docs.codehaus.org/display/IZPACK/Contributing+Code+Changes
You can enhance it with mor detailled descriptions of single steps, if you want. This might help many other contributors which are new to Github.

Thank you

Comment by Bruno F [ 02/Aug/13 ]

Ok. I've just sent the pull request!
Thank you as well

Comment by Rene Krell [ 02/Aug/13 ]

It worked out, congrats
There is still some space for improvements of the latest commit, see my comments on the pull request (https://github.com/izpack/izpack/pull/124).

Comment by Bruno F [ 02/Aug/13 ]

Thanks!
You're right: I've just issued another pull request (in the same branch).

Comment by Rene Krell [ 02/Aug/13 ]

Yes, it updated the same pull request instead of opening a new one, as expected. Well done.
Have you tested it with your example installer?

Comment by Rene Krell [ 02/Aug/13 ]

As discussed and seen on Github, the pull request seems to be ok now.
Thank you.

Will make a snapshot deployment, soon.





[IZPACK-892] Run privileged Installation fails on second run Created: 19/Dec/12  Updated: 19/Dec/12

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

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

OSX Lion


Number of attachments : 0

 Description   

When running the installer a second time the installer fails with a message
The directory cannot be written!

Tried the same without the run-privileged option and it works fine.






[IZPACK-891] When clicking on 'Back' then 'Next' the installer panel's contents are not displayed Created: 14/Dec/12  Updated: 18/Jul/13

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

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

Windows


Number of attachments : 0

 Description   

At the last panel of an IzPack installer, when clicking on 'Back' and then on 'Next',
the panel does not display its contents.



 Comments   
Comment by Martin Grihangne [ 14/Dec/12 ]

Additional details:

The problem occurs when navigating through the installer according to this sequence :

  • Next -> ShortcutPanel
  • Next -> FinishPanel (contents are correctly displayed)
  • Back -> Shortcutpanel
  • Next -> Finishpanel (contents are not displayed anymore)
    At this point the panel does not display its contents.
Comment by Pascale ANDRIANATREHANA [ 18/Jul/13 ]

Hi,

What is the status of this bug ?
Could it be planned for a future version ?

Thanks





[IZPACK-890] Uninstaller not working if an executable must be executed on uninstall stage Created: 14/Dec/12  Updated: 14/Dec/12

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

Type: Bug Priority: Major
Reporter: Massimiliano Ziccardi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: exception
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested on Windows XP


Number of attachments : 0

 Description   

I met this bug using the maven plugin version 5.0.0-beta-11 to create the installer.

If for example you put the following code inside your install.xml file:

<pack name="Service remover" required="no">
  <os family="windows"/>
  <description>Removes the Window Service</description>
  <executable targetfile="$INSTALL_PATH/native/wrapper.exe"
       stage="uninstall" keep="true">
    <args>
       <arg value="-r"/>
       <arg value="$INSTALL_PATH/wrapper.conf"/>
    </args>
  </executable>
</pack>

Than, when you run the uninstaller jar you get the following error:

java.lang.ClassNotFoundException: com.izforge.izpack.data.ExecutableFile
at java.net.URLClassLoader$1.run(Unknown Source)
...removed java stacktrace because I can't cut&paste...
at com.izforge.izpack.uninstaller.Destroyer.getExecutablesList(Destroyer.java:213)
at com.izforge.izpack.uninstaller.Destroyer.run(Destroyer.java:87)





[IZPACK-889] MultiVolumePackagerTest creates empty unstaged .pak file which messes up git Created: 13/Dec/12  Updated: 18/Oct/13  Resolved: 19/Dec/12

Status: Resolved
Project: IzPack
Component/s: Build
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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

After testing izpack-compiler I always get the following unstaged files

  • .pak (created by MultiVolumePackagerTest)
  • output.jar
  • out.zip
    which mess up git, because they are unstaged and unknown.
    Furthermore, the .pak file can't be seen in the Eclipse package explorer, which is the more annoying.





[IZPACK-888] After releasing or cloning, compilation fails due to not installed, self-contained artifacts Created: 13/Dec/12  Updated: 18/Oct/13  Resolved: 19/Dec/12

Status: Resolved
Project: IzPack
Component/s: Build
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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

As long as there is not installed/deployed the current version along with the POMs in the sources in a local or remote repository, the compilation or a simple mvn:clean of izpack-dist fails.

Example - POM version is 5.0.0-rc1-SNAPSHOT:

[INFO] ------------------------------------------------------------------------
[INFO] Building IzPack dist module
[INFO]    task-segment: [clean]
[INFO] ------------------------------------------------------------------------
[INFO] snapshot org.codehaus.izpack:izpack-maven-plugin:5.0.0-rc1-SNAPSHOT: checking for updates from nexus.plugin.snapshots
Downloading: http://nexus.mycompany.com/content/groups/public-snapshots/org/codehaus/izpack/izpack-maven-plugin/5.0.0-rc1-SNAPSHOT/izpack-maven-plugin-5.0.0-rc1-SNAPSHOT.jar
[INFO] Unable to find resource 'org.codehaus.izpack:izpack-maven-plugin:maven-plugin:5.0.0-rc1-SNAPSHOT' in repository nexus.plugin.snapshots (http://nexus.mycompany.com/content/groups/public-snapshots)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository

Try downloading the file manually from the project website.

Then, install it using the command:
    mvn install:install-file -DgroupId=org.codehaus.izpack -DartifactId=izpack-maven-plugin -Dversion=5.0.0-rc1-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there:
    mvn deploy:deploy-file -DgroupId=org.codehaus.izpack -DartifactId=izpack-maven-plugin -Dversion=5.0.0-rc1-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  org.codehaus.izpack:izpack-maven-plugin:maven-plugin:5.0.0-rc1-SNAPSHOT
...

As long as 5.0.0-rc1-SNAPSHOT isn't locally installed or deployed, the self-contained izpack-maven-plugin cannot be found.

This is also shown in Eclipse when refreshing or opening the appropriate IzPack source project.



 Comments   
Comment by Rene Krell [ 13/Dec/12 ]

A similar problem occurs in izpack-test with:

        <dependency>
            <!-- required by IzpackGenerationTest -->
            <groupId>${project.groupId}</groupId>
            <artifactId>izpack-dist</artifactId>
            <classifier>sources</classifier>
        </dependency>
...
        <dependency>
            <groupId>${project.groupId}</groupId>
            <artifactId>izpack-uninstaller</artifactId>
            <classifier>tests</classifier>
        </dependency>

The dependencies with classifiers are unmanaged and accessed on each compilation, not only on demand.
izpack-dist:sources cannot be found when not previously installed or deployed.

Comment by Rene Krell [ 13/Dec/12 ]

If the above is fixed, another problem occurs in this situation in izpack-test:
maven-dependency-plugin:unpack can't find izpack-dist:sources

Use this one instead:

<execution>
   <!-- copies sources from izpack-dist to test-classes/samples/izpack -->
   <!-- for IzpackGenerationTest, IzpackInstallationTest               -->
   <id>Unpack izpack installer files</id>
   <phase>process-resources</phase>
   <goals>
       <goal>unpack-dependencies</goal>
   </goals>
   <configuration>
       <includeArtifactIds>izpack-dist</includeArtifactIds>
       <includeClassifiers>sources</includeClassifiers>
       <excludeTransitive>true</excludeTransitive>
       <outputDirectory>${basedir}/target/test-classes/samples/izpack</outputDirectory>
   </configuration>
</execution>




[IZPACK-887] Previous button must be disabled once the installation has begun Created: 13/Dec/12  Updated: 13/Dec/12

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

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

Windows 7


Number of attachments : 0

 Description   

This is in continuation to issue 3 in

https://groups.google.com/forum/#!searchin/izpack-user/previous$20button/izpack-user/c1aelGMk09s/emnkK_eqhuEJ

Once the installation is started, previous button must be disabled, so that user does not go to the previous panel. Currently, it is enabled and if the user goes to previous panel and comes to installation panel again, the installation starts all over again, resulting in failure of installation.






[IZPACK-886] Compile-time check for existing panel id's from installation descriptor in UserInputPanel definitions Created: 07/Dec/12  Updated: 12/Dec/12  Resolved: 12/Dec/12

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

Type: New Feature 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   

User input panels are currently integrated into an installation as follows (example):
install.xml

<panels>
    ...
    <panel classname="UserInputPanel" id="container.installation.selection.panel"/>
    <panel classname="UserInputPanel" id="new.container.path.selection.panel" condition="new.container"/>
    <panel classname="UserInputPanel" id="existing.container.path.selection.panel" condition="existing.container"/>
    ...
  </panels>

userInputSpec.xml:

<userInput>
  <panel id="container.installation.selection.panel" ...>
    ...
  </panel>

  <panel id="new.container.path.selection.panel" ...>
    ...
  </panel>

  <panel id="existing.container.path.selection.panel" ...>
    ...
  </panel>
  ...
</userInput>

Currently, there is no compile time check, whether the panel id's in install.xml actually exist in the appropriate userInputSpec.xml. Instead, an error message is emitted during the installation on panel change (User input specification could not be found) and the panel with the bad or missing id is skipped.

The panel id's are consistent at compile time and should be check already here.



 Comments   
Comment by Rene Krell [ 12/Dec/12 ]

Another check concerns duplicate panel IDs in the resource userInputSpec.xml.

Comment by Rene Krell [ 12/Dec/12 ]

Placed a pull request at https://github.com/izpack/izpack/pull/79 with the according changes.

Comment by Rene Krell [ 12/Dec/12 ]

No considering IzPack 4 any longer for this feature.





[IZPACK-885] Remove parsing of panel.order attribute in userInputSpec.xml, require panel.id instead Created: 07/Dec/12  Updated: 07/Dec/12  Resolved: 07/Dec/12

Status: Resolved
Project: IzPack
Component/s: Panels
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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to IZPACK-884 Console installations: Bad user input... Resolved
Number of attachments : 0

 Description   

The panel.order attribute in userInputSpec.xml doesn't make any sense. The documentation says:
This is the order number of the user input panel for which this specification should be used. Counting starts at 0 and increments by 1 for each instance of the user input panel. If a spec should be used for the second occurrence of the user input panel use order="1".
Actually, the order of user input panels are given by the order they are defined within

<panels>...</panels>

and addtionally depending on panel conditions they might depend on. That's really sufficient and explicitly assigning an order to the panel definitions is ambigous.



 Comments   
Comment by Rene Krell [ 07/Dec/12 ]

Link to an issue, which shows the broken usage of the order attribute especially for console installations.





[IZPACK-884] Console installations: Bad user input panel order when using panel conditions Created: 06/Dec/12  Updated: 07/Dec/12  Resolved: 07/Dec/12

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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to IZPACK-885 Remove parsing of panel.order attribu... Resolved
Testcase included: yes
Number of attachments : 0

 Description   

During console installations (only), there are not correctly applied panel conditions and panel contents might occur in a bad order and not depending on a fulfilled panel condition.

Example:

userInputSpec.xml:

<userInput>
  <!-- WEB Container installation option -->
  <panel order="0" id="container.installation.selection.panel">
    <field type="title" txt="Container Installation Option" id="container.installation.selection.panel.title"/>
    <field type="check" variable="use.old.container">
      <description align="left" txt="Check if you want to use already installed container" id="container.option.check.description"/>
      <spec txt="Use existing container installation" id="container.option.check.label" true="yes" false="no" />
    </field>
  </panel>

  <!-- WEB Container installation path selection (for new installation) -->
  <panel order="1" id="new.container.path.selection.panel">
    <field type="title" txt="New Container Installation Setting" id="new.container.path.selection.panel.title"/>
    <field type="radio" variable="container.type">
      <description align="left" txt="Choose Container Type" id="container.option.radio.description"/>
        <spec>
          <choice txt="Apache Tomcat" id="tomcat.option.radio.label" value="tomcat" set="true" />
        </spec>
    </field>
    <field type="staticText" align="left" id="container.home.field" txt="Select Container Home Path"/>
    <field type="dir" align="left" variable="container.home">
      <spec txt="" size="25" set="" mustExist="true" create="true"/>
    </field>
    <field type="staticText" align="left" id="container.distribution.package.field" txt="Choose Container Distribution Package"/>
    <field type="file" align="left" variable="container.distribution.package">
      <spec txt="" size="25" set="" />
    </field>
  </panel>

  <!-- WEB Container installation path selection (for already existing installation) -->
  <panel order="2" id="existing.container.path.selection.panel">
    <field type="title" txt="Existing Container Settings" id="existing.container.path.selection.panel.title"/>
    <field type="radio" variable="container.type">
      <description align="left" txt="Choose Container Type" id="container.option.radio.description"/>
        <spec>
          <choice txt="Apache Tomcat" id="tomcat.option.radio.label" value="tomcat" set="true" />
          <choice txt="JBoss" id="netweaver.option.radio.label" value="jboss" set="false" />
        </spec>
    </field>
    <field type="staticText" align="left" id="container.home.field" txt="Select Container Home Path"/>
    <field type="dir" align="left" variable="container.home">
      <spec txt="" size="25" set="" mustExist="true" />
    </field>
  </panel>

  ...
</userInput>

install.xml:

  <conditions>
    <condition type="variable" id="new.container">
      <name>use.old.container</name>
      <value>no</value>
    </condition>
    <condition type="variable" id="existing.container">
      <name>use.old.container</name>
      <value>yes</value>
    </condition>
    ...
  </conditions>

  ...

  <panels>
    <panel classname="HelloPanel" />
    <panel classname="TargetPanel"/>
    <panel classname="UserInputPanel" id="container.installation.selection.panel"/>
    <panel classname="UserInputPanel" id="new.container.path.selection.panel" condition="new.container"/>
    <panel classname="UserInputPanel" id="existing.container.path.selection.panel" condition="existing.container"/>
    ...

In the GUI installation this works fine. But in a console installation, in case the Use existing container installation field is checked I'd expect to get the existing.container.path.selection.panel to be activated next, but the new.container.path.selection.panel appears instead.



 Comments   
Comment by Rene Krell [ 06/Dec/12 ]

This is because the "order" attribute of the panels in userInputSpec.xml is currently badly used in the code.

The order of UserInputPanels should be decided upon

  • the order they are defined in install.xml
  • conditions that those panels depend on

The order attribute in userInputSpec.xml should not be relevant here at all.
(It isn't even relevant at all and could be removed, IMHO ...)

Comment by Rene Krell [ 06/Dec/12 ]

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

Comment by Rene Krell [ 07/Dec/12 ]

Link to an issue dealing with removing the order attribute completely from the user input panels definitions





[IZPACK-883] No console implementation of panel HTMLInfoPanel,HTMLLicencePanel,SummaryPanel Created: 04/Dec/12  Updated: 30/Apr/13  Resolved: 17/Apr/13

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

Type: Bug Priority: Major
Reporter: Francois Le Fevre Assignee: Tim Anderson
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Hello
when trying to use the installer on a server without server x.
If I tried to use the '-console' option it doesn not work
it was working befor in version 4.3.x

Thanks for your help



 Comments   
Comment by Paul Bors [ 15/Apr/13 ]

I got this working by ignoring the output of the HTMLInfoPanel as such:

package com.izforge.izpack.panels.htmlinfo;

import java.util.Properties;

import com.izforge.izpack.api.data.InstallData;
import com.izforge.izpack.installer.console.AbstractPanelConsole;
import com.izforge.izpack.util.Console;

/**
 * FIXME IZPACK-883: Remove once izPack releases its own version of this panel or fixes the
 * -console installer to skip over missing console helpers.
 */
public class HTMLInfoPanelConsoleHelper extends AbstractPanelConsole {

    @Override
    public boolean runConsoleFromProperties(InstallData installData, Properties properties) {
        return true;
    }

    @Override
    public boolean runConsole(InstallData installData, Console console) {
        return true;
    }

}

I added this in my own custom panels jar but in the expected package name com.izforge.izpack.panels.htmlinfo.

You could consider this a work-around until izPack gets to fix it

I'll take a closer look see if I can understand how the GUI panel is put together and maybe have the above class print the actual HTML to the screen (I'm not promising anything yet as I need to finish implementing my installer).

Comment by Paul Bors [ 15/Apr/13 ]

At a first look it seems that one might want to share the implementation of the com.izforge.izpack.panels.htmlinfo.HTMLInfoPanel.loadHTMLInfoContent() to grab the custom HTML resource URL and then strip all HTML tags (or process the HTML to text only) by preserving the hyperlinks URLs as one might want to cut-n-paste them from the console to a browser.

I would have given this a shot, but I'm on a x64 Win 7 PC and when I run mvn clean install my compiler fails with:

...
[INFO] Compiling 39 source files to C:\src\izPack 5\izpack-compiler\target\classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] error: error reading C:\maven\repository\org\eclipse\swt\win32\win32\x86\3.3.0-v3346\x86-3.3.0-v3346.jar; error in opening zip file
[INFO] 1 error
[INFO] -------------------------------------------------------------
...
Comment by Paul Bors [ 15/Apr/13 ]

I just compared the output from my older installer build w/ izPack 4.3.5 and this panel didn't output anything for the HTMLInfoPanel while running in the console mode.

Thus above code could be merged into 5.0.0-beta11 (or beta12 since beta11 is out already) and the behavior would be the same as before.

I take it the same could be done for the HTMLLicencePanel and SummaryPanel ConsoleHelpers but I'm not sure how they behaved in 4.3.5 as I never used those panels let alone in console mode.

Comment by Paul Bors [ 16/Apr/13 ]

Expected Behavior

Running the installer via the -console mode it should skip over any panel that does not have an associated *ConsoleHelper.

Actual Outcome

Invoking an installer build with izPack 5.0.0-beta11 that's using a panel which is missing its ConsoleHelper via the -console mode cause the installce to fail.

Steps to Reproduce

  1. Create an installer using a panel that's missing the ConsoleHelper
  2. run that installer via the -console tag and notice it crash

    c:\>java -DTRACE=TRUE -jar test-installer\target\test-installer-1.0-SNAPSHOT.jar -console
    Apr 16, 2013 11:18:04 AM INFO: Logging initialized at level 'INFO'
    Apr 16, 2013 11:18:04 AM INFO: Commandline arguments: -console
    Apr 16, 2013 11:18:04 AM INFO: Detected platform: windows,version=6.1,arch=x64,symbolicName=WINDOWS_7,javaVersion=1.6.0_38
    Apr 16, 2013 11:18:04 AM WARNING: No console implementation of panel: com.izforge.izpack.panels.htmlinfo.HTMLInfoPanel
    Console installation is not supported by this installer
    [ Console installation FAILED! ]

The auto-installer skips panels that don't have the corresponding helper, so should the console.

I think that's the real bug. The rest is really a work around.

Comment by Tim Anderson [ 17/Apr/13 ]

Duplicate of IZPACK-871

Comment by Paul Bors [ 17/Apr/13 ]

Hey Tim,

In this comment on IZPACK-871 you mentioned that the console helpers were added but I don't see them in 5.0.0-beta11.

Were those added in a different version that hasn't yet been released?

Comment by Tim Anderson [ 17/Apr/13 ]

You can find the changes in a recent 5.0.0-rc1-SNAPSHOT, available from the Maven snapshot repository at https://nexus.codehaus.org/content/repositories/snapshots/

Comment by Paul Bors [ 17/Apr/13 ]

Hey Tim,

Sorry to bother you again, but do you guys develop on git://github.com/izpack/izpack.git (GitHub) and then release from git://git.codehaus.org/izpack.git (Codehaus)?

I'm a bit confused with what's documented at https://izpack.github.io/developers/.

Comment by Tim Anderson [ 18/Apr/13 ]

Usually. The github version hasn't been pushed to codehaus for a while, so I think Rene has been releasing snapshots from github.
BTW - we do have mailing lists, which are a better place for this discussion: https://izpack.github.io/mailing-lists/

Comment by Rene Krell [ 30/Apr/13 ]

Hi Paul,
regarding:

Sorry to bother you again, but do you guys develop on git://github.com/izpack/izpack.git (GitHub) and then release from git://git.codehaus.org/izpack.git (Codehaus)?

Currently, we actually use Github as repository for the active development to better reaching contributors. Unfortunately, I haven't found any service that allows automatic pushes (commit forwarding) from Github to Codehaus to not synchronize manually to git.codehaus.org.
I raised an issue (wish) at Codehaus, whether they wouldn't provide a web service for Github's post-receive hooks, this would be an effective way to mirror izpack/izpack from Github to Codehaus without any further intervention elsewhere.

Comment by Paul Bors [ 30/Apr/13 ]

Could you guys drop a note on https://izpack.github.io/developers/ so other people don't get confused?

Comment by Rene Krell [ 30/Apr/13 ]

I left that note also there. Let me know, whether this might be sufficient from your point of view for now.
Manual pushes are not really the state of the art, lets look forward on what the Codehaus guys could do here.





[IZPACK-882] Custom icons are not working for uninstaller Created: 30/Nov/12  Updated: 30/Nov/12

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

Type: Bug Priority: Major
Reporter: Ankur Gupta 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 custom icons defined in customicons.xml are not applied to uninstaller.






[IZPACK-881] SimpleFinishPanel does not display its contents Created: 29/Nov/12  Updated: 18/Jul/13

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

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

Linux


Attachments: PNG File izpack_simplefinish.png    
Number of attachments : 1

 Description   

When using a SimpleFinishPanel instead of a FinishPanel at the end of an IzPack installer,
the information that is supposed to be displayed in the panel is not visible,
whereas it is visible when using a FinishPanel.



 Comments   
Comment by Carlos Becker [ 08/Feb/13 ]

I've been able to reproduce this bug here, both versions 4.3.4 and 4.3.5.

I strongly believe that's related to another bug that occurs here: http://jira.codehaus.org/browse/IZPACK-877

I've tested it in both windows and linux, can't reproduce in Linux because the contents doesn't show up, and in windows it looks a little bit crazy. I'll specify the windows case in the proper issue.

Thanks

Comment by Pascale ANDRIANATREHANA [ 18/Jul/13 ]

Hi,

What is the current situation concerning this bug ? Could you take a look at it ?

Thanks





[IZPACK-880] Support a "izpack.windowsinstall.8" for Windows 8 installations Created: 28/Nov/12  Updated: 07/Dec/12  Resolved: 07/Dec/12

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

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

Windows 8


Number of attachments : 0

 Description   

Support will allow installers to work differently on windows 8 vs other windows environments.



 Comments   
Comment by Rene Krell [ 07/Dec/12 ]

Merged pull request from minsko to 5.0 - https://github.com/izpack/izpack/pull/76

Not considering IzPack 4.3 any longer. If someone needs this there, please feel free to reopen.

Thank you, well-done.





[IZPACK-879] Automatically install xml files is empty Created: 28/Nov/12  Updated: 22/Jan/13  Resolved: 22/Jan/13

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

Type: Bug Priority: Major
Reporter: Francois Le Fevre Assignee: Rene Krell
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux, fedora core


Number of attachments : 0

 Description   

After the installation process, the automatically install xml files is empty.
I have as final panel a
<panel classname="FinishPanel" id="finishPanel" />

where I can click to specify the location of the installation file but I have nothing in it.

If I made a mistake, I am sorry.
These feature was really important in order to allow deployment accross several computer.

Francois



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

This seems to be the same reason like
IZPACK-794 (Pressing "Generating automatic installation script" throws java.lang.NoClassDefFoundError: com/izforge/izpack/panels/imgpacks/ImgPacksPanelAutomationHelper) and
should be solved in 5.0.0-rc1-SNAPSHOT, will deploy a snapshot soon.





[IZPACK-878] Process Panel, if use <executeclass> the next <job> are not executed Created: 22/Nov/12  Updated: 22/Nov/12

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

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

Windows/MAC


Number of attachments : 0

 Description   

I'm trying to define, in the same processPanelSpec.xml two jobs, one contains a <executeclass> (to create a DB by jdbc connector...) and the other is a tipicall <executefile> (script to launch a tomcat...), but when mix both only the <executeclass> are executed properly and then the panel stops.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<processing>
<job name="Creating DB, please wait...">
<os family="windows|mac|unix" />
<executeclass name="com.myproject.installer.utils.CreateDBMedia">
<arg>$

{mysql.username}

</arg>
<arg>$

{mysql.password}

</arg>
</executeclass>
</job>

<job name="Launch Tomcat, please wait...">
<executeForPack name="pack.ApacheTomcat7" />
<os family="mac|unix" />
<executefile name="$INSTALL_PATH/scripts/launchTomcat.sh" />
</job>
</processing>






[IZPACK-877] FinishPanel text position is wrong Created: 20/Nov/12  Updated: 08/Feb/13

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

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

Windows 7 64 bit, Java 1.7


Number of attachments : 0

 Description   

The text and buttons on the FinishPanel, after an install has finished, are attached to the top of the frame/panel.
This has been reported with the JBoss community and there is a (small) fix there which works in the current stable version of IzPack (v.4.3.5): https://issues.jboss.org/browse/JBPAPP-6891. (this jboss case has a patch attached)

Please fix this in IzPack current stable version and also 5.0 if possible.

P.S. Not sure if there is a case for this here already, could not find one.



 Comments   
Comment by Carlos Becker [ 08/Feb/13 ]

I'm expecting this bug and this other one (http://jira.codehaus.org/browse/IZPACK-881?focusedCommentId=318899#comment-318899) as well.

Tested in both version 4.3.4 and 4.3.5, Windows and Linux.

I cannot reproduce this bug in Linux because of the other bug I cited above. In windows it looks pretty weird: sometimes the content text appears "truncated", but I hear some reports about it showing checkboxes and other strange things.

Thanks





[IZPACK-876] AuthorizationExecuteWithPrivileges() is deprecated on Mac OS 10.7 (privilege escalation) Created: 16/Nov/12  Updated: 16/Nov/12

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

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

Mac OS 10.7


Number of attachments : 0

 Description   

AuthorizationExecuteWithPrivileges() is deprecated on Mac OS 10.7

http://stackoverflow.com/questions/6841937/authorizationexecutewithprivileges-is-deprecated
http://developer.apple.com/library/mac/#samplecode/SMJobBless/Listings/ReadMe_txt.html






[IZPACK-875] No TargetPanel - GUI disappears & Java process remains active Created: 10/Nov/12  Updated: 10/May/13

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

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

Windows and Mac OS-X


Attachments: Zip Archive IZPack_V5_No_Target_Panel.zip    
Issue Links:
dependent
is depended upon by IZPACK-952 Avoid functional dependency on Target... Open
Number of attachments : 1

 Description   

When an installer has no TargetPanel then the GUI disappears without any notice.
Yet the Java process stays active.
On the Mac the installer program remains visible on "The Dock".

Even if I set the variables:
<dynamicvariables>
<variable name="INSTALL_PATH" value="C:\Program files"/>
<variable name="TargetPanel.dir.windows" value="C:\Program files"/>
</dynamicvariables>

The same install scripts runs fine with IZPack 4!



 Comments   
Comment by Rene Krell [ 01/May/13 ]

Can you please add a simple but complete example installer description which shows this?
Can you call the problematic installer with -DDEBUG=true and -DSTACKTRACE=true and send the console log?
Can you retry it with the latest 5.0.0-rc1 snapshot or HEAD from github (izpack/izpack)?
Thank you

Comment by Mulcamd [ 10/May/13 ]

Hi I created a little sample based on the sample provided with IZPack 4, see attachment.
The language selection dialog appears.
Then either select english or french.

After the selection no further dialogs appear.
Looking in the Task manager there is a JAVAX.EXE process running, but on screen not happens.

Comment by Mulcamd [ 10/May/13 ]

Sample installer

Comment by Rene Krell [ 10/May/13 ]

Thanks, you might also append a threaddump of the hanging Java process for us to see where it is hanging. We will try also, of course.

Comment by Mulcamd [ 10/May/13 ]

How do I make a threaddump? I'm on Windows 7.

Comment by Rene Krell [ 10/May/13 ]

Without a JDK, on Windows, only if you start the installer by java -jar ... from the command line, in that command line CTRL+BREAK should dump it to the same connsole window, but some people reported that this might not dump all the information.
I'd recommend using a tool from the JDK with the same version as your JRE you launch the installer with (jstack, JVisualVM), connect to the PID of the java.exe process and grab it. The complete output of that dump you can copy to a text file and attach here.
There is a bunch of information on the internet, especially:
http://docs.oracle.com/javase/6/docs/technotes/tools/share/jstack.html
http://docs.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html

If this doesn't work for you for some reason, I'm sure we will reproduce the reported problem also here and find a way.





[IZPACK-874] CLONE - Attempt to write uninstaller data while uninstaller is disabled Created: 31/Oct/12  Updated: 30/Apr/13  Resolved: 30/Apr/13

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

Type: Bug Priority: Major
Reporter: Francois Le Fevre Assignee: Rene Krell
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If I disable the installer via

<uninstaller write="no" />

IzPack nevertheless tries to write uninstaller data on the Quit/Done button of the last panel and therefore fails with

{{[ Writing the uninstaller data ... ]
com.izforge.izpack.api.exception.IzPackException: The package com.izforge.izpack.uninstaller has not been found in the classpath and is required by the installer}}

and a corresponding GUI error popup.



 Comments   
Comment by Francois Le Fevre [ 31/Oct/12 ]

Dear all,
I have still this error with

<izpack.plugin.version>5.0.0-beta10</izpack.plugin.version>
<izpack.version>5.0.0-beta10</izpack.version>

Francois

Comment by Rene Krell [ 31/Oct/12 ]

Please try the 5.0.0-beta11-SNAPSHOT, this should be already fixed.

Comment by Francois Le Fevre [ 31/Oct/12 ]

Rene,
I will try it
I have tried to change only my maven dependencies to
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-maven-plugin</artifactId>
<version>$

{izpack.version}</version>

when I swith to 5.0.0-beta11-SNAPSHOT for the plugin and depencies

<dependency>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-compiler</artifactId>
<version>${izpack.version}

</version>
<scope>provided</scope>
</dependency>

<dependency>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-panel</artifactId>
<version>$

{izpack.version}

</version>
</dependency>

I have now a problem of compilation

constituent[30]: file:/home/flefevre/programs/apache-maven-3.0.3/lib/maven-embedder-3.0.3.jar
---------------------------------------------------
Exception in thread "main" java.lang.AssertionError: com.izforge.izpack.api.exception.CompilerException: /home/flefevre/programs/birdsworkspace/scratch/flefevre-builder-64/sbwh6staging/izpack.xml:3: the file version is different from the compiler version
at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:184)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
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:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: com.izforge.izpack.api.exception.CompilerException: /home/flefevre/programs/birdsworkspace/scratch/flefevre-builder-64/sbwh6staging/izpack.xml:3: the file version is different from the compiler version
at com.izforge.izpack.compiler.helper.AssertionHelper.parseError(AssertionHelper.java:61)
at com.izforge.izpack.compiler.resource.ResourceFinder.getXMLTree(ResourceFinder.java:188)
at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:290)
at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo

in my izpack.xml, it begins with

<?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>

<installation version="1.0">

is it related?

Thanks a lot.

Francois

Comment by Francois Le Fevre [ 31/Oct/12 ]

Rene
I have migrated to the right xml schema, made the change
but I still get the error:

do you have any idea?

INFO: dynamic variable birdswui.host:
[ Writing the uninstaller data ... ]
com.izforge.izpack.api.exception.IzPackException: The package com.izforge.izpack.uninstaller has not been found in the classpath and is required by the installer
[flefevre@fedosynthia sbwh6-installer]$

My izapck.xml

<?xml version="1.0" encoding="iso-8859-1" ?>
<izpack:installation version="5.0"
xmlns:izpack="https://izpack.github.io/schema/installation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://izpack.github.io/schema/installation https://izpack.github.io/schema/5.0/izpack-installation-5.0.xsd">

<info>
<appname>$

{project.name}

-$

{sbwh6.arch}

</appname>
<appversion>$

{project.version}

</appversion>

<javaversion>1.6</javaversion>
<authors>

</authors>
<uninstaller write="no" />
</info>

Comment by Rene Krell [ 31/Oct/12 ]

Please try the following root declaration:

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

  <info>
  ...
  </info>

  ...
</izpack:installation>
Comment by Rene Krell [ 31/Oct/12 ]

Ah sorry, I see, you tried it. Can you provide the according POMs please, where you use the izpack-maven-plugin?

Comment by Rene Krell [ 31/Oct/12 ]

Try also a mvn clean and then rebuild the whole project.

Comment by Francois Le Fevre [ 31/Oct/12 ]

I have try mvn clean and then mvn install
here my sniped of my pom

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>fr.a</groupId>

<artifactId>b</artifactId>
<version>0.9.7-SNAPSHOT</version>

<name>BB</name>

<packaging>jar</packaging>

<properties>
<!-- izpack configuration -->
<mojo.java.target>1.6</mojo.java.target>

<izpack.plugin.version>5.0.0-beta11-SNAPSHOT</izpack.plugin.version>
<izpack.version>5.0.0-beta11-SNAPSHOT</izpack.version>

</properties>

<dependencies>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.6</version>
</dependency>

<dependency>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-compiler</artifactId>
<version>$

{izpack.version}</version>
<scope>provided</scope>
</dependency>

<dependency>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-panel</artifactId>
<version>${izpack.version}

</version>
</dependency>

<dependency>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-uninstaller</artifactId>
<version>$

{izpack.version}</version>
</dependency>

</dependencies>

<build>

<defaultGoal>install</defaultGoal>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.5.1</version>



<execution>
<id>copy-dependencies-for-izpack</id>
<phase>compile</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<stripVersion>true</stripVersion>
<outputDirectory>${dependency.staging.dir}</outputDirectory>
<Unable to render embedded object: File (-- excludeGroupIds>org.codehaus.izpack</excludeGroupIds --> <) not found.-- IMPORTANT: we don't want to copy the izpack dependency where our application jars live -->
</configuration>
</execution>

<execution>
<id>copy</id>
<phase>package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>

</artifactItem>

</artifactItems>
</configuration>
</execution>

</executions>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>

//copy stuff instaging dir

</executions>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>

<executions>
<execution>
<id>copy-and-filter-izpack-resources</id>
<phase>prepare-package</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${staging.dir}</outputDirectory>
<resources>
<resource>
<directory>${project.basedir}/src/main/izpack</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>


<plugin>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-maven-plugin</artifactId>
<version>${izpack.version}

</version>

<executions>
<execution>
<phase>package</phase>
<goals>
<goal>izpack</goal>
</goals>
<configuration>
<!-- base for relative paths in izpack descriptor -->
<baseDir>$

{staging.dir}</baseDir>
<!-- installFile>${project.basedir}/src/main/izpack/izpack.xml</installFile -->
<installFile>${staging.dir}

/izpack.xml</installFile>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-panel</artifactId>
<version>$

{izpack.version}</version>
</dependency>
<!-- dependency> <groupId>com.mycompany</groupId> <artifactId>mycustompanels</artifactId>
<version>1.0-SNAPSHOT</version> </dependency -->

<dependency>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-uninstaller</artifactId>
<version>${izpack.version}

</version>
</dependency>
</dependencies>
</plugin>

<pluginManagement>
<plugins>
<!--This plugin's configuration is used to store Eclipse m2e settings
only. It has no influence on the Maven build itself. -->
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>
org.apache.maven.plugins
</groupId>
<artifactId>
maven-antrun-plugin
</artifactId>
<versionRange>
[1.6,)
</versionRange>
<goals>
<goal>run</goal>
</goals>
</pluginExecutionFilter>
<action>
<execute></execute>
</action>
</pluginExecution>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<versionRange>
[2.5.1,)
</versionRange>
<goals>
<goal>unpack</goal>
<goal>copy-dependencies</goal>
</goals>
</pluginExecutionFilter>
<action>
<execute></execute>
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>

<profiles>

</profiles>
<repositories>

<repository>
<id>sonatype2s</id>
<name>Maven Sonatype Snapshot Plugin Repository</name>
<url>https://nexus.codehaus.org/content/repositories/snapshots</url>
<layout>default</layout>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<updatePolicy>never</updatePolicy>
</releases>
</repository>
</repositories>

<pluginRepositories>

<pluginRepository>
<id>sonatypes</id>
<name>Maven Sonatype Snapshot Plugin Repository</name>
<url>https://nexus.codehaus.org/content/repositories/snapshots</url>
<layout>default</layout>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<updatePolicy>never</updatePolicy>
</releases>
</pluginRepository>

</pluginRepositories>

</project>

Comment by Rene Krell [ 31/Oct/12 ]

This is not the right kind of usage. Please follow the hints according to http://docs.codehaus.org/display/IZPACK/IzPack+Maven+Plugin+Reference

Comment by Francois Le Fevre [ 02/Nov/12 ]

Dear Rene,
you are right, I have readden again the doc and apply several changes.
now, I have
-a right packaging <packaging>izpack-jar</packaging>

  • set the property <staging.dir>$ {env.SBWH6_BUILDER}

    /staging</staging.dir>
    and populate my plugin as follow (see below):

And I do not have again the uninstaller problem!
Only the automatic installation problem ( see below and https://jira.codehaus.org/browse/IZPACK-794)

Thanks a lot for your advice Rene.

Francoix

<plugin>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-maven-plugin</artifactId>
<version>$

{izpack.version}</version>
<extensions>true</extensions>
<configuration>
<baseDir>${staging.dir}</baseDir>
<installFile>${staging.dir}/install.xml</installFile>
<outputDirectory>${project.build.directory}</outputDirectory>
<finalName>${project.build.finalName}</finalName>
<enableOverrideArtifact>true</enableOverrideArtifact>
<mkdirs>true</mkdirs>
<autoIncludeUrl>true</autoIncludeUrl>
<autoIncludeDevelopers>true</autoIncludeDevelopers>
<kind>standard</kind>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-panel</artifactId>
<version>${izpack.version}

</version>
</dependency>

<dependency>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-panel</artifactId>
<version>$

{izpack.version}</version>
</dependency>

<dependency>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-uninstaller</artifactId>
<version>${izpack.version}

</version>
</dependency>
</dependencies>
</plugin>

Now I have only the problem of

Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com/izforge/izpack/panels/imgpacks/ImgPacksPanelAutomationHelper
at com.izforge.izpack.panels.packs.PacksPanelBase.makeXMLData(PacksPanelBase.java:330)
at com.izforge.izpack.installer.gui.InstallerFrame.writeXMLTree(InstallerFrame.java:735)
at com.izforge.izpack.panels.finish.FinishPanel.actionPerformed(FinishPanel.java:172)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
at java.awt.Component.processMouseEvent(Component.java:6288)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6053)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4651)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4481)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4481)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:643)
at java.awt.EventQueue.access$000(EventQueue.java:84)
at java.awt.EventQueue$1.run(EventQueue.java:602)
at java.awt.EventQueue$1.run(EventQueue.java:600)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
at java.awt.EventQueue$2.run(EventQueue.java:616)
at java.awt.EventQueue$2.run(EventQueue.java:614)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:613)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: java.lang.ClassNotFoundException: com.izforge.izpack.panels.imgpacks.ImgPacksPanelAutomationHelper
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 40 more

Comment by Rene Krell [ 02/Nov/12 ]

Hi Francoix, please remove all the explicit dependencies, they won't be necessary at all. R.

Comment by Rene Krell [ 30/Apr/13 ]

Disable writing an uninstaller works for me in the current HEAD (and worked also in 5.0.0-beta11). PLease reopen, if you're still in trouble with the originally reported problem.
In case of problems migrating to 5.0 ask the user mailinglist.
Thank you





[IZPACK-873] Warnings with NPEs during installation with activated stacktrace Created: 30/Oct/12  Updated: 22/Feb/13

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

Type: Bug Priority: Trivial
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   

During installation, with -DSTACKTRACE=true, the following stacktrace is repeatedly shown as warning:

Oct 30, 2012 4:44:05 PM WARNING: Icon null not found in icon list: null
java.lang.NullPointerException
        at java.util.TreeMap.getEntry(TreeMap.java:324)
        at java.util.TreeMap.get(TreeMap.java:255)
        at com.izforge.izpack.panels.userinput.UserInputPanel.addTitle(UserInputPanel.java:1414)
        at com.izforge.izpack.panels.userinput.UserInputPanel.init(UserInputPanel.java:506)
        at com.izforge.izpack.panels.userinput.UserInputPanel.panelActivate(UserInputPanel.java:1058)
        at com.izforge.izpack.installer.gui.InstallerFrame.switchPanel(InstallerFrame.java:606)
        at com.izforge.izpack.installer.gui.InstallerFrame$5.switchPanel(InstallerFrame.java:404)
        at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:128)
        at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:36)
        at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:418)
        at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:238)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:327)
        at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:310)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.navigate(DefaultNavigator.java:545)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.access$100(DefaultNavigator.java:508)
        at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler$1$1.run(DefaultNavigator.java:528)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:666)
        at java.awt.EventQueue.access$400(EventQueue.java:81)
        at java.awt.EventQueue$2.run(EventQueue.java:627)
        at java.awt.EventQueue$2.run(EventQueue.java:625)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:636)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

This should be avoided and handled more smart.



 Comments   
Comment by Sven Thomas [ 22/Feb/13 ]

The warning "Icon null not found in icon list: null" does even occur multiple times if you start the GUI installer without -DTRACE=true or -DSTACKTRACE=true from a command prompt.

There are also some more warnings. Since I don't want to open a ticket for them (again ), here is the output of a single installation:

22.02.2013 11:58:34 INFO: Logging initialized at level 'INFO'
22.02.2013 11:58:34 INFO: Commandline arguments:
22.02.2013 11:58:34 INFO: Detected platform: windows,version=6.1,arch=x64,symbolicName=WINDOWS_7,javaVersion=1.6.0_37
22.02.2013 11:58:35 WARNUNG: Resource customicons.xml not defined. No custom icons available
22.02.2013 11:58:35 INFO: Cannot find named resource: 'packsLang.xml' AND 'packsLang.xml_eng'
22.02.2013 11:58:37 WARNUNG: Cannot find named resource: 'userInputLang.xml' AND 'userInputLang.xml_eng'
22.02.2013 11:58:37 WARNUNG: Icon null not found in icon list: null
22.02.2013 11:58:39 WARNUNG: Cannot find named resource: 'userInputLang.xml' AND 'userInputLang.xml_eng'
22.02.2013 11:58:39 WARNUNG: Icon null not found in icon list: null
C:\Program Files\Java\jdk1.6.0_37\jre - isDir: true - mustExist: true - canCreate: false
22.02.2013 11:58:42 WARNUNG: Cannot find named resource: 'userInputLang.xml' AND 'userInputLang.xml_eng'
22.02.2013 11:58:42 WARNUNG: Icon null not found in icon list: null
22.02.2013 11:58:43 WARNUNG: Cannot find named resource: 'userInputLang.xml' AND 'userInputLang.xml_eng'
22.02.2013 11:58:43 WARNUNG: Icon null not found in icon list: null
22.02.2013 11:58:43 WARNUNG: Failed in constructor creating processor instance: java.lang.NullPointerException
[ Writing the uninstaller data ... ]

If the installer does not find an optional resource, it should print out an INFO at max (and ideally only once), but not a warning.

The java.lang.NullPointerException appears when a UserInputPanel with a PasswordField is created, here is the stacktrace:
22.02.2013 12:55:12 WARNUNG: Failed in constructor creating processor instance: java.lang.NullPointerException
java.lang.NullPointerException
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at com.izforge.izpack.panels.userinput.PasswordGroup.<init>(PasswordGroup.java:93)
at com.izforge.izpack.panels.userinput.UserInputPanel.addPasswordField(UserInputPanel.java:2324)
at com.izforge.izpack.panels.userinput.UserInputPanel.init(UserInputPanel.java:475)
at com.izforge.izpack.panels.userinput.UserInputPanel.panelActivate(UserInputPanel.java:1047)
at com.izforge.izpack.installer.gui.InstallerFrame.switchPanel(InstallerFrame.java:606)
at com.izforge.izpack.installer.gui.InstallerFrame$5.switchPanel(InstallerFrame.java:404)
at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:128)
at com.izforge.izpack.installer.gui.IzPanels.switchPanel(IzPanels.java:36)
at com.izforge.izpack.installer.panel.AbstractPanels.switchPanel(AbstractPanels.java:418)
at com.izforge.izpack.installer.panel.AbstractPanels.next(AbstractPanels.java:238)
at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:327)
at com.izforge.izpack.installer.gui.DefaultNavigator.next(DefaultNavigator.java:310)
at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.navigate(DefaultNavigator.java:545)
at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler.access$100(DefaultNavigator.java:508)
at com.izforge.izpack.installer.gui.DefaultNavigator$NavigationHandler$1$1.run(DefaultNavigator.java:528)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:666)
at java.awt.EventQueue.access$400(EventQueue.java:81)
at java.awt.EventQueue$2.run(EventQueue.java:627)
at java.awt.EventQueue$2.run(EventQueue.java:625)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:636)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)





[IZPACK-872] Parentheses in project path prevent custom jars from being added Created: 19/Oct/12  Updated: 19/Oct/12

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

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

IzPack 5.0.0-beta10


Number of attachments : 0

 Description   

My project home path contains parentheses: C:\development\projects\test(me).

In my install.xml (see below) I'm including jars to be available at install time. These jars are referenced with a relative path.

As expected, when I'm building the installer the log file states (please note the absolute path of the jars being processed):

...
Setting the installer information
Setting the GUI preferences
Adding langpack: deu
Adding resource: flag.deu
Adding langpack: eng
Adding resource: flag.eng
Adding content of jar: /C:/development/projects/test(me)/test/Code/test-installer/target/staging/lib/ant.jar
Adding content of jar: /C:/development/projects/test(me)/test/Code/test-installer/target/staging/lib/ant-launcher.jar
Adding panel: readme :: Classname : HTMLInfoPanel
Adding panel: UNKNOWN (SummaryPanel) :: Classname : SummaryPanel
Adding panel: UNKNOWN (InstallPanel) :: Classname : InstallPanel
[ Begin ]

Copying the skeleton installer
Copying 4 files into installer
Merging 0 jars into installer
Writing 1 Pack into installer
Writing Pack 0: Test

[ End ]

When compilng the installer everything seems perfect. There's no build failure, no stack trace logged, no warning traced. Nevertheless does the installation fail. The class files are simply missing in the created installer jar.

This happens on Windows as well as on Linux. It does work, however, when the parentheses are removed.

Here's my configuration:

install.xml
<?xml version="1.0" encoding="utf-8" ?>
<installation version="1.0">
  <info>
    <appname>Test Application</appname>
    <appversion>5.0.0-beta10</appversion>
    <url>http://www.micros.com</url>
    <javaversion>1.6</javaversion>
  </info>

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

  <jar src="lib/ant.jar" stage="install"/>
  <jar src="lib/ant-launcher.jar" stage="install"/>

  <panels>
    <panel classname="HTMLInfoPanel" id="readme"/>
    <panel classname="SummaryPanel"/>
    <panel classname="InstallPanel"/>
  </panels>

  <packs>
    <pack name="Test" id="test" required="yes">
      <description>The test installation.</description>
      <fileset dir="app" targetdir="${INSTALL_PATH}" override="true"/>
    </pack>
  </packs>
</installation>





[IZPACK-871] Console installation support for all built-in panels Created: 17/Oct/12  Updated: 18/Oct/13

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

Type: Task Priority: Major
Reporter: Mulcamd Assignee: Tim Anderson
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64 bits en Windows XP


Issue Links:
Supercedes
is superceded by IZPACK-929 Create console implementation of Inst... Resolved
is superceded by IZPACK-996 Create console implementation of HTML... Resolved
is superceded by IZPACK-997 Create console implementation of HTML... Resolved
is superceded by IZPACK-998 Create console implementation of Shor... Resolved
is superceded by IZPACK-999 Create console implementation of Simp... Resolved
is superceded by IZPACK-1000 Create console implementation of Summ... Resolved
is superceded by IZPACK-927 Create console implementation of Comp... Open
is superceded by IZPACK-928 Create console implementation of Data... Open
is superceded by IZPACK-930 Create console implementation of the ... Open
is superceded by IZPACK-931 Create console implementation of User... Open
is superceded by IZPACK-932 Create console implementation of Sele... Open
is superceded by IZPACK-933 Create console implementation of Sudo... Open
is superceded by IZPACK-934 Create console implementation of the ... Open
is superceded by IZPACK-935 Create console implementation of the ... Open
Number of attachments : 0

 Description   

17-okt-2012 18:35:21 INFO: Logging initialized at level 'INFO'
17-okt-2012 18:35:21 INFO: Commandline arguments: -options installer.properties
17-okt-2012 18:35:21 INFO: Detected platform: windows,version=6.1,arch=x86,symbolicName=WINDOWS_7,javaVersion=1.6.0_31
17-okt-2012 18:35:21 INFO: No custom langpack for nld available
17-okt-2012 18:35:21 WARNING: No console implementation of panel: com.izforge.izpack.panels.htmlhello.HTMLHelloPanel
17-okt-2012 18:35:21 WARNING: No console implementation of panel: com.izforge.izpack.panels.htmllicence.HTMLLicencePanel
17-okt-2012 18:35:21 WARNING: No console implementation of panel: com.izforge.izpack.panels.shortcut.ShortcutPanel
17-okt-2012 18:35:21 WARNING: No console implementation of panel: com.izforge.izpack.panels.simplefinish.SimpleFinishPanel
Console installation is not supported by this installer
[ Console installation FAILED! ]



 Comments   
Comment by Dan Gravell [ 18/Oct/12 ]

For me it simply says "[ Console installation done ]". The licence isn't shown, there's no request for installation location and there appears to be no files installed.

Comment by Mulcamd [ 18/Oct/12 ]

Forgive me for the perhaps stupid question since I'm not a native English speaker.

I do not understand the comment of Dan Gravell.

Perhaps I should add more info.
What i did was: java -jar installer.jar -options installer.properties

the property file installer.properties contains the desired information.
With IZPack version 4, this works fine. No problems.
IZPack version 5 gives the above message and no silent/console install is performed.

Comment by Tim Anderson [ 18/Oct/12 ]

Dan - you probably aren't running the latest code from git.

Mulcamd - there needs to be console implementations of HTMLHelloPanel, HTMLLicencePanel, ShortcutPanel, and SimpleFinishPanel in order for console installation to proceed.
See IZPACK-748 for more details

Comment by Dan Gravell [ 19/Oct/12 ]

Apologies Mulcamd. I was just saying that for me with v5.0 beta10 the console installation does not appear to have any effect.

Tim, I was looking at v5.0 simply to avoid the uninstaller bugs with Windows 7. I since found this bug: http://jira.codehaus.org/browse/IZPACK-538 which explained I needed to change my uninstaller shortcut to remove the 'command line' attribute.

Comment by Tim Anderson [ 24/Feb/13 ]

I've added console implementations of the following panels:

  • HTMLHelloPanel
  • HTMLInfoPanel
  • ShortcutPanel
  • SimpleFinishPanel
  • SummaryPanel (although this is just a dummy)

Notes:

  • the HTML to text conversion is somewhat imperfect, using code from the original HTMLLicencePanelConsoleHelper.
    These panels could be changed to look for a plain-text resource first, before resorting to converting html to plain-text.
  • I dislike the naming convention of PanelConsole - would prefer ConsolePanel instead. Given that the console stuff is a bit of a mess, I suspect a rename isn't going to cause too many problems. I can retain the PanelConsole interface and just rename implementations.

The following panels still have no console implementation:

  • CompilePanel
  • DataCheckPanel
  • DefaultTargetPanel
  • ImgPacksPanel
  • InstallationGroupPanel
  • InstallationTypePanel
  • PathInputPanel
  • SelectPrinterPanel
  • SudoPanel
  • UserPathInputPanel
  • UserPathPanel
  • XInfoPanel
Comment by Rene Krell [ 24/Feb/13 ]

I'd rename PanelConsole to ConsolePanel, 5.0 is a refactored version at all and one might have to get used to some new API and class names, I don't see any problem here, if we make some tests with it. Even if the is some code on the way for a pull request, an adaption or merge conflict resolution should be done easily.

Comment by Tim Anderson [ 11/Mar/13 ]

I've refactored PanelConsole and friends here https://github.com/izpack/izpack/pull/96
The PanelConsole interface has been deprecated in favour of ConsolePanel.
Existing implementations can extend AbstractConsolePanel to keep using the deprecated API.

Comment by Tim Anderson [ 13/Mar/13 ]

I've created individual JIRAs for the missing console panel implementations.

Comment by Rene Krell [ 18/Oct/13 ]

Leave this task open until it is completed for all panels





[IZPACK-870] Hanging on the Finish panel on the Mac OS-X Created: 12/Oct/12  Updated: 13/Jul/13

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

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

izpack-dist-5.0.0-beta11-20121005.142312-59

MAC OS-X


Attachments: Java Archive File install.jar     XML File install.xml    
Number of attachments : 2

 Description   

At the last panel, finish panel, the installer hangs for more than a minute and then quits.
However, when compiling with IZPack 4, the last page is quick.

Reproducable with the most basic install script.



 Comments   
Comment by Mulcamd [ 17/Oct/12 ]

Could this be related to the topic on Old Nabble "izPack installer hangs on Writing the uninstaller data"?
http://old.nabble.com/izPack-installer-hangs-on--Writing-the-uninstaller-data-...-td34482094.html

Comment by Mulcamd [ 20/Oct/12 ]

Compared to version 4 the last pannel is very slow also on Windows.

Comment by Paul Taylor [ 13/Jan/13 ]

Yes, I have the same problem using the Izpack 5.0.0 beta 11 on Windows, the cursor is busy for about 45 seconds on the last panel even though thi spabel is only displayed after it says it has already created the uninstaller, without an uninstaller there is no problem.

Comment by Paul Bors [ 13/Jul/13 ]

This must be related to the Old Nabble "izPack installer hangs on Writing the uninstaller data" and I can confirm as well that on Windows it takes a good minute to "[ Writing the uninstaller data ... ]" with izPack 5.0.0 beta 11.

The more jars you add to the uninstaller the more time it would take to generate the uninstaller.jar.

This is the abstract of my install.xml:

    <!-- Jar files to package in the installer. -->
    <jar src="dependency/MyCo-console-util.jar"                 stage="install" />
    <jar src="dependency/MyCo-commons.jar"                      stage="install" />
    <jar src="dependency/log4j.jar"                             stage="install" />
    <jar src="drivers/ojdbc6-${ojdbcVersion}.jar"               stage="install" />
    <jar src="drivers/jtds-${jtdsVersion}.jar"                  stage="install" />
    <jar src="${panels.dir}/MyCo-console-installer-panels.jar"  stage="install" />
    <jar src="${events.dir}/MyCo-console-installer-event.jar"   stage="uninstall" />

If I remove the MyCo-console-installer-event.jar from being added to the uninstall stage things would go a bit faster but I do need that custom code to execute during uninstallation (we stop the webapp server and then delete all relevant files and registry keys etc).





[IZPACK-869] Fatal error temp file access denied Created: 01/Oct/12  Updated: 02/Oct/12

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

Type: Bug Priority: Major
Reporter: Rocker Irwin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: exception
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


Number of attachments : 0

 Description   

this is the error code that i get. i think it has nothing to do with permissions. cuz the user is admin. it was working with the same user and permissions but suddenly everything changed. and i got this error all the time:

[java] -> Fatal error : 2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java]
C:\DOKUME~1\admin\LOKALE~1\Temp\izpack50398.tmp (Access denied)
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java] java.io.FileNotFoundException: C:\DOKUME~1\admin\LOKALE~1\Temp\izpack50398.tmp (Access denied)
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java] at java.io.FileInputStream.open(Native Method)
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java] at java.io.FileInputStream.<init>(FileInputStream.java:106)
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java] at com.izforge.izpack.compiler.Packager.writePacks(Unknown Source)
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java] at com.izforge.izpack.compiler.PackagerBase.writeInstaller(Unknown Source)
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java] at com.izforge.izpack.compiler.Packager.createInstaller(Unknown Source)
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java] at com.izforge.izpack.compiler.Compiler.createInstaller(Unknown Source)
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java] at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(Unknown Source)
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java] at com.izforge.izpack.compiler.CompilerConfig.main(Unknown Source)
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java] at com.izforge.izpack.compiler.Compiler.main(Unknown Source)
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java]
2012-10-01 16:43:32,944 [Thread-140367] INFO ScriptRunner - [java] (tip : use -? to get the commmand line parameters)



 Comments   
Comment by Rene Krell [ 02/Oct/12 ]

For sure this is a local system administration problem. On Windows, Java uses %TEMP% or %TMP% (not sure whether just one of them or whether it tries both) to resolve the temporary directory mapped to the internal system property java.io.tmpdir. The directory defined for your current user doesn't either exist at all or isn't writable for this user for some reason. Please check the settings of these system or user variables (might be overridden) and try to find the directory or create a file in it(without creating the temp directory itself implicitely).

Just call 'set' on the command line as this user and 'dir C:\DOKUME~1\admin\LOKALE~1\Temp\' first.
Try to set the %TEMP% system variable to the fully qualified equivalent path, not using the '~'.

Btw, 'admin' isn't the standard administrator user on Windows, it used to be 'administrator', but there is obviously used 'C:\DOKUME~1\admin\' as the home directory. If you launch the process using an user 'admin' that user is definitely additionally created, in this case check its permissions, also.

Comment by Rocker Irwin [ 02/Oct/12 ]

thnx for your answer. On the server there are two different TEMP and TMP environment variables, one for userdefined (in this case admin) and the other ones points to windows/temp directory. When i navigate to temp folder (C:\Dokumente und Einstellungen\admin\Lokale Einstellungen\Temp) i can see that izpack creates tmp files. but then gives the access denied error and deletes all tmp files. so thats why i thought there is nothing wrong with permissions. and i checked the permissions too. seems all normal. admin is the user name and hast administrator rights.

so what could be wrong ?

Comment by Rene Krell [ 02/Oct/12 ]

In this case the permissions seem to be OK, right.

What is shown for
echo %TEMP%
echo %TMP%
?

In case the appropriate one is set to the short path 'C:\DOKUME~1\admin\LOKALE~1\Temp' try to set it to 'C:\Dokumente und Einstellungen\admin\Lokale Einstellungen\Temp', and then restart and retry.

After answering tose questions it should be possible to analyze it, or simply to define a workaround.





[IZPACK-868] PacksPanel does not look good in Ubuntu Created: 28/Sep/12  Updated: 22/Jul/14

Status: Open
Project: IzPack
Component/s: None
Affects Version/s: 4.3.2, 4.3.3, 4.3.4, 5.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Jonas Stenberg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Ubuntu (still appears on 12.04)


Number of attachments : 0

 Description   

On Ubuntu, the PacksPanel initially opens with the pack list panel beeing really small and the dependencies description panel taking a majority of the window. When placing the cursors on the first pack and stepping down with the arrows, the window adjusts and now it looks fine.

This does not appear on Windows or when runing the installer via X terminal.

My guiprefs looks like this:
<guiprefs width="800" height="600" resizable="yes" >
</guiprefs>

Bonus tip: It would be nice if it was possible to select/unselect a pack with the space key.



 Comments   
Comment by Rene Krell [ 22/Jul/14 ]

Please retry in 5.0.0-rc3-SNAPSHOT from the current master.





[IZPACK-867] Log stdout/stderr from executable Created: 28/Sep/12  Updated: 28/Sep/12

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

Type: Improvement Priority: Major
Reporter: Jonas Stenberg 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 would be really helpful when examining an installation that has gone wrong if the stdout and stderr from executed scripts could be saved in a log file during installation. One big improvement compared to today would be if at least the names of the executed scripts and order were logged to a log file.






[IZPACK-866] Maintenance production release (4) versus development new release (5) Created: 24/Sep/12  Updated: 24/Sep/12

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

Type: Bug Priority: Major
Reporter: Mulcamd 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   

Let me first give thanks for this great project!

As a very small start up, you guys help me with packaging and distributing my software. Your installer is the first thing my users experience of my software product!

Open source is getting more importance and impact. Even Governments start to advocate it.
On the other side this will or should have consequences for Open Source projects, your project.
Imho, you have to make distinction between the maintenance of the release in production (releases 4) and those under development, 5, 6, 


I got really worried when I read the “4.3.6. snapshots?” thread, http://old.nabble.com/4.3.6.-snapshots--td34420113.html

The more people and companies rely on your project the more serious you have to deal with their issues on your current product release, 4.x.x. There should be a form of maintenance until the next release it out.

Companies or persons using IZPack are at the last phase for delivering their software to their clients They will use and rely on a stable tested IZPack release that is in production. In your case version 4.x.x. Using betas is for testing but not for delivering their final products. Companies can’t wait until a beta is production ready.

I get the impression that a lot the effort is put in version 5, which is fine, but that issues with the current 4.x.x. release get little or no attention. A next product release 4.3.6 is not even yet planned. So users with issues have to wait until 5 is ready or go to another installer.

My plead is to cherish your current users that rely today on the stable product release and help them solve their issues with release 4.

In my case there are 2 simple issues which in my opinion can easily be solved because the solution is already at hand:
• IZPACK-833 Windows shortcut with url for webpage not created in 4.3.5 - 4.3.3; correct in 4.3.2
This function works fine in 5.0 beta and in 4.3.2.
So the solution must be there.
• IZPACK-860: Uninstaller does not work on Windows 7 64 bits (normally without administrator rights)
This works fine in version 5 beta 10 and 11. Other version did I not test.






[IZPACK-865] Replace COIOS registry handler with the builtin ini4j tools Created: 21/Sep/12  Updated: 30/Jan/15

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

Type: Improvement 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   

The COIOS registry handler based on JNI can be replaced by using the <configurable tokey="..."> configuration action (see ConfigurationInstallerListener), which interacts with the "reg" Windows command instead of relying on an API






[IZPACK-864] Dynamic variables in ConfigurationInstallerListener don't work at all Created: 21/Sep/12  Updated: 21/Sep/12  Resolved: 21/Sep/12

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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The <variables> tag in the ConfigurationInstallerListener descriptor does not have any effect for an appropriate configuration action, no variable is read at all.



 Comments   
Comment by Rene Krell [ 21/Sep/12 ]

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





[IZPACK-863] Not possible to set a dynamic plain variable to "" Created: 21/Sep/12  Updated: 21/Sep/12  Resolved: 21/Sep/12

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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Setting a variable to "" results in an error during installing:

"Error in definition of dynamic variable variable_name: None or empty plain value"

There's no reason for having such a restriction, allow empty values.



 Comments   
Comment by Rene Krell [ 21/Sep/12 ]

Pull request with a fix: https://github.com/izpack/izpack/pull/70





[IZPACK-862] Installation in one existing folder not working Created: 19/Sep/12  Updated: 21/Sep/12  Resolved: 21/Sep/12

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

Type: Bug Priority: Major
Reporter: Sérgio Michels Assignee: Rene Krell
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win 7, IzPack 5.0 beta 11


Attachments: Zip Archive DirTest.zip    
Testcase included: yes
Number of attachments : 1

 Description   

If the directory of the installation already exists (can be empty) the installer will ask you if you want to continue and overwrite existing files. If you click yes the installer will return to the target panel not continuing the installation.

In the example (maven project) I set the default target to "C:\myapp". Creating this directory empty you will be able to reproduce the error.



 Comments   
Comment by Rene Krell [ 20/Sep/12 ]

I made a pull request with a fix for this: https://github.com/izpack/izpack/pull/69

Comment by Mulcamd [ 20/Sep/12 ]

This is the same issue as IZPACK-859.

Snapshot 5 beta snapshot 10 was Ok.

Comment by Rene Krell [ 21/Sep/12 ]

Yes, I can confirm this, this bug has been introduced within the last few weeks. The above pull request fixes it for me.

Comment by Rene Krell [ 21/Sep/12 ]

Duplicate of IZPACK-859





[IZPACK-861] No Dutch language Created: 15/Sep/12  Updated: 21/Sep/12  Resolved: 21/Sep/12

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

Type: Bug Priority: Major
Reporter: Mulcamd Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Snapshot izpack-dist-5.0.0-beta11-20120915.113332-1


Number of attachments : 0

 Description   

The dutch language does not appear in the list, although I specified it in the installer.xml
(Also in the installer of the snapshot itself does it not appear.)

Is this a bug or will this be added later?

Opening the snapshot jar with 7-Zip, in the directory D:\Downloads\izpack-dist-5.0.0-beta11-20120915.113332-1.jar\com\izforge\izpack\bin\langpacks\ the dutch language is there!



 Comments   
Comment by Tim Anderson [ 16/Sep/12 ]

Looks like a number of the language packs have been added with their ISO3 country code rather than their ISO3 language code.
The following is from the IzPack installer logs:

16/09/2012 8:10:45 AM WARNING: No locale for: ned
16/09/2012 8:10:45 AM WARNING: No locale for: svk
16/09/2012 8:10:45 AM WARNING: No locale for: rom
16/09/2012 8:10:45 AM WARNING: No locale for: mys
16/09/2012 8:10:45 AM WARNING: No locale for: chn
16/09/2012 8:10:45 AM WARNING: No locale for: scg
16/09/2012 8:10:45 AM WARNING: No locale for: cze
16/09/2012 8:10:45 AM WARNING: No locale for: glg
Comment by Mulcamd [ 17/Sep/12 ]

As far as I can find on the Internet, both the ISO3 language and the country code for the Netherlands is "nld".

Will this be solved in a snapshot?

Comment by Tim Anderson [ 19/Sep/12 ]

Fix is here: https://github.com/izpack/izpack/pull/68

Comment by Mulcamd [ 20/Sep/12 ]

Is there a snapshot I can test?

Comment by Tim Anderson [ 21/Sep/12 ]

See https://buildhive.cloudbees.com/job/izpack/job/izpack/132/org.codehaus.izpack$izpack-dist/

Comment by Mulcamd [ 21/Sep/12 ]

Confirmed, issue fixed!

Dutch language is selectable and flag is available!
Also conditions on language work!

Comment by Tim Anderson [ 21/Sep/12 ]

Pull request applied.

Renamed the following langpack resources and their corresponding flags:

  • cze -> ces. Replace Czech Republic country code with language code
  • ned -> nld. Replace country code with language code
  • por -> bra. Language pack contains Brazilian Portuguese messages. Replace Portuguese language code with Brazilan country code.
  • svk -> slk. Replace Slovakia country code with Slovakia language code
  • rom -> ron. Replaced outdated Romanian country code (now ROU) with language code
  • mys -> msa. Replaced Malaysia country code with language code
  • scg -> srp. Language pack contains Serbian messages. Replaced Singapore country code with Serbian language code.
  • ind -> idn. Language pack contains Indonensian messages, but the language code (idn) is indistinguishable from the lower case India country code (IND). Renamed to Indonesian country code to avoid potential conflict

Note that the glg (Galician) locale is not directly supported as it is not a locale distributed with the JVM. The http://sourceforge.net/projects/javagalician/ can be installed as an extension to add support however





[IZPACK-860] Uninstaller does not work on Windows 7 64 bits (normally without administrator rights) Created: 15/Sep/12  Updated: 18/Oct/12

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

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

4.3.5
Windows 7 64 bits
Programs are installed under C:\Program Files\My program


Number of attachments : 0

 Description   

The same uninstaller works fine under Windows XP 32 bits, but does not work under Windows 7 64 bits.
Further investigation shows that only when I start the command prompt (cmd.exe) with administrator rights and run java -jar uninstaller.jar the uninstaller functions properly. So probably this has to do with administrator rights???

The problem is that when creating a shortcut to the uninstaller or when right click on the uninstaller.jar file, there is not the option to exectute the jar with adminstrator rights.

In the installer is the option
<run-privileged condition="izpack.windowsinstall.vista|izpack.windowsinstall.7"/>
Could something similar be added to the uninstaller that it has administrator rights in itself?

Further testing, version 5 beta 11 is Ok and runs the installer fine on Windows 7 64 bits. So as far as I can test, this effect only 4.3.5 and not 5 beta 11 (izpack-dist-5.0.0-beta11-20120915.113332-1)



 Comments   
Comment by Dan Gravell [ 18/Oct/12 ]

See #727 I think... http://jira.codehaus.org/browse/IZPACK-727





[IZPACK-859] Dialog "Directory already exists. Are you sure ... : yes option has no effect Created: 15/Sep/12  Updated: 21/Sep/12  Resolved: 21/Sep/12

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

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

izpack-dist-5.0.0-beta11-20120915.113332-1.jar (latest 15 september 2012)
Windows XP


Attachments: JPEG File Dialog Directory exists Are you sure.JPG    
Number of attachments : 1

 Description   

When the directory exists, a dialog, see attachment, is shown.
This is correct.
Yet answering "Yes" on "Are you sure you want to install here and possible overwrite existing files? leaves you in the same Target panel dialog and clicking "Next" will bring up the dialog again. No way to get on to the next dialog / panel.



 Comments   
Comment by Mulcamd [ 15/Sep/12 ]

BTW the installer of the snapshot izpack-dist-5.0.0-beta11-20120915.113332-1 is also affected by this bug. Try to install this snapshot twice in the same directory.

Comment by Mulcamd [ 20/Sep/12 ]

This is the same issue as IZPACK-862.

Snapshot 5 beta 10 was Ok.

Comment by Rene Krell [ 21/Sep/12 ]

Please try the latest snapshot izpack-dist-5.0.0-beta11-20120921.105415-55.jar or later, whether this is fixed for you.

Comment by Mulcamd [ 21/Sep/12 ]

Fixed, as far as I can see.
Thank you!





[IZPACK-858] Uninstaller fails when INSTALL_PATH has spaces Created: 12/Sep/12  Updated: 15/Sep/12  Resolved: 15/Sep/12

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

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

Windows


Number of attachments : 0

 Description   

Uninstaller fails when INSTALL_PATH has spaces in 4.3.5.

This issue has been reported for version 5, see http://jira.codehaus.org/browse/IZPACK-839 and this issue links to http://jira.codehaus.org/browse/IZPACK-371.

Yet in 4.3.5 this is still a problem.
Since default Window uses Program files, all uninstallations there will fail.



 Comments   
Comment by Mulcamd [ 13/Sep/12 ]

Could this be solved in 4.3.6?

The resolution is already known.

Comment by Mulcamd [ 15/Sep/12 ]

The description is not correct. I close this issue and create a new one.





[IZPACK-857] ResourceNotFoundException: Image icon resource not found in flag.English Created: 11/Sep/12  Updated: 15/Sep/12  Resolved: 15/Sep/12

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

Type: Bug Priority: Major
Reporter: Mulcamd Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5.0 beta 11


Attachments: Text File error2.log     Text File error.log     Zip Archive Install_XML.zip    
Number of attachments : 3

 Description   

In my installer which runs fine in 4.3.5. I get the error:
ResourceNotFoundException: Image icon resource not found in flag.English
...
See attachment for full error.log

The GUI never comes up and in the task manager I see JAWAX.exe is still there. Nothing happens. I have to kill the process manually.

With java -jar install.jar I get the attached error.log

BTW, in a simple installer I do not get this error??

Probably this error is linked to http://jira.codehaus.org/browse/IZPACK-855



 Comments   
Comment by Mulcamd [ 11/Sep/12 ]

Used the izpack-dist-5.0.0-beta11-20120828.061123-50 snapshot.

Comment by Mulcamd [ 12/Sep/12 ]

All installer files

Comment by Mulcamd [ 12/Sep/12 ]

Error.log create by running the installer on the commandline with
java -jar instal.jar >error.log 2>&1

Windows XP.
Also on Windows 7 64 the GUI never gets visual.

Comment by Tim Anderson [ 14/Sep/12 ]

Fix is at https://github.com/izpack/izpack/pull/67

Comment by Mulcamd [ 15/Sep/12 ]

Great! I would be happy to test it.
Please let me know when there is snapshot which includes this fix.

Does this patch also fixes https://jira.codehaus.org/browse/IZPACK-855?
They seem to me to be related.

Comment by Tim Anderson [ 15/Sep/12 ]

Try http://ci.repository.codehaus.org/org/codehaus/izpack/izpack-dist/5.0.0-beta11-SNAPSHOT/izpack-dist-5.0.0-beta11-20120915.113332-1.jar

I've just configured the Bamboo service to deploy snapshots - hopefully this will appear in the Codehaus Nexus repository but doesn't appear to be there yet.

With the fix, I cannot reproduce IZPACK-855





[IZPACK-856] Setting variable $INSTALL_PATH not used in target panel - correct or bug?? Created: 11/Sep/12  Updated: 12/Sep/12  Resolved: 12/Sep/12

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

Type: Bug Priority: Major
Reporter: Mulcamd Assignee: Tim Anderson
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

IZPack 5 beta 11


Number of attachments : 0

 Description   

In 4.3.5. I used the code below to set the install path in the target panel:
<dynamicvariables>
....
<variable name="TARGET.DIR" value=some value"/>
<variable name="INSTALL_PATH" value="$

{APPLICATIONS_DEFAULT_ROOT}

$

{TARGET.DIR}

"/>
...
</dynamicvariables>

In 5.0 beta 11 I get the directory based on the <appname>

The documentation says:
This uses the following variable search order to determine the default directory to display:
TargetPanel.dir.<platform symbolic name> e.g. TargetPanel.dir.windows_7
TargetPanel.dir.<platform name> e.g. TargetPanel.dir.windows
TargetPanel.dir.<parent platform> e.g. given platform "FEDORA_LINUX" looks for TargetPanel.dir.linux, followed by TargetPanel.dir.unix
TargetPanel.dir
DEFAULT_INSTALL_PATH
SYSTEM_user_dir corresponds to the system property "user.dir"

The question is what is "DEFAULT_INSTALL_PATH". Is this the value of $INSTALL_PATH or the value from <appname>?
Atleast 4.3.5. I can set and use the $INSTALL_PATH.

HOWEVER, adding the code below solves my problem (workaround)
<variables>
...
<variable name="TargetPanel.dir.windows" value="$

{INSTALL_PATH}"/>
<variable name="TargetPanel.dir.mac_osx" value="${INSTALL_PATH}

"/>
</variables>



 Comments   
Comment by Tim Anderson [ 12/Sep/12 ]

In 5.0, INSTALL_PATH is populated by TargetPanel. When displayed, the path is initialised as per the documentation at http://docs.codehaus.org/display/IZPACK/Setting+Default+Installation+Directories

I've updated the documentation to include the DEFAULT_INSTALL_PATH information





[IZPACK-855] Failed to write uninstallation information (dialog) Created: 10/Sep/12  Updated: 19/Sep/12  Resolved: 19/Sep/12

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

Type: Bug Priority: Major
Reporter: Mulcamd Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64 bits
IZPack 5 beta 11


Attachments: Text File error.log     Text File error_small.log     JPEG File Error uninstallation information.jpg     Zip Archive Install_XML.zip    
Number of attachments : 4

 Description   

All the installation works fine, but at the last I get a popup with the message "Failed to write uninstallation information".

The install scripts work fine with 4.3.5 and have been adapted for 5 by setting the right version and the <natives>.

With a very simple installer the I do not get this message, but with my regular installer, this messsage occurs every time.

I tried java -jar installer.jar, but then I get not further information.



 Comments   
Comment by Mulcamd [ 10/Sep/12 ]

running java - jar install.jar under XP gives the error.log file.

[ Writing the uninstaller data ... ]
10-sep-2012 18:32:52 SEVERE: The path 'resources/langpacks/null.xml' is not present inside the classpath.
The current classpath is :/D:/Dropbox/myProgram rapporten/Export-Import/Test_Version5/install.jar

I also ran very simple basic test installer with java - jar install.jar: error_small.log

Comment by Mulcamd [ 11/Sep/12 ]

Workaround found.

Deleting all languages except english in my package makes that I do NOT get this error. I deleted dutch, french and german.
So for now this is my workaraound.

YET, I still find it strange that I get this error.
Selecting the english as language as user in both cases, the installer uninstaller quits with an error when other languages are possible. Even although I did'nt used them.

Please have a look at this before closing this issue!

Comment by Mulcamd [ 11/Sep/12 ]

Used the izpack-dist-5.0.0-beta11-20120828.061123-50 snapshot.

Comment by Tim Anderson [ 11/Sep/12 ]

Can you attach your install.xml?

Comment by Mulcamd [ 13/Sep/12 ]

Added install.xlm (all xml files).
Same files as for https://jira.codehaus.org/browse/IZPACK-857.

I think the issues are related.

Modifying the scrips with the 2 steps below will bring up the GUI, but finishes with the error dialog.
1) <modifier key="useFlags" value="yes"/> set to "no"
2) remove all languages except english
<!-- <langpack iso3="fra"/>
<langpack iso3="deu" />
<langpack iso3="ned" />
-->

Comment by Mulcamd [ 16/Sep/12 ]

Here this issues has been resolved.

Probably the solution for http://jira.codehaus.org/browse/IZPACK-857 "ResourceNotFoundException: Image icon resource not found in flag.English" has also fixed this.

I tested is short on Windows XP and Windows 7 64 bits.

Comment by Mulcamd [ 19/Sep/12 ]

Issue fixed!

with https://jira.codehaus.org/browse/IZPACK-857





[IZPACK-854] IzPack does not show which file it could not read Created: 07/Sep/12  Updated: 14/Sep/12  Resolved: 14/Sep/12

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

Type: Bug Priority: Major
Reporter: Jonas Stenberg Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Found in 5.0.0-beta10

Some file is missing in my package (I guess) but all I get from IzPack is a message displayed below. I would expect to be able to read which file that actually is missing from the error message.

The ScriptParser.java needs to catch IOException and re-throw it with the file name in the exception message.

From the console:
java.io.IOException: No such file or directory
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.checkAndCreate(File.java:1717)
at java.io.File.createTempFile0(File.java:1738)
at java.io.File.createTempFile(File.java:1815)
at com.izforge.izpack.installer.unpacker.ScriptParser.parseFiles(ScriptParser.java:89)
at com.izforge.izpack.installer.unpacker.Unpacker.run(Unpacker.java:383)
at java.lang.Thread.run(Thread.java:679)



 Comments   
Comment by Tim Anderson [ 12/Sep/12 ]

I've added more diagnostics at https://github.com/izpack/izpack/pull/66

Note that yhou'd be better off trying a recent snapshot of the 5.0.0-beta11 rather than 5.0.0-beta10.
Also see http://docs.codehaus.org/display/IZPACK/Debugging+Installers

Comment by Jonas Stenberg [ 12/Sep/12 ]

I will upgrade to beta11 as soon as it is available in the maven repository, until that I am stuck with beta10.

It is a good thing that you can debug the installer but you cannot expect an end user to do that when they get an error message, therefore all the error messages needs to be clear and precise. IzPack has historically suffered greatly from poor error messages. I hope this will improve in the 5.0 release, otherwise I will continue to report bugs whenever I find the error messages to be insufficient.





[IZPACK-853] PacksPanel empty without activating TargetPanel before Created: 31/Aug/12  Updated: 01/May/13

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

Type: Bug Priority: Major
Reporter: Sérgio Michels Assignee: Rene Krell
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x86


Attachments: Zip Archive ExampleAdjusted.zip     Zip Archive Example.zip    
Issue Links:
Duplicate
duplicates IZPACK-918 Unable to display packs in packs pane... Open
dependent
is depended upon by IZPACK-952 Avoid functional dependency on Target... Open
Testcase included: yes
Number of attachments : 2

 Description   

I just updated a project for the beta11 and adjusted the version of install.xml. The deploy that in beta10 generates *-install.jar now generates the same name of my maven artifactId and also the packs aren't displayed in PacksPanel.



 Comments   
Comment by Rene Krell [ 31/Aug/12 ]

Hi Sérgio,

you're mixing two completely different issues into one, the Maven plugin and the definition of packs in the install descriptor. But anyway, it just seems like you're using the latest IzPack in an unproper way.

Unfortunately I can't compile your example due to the missing dependencies
1) br.com.insoft4:ponto-soft-express-client:jar:0.1
2) br.com.insoft4:insoft-utils:jar:0.1.5

But I try to explain it:

For using the Maven plugin as it is, have a look at http://docs.codehaus.org/display/IZPACK/IzPack+Maven+Plugin+Reference
You don't have necessarily to use

<packaging>izpack-jar</packaging>

althought I'd recommend it in case you have a separate Maven module for the installer creation.
In each case you can overrde the finalName or use classifiers (for instance "installer") and optionally attach the installer as artifact to generate names like "myartifact-installer". Not everyone might want to give it this name, so it's one you to define exactly the finalName you want, otherwise it defaults to the artifactid itself, yes. This way you get the chance to install and deploy your installer as Maven artifact, if you want.

Concerning the packs, I'm not sure what happened but for your special case and with minimal changes, I'd recommend the following changes in your POM:

<plugin>
    <groupId>org.codehaus.izpack</groupId>
    <artifactId>izpack-maven-plugin</artifactId>
    <version>${izpack.version}</version>
    <!--
    <configuration>
         <izpackBasedir>${staging.dir}</izpackBasedir>
         <installerFile>${staging.dir}/install.xml</installerFile>
    </configuration>
    -->
    <configuration>
        <baseDir>${staging.dir}</baseDir>
        <installFile>${staging.dir}/install.xml</installFile>
        <outputDirectory>${project.build.directory}</outputDirectory>
        <finalName>${project.build.finalName}-installer</finalName>
        <mkdirs>true</mkdirs>
    </configuration>
    <!--
    <dependencies>
        <dependency>
             <groupId>org.codehaus.izpack</groupId>
             <artifactId>izpack-panel</artifactId>
             <version>${izpack.version}</version>
        </dependency>
    </dependencies>
    -->
    <executions>
        <execution>
            <id>standard-installer</id>
            <phase>package</phase>
            <goals>
                <goal>izpack</goal>
            </goals>
        </execution>
    </executions>
</plugin>

You don't need any extra explicit dependency for the plugin anymore.

Even more simple you'd get it using the "izpack-jar" packaging, which allows you to replace calling the jar plugin with the izpack plugin implicitely, but in this case you would need a separate module for the installer creation.

Comment by Rene Krell [ 31/Aug/12 ]

I would mark this not to be a bug. We have already many installers improved with the latest approach. This is just a misconfiguration.

In case I'm in mistake, please reopen. I'm ready to bring this discussion to an end here.

Comment by Sérgio Michels [ 31/Aug/12 ]

You are right, I mixed two things in one, sorry. The name of file is ok with the changes in the config of plugin, thanks!

Sorry about the dependencies too, I just forgot to comment them, for this sample you don't need them. But the PacksPanel still not showing any pack at all.

I commented the dependency of org.codehaus.izpack:izpack-panel as you said as you can see in the new attached example.

I also tried the "izpack-jar" packaging, but then Maven complains, saying that this is not a valid packaging.

Comment by Sérgio Michels [ 31/Aug/12 ]

The new version of example, with pom.xml changed.

Comment by Rene Krell [ 31/Aug/12 ]

Regarding Maven complaining izpack-jar as not valid packaging - yes, there is some point that should be pointed out in the documentation for this use-case:

Don't forget to add

<extensions>true</extensions>

to the plugin defintion in the POM, thus:

<plugin>
    <groupId>org.codehaus.izpack</groupId>
    <artifactId>izpack-maven-plugin</artifactId>
    <extensions>true</extensions>
    ...
</plugin>
Comment by Sérgio Michels [ 31/Aug/12 ]

Hi Rene, thanks for the response. I add the extensios but still cannot see any pack for selection. Can you try to build the "ExampleAdjusted"?

Comment by Sérgio Michels [ 31/Aug/12 ]

Just to add more info:

The same install.xml with beta10 (changing the tag install of course and defining the packaging as just jar) works. My complete env is:
JDK: jdk1.6.0_29
Maven: 3.0.4
Windows 7 x86

I'm trying beta11 because beta10 have a bug with executables running twice.

Comment by Rene Krell [ 31/Aug/12 ]

Yes, I compiled and see this:

you got to reorder the panels:

<panels>
    <panel classname="CheckedHelloPanel" id="checked"/>
    <panel classname="TargetPanel" id="target" />
    <panel classname="PacksPanel" id="selectpacks"  />
    ...

having the TargetPanel before the PacksPanel for some reason.
Not sure at the moment, for which reason.

Comment by Rene Krell [ 31/Aug/12 ]

Also I tried th izpack-jar packaging, its working fine for me in your example with:

<plugin>
    <groupId>org.codehaus.izpack</groupId>
    <artifactId>izpack-maven-plugin</artifactId>
    <version>${izpack.version}</version>
    <extensions>true</extensions>
    <configuration>
        <izpackBasedir>${staging.dir}</izpackBasedir>
        <installerFile>${staging.dir}/install.xml</installerFile>
        <outputDirectory>${project.build.directory}</outputDirectory>
        <finalName>${project.build.finalName}-installer</finalName>
        <mkdirs>true</mkdirs>
    </configuration>
</plugin>

not using the execution block at all (this is implicitly called similar to the jar plugin in the package phase).

Comment by Sérgio Michels [ 31/Aug/12 ]

It's really the panel order that messed up. I changed to TargetPanel first and works as you said. Maybe this occurs because you need to know if exists enough free space to execute the install (depending on packs selected)?





[IZPACK-852] ConfigurationInstallerListener - Add variable substitution to attribute <entry .. value="..."/> Created: 23/Aug/12  Updated: 24/Aug/12  Resolved: 24/Aug/12

Status: Resolved
Project: IzPack
Component/s: 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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, there is no variable substitution for the 'value' attribute
of the nested <entry> element in <configurable>.

For example, if I have something like:

<configurable ...>
        <entry key="set.JAVA_HOME" value="${previous.wrapper.java.home.canonical}"/>
</configurable>

and previous.wrapper.java.home.canonical is the name of an dynamic
Izpack variable from install.xml with a valid value, this isn't
replaced here.



 Comments   
Comment by Rene Krell [ 23/Aug/12 ]

The change introduces also variable substitution for the attribute
<entry data="..."/>
for registry entries.





[IZPACK-851] Remove support for unqualified class names for user classes at compilation Created: 18/Aug/12  Updated: 13/Dec/12  Resolved: 26/Aug/12

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

Type: New Feature Priority: Minor
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The compiler currently allows the specification of unqualified class names in install.xml.
When an unqualified class name is encountered, it uses ClassPathCrawler to find a class with the same simple name. If two classes have the same simple name, then its behaviour is non-deterministic.
A deterministic and faster approach would be to:

  • only allow unqualified names for IzPack classes; a simple mapping would be used to get their fully qualified names
  • require fully qualified class names for all other classes


 Comments   
Comment by Tim Anderson [ 21/Aug/12 ]

Pull request is at https://github.com/izpack/izpack/pull/61





[IZPACK-850] NullPointerException when building with maven plugin with custom panel Created: 17/Aug/12  Updated: 26/Aug/12  Resolved: 26/Aug/12

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

Type: Bug Priority: Minor
Reporter: Sérgio Michels Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: build, exception, maven
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win 7, IzPack 5.0.0-beta10, IzPack Maven plugin


Attachments: Zip Archive IzPackNullPointer.zip    
Number of attachments : 1

 Description   

I was trying to build my installer with the maven plugin and defining a custom panel in my install.xml:

<panel classname="br.com.insoft4.izpack.panels.PontoExpressTreePacksPanel" jar="dependency/Insoft4IzPackPanels.jar" />

With this way, the build process throw a NullPointerException:

java.lang.AssertionError: java.lang.NullPointerException
  at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:94)

...

Caused by: java.lang.NullPointerException at com.izforge.izpack.compiler.helper.CompilerHelper.getFullClassName(CompilerHelper.java:62)

If I change my xml to declare the jar outside of panels it works well.

<panels>
<panel classname="br.com.insoft4.izpack.panels.PontoExpressTreePacksPanel" />
</panels>
<jar src="dependency/Insoft4IzPackPanels.jar"/>

Maybe a better error message will help in finding the xml markup issue.



 Comments   
Comment by Sérgio Michels [ 17/Aug/12 ]

Simple maven project that simulates the error.

Comment by Tim Anderson [ 26/Aug/12 ]

Fixed as part of the refactoring of classpath handling for beta11





[IZPACK-849] ConfigurationInstallerListener - Remove the explicit strict checking of XML root elements during a merge, just do the merge according to the configured rules Created: 17/Aug/12  Updated: 22/Aug/12  Resolved: 22/Aug/12

Status: Resolved
Project: IzPack
Component/s: 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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, a XML merge of something like

Original:
<rootelement someattribute="somevalue">

Patch (for instance from a previous installation):
<rootelement>

with different elements or just attributes is not possible. Just for the root element there is a check, whether the element name is the same, the list of attributes is equal and even all attribute values are equal.

This check is not necessary and prevents from configuring the merge for the root element, the XML merge should be done according to the defined rules with actions, mappers and matchers, like for the nested elements. If someone needs to strictly compare the root elements, a rule can be defined, according to http://docs.codehaus.org/display/IZPACK/ConfigurationInstallerListener. This can be a default or a special XPath rule.






[IZPACK-848] ConfigurationInstallerListener - Report more details about unmatched root element during XML merge Created: 17/Aug/12  Updated: 17/Aug/12  Resolved: 17/Aug/12

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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

During merging of two XML files, if the root elements do not match, an error message is thrown:
"Root elements do not match."

Report, which elements do not match in particular for better finding them.






[IZPACK-847] <updatecheck> does not delete directories in the right hierarchical order Created: 17/Aug/12  Updated: 17/Aug/12  Resolved: 17/Aug/12

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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

On using the <updatecheck> tag, There are two problems in deleting unneeded directories in the target folder:

  • Deleting of directories happens in a random order. In most case this causes not to delete most of outstanding directories which are no longer part of the installation, although they are enabled to be removed. For example, on an update installation, there is a subfolder a/b/c from a previous application in the same target folder to be removed. Currently, during deletion they are read from a list of directories to be removed in a random order, thus, it may happen, they are tried to be deleted in the order
    1. a
    2. a/b
    3. a/b/c
      which doesn't work, because the first two of them are still non-empty. The installer logs a warning here.
      Solution: Try to order them first to delete them from the deepest hierachy level up to the highest one.
  • The update check tries also to delete directories, which are implicit parents of files which have been added as single files to the installer. In that case, the uninstaller, from which the list of installed files are fetched from, doesn't know all the parent directories, but just the single target files.
    Solution: First delete all files, then delete all directories, which is already done now. Additionally don't delete non-empty directories, because they are most probably implicit parents of installed files.





[IZPACK-846] TargetPanel sets variable INSTALL_PATH to default install path already on activating Created: 16/Aug/12  Updated: 16/Aug/12  Resolved: 16/Aug/12

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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The target panel sets the INSTALL_PATH variable by mistake to the default install path already on activating.
Instead, it should just fill the path input field with the defualt input path and set INSTALL_PATH with the contents of that field on leaving the panel.

For instance, this causes problems on using references to $INSTALL_PATH in conditions or dynamic variables, if there is not known the real target path the files should be installed to, for example in the Exists condition with tests of the existance of a variable value.

Just leave INSTALL_PATH unset unless the user chooses "his" target path during the installation.






[IZPACK-845] ProcessPanelAutomationHelper requires unsatisified dependency ProcessPanelWorker Created: 14/Aug/12  Updated: 17/Aug/12  Resolved: 17/Aug/12

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

Type: Bug Priority: Major
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   
org.picocontainer.injectors.AbstractInjector$UnsatisfiableDependenciesException:
com.izforge.izpack.panels.process.ProcessPanelAutomationHelper has
unsatisfied dependency 'class
com.izforge.izpack.panels.process.ProcessPanelWorker' for constructor
'public
com.izforge.izpack.panels.process.ProcessPanelAutomationHelper(com.izforge.izpack.panels.process.ProcessPanelWorker,com.izforge.izpack.util.Housekeeper)'
from
org.picocontainer.DefaultPicoContainer@5253c3f5:1<[Immutable]:org.picocontainer.DefaultPicoContainer@22e90943:45<|
at org.picocontainer.injectors.ConstructorInjector.getGreediestSatisfiableConstructor(ConstructorInjector.java:197)
  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)


 Comments   
Comment by Tim Anderson [ 17/Aug/12 ]

Fix is at https://github.com/izpack/izpack/pull/59





[IZPACK-844] Improve implementation and extensibility of ConfigurationActions framework Created: 14/Aug/12  Updated: 17/Sep/13

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

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

Attachments: XML File izpack-configaction-current.xml     XML File izpack-configaction-proposed-with-separate-sets.xml     XML File izpack-configaction-proposed.xml     XML File izpack-configurationactions-5.0.xsd    
Testcase included: yes
Number of attachments : 4

 Description   

ConfigurationInstallerListener drives major new functionality in 5.0 for modifying and patching configuration settings for an installation. It currently supports several file-based configuration types, and the Windows registry. It will be a huge advantage for update functionality (also IZPACK-655), and in deprecating the native COIOSHelper DLLs (IZPACK-600).

I propose working on the following specific bits and pieces.

  1. Refactor and consolidate ConfigurationInstallerListener source/target attributes (per this dev list discussion)
  2. Configurable type attribute should allow fully-qualified class name for third-party plugin implementations.
  3. SingleConfigurableTask.patchConfigurable() should be abstract/generic (to allow easier plugin development).
  4. Setting a patch source for registry config action should really be optional to support config driven by <entry> elements (e.g. uninstaller).
    • The fromKey attribute is actually documented as optional in RegistryTask.setFromKey(), but prevented in ConfigurationInstallerListener.readConfigurables().
  5. Registry configuration task should allow toKey="<new_key_name>", to support creating brand new keys without exporting large system-critical parent keys (e.g. uninstaller).
  6. Registry task should support writing a patched config to a new registry key like file-based configs.
    • The registry config doesn't appear to have an equivalent to the fromFile/originalFile/patchFile combination - just fromKey and toKey.
  7. Corresponding documentation updates.

These tweaks should enable users to make the most of the new features.



 Comments   
Comment by Daniel Abson [ 23/Aug/12 ]

Items 2 & 3 (extensibility of ConfigurationActions) should be deferred to a new issue (possibly for a 5.1/6.0 release?). The scope is too wide, and the refactoring too extensive. Getting the core functionality/interface finalised is more important.

Comment by Rene Krell [ 23/Aug/12 ]

Regardless of the changes in code, it would be good to see examples of a configuration action descriptor XML for each type of configurable with typical/possible use cases for everyone to get the message what effect this will have. They can be later copied to the documentation (Confluence).
The XML syntax/semantics and functionality changes are important here, the implementation is secondary.

Comment by Daniel Abson [ 23/Aug/12 ]

You mean like this idea of yours on the dev list:

<configurables>
<registry>
<entry key="..." value="..." data="..."/>
</registry>
<propertyfile>
<entry key="..." value="..."/>
</propertyfile>
...
</configurables>

I think that'd be great! I definitely agree that this is a better way to go with the XML spec. I can change direction with this issue, and go with that idea.

Comment by Rene Krell [ 23/Aug/12 ]

This has been just a suggestion.
This issue is just a mix of interface changes to the users and to developers and I'd like to point out for each of these groups, what they can expect here. For developers it is quite clear, maybe we can even separate this.
For one not familar with the details it would be a good help to give examples of an descriptor. We can discuss this here, this should not be that difficult.

Comment by Daniel Abson [ 23/Aug/12 ]

Making the interface for users more specific (separate elements for each type of configurable) rather than more universal (using the type attribute) does make more sense to me, now. I think this issue should focus on that user interface, and on the additional functions that are available to the user (e.g. allowing toKey to be a new registry key, which is created by the installer). I'll come up with a suggested new version of the XML spec, based on René's idea above, and post it here.

I'll also raise a separate issue for the developer interface issues (i.e. refactored abstraction and encapsulation to allow plugin development), so that this is all a bit clearer.

Comment by Daniel Abson [ 23/Aug/12 ]

I've attached two sample configuration spec files - one representing the current spec form, and one representing a new, proposed spec. I think I've listed all attributes of all elements, and tried to illustrate them using dummy values.

The idea behind the new spec is to get rid of the <configurable> element and replace it with more specific specs for each different configurable type. No functionality will be lost; some new functionality could be added.

I've also revived an idea that was originally discussed and mutually rejected on the dev mailing list: to merge the functions of <configurableset> and <configurable>. Now that there are specific elements for individual config types, I think it makes sense that file-based configs be able to support single- and multiple-file merges. This blurs the lines a bit between user/developer interface changes, but I think it's worth it.

The FileCopyTask already supports exactly this functionality, and I suggest that it's a good point of reference for refactoring the property/INI file code, as well as the XML spec. Merging configurable/configurableset would also add useful functionality like failOnError to single-file config operations.

I don't think supporting single- and multiple-file configs in a single element is confusing, now that there are separate elements for each config type. It will clearly only apply to property and INI files, and this will be self-explanatory and easily documented. The existing XML config type already supports both filesets and a single source file, and the whole thing is irrelevant to registry configs.

I've also added additional attributes in the proposed spec to the <registry> type, to reflect a couple of the original ideas in this issue (e.g. targetKey). Now that each config type has its own element, it seems pointless to make the to/from/target attribute names 'universal' - which was part of this original issue - but I've still kept the to/from/target forms instead of originalFile/patchFile.

Comment by Rene Krell [ 24/Aug/12 ]

They look quite good, that's exactly, what it makes more transparent.

One point I don't understand: How do you want to get in the functionality of <configurableset>? I see the filesets and mappers there, but isn't it better to leave the set as it is, for not having again mutations of attributes? if you have a fileset, toFile, fromFile and targetFile make no sense. Even in the configurableset as it is we need necessarily type attribute to know what to do with it, so where is actually the advantage?

Another question: Have you tried to validate this against a XSD at least syntactically, whether this is possible without the need of a certain order of nested elements? Just to prepare a good design for future changes in XML parsing. If yes, can you please attach this XSD file as well?

Comment by Rene Krell [ 24/Aug/12 ]

I'd enhance and modify your proposal by separating configurablesets from single configurables. This would remove most of the attribute mutations and checks for the valid usage would be much more easier in the code.
See the attached file izpack-configaction-proposed-with-separate-sets.xml ...

Comment by Daniel Abson [ 27/Aug/12 ]

The FileCopyTask already has a validate() method to handle both single-file and fileset functionality. At the moment, it's only used for configurableset, but it's still checking that the toFile/fromFile attributes and fileset element are not used at the same time. It seems like using FileCopyTask as the parent class for all file-type configurables (not just configurablesets) makes sense, since only file-type implementations are likely to need configurableset-like functionality (e.g. <registryset> doesn't really make sense). Merging the single- and multiple-file versions of the same element would reduce duplicate XML and code, and the logic is already there in the codebase!

I think that anybody familiar with Ant will be more than comfortable with the idea of specifying toFile/fromFile(/targetFile) or toDir/<fileset>. As stated, the FileCopyTask code is already designed this way. In fact, even the single file tasks currently have programmatic validation (SingleConfigurableTask.validate()), so there's already some checking that won't be done with the XSD. As for future changes to XML parsing, this kind of validation can be done using XSD 1.1 like this:

<xs:assert test="not(@toFile and fileset)"/>

Given that we want each config type to have its own element in the XML, I think it would be stranger to have separate elements for single-file and multiple-file configs than it would be to simply allow the toFile or toDir variants of the same element.

Comment by Rene Krell [ 27/Aug/12 ]

Its is not just about filesets, but also <entry> and <pathproperty> elements.

Regardless of the code, the Izpack users are not machines, there are too much erroneous mutations of attributes and elements here. I don't see the advantage having such a number of optional nested entry, which are really allowed or does make sense just in certain combinations of attribute values on another nested hierarchy level. I'd agree if there were just nested <fileset>s, which you proposed recently.

On the other hand, I'd rather appreciate some code optimization than adapting the XML interface to the code as it is. The discussion here is too much about the code than the effect for the users. Code optimizations can be done almost each time. The code should follow the interface (even the user interface), not vice versa, in my opinion.

I'd imagine just nesting single configurables into configurablesets, to inherit some attributes, as base directories, but I'd not go more far.

Comment by Daniel Abson [ 27/Aug/12 ]

That's true, I'd forgotten about the nested <entry> option. However, <xpathproperty> is only for XML files, which already allows both fromFile and nested <fileset> together.

Anyway, to optimise the code I would still refactor the single configurable tasks to extend FileCopyTask. Both single and multiple configurable properties/ini tasks use a large number of identical attributes and functions, so it makes sense to use the same code. As far as the user's concerned, there's really only two variations: three attributes and a nested element are valid for single file tasks; one different attribute and two different nested elements are valid for multiple file tasks. It works well for Ant - can you imagine having separate <copy> and <copyset> tasks?!

I'll get cracking on the code anyway, and do the XML parsing based on the separate configurable/configurableset interface. I can't imagine sets being used for anything but files, so a separate <configurablesets> tag maybe isn't needed. Maybe someone else will have an opinion on all this? It's going to be a big improvement either way!

Comment by Rene Krell [ 27/Aug/12 ]

Just got to add:

<xpathproperty> is just for xml files and not for a set of different xml files, because you must something know about the certain structure of the file.
Therefore it would be best placed in

<configurables ...>
  <xmlfile ...>
    <xpathproperty .../>
  </xmlfile>
</configurables>

This is more clear for someone using it. A XSD would be also simple.

It should be a very rare usecase, where a set of file have the same structure to be used along with <entry> and <xpathproperty>, shouldn't it?

Comment by Daniel Abson [ 27/Aug/12 ]

I think that would be quite rare. Are you suggesting an additional differentiation, like <xmlfile> and <xmlfileset>?

Comment by Rene Krell [ 28/Aug/12 ]

We can do that, as a synonym for <configurableset type="xml" .../>.

It is of course just an opinion.
Even from the developer's point of view I think it is better if you can easily transform from XSD, because in future coding will be more transparent than, too. A choice for the future might be also automatically generating code for XML externizable classes from XSD. It will be more difficult the more conditions and logics is defined around it. I'd rather simplify the XML in terms of having non-ambigouos elements and as much as possible decoupling complicated relations and checks between nested elements and their parents. This way we will be better prepared for JAXB and similar XML parser frameworks, objects can directly represent XML containers and frameworks can do syntax and value range checks, while semantic checks in our code will be reduced. Please someone correct me in case I'm in mistake.

Comment by Daniel Abson [ 28/Aug/12 ]

Having a framework like JAXB replace the XML parsing code will be a fantastic step forwards, but I don't think the XML needs to be 'dumbed down' in order to achieve that. Allowing a small amount of variation in the XML spec for individual elements is completely standard behaviour. Ant is perhaps the most relevant example, and I expect that the majority of the IzPack user base is familiar with it. IzPack itself uses a number of Ant conventions and features (such as the <fileset>/<mapper> that we're talking about here). In fact, Ant itself started off with separate <copyfile>/<copydir> tasks, which were deprecated way back in v1.2 in favour of the more compact <copy>. I wouldn't call it 'complicated', though.

As for removing syntax and value range checks from the code - XSD can already validate ranges, and XSD 1.1 (already supported by parsers like Xerces and Saxon) can validate attribute/element variants easily (see above). The current code already has some semantic checks that XSD 1.0 can't do, so moving all checks to schema-based validation will definitely be the way to go. I agree with simplicity and removing ambiguity, but decoupling two aspects of the same function might be a bit excessive! I think it's possible to improve the code and use a JAXB-like framework, while still maintaining a compact, intuitive, and mature XML spec.

Comment by Daniel Abson [ 14/Sep/12 ]

I've finished refactoring the code, and updated the XSD. There's some new functionality, mostly due to the refactoring - new possibilities are available through inheritance using pre-existing code. I haven't done any proper testing yet, and I do plan to add proper unit/integration tests for the framework, hopefully by the end of the month.

If anybody has the time to check out my branch https://github.com/omniamutantur/izpack/tree/IZPACK-844, I'd be really grateful. I will obviously need to update the documentation too, once any changes have been accepted.

Comment by Rene Krell [ 16/Sep/12 ]

Thank you, I've had two weeks of vacations until now, will have a look at it next week.

Comment by Daniel Abson [ 05/Oct/12 ]

My testing's been delayed by other projects, but my branch on GitHub is now up-to-date with the latest updates on the Git master, and has the first batch of unit tests for the config actions.

Comment by Rene Krell [ 30/Oct/12 ]

I'm currently checking your branch, nice work as far as I have seen. Just need some time to adapt and test my existing installers whether they will do their work as usual.

Comment by Rene Krell [ 30/Oct/12 ]

Some validation questions regarding your branch:

<xs:complexType name="fileType">
  ...
  <xs:attribute name="todir" type="xs:string" use="required"/>

Why is the toDir attribute mandatory here? I can define absolute paths in fromFile, toFile and targetFile and do not need a directory here in this case. This has been also the behavior before, toDir has been in most cases required for filesets.

The validation fails for

<property ...>
  <entry .../>
</property>

with

cvc-complex-type.2.4.a: Invalid content was found starting with element 'entry'. One of '{fileset, mapper}' is expected.

This should be allowed according to the implementation.

As far as I see those are XSD issues.

Another note: Could you please update or prepare the Confluence documentation at http://docs.codehaus.org/display/IZPACK/ConfigurationInstallerListener or do you have another page where this is documented separately?

Comment by Daniel Abson [ 30/Oct/12 ]

I've fixed the todir attribute for the fileType in this XSD so that it's optional. Not sure why you're getting the error with the xmlType, though. Both fileset and mapper elements have minOccur="0", which should make them optional.

I'm still working on finishing the unit tests, which have raised some issues that I've been able to fix. I'll be creating some new wiki pages when I've finished the test suite.

Comment by Rene Krell [ 30/Oct/12 ]

Appearantly fileset, mapper and entry are not merged as expected from the different type definitions. I checked this in Eclipse, do you have any validator which allows this?

Comment by Rene Krell [ 30/Oct/12 ]

I think I got it. There is a definition:

<xs:element name="configurables"  minOccurs="0" maxOccurs="1">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="inifile" type="multiMapFileType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="property" type="multiMapFileType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="registry" type="registryType" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

There should be a reference to "stdMultiMapFileType", instead, right?

Comment by Rene Krell [ 30/Oct/12 ]

Also, there should be

<xs:attribute name="cleanup" type="xs:boolean" use="optional"/>
...
<xs:attribute name="condition" type="xs:string" use="optional"/>
Comment by Rene Krell [ 30/Oct/12 ]

Attached the current configuration actions XSD which works for me.

Comment by Daniel Abson [ 30/Oct/12 ]

Thanks, René. I've merged the relevant changes to my working copy, and they'll go up to GitHub shortly.

Comment by Rene Krell [ 30/Oct/12 ]

There will be some more, for example:

  • Currently you must have configurables in the order they are defined (you cannot have <registry> before <property>, for example)
  • The XML configurables are missing at all, they are just defined as type but never used.
  • Regarding to the code (ConfigType), the configurable names must be {propertyfile, inifile, xmlfile, registry}

    , not

    {property, inifile, registry}
Comment by Rene Krell [ 30/Oct/12 ]

Re-attached the current XSD, which at least validates in theory, I'll go testing the resulting installer now
This might break your existing XML, but accords to the code. Another way would be changing the strings in ConfigType.

Comment by Rene Krell [ 30/Oct/12 ]

With the current implementation, I get a

Oct 30, 2012 4:44:11 PM SEVERE: java.lang.Exception: Warning: Could not find file /home/rkrell/mycompany/myapp/config/resources.xml to copy.
com.izforge.izpack.api.exception.InstallerException: java.lang.Exception: Warning: Could not find file /home/rkrell/mycompany/myapp/config/config/resources.xml to copy.
        at com.izforge.izpack.event.ConfigurationInstallerListener.performAllActions(ConfigurationInstallerListener.java:430)
        at com.izforge.izpack.event.ConfigurationInstallerListener.afterPack(ConfigurationInstallerListener.java:334)
        at com.izforge.izpack.installer.event.InstallerListeners.afterPack(InstallerListeners.java:287)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:408)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:260)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.run(UnpackerBase.java:242)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.Exception: Warning: Could not find file /home/rkrell/mycompany/myapp/config/resources.xml to copy.
        at com.izforge.izpack.util.file.FileCopyTask.execute(FileCopyTask.java:303)
        at com.izforge.izpack.util.config.ConfigFileTask.execute(ConfigFileTask.java:116)
        at com.izforge.izpack.util.config.MergeableConfigFileTask.execute(MergeableConfigFileTask.java:116)
        at com.izforge.izpack.util.config.XmlFileConfigTask.execute(XmlFileConfigTask.java:109)
        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:426)
        ... 6 more

for the configuration listener directive:

<xmlfile cleanup="true"
         fromfile="${INSTALL_PATH}/config/resources.xml.configbak"
         tofile="${INSTALL_PATH}/config/resources.xml"
          condition="isCompatibleUpgrade">
  <xpathproperty key="action.default" value="COMPLETE"/>
</xmlfile>

Appearently, there is some mess with com.izforge.izpack.util.config.ConfigFileTask.setToFile(File), which sets the source file instead of a target file in the parent class. The situation appears, if $

{INSTALL_PATH}

/config/resources.xml doesn't come with the new installation. In the previous implementation this has been silently tolerated, patches have been done just in case the file to compare with existed. There is probably interchanged the source and the target file, maybe you changed the meaning of some field.

Can you have a look at it, please?

Comment by Daniel Abson [ 31/Oct/12 ]

Will do. I've just pushed all my latest updates to GitHub. I'll have a look at the XML file issue next.

Comment by Daniel Abson [ 01/Nov/12 ]

Have a look at the latest version of the branch. I think it should be fixed now.

Comment by Daniel Abson [ 13/Nov/12 ]

Pull request created on GitHub, build is good, documentation is all finished.

Comment by Rene Krell [ 04/Dec/12 ]

Please look at my comment on the pull request. There is still some logical inconsistency in the actual behavior.

Comment by Daniel Abson [ 04/Dec/12 ]

I saw your comment, René - I'm working on it at the moment.

Comment by Rene Krell [ 13/Dec/12 ]

Alright. Meanwhile I adjusted the documentation to the current state because we decided to release 5.0.0-beta11 for testing. As soon as this works and gets merged we can switch it. See the subpages of http://docs.codehaus.org/display/IZPACK/Listeners

Comment by Daniel Abson [ 13/Dec/12 ]

I've pushed the fix for the "tofile" issue, would be great if all the new stuff could make it into the beta11 release!

Comment by Rene Krell [ 13/Dec/12 ]

Sorry, it's already a day too late, I launched the release yesterday after an agreement in the izpack-dev mailing list based on the state before.
But if it will look good in the next tests it will get in. This still has to be checked out. I think there is no problem to get it in later.

Comment by Daniel Abson [ 17/Sep/13 ]

Resolved an issue raised on the GitHub pull request, and added test cases. Feature branch should be complete! New test cases added, and draft documentation updated with latest change.





[IZPACK-843] executable with ABORT failure handling does not abort installer Created: 13/Aug/12  Updated: 13/Aug/12

Status: Open
Project: IzPack
Component/s: Installer, Uninstaller
Affects Version/s: 4.3.3
Fix Version/s: None

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

Windows 7 x64, Java 7


Number of attachments : 0

 Description   

When an executable from any given pack is configured with 'failure=abort' and executed, the GUI shows an error dialog telling the user the error message and another dialog saying the installation was not successful. However, the installation (standing at the PackPanel at the time of execution) can still be continued with the 'Forward' button at the bottom of the panel.

In my opinion, an abort failure handling should lead to the correct abort of the installer process, e.g. only Quit button, no uninstaller, delete all installed files etc.






[IZPACK-842] Disabled packs are available for installation in console mode Created: 13/Aug/12  Updated: 13/Aug/12

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

Type: Bug Priority: Major
Reporter: Iain Soars 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 several packs defined in my install.xml which have conditions on them to determine if they are available to be installed or not. In the GUI installer they are correctly greyed out and unselectable in the PacksPanel if those conditions are not met. In the console installer however, they are selected by default and will install regardless of the conditions.






[IZPACK-841] Cannot generate an automatic installation script from console installer Created: 13/Aug/12  Updated: 13/Aug/12

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

Type: Bug Priority: Major
Reporter: Iain Soars 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 FinishPanel of the GUI installer gives the user the opportunity to generate an automatic installation script which captures the selected installation options. When running the installer on the console however this option is not available.






[IZPACK-840] Document and clean up ConfigurationInstallerListener-local variables Created: 09/Aug/12  Updated: 13/Aug/12  Resolved: 13/Aug/12

Status: Resolved
Project: IzPack
Component/s: 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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

In the configuration actions descriptor there is already from the beginning implemented the ability to define local variables just seen by the configuration actions themselves.

This is not documented.

Syntactically, the variables are currently nested in
<configurationactions>
<variable/>
<variable/>
...
</configurationactions>

which is not clean and can not be handled later together with the configurationactions in an XSD.

Embed them in a <variables/> element and add this facitlity also to the documentation.



 Comments   
Comment by Rene Krell [ 09/Aug/12 ]

Fix available at https://github.com/izpack/izpack/pull/53 and documented.

Comment by Rene Krell [ 13/Aug/12 ]

Resolved in IzPack 5.0.0-beta11-SNAPSHOT





[IZPACK-839] Uninstaller fails when INSTALL_PATH has spaces Created: 08/Aug/12  Updated: 09/Aug/12  Resolved: 09/Aug/12

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

Type: Bug Priority: Major
Reporter: Daniel Abson Assignee: Tim Anderson
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Latest 5.0.0-beta11-SNAPSHOT from git HEAD


Attachments: Text File izpack6757619578386786713.log    
Number of attachments : 1

 Description   

Attached output from uninstaller log for the command

"C:\Program Files\Java\jre6\bin\java.exe" -jar "C:\Program Files\My Test App\uninstall.jar"

The only feedback to System.out is

The uninstaller has put a log file: Z:\TEMP\izpack6757619578386786713.log

'Phase 3' of the uninstall process fails to start. The command debugged in the log shows the the first part of the path to the uninstall jar is missing ("C:\Program "), and that the path is then getting split on the space character as individual arguments - instead of the whole thing getting escaped with double-quotes.



 Comments   
Comment by Tim Anderson [ 09/Aug/12 ]

This should have been fixed by https://github.com/izpack/izpack/pull/50 as per http://jira.codehaus.org/browse/IZPACK-371

Comment by Daniel Abson [ 09/Aug/12 ]

Yep, that fixes it. Thanks!

Comment by Tim Anderson [ 09/Aug/12 ]

Fixed in IZPACK-371





[IZPACK-838] CheckedHelloPanel not defining UNINSTALL_NAME variable Created: 06/Aug/12  Updated: 09/Aug/12  Resolved: 09/Aug/12

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

Type: Bug Priority: Major
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The CheckedHelloPanel is not defining the UNINSTALL_NAME variable.
This is required by izpack-dist\src\main\izpack\RegistrySpec.xml



 Comments   
Comment by Tim Anderson [ 08/Aug/12 ]

Fix is available at https://github.com/izpack/izpack/pull/52





[IZPACK-837] Replace IzPack DTDs with XSDs Created: 05/Aug/12  Updated: 28/Aug/12  Resolved: 28/Aug/12

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

Type: Improvement Priority: Major
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There are a number of out-dated DTDs in the izpack-core module under src/main/resources/dtd:

  • installation.dtd
  • langpack.dtd
  • conditions.dtd
  • event/antaction.dtd
  • event/bsfaction.dtd
  • event/registry.dtd

These should be replaced by XSDs and also uploaded to the website.
There are two schemas already, which appear to be incomplete:

  • izpack-dist/src/main/resources/schema/izpack-installation.xsd
  • izpack-dist/src/main/resources/schema/izpack-userinput.xsd

In addition to the above, there also needs to be a schema for shortcut specs.

Suggested conventions, borrowing from Spring:

  • schema names in lowercase, prefixed by "izpack-"
  • schema names will have the IzPack version in the suffix
  • each schema has its own namespace
  • each schema will eventually be published to izpack.org

E.g., izpack-installation.xsd is the schema for install.xml files.
Its targetNamespace is

https://izpack.github.io/schema/installation

and will be available at:

https://izpack.github.io/schema/installation/izpack-installation-5.0.xsd

Users can then reference the schema as follows:

<installation xmlns="https://izpack.github.io/schema/installation"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="https://izpack.github.io/schema/installation https://izpack.github.io/schema/installation/izpack-installation-5.0.xsd">


 Comments   
Comment by Tim Anderson [ 12/Aug/12 ]

This change provides an XML-Schema for each of the IzPack xml configuration files.
With the exception of the install.xml file, this change does not break existing configuration files that don't specify schema information.
For install.xml, the version attribute has been updated from "1.0" to "5.0".
If specified, the schemas will enforce ordering constraints that may require existing configuration files to be re-ordered.

Changes are available at https://github.com/izpack/izpack/pull/54

The schemas are located in the izpack-dist/src/main/resources/schema/5.0/ directory.
On completion these will be published to the izpack.org website, under https://izpack.github.io/schema/5.0/.

To add schema validation, use the following declarations:

Installation:

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

Conditions:

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

Langpack:

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

Registry:

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

Shortcuts:

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

Ant Actions:

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

BSF Actions:

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

Icons:

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

Configuration Actions:

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

User Input

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

Processing

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

Compilation

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

Note: the misspelt packdepency element has been renamed to packdependency.

Comment by Tim Anderson [ 28/Aug/12 ]

The schemas have been pushed to the https://izpack.github.io/schema/5.0.

The schema paths are:

Note that if the schema path is incorrect or incomplete (e.g. https://izpack.github.io/schema/5.0/ ), a 404 error will be raised. Does Github:Pages have a convenient way of generating an html listing of all files under a path?





[IZPACK-836] Introduce multiple dynamic variable filters, add LocationFilter Created: 03/Aug/12  Updated: 09/Aug/12  Resolved: 09/Aug/12

Status: Resolved
Project: IzPack
Component/s: Compiler, Documentation, Installer, Showcases
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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Testcase included: yes
Number of attachments : 0

 Description   

Some refactory is still necessary to make the handling of dynamic variables more clean. I've already updated the chapter "Filtering Values" at http://docs.codehaus.org/display/IZPACK/Dynamic+Variables according to this. To this time, a nested <regex> filter could be included.

There have been some disadvantages with this:

  • There could be just one regex filters used, not a chain of several filters with different attributes
  • It has been difficult to add more filters
  • The XML structure was not really clean to get more filters added, because there are also other nested elements possible to <dynamicvariable>, which are not filters, resulting in mixing filters and other arguments.

The goal ist to make a clean API and user XML interface, embed filters in a nested <filters> element.
Further I add an LocationFilter to give the possibility to resolve relative filenames against some basedir, see the mentioned documentation.



 Comments   
Comment by Rene Krell [ 09/Aug/12 ]

Fixed in latest 5.0.0-SNAPSHOT deployment.





[IZPACK-835] IzPack 5.0.0-beta10, IzPack 5.0.0-beta9 - can not compile with properties section Created: 02/Aug/12  Updated: 06/Sep/12

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

Type: Bug Priority: Major
Reporter: Eugene Ustimenko Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: izpack, linux, properties
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Ubuntu 12.04


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

 Description   

IzPack is not compile install.xml with <properties> section.
The error log and installation file attached to issue.



 Comments   
Comment by Rene Krell [ 02/Aug/12 ]

Please try to use the latest 5.0.0-beta11-SNAPSHOT deployments. I deploy them frequently, at the current time.

The documentation, http://docs.codehaus.org/display/IZPACK/Properties, might be useful for you.

Comment by Eugene Ustimenko [ 02/Aug/12 ]

Rene, we use maven in our project and can not include jars to it.
Thank you for link, but this documentation is not helpful for me, because I write my izpack app due to it.

Comment by Rene Krell [ 02/Aug/12 ]

You can regularly include also snapshot deployments in your Maven project. Just reconfigure the maven-enforcer-plugin to temporarily accept them by

<pluginManagement>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-enforcer-plugin</artifactId>
          <executions>
            <execution>
              <id>enforce-plugin-versions</id>
              <goals>
                <goal>enforce</goal>
              </goals>
              <configuration>
                <rules>
                  <requirePluginVersions>
                     <!-- Allow snapshots of IzPack Maven Plugin -->
                     <unCheckedPluginList>org.codehaus.izpack:izpack-maven-plugin</unCheckedPluginList>
                  </requirePluginVersions>
                </rules>
              </configuration>
            </execution>
          </executions>
        </plugin>
</pluginManagement>

Alright?

Comment by Eugene Ustimenko [ 07/Aug/12 ]

Rene, it is not help.

Comment by Eugene Ustimenko [ 06/Sep/12 ]

Izpack do not create jar-files with this fix.





[IZPACK-834] Possible NPE in ConfigurationInstallerListener due to unknown attribute values in configuration action specification file Created: 01/Aug/12  Updated: 03/Aug/12  Resolved: 03/Aug/12

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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5.0.0-beta11-SNAPSHOT


Number of attachments : 0

 Description   

A NullPointerException is thrown in one installation case during execution of the ConfigurationInstallerListener

Aug 1, 2012 9:54:12 AM com.izforge.izpack.installer.unpacker.UnpackerBase unpack
SEVERE: java.lang.NullPointerException
com.izforge.izpack.api.exception.InstallerException: java.lang.NullPointerException
        at com.izforge.izpack.event.ConfigurationInstallerListener.performAllActions(ConfigurationInstallerListener.java:347)
        at com.izforge.izpack.event.ConfigurationInstallerListener.afterPack(ConfigurationInstallerListener.java:251)
        at com.izforge.izpack.installer.event.InstallerListeners.afterPack(InstallerListeners.java:287)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:406)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:258)
        at com.izforge.izpack.installer.unpacker.UnpackerBase.run(UnpackerBase.java:240)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
        at com.izforge.izpack.util.config.SingleConfigurableTask.executeNestedEntries(SingleConfigurableTask.java:555)
        at com.izforge.izpack.util.config.SingleConfigurableTask.execute(SingleConfigurableTask.java:198)
        at com.izforge.izpack.event.ConfigurationActionTask.execute(ConfigurationActionTask.java:71)
        at com.izforge.izpack.event.ConfigurationAction.performInstallAction(ConfigurationAction.java:65)
        at com.izforge.izpack.event.ConfigurationInstallerListener.performAllActions(ConfigurationInstallerListener.java:343)
        ... 6 more


 Comments   
Comment by Rene Krell [ 01/Aug/12 ]

This has been caused due to a misconfigured configuration action in the config actions spec:

<configurable type="options" cleanup="true"
                    keepOldKeys="false" keepOldValues="false"
                    patchfile="${INSTALL_PATH}/wrapper.conf.configbak"
                    tofile="${INSTALL_PATH}/wrapper.conf"
                    condition="keepWrapperJavaVersion+haveWrapperJavaCmd">
    <entry key="set.JAVA_HOME" operation="${previous.wrapper.java.home}"/>
</configurable>

was a typo, should be

<configurable type="options" cleanup="true"
                    keepOldKeys="false" keepOldValues="false"
                    patchfile="${INSTALL_PATH}/wrapper.conf.configbak"
                    tofile="${INSTALL_PATH}/wrapper.conf"
                    condition="keepWrapperJavaVersion+haveWrapperJavaCmd">
    <entry key="set.JAVA_HOME" value="${previous.wrapper.java.home}"/>
</configurable>

but NPEs should not be user-visible.

Improving error handling to make it a user-understandable error message.

Comment by Tim Anderson [ 03/Aug/12 ]

Pull request merged.





[IZPACK-833] Windows shortcut with url for webpage not created in 4.3.5 - 4.3.3; correct in 4.3.2 Created: 31/Jul/12  Updated: 13/Sep/12

Status: Reopened
Project: IzPack
Component/s: None
Affects Version/s: 4.3.3, 4.3.4, 4.3.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mulcamd Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: shortcut, web
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP3


Attachments: File CompileIzPack_v4_older.cmd     Text File compile.log     Text File errors_1.log     Text File errors_2.log     XML File Installer_Windows_shortcutSpec.xml     XML File install.xml     Text File Licence.txt     Text File Readme.txt    
Number of attachments : 8

 Description   

Shortcut with reference to a page on the web is not created in 4.3.5, 4.3.4 and 4.3.3.
YET in 4.3.2 the shortcut is properly created.
Created a small test installation.
Below is the shortcut part.

<shortcut applications="no" description="$APP_NAME on the web"
desktop="no" initialState="noShow" name="$APP_NAME on the web"
programGroup="yes" startMenu="no" startup="no" target="http://www.google.com"/>



 Comments   
Comment by Mulcamd [ 04/Aug/12 ]

I made a mistake to fill the fix version invalid to 4.3.2
This issue is active for 4.3.5

Comment by Mulcamd [ 04/Aug/12 ]

I made a mistake filling the fix version invalid.
This is a active issue for 4.3.5.

What I meant was that in 4.3.2 this issue worked correctly and from 4.3.3 onward this issue exists.

Comment by Tim Anderson [ 04/Sep/12 ]

The following works for me using 5.0:

    <shortcut applications="no" description="$APP_NAME on the web"
              desktop="no" initialState="noShow" name="$APP_NAME on the web"
              programGroup="yes" startMenu="no" startup="no" commandLine="" target="http://www.google.com">
        <createForPack name="Base"/>
    </shortcut>
Comment by Mulcamd [ 07/Sep/12 ]

Thank you for looking in to it.

I tested your code above in both 4.3.5 and 4.3.2.
In 4.3.5 the shortcut is NOT created.
In 4.3.2 the shortcut is created.
So in the change from 4.3.2. to 4.3.3. something has changed and makes that it is since then not working anymore.

Could you please fix this in 4.3.6!
Shortcuts to the Web are important, because all the information is there.
So many people are still on 4.3.x AND I tried 5.0. beta 10 and I ran into all kinds of errors.

I also tried 5.0 beta 10 standalone, but then I get all kinds of errors:
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com/izforge/izpack/panels/htmlinfo/HTMLInfoPanel
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)

...
Ok I could solve that by change the HTMLHelloPanel to HTMLInfoPanel
but then I get

INFO: The next panel of 4 is panel number 5
java.lang.ClassNotFoundException: com.izforge.izpack.Pack
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.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at java.io.ObjectInputStream.resolveClass(Unknown Source)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at java.util.ArrayList.readObject(Unknown Source)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at java.io.ObjectStreamClass.invokeReadObject(Unknown Source)
at java.io.ObjectInputStream.readSerialData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at com.izforge.izpack.installer.unpacker.UnpackerBase.writeInstallationInformation(UnpackerBase.java:597)
at com.izforge.izpack.installer.unpacker.Unpacker.run(Unpacker.java:418)
at java.lang.Thread.run(Unknown Source)

Comment by Mulcamd [ 07/Sep/12 ]

Added the error logs when running with IZPack 5

Attachment error_2.log is from a real installer.
Attachment error_1.log is based on the samples provided, where I added <natives> ... </natives>

Comment by Tim Anderson [ 07/Sep/12 ]

You'll need to use a recent snapshot of IzPack 5.0.0-beta11 to avoid these issues, and also consult http://docs.codehaus.org/display/IZPACK/Upgrading+from+IzPack+4.3+to+5.0

Comment by Tim Anderson [ 07/Sep/12 ]

If you can't use 5.0 I suggest you go back through the git history for izpack-native-parent\src\main\native\ShellLink\src\ShellLink.cxx and determine which version breaks URL shortcuts.
The fix for IZPACK-538 may fix the issue.
You might even be able to use an earlier/later version of ShellLink.dll as a workaround.

Comment by Mulcamd [ 08/Sep/12 ]

Were can I download the latest snapshot?
Is this an installer like "http://dist.codehaus.org/izpack/releases/5.0.0-beta10/izpack-dist-5.0.0-beta10-installer.jar" or do I have to compile it myself?

Comment by Tim Anderson [ 08/Sep/12 ]

You can find a snapshot of the distribution at https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/izpack/izpack-dist/5.0.0-beta11-SNAPSHOT/
At the time of writing, the latest is izpack-dist-5.0.0-beta11-20120828.061123-50.jar
If you are using maven, you can just add a dependency like:

            <plugin>
                <groupId>org.codehaus.izpack</groupId>
                <artifactId>izpack-maven-plugin</artifactId>
                <version>5.0.0-beta11-SNAPSHOT</version>
                <configuration>
                    <installFile>${staging.dir}/install.xml</installFile>
                    <baseDir>${staging.dir}</baseDir>
                </configuration>
                <executions>
                    <execution>
                        <id>standard-installer</id>
                        <phase>package</phase>
                        <goals>
                            <goal>izpack</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

which will give you the latest snapshot of the plugin.

Comment by Mulcamd [ 08/Sep/12 ]

I use the standalone version.
I downloaded the snapshot, izpack-dist-5.0.0-beta11-20120828.061123-50.jar

First, I can confirm that issue http://jira.codehaus.org/browse/IZPACK-687 has been solved!

I could not compile my installers, because:
8-sep-2012 22:53:50 com.izforge.izpack.core.container.PlatformProvider provide
INFO: Detected platform: windows,version=5.1,arch=x86,symbolicName=WINDOWS_XP,javaVersion=1.6.0_33
-> Fatal error :
install.xml:2: the file version is different from the compiler version

I googled, but could not find information on the error.

Any suggestions?

Full log attached,

Comment by Mulcamd [ 08/Sep/12 ]

Fatal error :
install.xml:2: the file version is different from the compiler version

Should I create a seperate issue for version 5?

Comment by Tim Anderson [ 09/Sep/12 ]

Nope - the configuration files have changed format for 5.0.
See http://docs.codehaus.org/display/IZPACK/Upgrading+from+IzPack+4.3+to+5.0
In particular, have a look at the section: IzPack XML-Schemas (IzPack-5.0.0-beta-11)

Comment by Mulcamd [ 13/Sep/12 ]

Back to the original shortcut issue in 4.3.5.
Since version 4 is a production release, could this issues be solved in 4.3.6?
At least for me it is essential to be able to created shortcuts to the internet for help, for more information on the product and on company.

It has already worked (4.3.2) and it is working in version 5. Hopefully this would not be to hard to solve???





[IZPACK-832] Incorrect error message returned from DataValidator class in console mode Created: 31/Jul/12  Updated: 31/Jul/12

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

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

Red Hat Linux and Windows 7 with -console


Number of attachments : 0

 Description   

I have an implementation of the DataValidator interface which is used to validate on of my UserInputPanel screens. The validator returns an error message which is correctly displayed in the GUI if validation fails. However, if validation fails in console mode a different error message is displayed 'Validation Failed, please verify your input' which looks like a default message rather than the my custom message






[IZPACK-831] Variables in descriptions not parsed in console mode Created: 27/Jul/12  Updated: 27/Jul/12

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

Type: Bug Priority: Minor
Reporter: Iain Soars 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   

If a variable is added to the <description> element for a pack it is correctly substituted in the graphical installer. However the same variable does not get substituted when installing in console mode.

As an example, I have a variable defined as <variable name="tomcat.dist.version" value="7.0.27"/> and a pack with the description <description>Installs the Apache Tomcat $

{tomcat.dist.version} application server.</description>. The graphical installer will correctly substitute the variable for 7.0.27 but in console mode the description is displayed with ${tomcat.dist.version}

instead






[IZPACK-830] java.lang.NoSuchMethodError: com.izforge.izpack.util.file.FileUtils.close when run install.jar Created: 26/Jul/12  Updated: 18/Aug/12  Resolved: 18/Aug/12

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

Type: Bug Priority: Major
Reporter: Paul Taylor Assignee: Tim Anderson
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Build a simple install.jar from install.xml, when I try and run the install.jar it complains it cnanot find a method. This occurs if I build and install using either Java 6 or Java 7.

If I build and install using izpack 4.3.5 I have no problem.

Exception in thread "AWT-EventQueue-0" java.lang.NoSuchMethodError: com.izforge.izpack.util.file.FileUtils.close(Ljava/io/Closeable;)V
at com.izforge.izpack.installer.container.impl.EventFiller.readObject(EventFiller.java:154)
at com.izforge.izpack.installer.container.impl.EventFiller.loadCustomData(EventFiller.java:62)
at com.izforge.izpack.installer.container.impl.InstallerContainer.fillContainer(InstallerContainer.java:98)
at com.izforge.izpack.core.container.AbstractContainer.initBindings(AbstractContainer.java:25)
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:47)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)



 Comments   
Comment by Tim Anderson [ 18/Aug/12 ]

Try running a recent snapshot of 5.0.0-beta-11 or pull the latest sources from git





[IZPACK-829] Enable default TargetPanel directory to be configured via variables based on platform Created: 24/Jul/12  Updated: 26/Jul/12  Resolved: 26/Jul/12

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

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

Number of attachments : 0

 Description   

In 4.3.5, the default directory displayed in TargetPanel may be configured in a text file named:

  • TargetPanel.dir.<os name>
  • TargetPanel.dir

In the <os name> form, the os name is one of:

  • System.getProperty("os.name").replace(' ', '_')
  • "windows"
  • "macosx"
  • "unix"

For 4.3.6, IZPACK-798 changed the above to use variables instead of text files, following the same naming convention.
For 5.0 a better approach would be to use Platform to determine the appropriate variable.
The variable could be derived from:

  • Platform.getSymbolicName(), if the current platform has one, E.g. TargetPanel.dir.windows_7
  • Platform.getName() E.g., TargetPanel.dir.windows
  • The parent platform, if there is no directory specified for getSymbolicName() or getName(). E.g. if current platform is FEDORA_LINUX and there is no TargetPanel.dir.fedora_linux, fall back to TargetPanel.dir.linux. Failing that, fall back to TargetPanel.dir.unix

If no variable is specified for the current platform, it would use TargetPanel.dir



 Comments   
Comment by Tim Anderson [ 26/Jul/12 ]

Pull request is at: https://github.com/izpack/izpack/pull/38

This uses the following variable search order to determine the default directory to display:

  1. TargetPanel.dir.<platform symbolic name> e.g. TargetPanel.dir.windows_7
  2. TargetPanel.dir.<platform name> e.g. TargetPanel.dir.windows
  3. TargetPanel.dir.<parent platform> e.g. given platform "FEDORA_LINUX" looks for TargetPanel.dir.linux, followed by TargetPanel.dir.unix
  4. TargetPanel.dir
  5. DEFAULT_INSTALL_PATH
  6. SYSTEM_user_dir corresponds to the system property "user.dir"

Available platforms can be found in the class Platforms. The names are the lowercase versions of those defined.
Allowed names include:

  • aix
  • debian_linux
  • fedora_linux
  • freebsd
  • hp_ux
  • linux
  • mac
  • mac_osx
  • mandrake_linux
  • mandriva_linux
  • os_2
  • red_hat_linux
  • sunos
  • sunos_x86
  • sunos_sparc
  • suse_linux
  • unix
  • ubuntu_linux
  • windows
  • windows_7
  • windows_xp
  • windows_2003
  • windows_vista

Differences from 4.3.5

In 4.3.5, resources were used rather than variables. Resources were searched for with the following names

  • "TargetPanel.dir." + lower case version of System.getProperty("os.name"), with any spaces replace with underscores
  • "TargetPanel.dir." + <platform> where platform is one of ("windows", "macosx", "unix")
  • "TargetPanel.dir"




[IZPACK-828] panel class throwing ClassNotFoundException if parent class from other package not included in install.xml Created: 23/Jul/12  Updated: 23/Jul/12

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

Type: Bug Priority: Major
Reporter: Jyoti Tripathi 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   

Izpack only includes classes from the same package as the panel class, resulting in a ClassNotFoundException for parent classes from other packages






[IZPACK-827] AntActionInstallerListener - Izpack variable are not substituted in resource "AntActionsSpec.xml" when launching Ant targets Created: 20/Jul/12  Updated: 20/Jul/12  Resolved: 20/Jul/12

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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There are not replaced variables in the resource "AntActionsSpec.xml"

    <antcall order="afterpacks" buildresource="antBuild.xml" verbose="yes" logfile="${INSTALL_PATH}/setup/log/setup_antactions_afterpacks.log">
      <property name="setup.base" value="${INSTALL_PATH}"/>
    ...

There are not replaced the $

{INSTALL_PATH}

variables as expected before using the spec effectively.



 Comments   
Comment by Rene Krell [ 20/Jul/12 ]

Thanks to Tim for the useful hints.
Fix on GitHub: izpack/izpack





[IZPACK-826] IzPack variables not substituted in XML attributes of the ConfigurationInstallerListener descriptor Created: 20/Jul/12  Updated: 20/Jul/12  Resolved: 20/Jul/12

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: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours
Original Estimate: Not Specified
Environment:

5.0.0-beta11-SNAPSHOT
all OS


Number of attachments : 0

 Description   

Variable substitution has been broken along with some latest refactoring in ConfigurationInstallerListener. For example, in a descriptor like

<configurationactions>
  <pack name="My Application Core">
    <configurationaction order="afterpack">

      <!-- Patch and merge single all property files -->
      <configurableset type="options" cleanup="true"
                       keepOldKeys="false" keepOldValues="true" overwrite="true"
                       todir="${INSTALL_PATH}/config"
                       condition="isUpgrade">
        <fileset dir="${INSTALL_PATH}/config">
          <include name="*.properties.configbak"/>
        </fileset>
        <mapper type="glob" from="*.properties.configbak" to="*.properties"/>
      </configurableset>

  </pack>
</configurationactions>

there haven't been subsituted the $

{INSTALL_PATH}

by the IzPack variable representing the actual target installation path.






[IZPACK-825] In an unattended install using -options, the field of type password is not set Created: 18/Jul/12  Updated: 30/Nov/12

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

Type: Bug Priority: Major
Reporter: Jonathan Albrecht Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows, Linux


Number of attachments : 0

 Description   

I have a field of type password in one of my panels:

<field type="password" variable="dbPassword">
  <spec>
    <pwd txt="Database Password:" size="15" set="myset" />
  </spec>
</field>

I'm using the -options installer arg to specify a property file like:

INSTALL_PATH=C:\\Program Files\\myapp
controllerPort=9997
dbType=oracle
dbHostname=qa-ora112-rhes54.rd.local
dbPort=1521
dbName=orcl.rd.local
dbPassword=mypwd
dbUsername=qa_auto01

All of the fields have their value set except for dbPassword which gets the value "$dbPassword". It should get the value "mypwd".



 Comments   
Comment by Björn Bung [ 30/Nov/12 ]

I got the same error with 4.x izPack.





[IZPACK-824] UserInputPanel console mode missing multiple fixes from 4.3 branch Created: 04/Jul/12  Updated: 24/Sep/12

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

Type: Bug Priority: Major
Reporter: Alison Winters Assignee: Tim Anderson
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

There have been a number of important fixes committed to the 4.3 branch UserInputPanelConsoleHelper that are missing in 5.0. In particular, commit 7bd1853090fd9ca88d3a4388297f4ab098bae67d introduced field validation to match the GUI behavior. Right now 5.0 installers don't validate any fields on the UserInputPanel. It would be great if all the various fixes missing from 5.0 could be rolled in, but validation in particular is a notable absence.



 Comments   
Comment by Tim Anderson [ 04/Jul/12 ]

Please feel free to fix this and submit a pull request: https://izpack.github.io/developers/





[IZPACK-823] Problems Using IzPack On Windows 7 Created: 03/Jul/12  Updated: 05/Jul/12  Resolved: 04/Jul/12

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

Type: Bug Priority: Major
Reporter: doc Assignee: Tim Anderson
Resolution: Not A Bug Votes: 0
Labels: help-requested
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Up to date JRE, On a clients computer


Number of attachments : 0

 Description   

I have been working on a java program that uses IzPack. One of my clients that used the generated installer reported that the installer got to the part where files are copied, and it passed that. When they clicked next (going to the shortcut part) it froze.

The client said that the files weren't copied to the computer, and there were no shortcuts. The client even ran it in command prompt using Installer.exe command, and it didn't print anything, it just ran the installer, with the same results. It works fine on my windows XP computer, and a windows Vista computer. Thanks for helping in advance!

Here's the xml for my installer:

<?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>

<!--
A sample installation file.
Use it as a base for your own installers

To compile it :
- go in the bin directory where you installed IzPack
- call "compile ../sample/install.xml -b ../sample"
-->

<installation version="1.0">

<!--
The info section.
The meaning of the tags should be natural ...
-->
<info>
<appname>TFFS</appname>
<appversion>1.0</appversion>
<authors>
<author name="Doc" email=""/>
</authors>
<url>http://tffs.castraponere.com/</url>
</info>

<!--
The gui preferences indication.
Sets the installer window to 640x480. It will not be able to change the size.
-->
<guiprefs width="640" height="480" resizable="yes"/>
<variables>
<variable name="DesktopShortcutCheckboxEnabled" value="true"/>
</variables>
<!--
The locale section.
Asks here to include the English and French langpacks.
-->
<locale>
<langpack iso3="pol"/>
<langpack iso3="eng"/>
</locale>

<!--
The resources section.
The ids must be these ones if you want to use the LicencePanel and/or the InfoPanel.
-->
<resources>
<res src="shortcutSpec.xml" id="shortcutSpec.xml"/>
<res id="LicencePanel.licence" src="Licence.txt"/>
<res id="InfoPanel.info" src="Readme.txt"/>
<res id="TargetPanel.dir.windows" src="TargetDir.txt" parse="yes"/>
</resources>

<!--
The panels section.
We indicate here which panels we want to use. The order will be respected.
-->
<panels>
<panel classname="HelloPanel"/>
<panel classname="LicencePanel"/>
<panel classname="TargetPanel"/>
<panel classname="PacksPanel"/>
<panel classname="InstallPanel"/>
<panel classname="ShortcutPanel"/>
<panel classname="FinishPanel"/>
</panels>

<!--
The packs section.
We specify here our packs.
-->
<packs>
<pack name="Base" required="yes">
<description>The base files</description>
<file src="Readme.txt" targetdir="$INSTALL_PATH"/>
<file src="Licence.txt" targetdir="$INSTALL_PATH"/>
<file src="exe.ico" targetdir="$INSTALL_PATH"/>
<file src="uninstaller.exe" targetdir="$INSTALL_PATH/Uninstaller"/>
<fileset dir="code" targetdir="$INSTALL_PATH/code">
<include name="**"/>
</fileset>
</pack>
</packs>
<native type="izpack" name="ShellLink.dll"/>
<native type="3rdparty" name="COIOSHelper.dll" stage="both">
<os family="windows"/>
</native>
</installation>

Here's the shortcutspec.xml:


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<shortcuts>

<skipIfNotSupported/>

<programGroup defaultName="TFFS" location="applications"/>

<shortcut
name="TFFS"
programGroup="yes"
desktop="yes"
applications="no"
startMenu="no"
startup="no"
target="$INSTALL_PATH\code\TFFSbase.exe"
commandLine=""
description="Play TFFS"
iconFile="$INSTALL_PATH\exe.ico"
iconIndex="0"
workingDirectory="$INSTALL_PATH\code"
initialState="noShow">

<createForPack name="Base"/>

</shortcut>

<shortcut
name="TFFS Uninstaller"
programGroup="yes"
desktop="no"
applications="no"
startMenu="no"
startup="no"
target="$INSTALL_PATH\Uninstaller\uninstaller.exe"
commandLine=""
iconFile="%SystemRoot%\system32\SHELL32.dll"
iconIndex="31"
workingDirectory="$INSTALL_PATH\Uninstaller"
description="Uninstall TFFS">

<createForPack name="Base"/>
</shortcut>

</shortcuts>




 Comments   
Comment by Tim Anderson [ 04/Jul/12 ]

Please use the mailing list to ask questions before raising bug reports.
You have at least two issues with your install.xml:
1. you are missing the 64 bit versions of the ShellLink and COIOSHelper dlls:

        <native type="izpack" name="ShellLink.dll"/>
        <native type="izpack" name="ShellLink_x64.dll"/>
        <native type="3rdparty" name="COIOSHelper.dll" stage="both"/>
        <native type="3rdparty" name="COIOSHelper_x64.dll" stage="both"/>

2. you might need to elevate permissions on Vista and Windows 7:

    <info>
        <!-- snip -->
        <run-privileged condition="izpack.windowsinstall.vista|izpack.windowsinstall.7"/>
    </info>
Comment by doc [ 04/Jul/12 ]

Ok, sorry about not using the mailing list. I searched for it but I couldn't find it.

Thanks for the tips! I'll try them.

Comment by Tim Anderson [ 04/Jul/12 ]

You can find the mailing lists at https://izpack.github.io/mailing-lists/

Comment by doc [ 05/Jul/12 ]

Ok, it works. Thank you for helping me, and in the future, if I have problems I'll use the mailing list.





[IZPACK-822] IconsDatabae should be used to get installer JFrameIcon Created: 03/Jul/12  Updated: 04/Jul/12  Resolved: 04/Jul/12

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

Type: Bug Priority: Minor
Reporter: Daniel Abson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The IconsDatabase object, populated from the icons listed in the standard icons.xml and the optional customicons.xml, is not used to get the main installer window icon, JFrameIcon. Instead, a hard-coded path to the default icon is used in InstallerFrame, and for the language dialog in GUIInstallerContainer. Both should use the version in the IconsDatabase instance instead.



 Comments   
Comment by Tim Anderson [ 04/Jul/12 ]

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





[IZPACK-821] Installer image on left-hand side does not work as documented Created: 02/Jul/12  Updated: 04/Jul/12  Resolved: 04/Jul/12

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

Type: Bug Priority: Minor
Reporter: Daniel Abson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The installer image functionality as documented in the wiki appears broken in recent builds from Git master. In fact, the image is not displayed in the IzPack installer itself.

Specifically, and with Installer.image.0 defined as documented:

  • using the Installer.image._panelID does not display an image on the identified panel;
  • using Installer.image.0 does not display an image on the first panel (e.g. HelloPanel);
  • the image defined by Installer.image.0 appears initially before the contents of the first panel are displayed (e.g. if an already-installed warning appears using CheckedHelloPanel), but then disappears when the panel is actually displayed;
  • numbering for displaying images in panels by index still works if you use 1 for the first panel, instead of 0 as documented (though Installer.image.0 still needs to be defined).


 Comments   
Comment by Daniel Abson [ 02/Jul/12 ]

Submitted pull request 14 with fixes. PanelID images now work again, and numbering for panels again starts at index 0.

But from the logic in InstallerFrame.switchPanel() and AbstractPanels.getVisibleIndex() it looks like the index numbering would be not be consistent if one or more panels were made visible conditionally. If Installer.image.1 was set, but the second panel was not shown due to an unfulfilled condition, all the numbered images would then be out of place. Panel 3 would have index 1, Panel 4 would have index 2, etc, and the wrong images would be shown.

Would it be better to remove the index numbering system altogether? Installer.image.0 could be a default image, shown if no other is given, and all others would be specified by ID. It would simply the logic in the installer, too.

Comment by Tim Anderson [ 02/Jul/12 ]

Not sure of the history behind the image numbering. It does fail if the no. of panels change. In these situations, the Installer.image.id convention must be used. This is more or less covered in the wiki entry:

The index-based solution is less flexible than using identifiers, but that is really up to you. You may also combine both styles, although this may cause some maintenance headaches on your side.

Comment by Daniel Abson [ 03/Jul/12 ]

That's fair enough. The pull request fixes just the bugs reported by this issue, restoring the functionality as currently documented.

Comment by Tim Anderson [ 04/Jul/12 ]

Pull request merged thanks.





[IZPACK-820] Add summary output to ShortcutPanel Created: 29/Jun/12  Updated: 29/Jun/12

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

Type: Wish Priority: Minor
Reporter: Daniel Abson 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   

Where ShortcutPanel is displayed before InstallPanel (see also IZPACK-819), it would be nice to include data on SummaryPanel listing the selected options.






[IZPACK-819] Missing dependency for running an installer with LateShortcutInstallListener Created: 27/Jun/12  Updated: 02/Jul/12  Resolved: 30/Jun/12

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

Type: Bug Priority: Minor
Reporter: Daniel Abson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The following exception occurs when trying to run an installer compiled with LateShortcutInstallListener.

Output from command line with -DTRACE=true

27-Jun-2012 15:54:42 INFO: Logging initialized at level 'INFO'
27-Jun-2012 15:54:42 INFO: Commandline arguments:
Exception in thread "AWT-EventQueue-0" com.izforge.izpack.api.exception.IzPackException: com.izforge.izpack.api.exception.ContainerException: org.picocontainer.injectors.AbstractInjector$UnsatisfiableDependenciesException: com.izforge.izpack.event.LateShortcutInstallListener has unsatisfied dependency 'interface com.izforge.izpack.api.panels.IShortcutPanelLogic' for constructor 'public com.izforge.izpack.event.LateShortcutInstallListener(com.izforge.izpack.api.panels.IShortcutPanelLogic,com.izforge.izpack.api.data.InstallData)' from org.picocontainer.DefaultPicoContainer@baa466:1<[Immutable]:org.picocontainer.DefaultPicoContainer@18bbc5a:44<|
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:64)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:646)
at java.awt.EventQueue.access$000(EventQueue.java:84)
at java.awt.EventQueue$1.run(EventQueue.java:607)
at java.awt.EventQueue$1.run(EventQueue.java:605)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:616)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: com.izforge.izpack.api.exception.ContainerException: org.picocontainer.injectors.AbstractInjector$UnsatisfiableDependenciesException: com.izforge.izpack.event.LateShortcutInstallListener has unsatisfied dependency 'interface com.izforge.izpack.api.panels.IShortcutPanelLogic' for constructor 'public com.izforge.izpack.event.LateShortcutInstallListener(com.izforge.izpack.api.panels.IShortcutPanelLogic,com.izforge.izpack.api.data.InstallData)' from org.picocontainer.DefaultPicoContainer@baa466:1<[Immutable]:org.picocontainer.DefaultPicoContainer@18bbc5a:44<|
at com.izforge.izpack.core.container.AbstractContainer.getComponent(AbstractContainer.java:135)
at com.izforge.izpack.core.factory.DefaultObjectFactory.create(DefaultObjectFactory.java:74)
at com.izforge.izpack.core.factory.DefaultObjectFactory.create(DefaultObjectFactory.java:102)
at com.izforge.izpack.installer.container.impl.CustomDataLoader.addInstallerListener(CustomDataLoader.java:132)
at com.izforge.izpack.installer.container.impl.CustomDataLoader.loadCustomData(CustomDataLoader.java:107)
at com.izforge.izpack.installer.container.impl.InstallerContainer.resolveComponents(InstallerContainer.java:152)
at com.izforge.izpack.installer.container.impl.GUIInstallerContainer.resolveComponents(GUIInstallerContainer.java:90)
at com.izforge.izpack.installer.container.impl.InstallerContainer.fillContainer(InstallerContainer.java:87)
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:42)
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:48)
... 14 more



 Comments   
Comment by Daniel Abson [ 29/Jun/12 ]

Created pull request 13 with a solution.

Following refactoring in 5.0, it doesn't really make sense for this to be a separate listener. The interface IShortcutLogic appears to exist solely to service LateShortcutInstallListener, and due to the order of component registration in the PicoContainer it looks like getting an implementation for the ShortcutLogic instance via dependency injection is a non-starter.

So I added an option <lateShortcutInstall/> to the shortcutSpec, and now ShortcutLogic itself registers LateShortcutListener (now an inner class) to create shortcuts after files are installed. This has the added bonus of removing the unnecessary IShortcutLogic interface and simplifying the original requirement: to create shortcuts after the installation, but show the panel before.

Comment by Tim Anderson [ 30/Jun/12 ]

Changes applied thanks.

Comment by Daniel Abson [ 02/Jul/12 ]

Thanks. Could someone with remove rights on the wiki delete this page: http://docs.codehaus.org/display/IZPACK/LateShortcutInstallListener. I was a bit hasty in writing the page before trying it out and now it's gone, so the page should be pulled, too. Ta!





[IZPACK-818] mistake in Polish translation Created: 25/Jun/12  Updated: 25/Jun/12

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

Type: Bug Priority: Major
Reporter: Alexander Maslov 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   

See issue IZPACK-375 comment #1 . The issues is marked as fixed, but nobody changed what was asked in comment #1. Most probably just attached xml was used (without requested modification).
As a result the mistake still exists in all branches.

<str id="InfoPanel.info" txt="Proszę przeczytać poniÅŒsze informację: "/>

need to be

<str id="InfoPanel.info" txt="Proszę przeczytać poniÅŒsze informacje: "/>





[IZPACK-817] Dynamic Variable substitution in a resource on windows not working Created: 22/Jun/12  Updated: 22/Jun/12

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

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

Windows 7


Number of attachments : 0

 Description   

When my installer is run on windows the dynamic variable substitution for a resource is not done. When run in the debugger the dynamic variable is set properly, but the INSTALL_PATH still contains the variable name.

This functionality works on mac and unix platforms.

Here are the relevant snippets from my installer script and resource file:

<variables>
<variable name="vendor" value="MyCompany" />
</variables>

<dynamicvariables>
<variable name="product.short.name" value="My Tool"
condition="izpack.windowsinstall" />
<variable name="product.short.name" value="MyTool"
condition="izpack.linuxinstall|izpack.macinstall" />
</dynamicvariables>

<resources>
<res id="TargetPanel.dir.windows" src="@

{config.dir}/targetdir.windows.conf" />
<res id="TargetPanel.dir.unix" src="@{config.dir}

/targetdir.unix.conf" />
<res id="TargetPanel.dir.mac" src="@

{config.dir}

/targetdir.unix.conf" />
</resources>

targetdir.windows.conf:
$

{APPLICATIONS_DEFAULT_ROOT}

$

{FILE_SEPARATOR}

$

{vendor}

$

{product.short.name}

Debug variable values:
Debug Details of INSTALL_PATH
1. C:\Program Files\MyCompany ${product.short.name}

Debug Details of product.short.name
1. My Tool (new after panel UNKNOWN (com.izforge.izpack.panels.CheckedHelloPanel))

If I specify a plain variable rather than a dynamic variable then the substitution works fine.






[IZPACK-816] Uninstaller fails to initialize GUI Created: 22/Jun/12  Updated: 21/Jul/12  Resolved: 21/Jul/12

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

Type: Bug Priority: Major
Reporter: Bjørnar Ruud Assignee: Tim Anderson
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File crashlog.txt     Text File izpack2887099505283061405.log    
Number of attachments : 2

 Description   

When I use the lastest 5.0.0-beta11-SNAPSHOT of izpack to create an uninstaller for my project it causes the uninstaller to crash at runtime with an PicoCompositionException.



 Comments   
Comment by Daniel Abson [ 19/Jul/12 ]

Attachment crashlog.txt has no useful content. Attached log output izpack2887099505283061405.log from running uninstaller for the IzPack Windows Installation Test, from the project test suite, showing the issue.

Comment by Daniel Abson [ 19/Jul/12 ]

The console uninstaller still works as expected.

Comment by Tim Anderson [ 19/Jul/12 ]

Fix is available at https://github.com/izpack/izpack/pull/31
Updated WindowsInstallationTest to use the GUI uninstaller rather than console uninstaller, to verify the fix.

Comment by Daniel Abson [ 19/Jul/12 ]

Added pull request 32 with a solution.

UPDATE: didn't see pull 31 or previous comment before posting!

Comment by Tim Anderson [ 21/Jul/12 ]

Pull request 31 merged





[IZPACK-815] Sub menus are not created in Gnome3 Created: 14/Jun/12  Updated: 16/Jun/12  Resolved: 16/Jun/12

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

Type: Bug Priority: Minor
Reporter: Dustin Kut Moy Cheung Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File JBoss.png    
Number of attachments : 1

 Description   

Submenus are not displayed in Gnome3.

Reason: http://lists.fedoraproject.org/pipermail/devel/2011-August/155342.html



 Comments   
Comment by Dustin Kut Moy Cheung [ 15/Jun/12 ]

The JBoss platform submenu was created with that fix.

Comment by Dustin Kut Moy Cheung [ 15/Jun/12 ]

https://github.com/izpack/izpack/pull/7

Comment by Dustin Kut Moy Cheung [ 15/Jun/12 ]

https://github.com/izpack/izpack/pull/8





[IZPACK-814] Install size does not update when preselected="yes" but condition evaluates to false Created: 14/Jun/12  Updated: 14/Jun/12

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

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

Attachments: PNG File izpack_1.png     PNG File izpack_2.png    
Number of attachments : 2

 Description   

See pictures. The 64 bit driver is greyed out by checking for 64 bit os and setting condition="is64bit" in the <pack>. However, it seems that the install size is not updated by this (even though it will indeed not try to install the 64 bit driver). When clicking the greyed out checkbox the size will update.






[IZPACK-813] Built-in OS conditions don't work in 5.0 Created: 12/Jun/12  Updated: 16/Jun/12  Resolved: 16/Jun/12

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

Type: Bug Priority: Blocker
Reporter: Daniel Abson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: condition
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

 Description   

The implementation of built-in OS conditions has changed in 5.0, and no longer work. The platform type used on which an installer is compiled is always treated as the 'current platform' when the installer runs.

In 4.3 and earlier, the OS conditions were created as instances of JavaCondition, where the 'current platform' was evaluated at condition execution time, when a certain platform-specific field of the OsVersion class was checked. In 5.0, RulesEngineImpl.initStandardConditions() creates the OS conditions as anonymous inner classes when a RulesEngineImpl object is initialised. The 'current platform' for each instance is set at creation time.

I guess the original idea was that the OS conditions would be created dynamically every time an installer runs, so the 'current platform' would be whatever platform the installer runs on. However, these conditions are currently being serialised at compile time into the installer itself (see RulesEngine.resolveConditions(), only called from CompilerConfig.addConditions(IXMLElement)). This is shown also by the fact that the NotSerializableException occurs at compile-time.

So, built-in OS "ref" conditions in 5.0 are actually using a value for 'current platform' equal to platform used to compile the installer, not the platform on which the installer is running! Moving the creation of the platform conditions into a separate class (as in my original patch) might still be a good idea, for neatness, but it doesn't solve the actual problem! An API change is probably required to implement a proper solution.

Maybe a new interface StaticCondition could be used to mark conditions that are constructed statically every time IzPack runs (rather than serialised at compile-time). RulesEngineImpl would have to call, e.g. StaticCondition.getConditions() and then add all returned conditions to a staticConditionsMap. The resolution of referenced conditions in the ConditionReference API would also have to be changed, to take into account static conditions. Perhaps referenced conditions should be resolved at installation time, not compile time? Static conditions would need some kind of dependency injection to provide specific required objects (e.g. Platform, in the case of the OS conditions). I'll spend some time looking into this, until I hear otherwise.

Alternatively, the 4.3 implementation could be restored (or something similar) to replace the current implementation.



 Comments   
Comment by Tim Anderson [ 13/Jun/12 ]

The 4.3 approach relies on the static methods of OsVersion which make testing difficult (e.g. RulesEngineImplTest.testPlatformConditions()), hence the change to injecting Platform.

Can you attach a minimalist install.xml which reproduces the problem?

Comment by Daniel Abson [ 14/Jun/12 ]

Attached a sample install.xml. Looks like the problem actually only occurs when the OS condition is used as a nested condition, e.g. inside an OrCondition.

This also applies to the issue reported in IZPACK-810. That means you'll have to build IzPack either with the modifications from my IZPACK-810 branch in GitHub, or by adding the transient keyword to the

private final ConditionContainer container;

declaration in RulesEngineImpl.

I ran the output install.jar on Windows XP (should work) and on CentOS Linux (shouldn't work) and the installer loaded and ran on both platforms.

Comment by Tim Anderson [ 16/Jun/12 ]

The fix is available at https://github.com/izpack/izpack/pull/6

Comment by Julien Ponge [ 16/Jun/12 ]

Pull request merged.





[IZPACK-812] Incorrect display of 'product already exists' message in CheckedHelloPanel Created: 11/Jun/12  Updated: 12/Jun/12  Resolved: 12/Jun/12

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

Type: Bug Priority: Minor
Reporter: Daniel Abson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: i18n
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Commit e922515ae37dd2ea977524d6610c5040fa1a2418 appears to have introduced a typo at line 100 of CheckedHelloPanel:

        String noLuck = getString("CheckedHelloPanel.productAlreadyExist0") + path + " . "
                + getString("CheckedHelloPanel.prouctAlreadyExist1");

The i18n ID CheckedHelloPanel.productAlreadyExist1 is now missing a the 'd' in 'product', so the bad ID instead of the i18n text is now being displayed in a message box when a repeat installation is attempted.

The corresponding message in the console version of the class is spelled correctly.



 Comments   
Comment by Daniel Abson [ 12/Jun/12 ]

Sent pull request through GitHub.

Comment by Tim Anderson [ 12/Jun/12 ]

Thanks for the patch.

Merge details: https://github.com/izpack/izpack/commit/c98dde2f3fc6cc7d25d0086eebaf2f957ee7ff05





[IZPACK-811] TRACE mode throws NullPointerException when language selection dialog isn't displayed Created: 11/Jun/12  Updated: 12/Jun/12  Resolved: 12/Jun/12

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

Type: Bug Priority: Major
Reporter: Daniel Abson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: debugging
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File IZPACK-811.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Following recent refactoring of Panel, the class Debugger throws NPE at in this method, where language selection dialog isn't first displayed.

    private void debugConditions(Panel nextpanelmetadata, com.izforge.izpack.api.data.Panel lastpanelmetadata)
    {
        conditionhistoryrenderer.clearState();
        updateChangedConditions(
                "changed after panel switch from " + lastpanelmetadata.getPanelid() + " to " + nextpanelmetadata.getPanelid());
    }

When switching to HelloPanel, the reference lastpanelmetadata has the value null.



 Comments   
Comment by Daniel Abson [ 11/Jun/12 ]

Attached patch. Inline null-check introduced to method call in Debugger.

Comment by Julien Ponge [ 11/Jun/12 ]

Could you make a pull request at https://github.com/izpack/izpack ?

Comment by Daniel Abson [ 11/Jun/12 ]

I'll have to see what I can do - see comment on IZPACK-810.

Comment by Daniel Abson [ 12/Jun/12 ]

Sent pull request through GitHub.

Comment by Tim Anderson [ 12/Jun/12 ]

Patch applied thanks.

https://github.com/izpack/izpack/pull/3





[IZPACK-810] Writing installer fails during serializing OS conditions - NotSerializableException: com.izforge.izpack.core.rules.ConditionContainer Created: 11/Jun/12  Updated: 14/Jun/12  Resolved: 12/Jun/12

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

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

Attachments: Text File IZPACK-810.patch    
Testcase included: yes
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Writing an installer fails when one of the built-in OS conditions is used.

Stacktrace:

-> Fatal error :
Error serializing instance of java.util.HashMap as entry "rules"
java.io.IOException: Error serializing instance of java.util.HashMap as entry "rules"
at com.izforge.izpack.compiler.packager.impl.PackagerBase.writeInstallerObject(PackagerBase.java:517)
at com.izforge.izpack.compiler.packager.impl.PackagerBase.writeInstaller(PackagerBase.java:444)
at com.izforge.izpack.compiler.packager.impl.PackagerBase.createInstaller(PackagerBase.java:405)
at com.izforge.izpack.compiler.Compiler.createInstaller(Compiler.java:150)
at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:308)
at com.izforge.izpack.compiler.bootstrap.CompilerLauncher.main(CompilerLauncher.java:33)
Caused by: java.io.NotSerializableException: com.izforge.izpack.core.rules.ConditionContainer
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at java.util.ArrayList.writeObject(ArrayList.java:570)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at java.util.ArrayList.writeObject(ArrayList.java:570)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at java.util.HashMap.writeObject(HashMap.java:1001)
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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at com.izforge.izpack.compiler.packager.impl.PackagerBase.writeInstallerObject(PackagerBase.java:513)
... 5 more



 Comments   
Comment by Daniel Abson [ 11/Jun/12 ]

I think this is related to IZPACK-757. The fix for that JIRA included making the reference to RulesEngine in a number of Condition implementations transient, so that NotSerializableException didn't occur.

The platform conditions, however, are created as anonymous inner classes of RulesEngineImpl - as anonymous classes they have implicit references to RulesEngineImpl.this, so the compiler will still try to serialise RuleEngineImpl for OS/platform conditions. Any non-serializable classes referenced in member fields of RulesEngineImpl (in this case, ConditionContainer) will still cause this exception, despite IZPACK-757, when an OS condition is used in an installer.

Comment by Daniel Abson [ 11/Jun/12 ]

Attached a patch against the current master, IZPACK-810.patch, to extract the creation of OS conditions into a separate factory class, to avoid attempts by the compiler to serialize instances of RulesEngineImpl. Existing test case RulesEngineImplTest.testPlatformConditions() still passes, and installers using OS conditions created with this build compile successfully.

Comment by Julien Ponge [ 11/Jun/12 ]

We are moving to a policy of pull requests at https://github.com/izpack/izpack over patches in JIRA issues, so it would be great if you could post it here

Comment by Daniel Abson [ 11/Jun/12 ]

I'll see what I can do. I'm behind a corporate firewall here - getting updates from github to my local repo is pretty convoluted! So, github wouldn't be able to pull anything directly from my repo.

Comment by Julien Ponge [ 11/Jun/12 ]

You can push over HTTP(S) it seems. Hope it helps!

Comment by Daniel Abson [ 12/Jun/12 ]

Thanks for the tip, Julien! I've got it all set up now. As it is, I want to do a bit more work on this patch - not sure that it's working properly. I'll make sure to submit future 'patches' as pull requests.

Comment by Daniel Abson [ 12/Jun/12 ]

I've realised that my original solution (IZPACK-810.patch, attached, and also on my IZPACK-810 branch in GitHub) is addressing the wrong problem. Fixing the serialisation of the built-in OS conditions isn't the issue - the point is, they shouldn't be serialised at all!

EDIT:
Raised as a new issue, IZPACK-813.

Comment by Daniel Abson [ 12/Jun/12 ]

Perhaps this issue should be closed in favour of IZPACK-813? This issue describes only part of a problem.

Comment by Daniel Abson [ 14/Jun/12 ]

Only applies when an OS condition is used as a nested condition (e.g. inside an OrCondition).





[IZPACK-809] OS-restriction for fileset on OSX Lion won't work Created: 10/Jun/12  Updated: 26/Jul/12

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

Type: Bug Priority: Major
Reporter: Thilo Schwarz 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've got file-sets for different OS's. For each file-set an OS-restriction is used.

For Mac OSX I've tested with
<os family="osx"/>
<os family="mac"/> and
<os name="Mac OS X"/>

All failed!

Is this fixed IZPACK-806?



 Comments   
Comment by Daniel Abson [ 12/Jun/12 ]

This is failing because the built-in OS conditions are currently broken in the 5.0 releases. See IZPACK-813.

Comment by Daniel Abson [ 14/Jun/12 ]

Might be you can ignore my previous comment - looks like IZPACK-810/IZPACK-813 only apply to the OS conditions when used as a nested condition (e.g. inside an OrCondition).

Comment by Tim Anderson [ 26/Jul/12 ]

If you build the latest sources, there are a few more debug messages that may help diagnose what's going on.
Run the installer with debug enabled:

java -DDEBUG=true -jar yourinstaller.jar

This will display the detected platform, e.g.:

INFO: Detected platform: windows,version=6.1,arch=x64,symbolicName=WINDOWS_7,javaVersion=1.6.0_30

The Unpacker will also display if its unpacking or skipping files e.g.:

FINE: Unpack $INSTALL_PATH/utils/wrappers/izpack2exe
FINE: Skip $INSTALL_PATH/foo.sh

With the latest master, you should also be able to use the platform names defined by the Platform.Name enum. Current supported names include:

  • aix
  • debian_linux
  • fedora_linux
  • freebsd
  • hp_ux
  • linux
  • mac
  • mac_osx
  • mandrake_linux
  • mandriva_linux
  • os_2
  • red_hat_linux
  • sunos
  • suse_linux
  • unix
  • ubuntu_linux
  • windows

e.g.:

<os family="mac"/>
<os family="mac_osx"/>
<os name="mac"/>
<os name="mac_osx">




[IZPACK-808] Regression in shortcut support for Windows Created: 07/Jun/12  Updated: 16/Oct/14

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

Type: Bug Priority: Major
Reporter: Vincent Massol Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows7


Number of attachments : 0

 Description   

I've been using IzPack 4.2.1 since now and I've just upgraded to 4.3.5 and I was surprised to find an important regression: my shortcut don't install properly anymore and some install wrongly.

Precisely, I have the followng shortcut spec for windows:

<shortcuts>
   <skipIfNotSupported/>
   <programGroup defaultName="XWiki Enterprise" location="applications"/>
   <shortcut name="Start XWiki Enterprise"
       target="$INSTALL_PATH\start_xwiki.bat"
       iconFile="$INSTALL_PATH\xe.ico"
       iconIndex="0"
       workingDirectory="$INSTALL_PATH"
       description="Start XWiki"
       initialState="normal"
       programGroup="yes"
       desktop="yes"
       startMenu="no"/>
  <shortcut name="Stop XWiki Enterprise"
      target="$INSTALL_PATH\stop_xwiki.bat"
      iconFile="$INSTALL_PATH\xe.ico"
      iconIndex="0"
      workingDirectory="$INSTALL_PATH"
      description="Stop XWiki"
      initialState="normal"
      programGroup="yes"
      desktop="yes"
      startMenu="no"/>
  <shortcut name="""
      target="http://localhost:8080/xwiki/bin/view/Main/"
      iconFile="$INSTALL_PATH\xe.ico"
      iconIndex="0"
      workingDirectory=""
      description="Go to the local XWiki installation home page"
      initialState="normal"
      programGroup="yes"
      desktop="no"
      startMenu="no"/>
  <shortcut name="Documentation"
      target="http://xwiki.org"
      iconFile="$INSTALL_PATH\xe.ico"
      iconIndex="0"
      workingDirectory=""
      description="XWiki Documentation"
      initialState="normal"
      programGroup="yes"
      desktop="no"
      startMenu="no"/>
  <shortcut name="Uninstall"
      target="javaw"
      iconFile="$INSTALL_PATH\xe.ico"
      iconIndex="0"
      commandLine="-jar &quot;$INSTALL_PATH\Uninstaller\uninstaller.jar&quot;"
      description="Uninstall XWiki"
      initialState="normal"
      programGroup="yes"
      desktop="no"
      startMenu="no"/>
</shortcuts>

Only 3 shortcuts install in 4.3.5:

  • "Start XWiki Enterprise"
  • "Stop XWiki Enterprise"
  • "Uninstall"

So 3 are not installing at all:

  • "My Wiki"
  • "Documentation"

And the "Uninstall" shortcut is wrong; it generates a target of:

"C:\Program Files\XWiki Enterprise\stop_xwiki.bat" -jar "C:\Program Files\XWiki Enterprise\Uninstaller\uninstaller.jar"

instead of

javaw -jar "C:\Program Files\XWiki Enterprise\Uninstaller\uninstaller.jar"

Again this was working just fine in 4.2.1. I don't know when this got broken between 4.2.1 and 4.3.5.

It's a big issue for me since I need to upgrade because the condition "izpack.windowsinstall.7" doesn't work in 4.2.1... Would be great to know when it was first introduced btw so that I could test that version and hope that shortcut work in it...



 Comments   
Comment by Vincent Massol [ 08/Jun/12 ]

FYI It works with 4.3.2 but fails with 4.3.4 and 4.3.5.

Comment by Doug Palmer [ 22/Sep/12 ]

I've had the same problem. The target for all shortcuts seems to be set to the first target in the list of shortcuts. Returning to 4.3.2 fixes the problem.

Comment by Mulcamd [ 23/Sep/12 ]

I have and reporter the same problem: http://jira.codehaus.org/browse/IZPACK-833
For me especially the shortcuts to the web are broken.

By the way, going back to 4.3.2 is not working for me because in that version there is a problem with updating files that already exists!

Comment by Pascale ANDRIANATREHANA [ 16/Oct/14 ]

Hi,

I use 4.3.5 version of IzPack.

About this : "The target for all shortcuts seems to be set to the first target in the list of shortcuts. Returning to 4.3.2 fixes the problem".

I seem to have the same problem.
I have declared two shortcuts in shortcutSpec.xml file : the first one to launch the application, the second one for uninstaller.

It works fine on Linux and Windows XP.

But on Windows 7, uninstaller launches the application. as if it uses the first target in my list of shortcuts.

I have downgraded IzPack version to 4.3.2, and it works almost fine on windows 7, except it asks for administrator rights, which should not be necessary (and is not acceptable in my case). But maybe this was not handled in previous versions of IzPack ?





[IZPACK-807] Replace hard-coded uninstaller path in RegistryInstallerListener Created: 06/Jun/12  Updated: 13/Jun/12  Resolved: 13/Jun/12

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

Type: Bug Priority: Major
Reporter: Daniel Abson Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: uninstaller, windows
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File IZPACK-807.patch    
Number of attachments : 1

 Description   

The method RegistryInstallerListener.registerUninstallKey() always writes the UninstallString value in the Windows registry uninstall key using the IzPack default value ($INSTALL_PATH\uninstaller\uninstaller.jar). Alternative values defined using the install.xml <uninstaller> tag are ignored. Therefore, where alternative values are defined, the uninstall entry in the Windows Add/Remove Programs (or Programs and Features under NT6) won't work.



 Comments   
Comment by Daniel Abson [ 06/Jun/12 ]

I'm happy to write a patch for this.

Comment by Julien Ponge [ 07/Jun/12 ]

... and I guess we would be quite happy to review it

Comment by Daniel Abson [ 08/Jun/12 ]

Attached a patch against the current master. Includes a new test case in WindowsConsoleInstallationTest.

Comment by Daniel Abson [ 12/Jun/12 ]

Sent pull request through GitHub.

Comment by Julien Ponge [ 13/Jun/12 ]

Merged pull request.





[IZPACK-806] Pre-set condition 'izpac.macinstall' is wrong for OSX Lion Created: 19/May/12  Updated: 20/May/12  Resolved: 20/May/12

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

Type: Bug Priority: Major
Reporter: Thilo Schwarz Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Debugging my installer with JVM argument -DTRACE=true I've found out that the pre-set condition 'izpack.macinstall' is 'false' if it runs on OSX Lion.



 Comments   
Comment by Thilo Schwarz [ 19/May/12 ]

Additional hint!
I've written my own condition and it works as expected:

<conditions>
<condition type="java" id="installonosx">
<java>
<class>com.izforge.izpack.util.OsVersion</class>
<field>IS_OSX</field>
</java>
<returnvalue type="boolean">true</returnvalue>
</condition>
</conditions>

Comment by Tim Anderson [ 20/May/12 ]

There is currently no predefined condition for OSX. The izpack.macinstall condition applies to Macs pre OSX.

Comment by Thilo Schwarz [ 20/May/12 ]

In the documentation you can find: "True if the current OS is Mac OS X"
That should be fixed.

Btw: I think it makes more sense to take OSX as predefined condition. Pre-OSX-Macs are really rare.

Comment by Tim Anderson [ 20/May/12 ]

On closer inspection, izpack.macinstall is supposed to evaluate true for all Macs, not just pre-OSX. I've fixed this, and added a new condition, izpack.macinstall.osx, to detect OSX only.





[IZPACK-805] executable script is always starting twice Created: 14/May/12  Updated: 18/May/12  Resolved: 18/May/12

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

Type: Bug Priority: Major
Reporter: David Leuenberger Assignee: Tim Anderson
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 12.04 Desktop 64 Bit
Kubuntu 12.04 Desktop 64 Bit


Attachments: File Installer.tar.bz2    
Number of attachments : 1

 Description   

If I add a script to execute with the tag executable, then the scripts is executed twice.
I have only a linux system, so I could not test on windows.
I attach a very simple demo.



 Comments   
Comment by David Leuenberger [ 14/May/12 ]

Comment to the environment:
openjdk-6-jdk, 6b24-1.11.1-4ubuntu2

Comment by David Leuenberger [ 14/May/12 ]

attach new version

Comment by Tim Anderson [ 18/May/12 ]

This is a duplicate of IZPACK-741.
Try a 5.0.0-beta11-SNAPSHOT or checkout and build the trunk.





[IZPACK-804] izpack2exe.exe missing from distribution Created: 13/May/12  Updated: 18/Jul/14

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

Type: Wish Priority: Major
Reporter: Timothy Vogel Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Number of attachments : 0

 Description   

The documentation states that the izpack2exe executable ships with the distribution so that I don't have to download and install Python. The utils\wrappers\izpack2exe has the .py but not the executable.

Is the executable still available?



 Comments   
Comment by Julien Ponge [ 24/May/12 ]

The executable is generated using py2exe, which requires being on Windows I think (I need to check). Putting it under version control is not an option, so let's investigate wether it can be automated or not outside of Windows.

Comment by Laurent TOURREAU [ 18/Jul/14 ]

Hi I can't generate the izpack2exe.exe when running py2exe (i use python 2.6 32 bits).
The build failed to find app.ico:

c:\Python26>python "c:\Program Files (x86)\IzPack\utils\wrappers\izpack2exe\setup.py" install
c:\Python26\lib\site-packages\py2exe\build_exe.py:16: DeprecationWarning: the sets module is deprecated
  import sets
running py2exe
creating c:\Python26\build
creating c:\Python26\build\bdist.win32
creating c:\Python26\build\bdist.win32\winexe
creating c:\Python26\build\bdist.win32\winexe\collect-2.6
creating c:\Python26\build\bdist.win32\winexe\bundle-2.6
creating c:\Python26\build\bdist.win32\winexe\temp
creating c:\Python26\dist
error: Resource filename 'app.ico' does not exist
Comment by Laurent TOURREAU [ 18/Jul/14 ]

Finally i found the solution; I run py2exe from izpack2exe directory instead:

C:\Program Files (x86)\IzPack\utils\wrappers\izpack2exe>C:\Python26\python.exe setup.py install

It's work fine.





[IZPACK-803] While my war is deploying using installer(izpack) in jboss is not deployed .But the same war is deploying manually successfully in jbossWhy installer behvaes like this Created: 03/May/12  Updated: 04/May/12  Resolved: 03/May/12

Status: Closed
Project: IzPack
Component/s: Build
Affects Version/s: 4.3.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nagaraju b Assignee: Julien Ponge
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File server.log    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

While my war is deploying using installer(izpack) in jboss is not deployed .But the same war is deploying manually successfully in jboss .Why it is not deploying by using installer .Can any one help me please As soon as possible

Thanks in advance.



 Comments   
Comment by Julien Ponge [ 03/May/12 ]

How can anyone understand anything from this issue is a good question :-D

Comment by Tim Anderson [ 04/May/12 ]

This is not a support forum. You should be posting queries to the izpack user mailing list. See http://xircles.codehaus.org/projects/izpack/lists for details.

That said, check your stack traces. Your problem could be:

Caused by: org.springframework.beans.PropertyBatchUpdateException; nested PropertyAccessExceptions (1) are:
PropertyAccessException 1: org.springframework.beans.MethodInvocationException: Property 'driverClass' threw exception; nested exception is java.beans.PropertyVetoException: Could not locate driver class with name 'com.microsoft.sqlserver.jdbc.SQLServerDriver'.
  at org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java)
  at org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java)
  ... 206 mor




[IZPACK-802] <run-privileged condition="izpack.windowsinstall.vista|izpack.windowsinstall.7"/> affects RedHat too Created: 30/Apr/12  Updated: 15/Jul/12

Status: Open
Project: IzPack
Component/s: Native launcher
Affects Version/s: 4.3.4
Fix Version/s: 4.3.6

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

RedHat 26.18 64 bits


Number of attachments : 0

 Description   

I added the option <run-privileged condition="izpack.windowsinstall.vista|izpack.windowsinstall.7"/> to my installer.xml file.

It did fix the problem I had with Windows Vista and Windows 7 where installation couldn't be done in C:\Program Files\ but... it affected RedHat too. On RedHat, it prompts a message:

[sudo] password for myaccount

After entering the password, it crashes.

If I remove the "run-privileged" option, it works fine on RedHat.

The option run-privileged clearly indicates that it should affect only Windows Vista and Windows 7, why does it affect RedHat too ? This issue prevents me from releasing an installer that installs in C:\Program Files for Windows.



 Comments   
Comment by Dustin Kut Moy Cheung [ 21/Jun/12 ]

Hi,

What RedHat version is that? Is it RHEL4?

I can't reproduce it on Fedora 17 and on RHEL6.

Comment by Thierry D [ 15/Jul/12 ]

bash-3.1# uname -a
Linux localhost.localdomain 2.6.18-274.12.1.el5 #1 SMP Tue Nov 8 21:37:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux





[IZPACK-801] NPE in RuleInputField Created: 27/Apr/12  Updated: 29/Apr/12  Resolved: 29/Apr/12

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

Type: Bug Priority: Critical
Reporter: Steven Scott Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

RuleInputField's constructor should create the VariableSubstitutor before calling setFields() - that method uses the null substitutor and throws an NPE



 Comments   
Comment by Tim Anderson [ 29/Apr/12 ]

Fix will be available in 5.0-beta-11





[IZPACK-800] os attribute for packs backwards-compatibility broken Created: 27/Apr/12  Updated: 29/Apr/12  Resolved: 29/Apr/12

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

Type: Bug Priority: Major
Reporter: Steven Scott Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

OsConstraintHelper.java line 85, family is passed as the first parameter to OsModel instead of the second



 Comments   
Comment by Steven Scott [ 27/Apr/12 ]

Sorry, line 104

Comment by Tim Anderson [ 29/Apr/12 ]

Fix will be available in 5.0-beta-11





[IZPACK-799] PackSelectionCondition uses the wrong pack attribute Created: 26/Apr/12  Updated: 07/Aug/12  Resolved: 07/Aug/12

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

Type: Bug Priority: Minor
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The PackSelectionCondition class, and its use in RulesEngineImpl.initStandardConditions() use the Pack.id attribute to identify packs.
This is the wrong attribute. Pack.id is the localisation identifier, and is optional. Its supposed to be used to derive a pack name for the current locale.
PackSelectionCondition should be using Pack.name instead.

The reason it works currently is due to some code in Packager that assigns Pack.name to Pack.id if the id is null.



 Comments   
Comment by Tim Anderson [ 04/Aug/12 ]

There's a few places in the code which make the same mistake:

  • RulesEngineImpl.initStandardConditions()
  • PacksModel
  • PacksPanelAutomationHelper
  • PacksPanelBase
  • TreePacksPanel
  • TreePacksPanelConsole
Comment by Tim Anderson [ 04/Aug/12 ]

Pull request is at: https://github.com/izpack/izpack/pull/46

The PackSelectionCondition class has been changed to require a "name" element instead of a "packid" element e.g.:

   <condition type="packselection" id="packselection1">
        <name>Core</name>
    </condition>
 

to force existing users to update their conditions.





[IZPACK-798] Cannot modify INSTALL_PATH before TargetPanel gets called Created: 24/Apr/12  Updated: 29/Jul/12  Resolved: 29/Jul/12

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

Type: Bug Priority: Blocker
Reporter: Fabien Nisol Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day
Environment:

Linux, Windows,...


Attachments: Text File patch.txt    
Patch Submitted:
Yes
Source ID: TargetPanelConsoleHelper.java and TargetPanel.java
Number of attachments : 1

 Description   

TargetPanel was modified in order to take variables out of the install definition (Target.dir.os)
A nice feature would be to allow modifying the target path within user panels called before the target panel. This is impossible right now

After investigation, I noticed that the code loading the variables out of the install.xml file is called through the constructor.

Instead, I propose to call that code through the panelActivated() method which was created for this purpose

I issued a patch with this issue. I tested the patch which works

  • created a user panel that let the user select some kind of "target environment" ie development or production
  • that panel is the first to be called
  • modified installer.xml so the TargetPanel.dir variable is using the variable defined in the first user panel
  • tested the installer, the default install directory changes as expected


 Comments   
Comment by Fabien Nisol [ 24/Apr/12 ]

diff -r -w -u jponge-izpack-4.3.5 jponge-izpack-4.3.5-hq > patch.txt

Comment by Julien Ponge [ 26/Apr/12 ]

Fixed, thanks.

Comment by Tim Anderson [ 11/Jul/12 ]

Change needs to be applied to 5.0

Comment by Tim Anderson [ 24/Jul/12 ]

Pull request is: https://github.com/izpack/izpack/pull/37





[IZPACK-797] Implement ProcessPanelConsoleHelper for console support Created: 17/Apr/12  Updated: 19/Apr/12  Resolved: 17/Apr/12

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

Type: New Feature Priority: Major
Reporter: Martin Michna Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 6 hours
Time Spent: Not Specified
Original Estimate: 6 hours

Number of attachments : 0

 Comments   
Comment by Martin Michna [ 17/Apr/12 ]

Fixed and commited into the https://mmichna@github.com/mmichna/izpack.git

Comment by Julien Ponge [ 17/Apr/12 ]

You should open a pull request on jponge/izpack if you want me to have a look and merge.

Comment by Martin Michna [ 19/Apr/12 ]

I have open pull request but i must format my code by IzPack formatter





[IZPACK-796] Make PanelAction and Panel configuration <param> tags consistent with equivalent in installer <guiprefs> and UserInputPanel <validator> Created: 17/Apr/12  Updated: 18/Apr/12  Resolved: 18/Apr/12

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

Type: Improvement Priority: Minor
Reporter: Daniel Abson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: panel-action, panel-configuration, param
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File param-name_value-change-fixed.patch     Text File param-name_value-change.patch    
Testcase included: yes
Patch Submitted:
Yes
Number of attachments : 2

 Description   

Currently, the optional (and undocumented) <param> tag for a panel <action> uses nested elements to define a key and a value. The similarly undocumented <configuration> tag for a panel also takes a <param> tag in this form. These should be changed to use the name/value attributes common to the other, documented <param> tags in the installation descriptor and UserInputPanel descriptor, and the whole lot should be documented. The changes should also be documented in the Upgrading from Previous Versions wiki page.

There are no PanelAction implementations in the IzPack distribution, nor any panels that use the <configuration> tag. These changes, then, affect only third-party extensions for IzPack. This change for the PanelAction <param> was previously mooted in IZPACK-791.



 Comments   
Comment by Daniel Abson [ 17/Apr/12 ]

The patch also removes a redundant null-check in the CompilerConfig code that parses the panel <configuration> tag, and add integration tests for both changes.

Comment by Daniel Abson [ 17/Apr/12 ]

I'm happy to update the new documentation with this information, by the way. I guess that would be best done after the release of the next beta?

Comment by Tim Anderson [ 17/Apr/12 ]

You might as well add it now, with a note that it isn't released yet. That way its less likely to be forgotten.

There's a few minor issues:

  • CompilerConfigMockedTest.shouldAddPanelConfiguration() is incomplete
  • panelactions.xml has the key/value configuration instead of name/value
Comment by Daniel Abson [ 17/Apr/12 ]

New patch fixes the integration tests. I've updated the documentation as well, with warning boxes that can be removed after 5.0.0-beta11 is released.

Comment by Tim Anderson [ 18/Apr/12 ]

Changes applied thanks.





[IZPACK-795] Displays plain text instead of XML/THML Created: 14/Apr/12  Updated: 14/Apr/12

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

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

GNU/Debian Linux x86_64


Attachments: HTML File info.html     XML File installer.xml     PNG File izpack_problem.png    
Number of attachments : 3

 Description   

Even if I added type="xml" to resource specification, the installer presents just a plain text file. Attached are the installer.xml, the whole info.html -file (with an XML header) and a screenshot.






[IZPACK-794] Pressing "Generating automatic installation script" throws java.lang.NoClassDefFoundError: com/izforge/izpack/panels/imgpacks/ImgPacksPanelAutomationHelper Created: 12/Apr/12  Updated: 07/Jul/14  Resolved: 07/Jul/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: 1
Labels: 5.0.0-rc1, 5.0.0-rc3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Number of attachments : 0

 Description   

On pressing the button for saving the installation record at the end of a successful installation I get:

Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com/izforge/izpack/panels/imgpacks/ImgPacksPanelAutomationHelper
        at com.izforge.izpack.panels.packs.PacksPanelBase.makeXMLData(PacksPanelBase.java:322)
        at com.izforge.izpack.installer.base.InstallerFrame.writeXMLTree(InstallerFrame.java:868)
        at com.izforge.izpack.panels.finish.FinishPanel.actionPerformed(FinishPanel.java:173)
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
        at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
        at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
        at java.awt.Component.processMouseEvent(Component.java:6290)
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
        at java.awt.Component.processEvent(Component.java:6055)
        at java.awt.Container.processEvent(Container.java:2039)
        at java.awt.Component.dispatchEventImpl(Component.java:4653)
        at java.awt.Container.dispatchEventImpl(Container.java:2097)
        at java.awt.Component.dispatchEvent(Component.java:4481)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4575)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4236)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4166)
        at java.awt.Container.dispatchEventImpl(Container.java:2083)
        at java.awt.Window.dispatchEventImpl(Window.java:2482)
        at java.awt.Component.dispatchEvent(Component.java:4481)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:648)
        at java.awt.EventQueue.access$000(EventQueue.java:84)
        at java.awt.EventQueue$1.run(EventQueue.java:607)
        at java.awt.EventQueue$1.run(EventQueue.java:605)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
        at java.awt.EventQueue$2.run(EventQueue.java:621)
        at java.awt.EventQueue$2.run(EventQueue.java:619)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:618)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: java.lang.ClassNotFoundException: com.izforge.izpack.panels.imgpacks.ImgPacksPanelAutomationHelper
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
        ... 40 more


 Comments   
Comment by Francois Le Fevre [ 18/Oct/12 ]

I do have exactly the same problem with izpack 5.0.0-beta10
when looking into the jar, I have noticed that there is no com/izforge/izpack/panels/imgpacks into the distribution?

Comment by Rene Krell [ 18/Jan/13 ]

This one should fix it, please review: https://github.com/izpack/izpack/pull/81

Comment by Rene Krell [ 22/Jan/13 ]

Tested in 5.0.0-rc1-SNAPSHOT

Comment by Rene Krell [ 07/Jul/14 ]

Another stacktrace of that kind:

Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com/izforge/izpack/panels/imgpacks/ImgPacksPanelAutomationHelper
        at com.izforge.izpack.panels.treepacks.TreePacksPanel.makeXMLData(TreePacksPanel.java:310)
        at com.izforge.izpack.installer.gui.InstallerFrame.writeXMLTree(InstallerFrame.java:743)
        at com.izforge.izpack.panels.finish.FinishPanel.actionPerformed(FinishPanel.java:172)
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
        at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252)
        at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289)
        at java.awt.Component.processMouseEvent(Component.java:6505)
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3320)
        at java.awt.Component.processEvent(Component.java:6270)
        at java.awt.Container.processEvent(Container.java:2229)
        at java.awt.Component.dispatchEventImpl(Component.java:4861)
        at java.awt.Container.dispatchEventImpl(Container.java:2287)
        at java.awt.Component.dispatchEvent(Component.java:4687)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
        at java.awt.Container.dispatchEventImpl(Container.java:2273)
        at java.awt.Window.dispatchEventImpl(Window.java:2719)
        at java.awt.Component.dispatchEvent(Component.java:4687)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735)
        at java.awt.EventQueue.access$200(EventQueue.java:103)
        at java.awt.EventQueue$3.run(EventQueue.java:694)
        at java.awt.EventQueue$3.run(EventQueue.java:692)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
        at java.awt.EventQueue$4.run(EventQueue.java:708)
        at java.awt.EventQueue$4.run(EventQueue.java:706)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
Caused by: java.lang.ClassNotFoundException: com.izforge.izpack.panels.imgpacks.ImgPacksPanelAutomationHelper
        at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 40 more

Reported by mail (thanks to TRAN Antoine) against 5.0.0-rc2 on Linux Redhat 6.5.

Comment by Rene Krell [ 07/Jul/14 ]

Sent and merged pull request: https://github.com/izpack/izpack/pull/224.





[IZPACK-793] Missing i18n string "installer.help.close" Created: 11/Apr/12  Updated: 18/Oct/13  Resolved: 12/Sep/13

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

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

Patch Submitted:
Yes
Number of attachments : 0

 Description   

The HelpWindow dialog has a close button, but the i18n string installer.help.close is missing from the langpack files. A temporary workaround is to add the required text (e.g. "Close") to the CustomLangPack file.



 Comments   
Comment by Rene Krell [ 11/Apr/12 ]

Just BTW, the CustomLangPack works for you in 5.0, really? Actually I got a problem with custom translations in 5.0.

Comment by Daniel Abson [ 12/Apr/12 ]

It works for me using the latest, clean build from git master, with this tag in the install.xml:

<res id="CustomLangPack.xml_eng" src="lang/CustomLangPack_eng.xml"/>

I also tried overriding one of the default strings (installer.madewith), and that worked too.

Comment by Rene Krell [ 20/Aug/13 ]

Is this solved for you now in the latest 5.0.0-rc1-SNAPSHOT?

Comment by Daniel Abson [ 12/Sep/13 ]

No, still doesn't work without my custom langpack workaround. The installer.help.close string still doesn't seem to be defined in any langpack file in izpack-core. I've updated the English langpack, and found translations for other langpacks that already have the installer.help string. See pull request.

Comment by Rene Krell [ 12/Sep/13 ]

Solved by Daniel at https://github.com/izpack/izpack/pull/136.
Thank you.





[IZPACK-792] Installer fails to unpack internal pack200 jars Created: 10/Apr/12  Updated: 11/Apr/12  Resolved: 11/Apr/12

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

Type: Bug Priority: Critical
Reporter: Daniel Abson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: pack200
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File pack200-installer-fix.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Jars compressed with pack200 and colocated in the installer with the regular pack files at /resources/packs/pack200-<index> cannot be found by Unpacker during installation. The installer bombs out, and leaves a zero-length file in the destination. The following code is responsible for the failure to find the pack200 resource:

com.izforge.izpack.installer.unpacker.Unpacker, line 311
InputStream pack200Input = resourceManager.getInputStream("/packs/pack200-" + key);

This line doesn't seem to have been updated since 4.3.x, and still looks for the pack200 file at the absolute path /packs/ (where the correct path is /resources/packs/. The only change required is to remove the leading /, as ResourceManager automatically prepends /resources/ to all relative paths passed to the getInputStream method. A patch is hardly necessary, but attached anyway. An installer built with the patched class succeeds.



 Comments   
Comment by Tim Anderson [ 11/Apr/12 ]

Change applied thanks.

I've added a new integration test com.izforge.izpack.integration.packaging.PackagingTest to test this in future.





[IZPACK-791] XStream processing breaks support for PanelAction <param> tag Created: 04/Apr/12  Updated: 17/Apr/12  Resolved: 13/Apr/12

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

Type: Bug Priority: Major
Reporter: Daniel Abson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: action, breaking, exception, param, xstream
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Git master branch (5.0.x).


Attachments: Text File panel-action-param.patch     Text File panel-action-param-stacktrace.txt     Text File remove-xstream-provider.patch     Text File remove-xstream-provider-plus-deps.patch    
Testcase included: yes
Patch Submitted:
Yes
Number of attachments : 4

 Description   

IzPack 4.3.x supported a <param> tag in PanelAction specs (this was not documented). For example:

<action stage="postvalidate" classname="RegistryWriterAction">
    <param>
        <key>ConfigurationFile</key>
        <value>RegistryReaderConfiguration.xml</value>
    </param>

When attempting to compile an installation with a <param> tag in 5.0.x, XStream reports the following error (see attachment for full stack trace):

     [java]    param : param : param : param
     [java] ---- Debugging information ----
     [java] message             : param : param
     [java] cause-exception     : com.thoughtworks.xstream.mapper.CannotResolveClassException
     [java] cause-message       : param : param
     [java] class               : com.izforge.izpack.api.data.binding.IzpackProjectInstaller
     [java] required-type       : com.izforge.izpack.api.data.binding.Action
     [java] path                : /installation/panels/panel[4]/actions/action/param
     [java] line number         : 51
     [java] -------------------------------

The data bindings classes in izpack-api should be updated to allow the <param> tag.

Additionally, I recommend changing the PanelAction <param> tag to make it consistent with the <param> tag in <guiprefs> and <validator>. Instead of specifying <param><key>foo</key><value>bar</value></param>, you should use <param name="foo" value="bar"/>.

The attached patch against the git master branch adds data binding support for the <param> tag, and support for the attributes name and value. JUnit tests IzpackProjectProviderTest and PanelActionTest are also updated. This patch allows both forms of the <param> tag. Comments in the following source files identify the sections of code/markup that implement either --- ELEMENT KEY/VALUE -- or -- ATTRIBUTE KEY/VALUE ---.

  • izpack-compiler/src/main/java/com/izforge/izpack/compiler/CompilerConfig.java
  • izack-compiler/src/main/java/com/izforge/izpack/compiler/container/provider/IzPackProjectProvider.java
  • izack-compiler/src/test/java/com/izforge/izpack/compiler/container/provider/IzPackProjectProviderTest.java
  • izpack-compiler/src/test/resources/bindingTest.xml
  • izpack-test/src/test/resources/samples/panelactions.xml

Removing support for the element key/value version would improve consistency, but would break pre-5.0 install descriptors. A note could be added to the Upgrading from Previous Versions wiki page to mitigate this.



 Comments   
Comment by Tim Anderson [ 04/Apr/12 ]

I can't see that IzPackProjectProvider is actually used anywhere.
It gets written out to the installer jar in PackagerBase.writeInstaller():

    private IzpackProjectInstaller izpackInstallModel;

...

    protected void writeInstaller() throws Exception
    {
...
        writeInstallerObject("izpackInstallModel", izpackInstallModel);
....

I can't see that it gets read back in during installation.

Does anyone know what this was intended for, and if it is still required?

Comment by Daniel Abson [ 04/Apr/12 ]

Maybe somebody was trying to replace all the explicit XML parsing and object construction in CompilerConfig by delegating it all to XStream?

Comment by Daniel Abson [ 04/Apr/12 ]

Yep, it's a fairly new development - see IZPACK-764. It would definitely be a major improvement to the application's XML handling.

Comment by Tim Anderson [ 04/Apr/12 ]

Actually it predates that. It goes back at least to 27/02/2010, revision 63de2c95fd6354ddef6e9657a293974e2532e395

Comment by Rene Krell [ 04/Apr/12 ]

Concerning IZPACK-764, this is just a recommendation, there hasn't been done anything in that scope.

Comment by Daniel Abson [ 05/Apr/12 ]

Maybe the code that builds izpackInstallModel needs to be removed from master at the moment, then? It could be a start point for implementing IZPACK-764 in a developer branch, but in its current state it's conflicting with CompilerConfig as described in this issue.

Comment by Rene Krell [ 05/Apr/12 ]

You're right. XStream isn't an agreed approach for XML parsing in IzPack in the developer team due to the additional dependencies, JAXB will be the better choice, but this is pretty much work. Nothing for 5.0, to finally get off the ground with the new version.

With respect of the small amount of time we're having there would be appreciated a tested patch which works for you, even if there are small changes. Would this be possible?

Comment by Daniel Abson [ 05/Apr/12 ]

Yes, I'll have a go at that.

Comment by Daniel Abson [ 11/Apr/12 ]

This will also fix a compiler error when trying to specify a <help/> tag on a <panel/>:

java.io.NotSerializableException: com.izforge.izpack.api.data.binding.Help

Comment by Daniel Abson [ 11/Apr/12 ]

The installer help functionality is actually disabled completely, by commit 0cc80a3d1022317248286b68e727bb90bd0b6a2a on CompilerConfig. The call to panel.addHelp(iso3, resourceId) in addPanels() was commented out and never restored. I'll update and fix this, too.

Comment by Daniel Abson [ 11/Apr/12 ]

The new patch remove-xstream-provider.patch removes the XStream provider from the izpack-compiler module. A couple of test cases for the XStream provider have also been deleted, and annother test case fixed to account for the removal of the XStream provider.

The compiler support for panel helps has also been fixed, and the Help API class made Serializable.

The originally-reported issue (the PanelAction <param> tag) works as under 4.3.x without any changes - the code in the original patch to allow the <param name="" value=""/> form has not been included.

Comment by Daniel Abson [ 11/Apr/12 ]

Attached an updated version of the latest patch file, remove-xstream-provider-plus-deps.patch. This removes the xstream dependency from the build.

Comment by Daniel Abson [ 12/Apr/12 ]

[scratched]

Comment by Tim Anderson [ 13/Apr/12 ]

I've applied the remove-xstream-provider-plus-deps.patch.

Could you please update the panel-action-param.patch and resubmit it in another JIRA? It would be good to make the PanelAction <param> tag consistent with the <param> tag in <guiprefs>.

Comment by Daniel Abson [ 17/Apr/12 ]

Done - IZPACK-796 has the patch, with updated integration tests.





[IZPACK-790] Remove GUIInstallData.currentPanel Created: 02/Apr/12  Updated: 13/Dec/12  Resolved: 03/Apr/12

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

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

Number of attachments : 0

 Description   

GUIInstallData temporarily caches the current Panel in the field currentPanel during panel construction, in order for the IzPanel to access its own meta-data during construction.
In 5.0 this doesn't appear to be populated any longer.
Given it was a workaround, and 5.0 supports dependency injection, a better approach would be to pass the Panel at construction.



 Comments   
Comment by Tim Anderson [ 03/Apr/12 ]

IzPanel and its subclasses now take the Panel as an argument at construction





[IZPACK-789] TargetPath and PathSelection Panel have weird horizontal issues Created: 27/Mar/12  Updated: 23/Apr/12  Resolved: 23/Apr/12

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

Type: Bug Priority: Major
Reporter: Dustin Kut Moy Cheung Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: HTML File IZPACK-789     PNG File selectpath-1.png     PNG File selectpath-2.png     PNG File targetpath-1.png     PNG File targetpath-2.png    
Number of attachments : 5

 Description   

See screenshots.



 Comments   
Comment by Dustin Kut Moy Cheung [ 27/Mar/12 ]

With the patch applied, this results in the screenshots.

Note that the patch also includes the patch introduced in IZPACK-337

Comment by Dustin Kut Moy Cheung [ 27/Mar/12 ]

https://github.com/jponge/izpack/pull/16





[IZPACK-788] Remove installer dependency on ClassPathCrawler Created: 25/Mar/12  Updated: 27/Mar/12  Resolved: 27/Mar/12

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

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

Number of attachments : 0

 Description   

The installer has a dependency on ClassPathCrawler via RulesEngineImpl and PathResolver (used by UninstallerDataWriter).
This should not be required as:

  • all classnames emitted by the compiler should be fully qualified or readily mapped to an internal IzPack class
  • ClassPathCrawler can return incorrect classes if they happen to have the same simple name
  • ClassPathCrawler is not particularly efficient as it has to scan the entire class path

The RulesEngineImpl dependency on ClassPathCrawler should be removed.
The compiler specific parts of PathResolver should be moved into a new class (e.g. CompilerPathResolver) residing in the izpack-compiler module.






[IZPACK-787] InstallationTest.testSubstanceLaf() fails with ClassNotFoundException Created: 25/Mar/12  Updated: 25/Mar/12  Resolved: 25/Mar/12

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

Type: Bug Priority: Minor
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

InstallationTest.testSubstanceLaf() fails with:

java.lang.NoClassDefFoundError: org/pushingpixels/trident/ease/TimelineEase
  at org.pushingpixels.lafwidget.animation.AnimationFacet.<init>(AnimationFacet.java:54)
  at org.pushingpixels.lafwidget.animation.AnimationFacet.<clinit>(AnimationFacet.java:61)
  at org.pushingpixels.substance.api.SubstanceLookAndFeel.<clinit>(SubstanceLookAndFeel.java:153)
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:247)
  at javax.swing.SwingUtilities.loadSystemClass(SwingUtilities.java:1850)
  at javax.swing.UIManager.setLookAndFeel(UIManager.java:557)
  at com.izforge.izpack.installer.container.provider.GUIInstallDataProvider.loadLookAndFeel(GUIInstallDataProvider.java:283)
  at com.izforge.izpack.installer.container.provider.GUIInstallDataProvider.provide(GUIInstallDataProvider.java:91)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  at org.picocontainer.injectors.MethodInjector.invokeMethod(MethodInjector.java:141)
  at org.picocontainer.injectors.MethodInjector.access$000(MethodInjector.java:37)
  at org.picocontainer.injectors.MethodInjector$2.run(MethodInjector.java:125)
  at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:272)
  at org.picocontainer.injectors.MethodInjector.decorateComponentInstance(MethodInjector.java:132)
  at org.picocontainer.injectors.CompositeInjector.decorateComponentInstance(CompositeInjector.java:58)
  at org.picocontainer.injectors.Reinjector.reinject(Reinjector.java:142)
  at org.picocontainer.injectors.ProviderAdapter.getComponentInstance(ProviderAdapter.java:96)
  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.InstallerContainer.resolveComponents(InstallerContainer.java:91)
  at com.izforge.izpack.installer.container.impl.GUIInstallerContainer.resolveComponents(GUIInstallerContainer.java:57)
  at com.izforge.izpack.installer.container.impl.InstallerContainer.fillContainer(InstallerContainer.java:46)
  at com.izforge.izpack.compiler.container.TestInstallationContainer.fillInstallerContainer(TestInstallationContainer.java:35)
  at com.izforge.izpack.compiler.container.AbstractTestInstallationContainer.fillContainer(AbstractTestInstallationContainer.java:36)
  at com.izforge.izpack.core.container.AbstractContainer.initBindings(AbstractContainer.java:25)
  at com.izforge.izpack.test.junit.PicoRunner$1.run(PicoRunner.java:121)
  at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
  at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:641)
  at java.awt.EventQueue.access$000(EventQueue.java:84)
  at java.awt.EventQueue$1.run(EventQueue.java:602)
  at java.awt.EventQueue$1.run(EventQueue.java:600)
  at java.security.AccessController.doPrivileged(Native Method)
  at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
  at java.awt.EventQueue.dispatchEvent(EventQueue.java:611)
  at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
  at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
  at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
  at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: java.lang.ClassNotFoundException: org.pushingpixels.trident.ease.TimelineEase
  at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
  at java.security.AccessController.doPrivileged(Native Method)
  at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
  ... 47 more


 Comments   
Comment by Tim Anderson [ 25/Mar/12 ]

Caused by exclusion of org.pushing-pixels:trident in pom.xml

        <dependency>
                <groupId>org.java.net.substance</groupId>
                <artifactId>substance</artifactId>
                <version>6.0</version>
                <exclusions>
                    <exclusion>
                        <groupId>com.google.android</groupId>
                        <artifactId>android</artifactId>
                    </exclusion>
                    <exclusion>
                        <groupId>org.pushing-pixels</groupId>
                        <artifactId>trident</artifactId>
                    </exclusion>
                    <exclusion>
                      <artifactId>ant</artifactId>
                      <groupId>ant</groupId>
                    </exclusion>
                </exclusions>
            </dependency>

The exclusion has now been removed





[IZPACK-786] Remove restriction of one configuration per PanelAction class Created: 24/Mar/12  Updated: 23/Jul/12  Resolved: 23/Jul/12

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

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

Number of attachments : 0

 Description   

The same PanelAction implementation cannot be registered for multiple actions on a panel (preconstruct, preactivate, prevalidate, postvalidate) with different parameters.
This is because the parameters are held in a map, keyed on the actions' class name.
This restriction should be removed.






[IZPACK-785] Create console implementation of CheckedHelloPanel Created: 23/Mar/12  Updated: 23/Mar/12  Resolved: 23/Mar/12

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

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

Number of attachments : 0

 Description   

The console installer needs an implementation of CheckedHelloPanel



 Comments   
Comment by Tim Anderson [ 23/Mar/12 ]

Also added integration test: com.izforge.izpack.integration.windows.WindowsConsoleInstallationTest





[IZPACK-784] Remove automatic registration of panel classes Created: 22/Mar/12  Updated: 13/Dec/12  Resolved: 25/Mar/12

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

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

Number of attachments : 0

 Description   

The PanelManager has a method loadClassesInSamePackage() which crawls the classpath to register all public classes in the same package with the pico container.
This implicit registration of classes with the container could yield unexpected results. Its also not very efficient.
(ClassPathCrawler should be a compiler only class).

Panels requiring objects not provided by the container can

  • construct the object internally
  • use BindeableContainer to get the object
  • use ObjectFactory to create a new instance





[IZPACK-783] MultiVolumePackager Created: 20/Mar/12  Updated: 26/Apr/12  Resolved: 26/Apr/12

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

Type: Bug Priority: Critical
Reporter: Grzegorz Rozniecki Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

According to Next Documentation "Currently two implementations are available (com.izforge.izpack.compiler.packager.impl.Packager, com.izforge.izpack.compiler.packager.impl.MultiVolumePackager)." but in fact com.izforge.izpack.compiler.packager.impl.MultiVolumePackager isn't available. Looking in source code (branch master on git repo) explains that situation: whole content of this file is commented out.

We want to use MultiVolumePackager feature in our project but despite it's documented, it doesn't work.



 Comments   
Comment by Tim Anderson [ 26/Apr/12 ]

Change will be available in 5.0-beta-11





[IZPACK-782] Add custom lifecycle mappings to IzPack Maven plugin Created: 20/Mar/12  Updated: 23/Mar/12  Resolved: 23/Mar/12

Status: Resolved
Project: IzPack
Component/s: Maven plugin
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   

There must be defined for each time a packaging type (default is "jar"). This packaging type is mapped to a default Maven lifecycle mapping, which currently launches the Maven Jar plugin. There isn't even another packaging type with an appropriate lifecycle mapping to integrate the IzPack Maven plugin with.

Currently, if you have a POM with packaging="jar" and using the IzPack plugin, there is been automatically called the Maven Jar plugin, which creates parallely Jar files during the package phase. The Jar pluging doesn't offer an option to skip this. Concurrently, we produce also Jars, but they are of a complete different type than Jars compiled from Java sources.

Therefore, for a clean compile POM, that can be separated from the source code compiling, it would be of advantage to automatically launch the IzPack plugin instead of the Jar plugin during the package phase. This will need a custom configuration packaged with the Izpack plugin for Plexus with a new role-hint, like "izpack-jar" instead "jar".



 Comments   
Comment by Tim Anderson [ 20/Mar/12 ]

It's not required. You just need to declare:

    <packaging>pom</packaging>
Comment by Rene Krell [ 21/Mar/12 ]

I agree, it is not a blocker. I meant this as a convenient mapping, as a replacement for what "jar" packaging does, just replacing the default for the "package" phase.

The POM packaging avoids the concurrent creation of Jars, but also removes other plugin calls which might be useful for several use cases, see Package-specific Lifecycles.

One might compiling several test tools including all the pre-processing a normal compile cycle does, but just not packing classes into the Jar, but as install tools to the IzPack installer. For that case, he has to call all the missing plugin goals explicitly, making the POM more difficult. There could be also useful explicitly attaching the installer jar to the project, which I suggested in a separate issue.
Another use case I see in real world projects are modules, which compile application source code and create installers on thy fly, not wanting separate modules for installer creation. This is even more special, if the compiled application source code should be JARed, and after that packaged into an installer. For this use case it could be even better creating the installer in a phase after the "package" phase.

That's why I thought about a convenience, to not get messy POMs. I'm still not sure, how an "ideal" lifecyle mapping with Izpack should look like, just saw what's going on in one particular real-world project. I could even imagine several hints for particular use cases. This is all about somehow working around what Maven hasn't been originally made for - installer creation/deployment, because no module will depend on an installer. Still subject to discuss.

Furthermore, the new packaging type would be a clear add-on option for use cases as above, nothing would change if one uses default packaging methods, there wouldn't be any usage conflict or broken compatibility.

Comment by Rene Krell [ 23/Mar/12 ]

There can now be used a separate package type "izpack-jar".
When defining it, there is no need to call the execution of the Maven IzPack plugin, it will be executed automatically in the package phase. If the resulting installer jar is used as artifact, it will be furthermore installed and deployed like any other artifact.

Example:

  <packaging>izpack-jar</packaging>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.izpack</groupId>
        <artifactId>izpack-maven-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
          <descriptorEncoding>UTF-8</descriptorEncoding>
          <baseDir>${staging.dir.app}</baseDir>
          <installFile>${izpack.dir.app}/install.xml</installFile>
          <outputDirectory>${project.build.directory}</outputDirectory>
          <finalName>${project.build.finalName}</finalName>
          <enableOverrideArtifact>true</enableOverrideArtifact>
        </configuration>
      </plugin>
    </plugins
  </build>

This is a first proposal for the most common use-case - using the installer jar as main or classified artifact and being able to install and deploy it as normal artifacts (including the renaming which the core artifact installer and deployer classes in Maven do). There might be added more convenient mappings in future.





[IZPACK-781] Add outputDirectory, finalName, classifier, and attach properties to Maven plugin Created: 20/Mar/12  Updated: 21/Mar/12  Resolved: 21/Mar/12

Status: Resolved
Project: IzPack
Component/s: Maven plugin
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   

The following properties could be added to the IzPack Maven plugin to enhance its possibilities and make it work similar to the Maven Jar Plugin regarding its output:

*outputDirectory
Directory containing the generated JAR.
Default-value="$

{project.build.directory}

"
*finalName
Name of the generated JAR.
Default-value="$

{project.build.finalName}

"
*classifier
Classifier to add to the artifact generated. If given, the artifact is attachable. Furthermore, the outputfile name gets -<classifier> as suffix.
If this is not given,it will merely be written to the output directory according to the finalName.
No default.
*enableAttachArtifact
Whether to attach the generated installer jar to the project as artifact, if a classifier was specified.
Default-value="true"
*enableOverrideArtifact
Whether to override the artifact file by the generated installer jar, if no classifier is specified.
This will set the artifact file to the given name based on outputDirectory + finalName or on output.

The given defaults make it compatible with the previous behavior.
The "output" property overrides outputDirectory, finalName, classifier, but should be marked deprecated .



 Comments   
Comment by Rene Krell [ 21/Mar/12 ]

Resolved as described.





[IZPACK-780] Add ability to recursively create parent dir of installer output file Created: 20/Mar/12  Updated: 21/Mar/12  Resolved: 21/Mar/12

Status: Resolved
Project: IzPack
Component/s: Compiler, Maven plugin
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 Maven, it might be convenient for several use cases to generate the output jar in a different target directory than the default one: $

{project.build.directory}. This might be the case for instance on deployments using the maven-wagon-plugin, if you want to recursively generate output directories to a base directory, which can be done in the includes element only, for example:


<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>wagon-maven-plugin</artifactId>
<configuration>
<fromDir>${project.build.directory}

</fromDir>
<includes>sample/$

{project.build.finalName}*.jar</includes>
<toDir>app_group1</toDir>
<url>${deploy.baseUrl}</url>
</configuration>
</plugin>



Provided the directory ${deploy.baseUrl}/app_group1/ exists, recursively creating directories can be done only by the <includes/> element. This means, the source files included must already exist in the given structure.

Currently, there is no possibility to achieve this in a straight way, for instance the following configuration will fail if ${project.build.directory}/sample/ doesn't yet:


<plugin>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-maven-plugin</artifactId>
<executions>
<execution>
<id>standard-installer</id>
<phase>package</phase>
<goals>
<goal>izpack</goal>
</goals>
<configuration>
...
<output>${project.build.directory}/sample/${project.build.finalName}

.jar</output>
</configuration>
</execution>
</executions>
</plugin>


I'd like to add a flag to izpack-maven-plugin and the IzPack Ant task, which enables recursively creating parent directories of the output file.



 Comments   
Comment by Rene Krell [ 21/Mar/12 ]

Resolved. Use plugin configuration property

<mkdirs>true|false</mkdirs>




[IZPACK-779] Add dependency injection support for DataValidator, PanelAction and PackValidator implementations Created: 18/Mar/12  Updated: 19/Mar/12  Resolved: 19/Mar/12

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

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

Number of attachments : 0

 Description   

Currently, DataValidator, PanelAction and PackValidator implementations must provide a public no-arg constructor.
Given that singletons have been removed by IZPACK-772, support should be added to enable dependencies to be injected at construction.



 Comments   
Comment by Tim Anderson [ 19/Mar/12 ]

Also added integration tests:

  • com.izforge.izpack.integration.datavalidator.DataValidatorTest
  • com.izforge.izpack.integration.panelaction.PanelActionTest
  • com.izforge.izpack.integration.packvalidator.PackValidatorTest




[IZPACK-778] Usage of Apache Commons Compress as is as replacement for built-in zip stream Created: 18/Mar/12  Updated: 21/Sep/12

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

Type: Improvement 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   

Currently just as a reminder and for discussion:
Currently, there is a housemade Jar stream class used, which has been made due to incompatibilities of the one coming from the JDK using different compressors, as BZIP2. It inherits already from a special Apache zip stream from an ealier version of this framework.

From what I have seen, the JDK class didn't change as much, but meanwhile, there has been added and improved support for several compressors we use in the Apache Commons Compress framework, see http://commons.apache.org/compress/.
We should give it a try, somewhere in the roadmap.

Of course, this is no stabilization, more a code improvement, to get rid of code parts which concentrates someone else more in particular.






[IZPACK-777] General JAR package test improvements Created: 16/Mar/12  Updated: 16/Mar/12  Resolved: 16/Mar/12

Status: Resolved
Project: IzPack
Component/s: None
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   

There are several test improvements to be filed here:

  • improvement of jar file packaging and integration tests,
  • fixed usage of MergeMatcher with MergeManagerImpl (cleared the list after first merge)
  • use JarFile instead of just File with lazy PicoContainer instantiation
  • added debug logging to MergeMatcher and ZipMatcher





[IZPACK-776] Windows 7 treats installation as not compatible when is run by Administrator Created: 16/Mar/12  Updated: 16/Mar/12

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

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

OS: Windows 7
IzPack: 4.3.5
Python: 3.2.2
JVM: 1.6.0_26-b03


Attachments: PNG File program_compatibility_assistant_complain.png    
Number of attachments : 1

 Description   

When installation is run by administrator (i.e. Run As Administrator), after installation Windows 7 Program Compatibility Assistant shows appropriate dialog window with complains about installation incompatibility.






[IZPACK-775] <parsable> requires targetFile attribute, even if nested filesets are used Created: 12/Mar/12  Updated: 21/Mar/12  Resolved: 21/Mar/12

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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

<parsable> requires targetFile attribute, even if nested filesets are used. This is not as documented, targetFile makes no sense in case of using filesets.






[IZPACK-774] IzPack 5 fails to create web installer while using same install.xml file which works with 4.3.5 Created: 10/Mar/12  Updated: 10/Mar/12

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

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

Ubuntu Linux 10.10 32bit, Sun Java 1.6.0_26


Number of attachments : 0

 Description   

I have an install.xml that works fine with IzPack 4.3.5 and generates an web installer.
With IzPack 5.0.0-beta10, only standard installer can be generated and process of generating web installer fails as follows:

.:: IzPack - Version 5.0.0-beta10 ::.

< compiler specifications version: 1.0 >

  • Copyright (c) 2001-2010 Julien Ponge and others. All Rights Reserved.
  • Visit https://izpack.github.io/ for the latest releases
  • Released under the terms of the Apache Software License version 2.0.

-> Processing : install.xml
-> Output : install.jar
-> Base path : .
-> Kind : web
-> Compression : default
-> Compr. level: -1
-> IzPack home : /home/tomas/Projects/IzPack_v5

< my install xml content printed here>

Setting the installer information
Setting the GUI preferences
Adding langpack: eng
Adding resource: flag.eng
Adding resource: LicencePanel.licence
Adding panel: UNKNOWN (HelloPanel) :: Classname : HelloPanel
Adding panel: UNKNOWN (LicencePanel) :: Classname : LicencePanel
Adding panel: UNKNOWN (TargetPanel) :: Classname : TargetPanel
Adding panel: UNKNOWN (InstallPanel) :: Classname : InstallPanel
[ Begin ]

Copying the skeleton installer
Copying 3 files into installer
Merging 0 jars into installer
Writing 5 Packs into installer
Writing Pack 0: Pack_Linux_x86
Writing Pack 1: Pack_Linux_x86_64
-> Fatal error :
Bad file descriptor
java.io.IOException: Bad file descriptor
at java.io.RandomAccessFile.writeBytes(Native Method)
at java.io.RandomAccessFile.write(RandomAccessFile.java:482)
at org.apache.tools.zip.ZipOutputStream.writeOut(ZipOutputStream.java:826)
at org.apache.tools.zip.ZipOutputStream.writeOut(ZipOutputStream.java:815)
at org.apache.tools.zip.ZipOutputStream.writeLocalFileHeader(ZipOutputStream.java:559)
at org.apache.tools.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:412)
at com.izforge.izpack.compiler.stream.JarOutputStream.putNextEntry(JarOutputStream.java:145)
at com.izforge.izpack.compiler.packager.impl.Packager.writePacks(Packager.java:292)
at com.izforge.izpack.compiler.packager.impl.PackagerBase.writeInstaller(PackagerBase.java:373)
at com.izforge.izpack.compiler.packager.impl.Packager.createInstaller(Packager.java:123)
at com.izforge.izpack.compiler.Compiler.createInstaller(Compiler.java:131)
at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:307)
at com.izforge.izpack.compiler.bootstrap.CompilerLauncher.main(CompilerLauncher.java:31)

(tip : use -? to get the commmand line parameters)






[IZPACK-773] Unite variables and dynamic variables Created: 09/Mar/12  Updated: 21/Sep/12

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

Type: Wish 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   

As already mentioned in IZPACK-696 and in some earlier discussions, there are ideas for uniting variables and dynamic variables to make a more consistent concept of variables.

Tim made a good start for a discussion: Variables would then be evaluated wherever they are used, and the InstallerBase.refreshDynamicVariables() method would not be needed any longer. On the off chance that a variable should be a constant, an attribute could be introduced (e.g constant="true", static="true", or final="true"). In this situation, the variable would be evaluated once.

One more idea coming from practical using dynamic variables: In several use cases I need to start evaluating a variable beginning with a certain panel. Example: Getting the version of a previous installation from some release.jar can be done when you know the target path the user wishes. If the previous installation files can be found there, the installer can start reading the release.jar there, otherwise this will fail. At the moment, I handle this using several additional helper conditions.

From what I see, to consolidate the variables concept there are first ideas how to mark variables (independent of how naming the attributes and the XML syntax):

  • type: final | dynamic
  • first evaluation time: installer start | when a certain panel is reached | until a certain panel is reached
  • scope: compiler | installer | uninstaller (or a combination of them, best as nested elements)

Any more ideas?



 Comments   
Comment by Tim Anderson [ 10/Mar/12 ]

Does it need to be that complex?

Currently we have:

<variables>
  <variable name="app-version" value="1.4"/>
  <variable name="released-on" value="08/03/2002"/>
</variables>

and:

<dynamicvariables>
  <variable name="app-version" value="1.4" condition="mycondition1" />
  <variable name="app-version" value="1.4b" condition="!mycondition1" />
  <variable name="released-on" value="08/03/2002" />
  <variable name="path" value="$INSTALL_PATH"/> <!-- variable with value containing a nested variable -->
</dynamicvariables>

This could merged so that it could be written as:

<variables>
  <variable name="app-version" value="1.4"/>
  <variable name="released-on" value="08/03/2002"/>
  <variable name="app-version">
      <condition="mycondition1" value="1.4"/>
      <condition="!mycondition1" value="1.4b"/>
  </variable>
  <variable name="path" value="$INSTALL_PATH"/>
</variables>

Variables would be evaluated every time they are accessed.

Comment by Rene Krell [ 12/Mar/12 ]

In case of dynamic variables I would save evaluations, because there might be executed external commands, for example. In other cases there might appear invalid values, because the situation for evaluation is not given, for instance if you want to gather information about a previous installation, but the user hasn't entered the target install path yet.

In complex installers you can define conditions based on variables, one relying on the other, and it could get messed, if the control of evaluation is not a bit more fain-grained. The dynamic variables enhancements in IzPack 5.0 come from bigger real-world installers, where it was necessary to gather and filter system information in a more complex way than just from an environment variable, all what has been missing in 4.3.

Comment by Rene Krell [ 12/Mar/12 ]

I would appreciate something like:

<variables>

  <!-- that is the variable definition as before, evaluate always: -->
  <variable name="SERVICE_NAME" value="MyService"/>

  <!-- evaluate once after the TargetPanel is left -->
  <variable name="previous.version"
    once="true"
    afterPanel="TargetPanel"
    jarfile="${INSTALL_PATH}/libs/release.jar"
    entry="release.properties" type="options"
    key="release.version"
    ignorefailure="true">
  </variable>

  <!-- evaluate always from beginning -->
  <variable name="current.hostname" once="false"
    executable="hostname"
    type="process"/>

</variables>

See also http://docs.codehaus.org/display/IZPACK/Dynamic+Variables, they are able to do a lot against IzPack 4.3. Simplicity could be made in choosing the right defaults, who wants more from variables, chooses several attributes, IMHO.

Comment by Tim Anderson [ 13/Mar/12 ]

Variables would be lazily evaluated. If you have a "once" attribute, then I don't see that you need to specify an "afterPanel" attribute. Presumably you would only access the variable in a panel after TargetPanel - this first access would evaluate and cache the value.

I also think it would be better to have nested elements rather than having multiple attributes e.g.:

<variable name="SERVICE_NAME" value="MyService"/>

<variable name="previous.version" once="true">
   <property archive="${INSTALL_PATH}/libs/release.jar" file="release.properties"
             name="release.version" ignorefailure="true"/>
</variable>

<variable name="current.hostname">
   <exec path="hostname"/>
</variable>

<variable name="file.exist">
   <available file="~/.bashrc"/>
</variable>

If there are instances where variable evaluation needs to be scoped to panels, either introduce a condition:

<variable name="previous.version">
    <beforePanel name="TargetPanel" value="unset"/>
    <afterPanel name="TargetPanel" once="true">
         <property archive="${INSTALL_PATH}/libs/release.jar" file="release.properties"
                   name="release.version" ignorefailure="true"/>
    </afterPanel>
</variable>

Or enable variables evaluation to be specified with panels:

    <panels>
        <panel classname="TargetPanel">
            <after>
                <variable name="previous.version" once="true">
                   <property archive="${INSTALL_PATH}/libs/release.jar" file="release.properties"
                    name="release.version" ignorefailure="true"/>
                </variable>
            </after>
        </panel>
    </panels>
Comment by Rene Krell [ 13/Mar/12 ]

I fully agree with nested elements instead of too many attributes. This is better than mixing all the attributes to the syntax of one element. There should be those attributes allowed in the <variable> tag, which directly belong to it, not the implementation of the evaluation.

What I don't agree with is this abstract: If you have a "once" attribute, then I don't see that you need to specify an "afterPanel" attribute. Presumably you would only access the variable in a panel after TargetPanel - this first access would evaluate and cache the value.:
The difference between once="true" and once="false" is of matter here - by meanings of "dynamic variables". If you have once="false", the values should be refreshed on each panel change after or before a given panel. I would not remove this facility, there might be use cases, when you permanently have to check some system changes. For instance you might read some data from the application database which changes during the installation process.
We might choose for instance once="true" or dynamic="false or something similar as default to have an as less as possible number of evaluations.

I agree with registering variables with panels, whis is a good idea. Inside <after/> and </before> there can be exactly the same <variable> syntax as it would have been defined in <variables/>. Furthermore, in this case there is no need to check, whether the given panel is really used.

Finally, IMHO, there no good reason to mix <property> and <variable>. "Properties" by meanings of Izpack are visible just during compiling, variables are resolved during installing, text with references to variables should be saved unresolved in the installer. This is a clean way.

What is still not declared is the scope: "installer" or "uninstaller". That's the question. We can leave this for later. Personally I haven't had the need of dividing the scopes in that way, but one might find this useful.

Note: There is one issue, which I don't like in IzPack 5.0. $INSTALL_PATH is automatically evaluated with the default installation path even if the target panel hasn't been reached. This is not clean. $INSTALL_PATH should be only valid before that panel, if it has been set in an auto-install.xml record or using the system property INSTALL_PATH for unattended installations, otherwise not.

Comment by Tim Anderson [ 13/Mar/12 ]

If variables have once="false" there doesn't need to be an explicit refresh. They refresh automatically when accessed.
E.g.

   installData.setVariable("foo", "$INSTALL_PATH");
   installData.setVariable("INSTALL_PATH", "bar");
   String foo1 = installData.getVariable("foo"); // -> "bar"
   installData.setVariable("INSTALL_PATH", "gum");
   String foo2 = installData.getVariable("foo"); // -> "gum"

My use of "property" in the example above might better have been expressed as:

   <variable name="previous.version" once="true">
       <propertyfile archive="${INSTALL_PATH}/libs/release.jar" file="release.properties"
                     name="release.version" ignorefailure="true"/>
   </variable>
Comment by Rene Krell [ 13/Mar/12 ]

If variables have once="false" there doesn't need to be an explicit refresh. They refresh automatically when accessed.
After considering all the side effects I'd agree with that.
But I'm not sure whether this doesn't confuse someone who debugs a problem with the installer. In this case "accessing" means also logging the current value of a variable and showing the current value in the graphical debug mode (-DDEBUG, -DTRACE), not just accessing somewhere in the installation itself.
Furthermore, there still must be checked conditions and the current active panel, if there has been defined an association. The evaluation on access is regardless from the value of the once attribute, if not evaluated it has to evaluated "now" in each case. Variables with once="true" would be skipped after the first evaluation, when already set. But we might avoid evaluating variables different than plain ones from being evaluated more times on a certain active panel. Maybe the variables get a second flag indicating panel changes and allowing reevalutaion, which is an implementation detail.

The setVariable() method doesn't make sense for other types than plain variables and should not change user-defined variables at all except when evaluating them by their definition (I assume this won't be even necessary in a different way). It should be used only in certain cases (for instance setting INSTALL_PATH in the TargetPanel) and needs wrapping the value to a PlainValue (according to the current implementation of dynamic "plain" variables).

Regarding <propertyfile>:
This is a convenient definition, but there are more file formats the value could be read from.
We can add <propertyfile>, <xmlfile>, <inifile> and so on. This way each new file format in future will require a new element definition, which doesn't actually matter.

Comment by Rene Krell [ 13/Mar/12 ]

Regarding the implementation:
There are two variants of getting variables into the installer:

  1. Using a Map<String, (Dynamic)Variable> instead of a Map <String, String>, which makes it easy, when all variables implementations are serializable. The "once" flag and other flags are completely serialized.
    We would have a Variable.getOnce() method and so on. Special implementations are recognized with instanceof during the installation/uninstallation.
  2. Just adding a XML definition to the installer and make the instantiation in the installer/uninstaller.
    Advantage:
    • The installer jar will get smaller, especially on an intensive use of variables.
    • We're independent on the JRE implementation of serialization.

I'd prefer the first one, this is the way how dynamic variables currently work.

Comment by Tim Anderson [ 13/Mar/12 ]

I'd opt for XML. The use of Serializable locks installations into using a single version of IzPack, as there is no facility to migrate between versions. At the moment, the only viable solution for moving an installation from IzPack 4 to IzPack 5 is to uninstall first. If everything was stored as XML, it would be a less complex task to support migration - xsl could be used to convert the uninstallation data.

With regards to when variables are evaluated, this could be determined by an "eval" attribute (instead of "once")
Values would be:

  • always - always evaluate. This is the default
  • once - evaluate on first access, return cached value thereafter
  • panel - evaluated on first access entering a panel, return cached value thereafter. Evaluated again on first access entering another panel.
  • condition=<some-condition> - evaluates <some-condition> to determine if the variable should be evaluated
Comment by Rene Krell [ 13/Mar/12 ]

What I meant is adding objects to the installer jar during compiling, for instance variables, header and so on, but this kind of serialization is done generally in IzPack, this way there must be changed the whole concept and maybe diesn't make any sense. Just for discussing about one and the same thing.

Saving the uninstaller as XML I fully support. No data should be written to the filesystem serialized by Serializable. But this is a different issue.

I agree with the evaluate attribute, except the "condition" value. Conditions I would evaluate additionally as nested elements. There can be more conditions, which play a role and one might not want to define an extra single condition outside of the variable definition scope just for a variable evaluation.

Better would be for example from my point of view:

<variable name="var1" eval="always" ...>
  <condition type="and">
    <condition refid="cond1"/>
    <condition refid="cond2"/>
  </condition>
</variable>
Comment by Rene Krell [ 13/Mar/12 ]

Regarding serializing XML:
To be honest, I'd prefer some refactory of the IXMLElement and the parser itself to support objects which parse and save objects automatically and map fields and local XMLExternalizable instances to XML elements and attributes. This way we wouldn't even need XSL definitions, although they are good for syntax checking in external tools. This way be could remove all the makeXML() and similar methods all over in the code.

If we had some kind of XMLExternalizable, which could automatically parse and validate the correctness of an XML and save its contents by one method to a XML output stream, much work would have been done. We could then add the XMLExternalizable to the installer (even serialized or as XML) during compiling, and easily instantiate XMLExternalizable objects during the execution of the installer.

Just a dream for now...

Comment by Tim Anderson [ 14/Mar/12 ]

The eval="condition=<eval-condition>"> would be used to determine when the variable is evaluated.
The nested conditions would determine its value when eval-condition is true.
E.g.:

  <variable name="var1" eval="condition=some-condition">
      <condition expression="mycondition" value="1.4"/>
      <condition expression="!mycondition" value="1.4b"/>
  </variable>

Alternatively, nest the eval condition:

  <variable name="var2">
      <if expression="someexpression"/>
        <case expression="mycondition" value="1.4"/>
        <case expression="!mycondition" value="1.4b"/>
      </if>
  </variable>

Serialization: both JAXB and XStream are good for this. If the intention is to allow users to extend the XML then an XStream solution might be the better approach.





[IZPACK-772] Replace use of singletons with dependency injection Created: 09/Mar/12  Updated: 17/Mar/12  Resolved: 17/Mar/12

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

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

Number of attachments : 0

 Description   

Much of the installer and uninstaller has been converted to using dependency injection.
Several classes remain as singletons, and some are used as both singletons and via dependency injection.
These include:

  • ResourceManager
  • Librarian
  • TargetFactory
  • Housekeeper
  • RegistryDefaultHandler
  • COIOSHelper
  • AutomatedInstallData

This use should be refactored to use dependency injection to make writing tests simpler.






[IZPACK-771] Non existing source file in <file> silently ignored and compiler succeeds anyway Created: 09/Mar/12  Updated: 09/Mar/12  Resolved: 09/Mar/12

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

Type: Bug 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

Number of attachments : 0

 Description   

In a definition:

<file src="@{staging.dir.app}/@{project.build.finalName}.zip" targetdir="${INSTALL_PATH}" unpack="true" override="true"/>

a non-existent file is silently ignored when the parent directory (@

{staging.dir.app}

) exists.

In this case, no content is added to the installer from that archive and the installer suceeds without a warning.






[IZPACK-770] Document logging and tracing for developers and users Created: 09/Mar/12  Updated: 10/Jul/13

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

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

Issue Links:
dependent
depends upon IZPACK-765 Switch IzPack logging to Java logging... Resolved
depends upon IZPACK-768 Switch IzPack logging to sfl4j Open
Number of attachments : 0

 Description   

Just not to forget:
IzPack logging got to be documented. This issue should serve as a collection of ideas about the contents of this documentation.



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

Developers need a guidline how to use it.

Installer logging levels:

  • ERROR
    Entries about serious problems preventing the installer from continuing.
  • WARNING
    Entries about problems, which are ignored or tolerated by the installer and do not lead to an abnormal aborting of the installation.
  • INFO
    Entries about important operations also for the user - no warnings and errors.
  • DEBUG
    Show detailed operation states just important for analyzing problems, but no longer bunches of data.
    Example:
    Refreshing dynamic variables
  • TRACE
    Show data, for instance lists of translations,
    Example:
    Showing all variable values:\nkey1=value1\nkey2=value2\n...
Comment by Tom Maynard [ 10/Jul/13 ]

IzPack v5.x should behave – at least as a default – the same way as v4.x: no visible logging messages to the console during execution. When a user runs a v4.x installation, they only see the panels built into the installer. A collection of INFO, and WARNING messages is confusing for a user in a production environment.

Console logging/tracing should be configurable at compile time: ON (at different levels) during development, and then OFF for the production release. It should be treated the same as any debugging information, and the user should not be exposed to it.

An example of the current, undesirable behavior is:

$ java -jar myInstaller.jar
Jul 9, 2013 5:29:11 PM INFO: Logging initialized at level 'INFO'
Jul 9, 2013 5:29:11 PM INFO: Commandline arguments:
Jul 9, 2013 5:29:12 PM INFO: Detected platform: windows,version=6.2,arch=x64,symbolicName=WINDOWS_8,javaVersion=1.7.0_25
Jul 9, 2013 5:29:12 PM INFO: No custom langpack for eng available
Jul 9, 2013 5:29:12 PM WARNING: Resource customicons.xml not defined. No custom icons available
Jul 9, 2013 5:29:12 PM INFO: Cannot find named resource: 'packsLang.xml' AND 'packsLang.xml_eng'
Jul 9, 2013 5:29:17 PM WARNING: Cleanup failed for native libraries: Cannot run program "C:\Program": CreateProcess error=2, The system cannot find the file specified





[IZPACK-769] Custom translations are not found in GUI installer - CustomLangPack.xml Created: 08/Mar/12  Updated: 18/Oct/13  Resolved: 20/Aug/13

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-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The resource CustomLangPack.xml is found and loaded by the GUIInstallDataProvider, but for some unknown reason the translations are no longer available in IzPanel.processValidationState(Status state), where it is needed get the translated error message presented to the user. Instead, just the translation id is shown in the message box instead of the message.

For developers who want to analyze this:

For displaying the translations available I to
com.izforge.izpack.installer.base.IzPanel.processValidationState(Status)
at the end of the catch block for validation errors:

...
//FIXME this shows that custom translations are missing
for (String s : installData.getLangpack().keySet())
{
    System.out.println("+++"+s);
}

this.emitError(getString("data.validation.error.title"), errorMessage);

but when you do some similar output in

com.izforge.izpack.installer.container.provider.AbstractInstallDataProvider.addCustomLangpack(AutomatedInstallData)

called from

com.izforge.izpack.installer.container.provider.GUIInstallDataProvider.provide(ResourceManager, VariableSubstitutor, Properties, PathResolver, ClassPathCrawler, BindeableContainer)

it is loaded to the installdata's pack.

There seem to be two different instance of the LocalDatabase or AutomatedInstallData. This might be some issue with instantiating and constructor dependency injection in picocontainer.



 Comments   
Comment by Martin Michna [ 18/Apr/12 ]

Problem is with key for customer localization (see: com.izforge.izpack.installer.container.provider.AbstractInstallDataProvider.LANG_FILE_NAME). Old verison use CustomLangpack.xml and new version use CustomLangPack.xml


Second way how fix this problem on old 4.3.6 version is put resource line for key packsLang.xml

...
<resources>
  <res id="CustomLangpack.xml_eng" src="messages.eng.xml" />
  <res id="packsLang.xml_eng" src="messages.eng.xml" /> <!-- special localization definition for packages -->
...
</resources>

...
<packs>
  <pack id="pack.gui" name="gui" required="yes">
  ...
  </pack>
</packs>

and with messages.eng.xml:

<?xml version="1.0" encoding="UTF-8"?>
<langpack>
  <str id="pack.gui" txt="The GUI files" />
  <str id="pack.gui.description" txt="GUI library and resources files" />
...
</langpack>
Comment by Rene Krell [ 18/Apr/12 ]

Not here. In IzPack 5.0 (latest snapshot) I use

  <resources>
    ...
    <res id="CustomLangPack.xml_eng" src="@{izpack.dir.app}/i18n/customLangPack.xml_eng"/>
    <res id="CustomLangPack.xml_deu" src="@{izpack.dir.app}/i18n/customLangPack.xml_deu"/>
  </resources>

with valid translations, but they can't be found in time (checking installer requirement) when accessing from a GUI installation. There seems to be a different cause, as mentioned above.
As far as I have checked this there happen several reinstantiations of LocalDatabase (different kind depending on whether it is a console or GUI installation), and the instance winning this race does not get these packs initialized for me, just the default language packs.

Comment by Tim Anderson [ 14/Aug/12 ]

Can you verify that this still occurs in the latest codebase? The langpack code has been refactored since this was raised.

There is now a unit test:

izpack-installer/src/test/java/com/izforge/izpack/installer/container/provider/AutomatedInstallDataProviderTest.java

to verify that custom langpacks are loaded - this passes.

If the provider cannot find a custom langpack, you'll get a message like:

14/08/2012 9:36:28 PM com.izforge.izpack.installer.container.provider.AbstractInstallDataProvider addCustomLangpack
INFO: No custom langpack for eng available

If its still a problem, stick a breakpoint in:

  • AutomatedInstallData.setMessages(Messages) - should only be called by AbstractInstallDataProvider or AutomatedInstaller
  • LocaleDatabase.add(Messages) - should only be called by AbstractInstallDataProvider or LocaleDatabase.newMessages()

Also check that your code is accessing the langpack via the Messages interface rather than via LocaleDatabase which can be used to modify the langpack.

Comment by Rene Krell [ 16/Aug/13 ]

This is no longer present in the current HEAD of izpack-5.0.0-rc1-SNAPSHOT.

Comment by Rene Krell [ 20/Aug/13 ]

This issue happened again

Comment by Rene Krell [ 20/Aug/13 ]

Fixed in https://github.com/izpack/izpack/pull/132.
The language propagation from LanguageDialog in GUI installations did not read custom translations of the chosen language, but just the default translations.





[IZPACK-768] Switch IzPack logging to sfl4j Created: 08/Mar/12  Updated: 09/Jul/13

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

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

Issue Links:
Related
relates to IZPACK-765 Switch IzPack logging to Java logging... Resolved
dependent
is depended upon by IZPACK-770 Document logging and tracing for deve... Open
Number of attachments : 0

 Description   

After introducing the usage of the Java Logging API the logging should be wrapped by the SFL4J API - see http://www.slf4j.org/






[IZPACK-767] Attempt to write uninstaller data while uninstaller is disabled Created: 07/Mar/12  Updated: 07/Mar/12  Resolved: 07/Mar/12

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

Type: Bug Priority: Major
Reporter: Andreas Schöneck Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If I disable the installer via

<uninstaller write="no" />

IzPack nevertheless tries to write uninstaller data on the Quit/Done button of the last panel and therefore fails with

{{[ Writing the uninstaller data ... ]
com.izforge.izpack.api.exception.IzPackException: The package com.izforge.izpack.uninstaller has not been found in the classpath and is required by the installer}}

and a corresponding GUI error popup.



 Comments   
Comment by Andreas Schöneck [ 07/Mar/12 ]

Duplicate of IZPACK-738





[IZPACK-766] Installer transactions Created: 06/Mar/12  Updated: 21/Sep/12

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

Type: Wish 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   

Make installer including listeners work transactionally, not destroying the existing files and settings or rolling back existing files on a failing installation and introduce facilities and listener entry points for doing custom transaction steps, like DB rollback and so on.

Currently, in IzPack 5, there is just the possibility to automatically rename existing files, there should be more automatism.






[IZPACK-765] Switch IzPack logging to Java logging API Created: 06/Mar/12  Updated: 09/Jul/13  Resolved: 08/Mar/12

Status: Resolved
Project: IzPack
Component/s: None
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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to IZPACK-768 Switch IzPack logging to sfl4j Open
dependent
is depended upon by IZPACK-770 Document logging and tracing for deve... Open
Number of attachments : 0

 Description   

I'd appreciate to replace the Debug object by using the Java Logging API (or some alternative lightweight framework) to make it more configurable and standard-conform.



 Comments   
Comment by Dan Tran [ 06/Mar/12 ]

how about slf4j? so that user can pick their own provider? like logback?

Comment by Rene Krell [ 07/Mar/12 ]

Currently I'm reworking it for the standard java logging API, to have a start. The user can configure it and provide its own handlers and filters on class level and there is no overhead. The current Debug solution isn't state of the art, IMHO - to replace it (and keeping some certain compatibility in terms of command line options) would be the main goal for now.

Someone might return to it in future, I'm trying to avoid dependencies on an external logging framework to be compiled in into installers, although from what I have seen slf4j is really small in its basic requirements.

Comment by Rene Krell [ 07/Mar/12 ]

@Dan: I've looked at some more details of slf4j. Since it is a clear abstraction to logging frameworks it looks really nice.

  • Installer:
    Users may pack the logging framework of their choice to IzPack, for instance as "jar" in install.xml, or we create a separate descriptor tag for logging frameworks.
  • Compiler:
    There can be used a completely separate logging framework for compiling to be added as Maven dependency.

Hopefully this will play as nice together as it sounds.
Your idea is really good and the overhead of the slf4j API is really very small. I'll look at it further if no one else does.

Maybe really a good choice to integrate into upcoming 5.0, any more opinions?

Comment by Tim Anderson [ 08/Mar/12 ]

I'd prefer slf4j over java.util.logging - its a little easier to use.
Be good to include in 5.0

Comment by Dan Tran [ 08/Mar/12 ]

slf4j over java.util.logging is a good choice to start with. Thank you for working hard on izpack

Comment by Rene Krell [ 08/Mar/12 ]

At the moment, the Java Logging API is activated. For introducing sfl4j I'll open a separate issue.

Comment by Rene Krell [ 08/Mar/12 ]

Migrating should be easy now using the slf4j migration tool. It supports partly migrating from java.util.logging. The logger.fine() can be migrated to .debug() manually.





[IZPACK-764] Improve XML handling - JAXB, XStream Created: 05/Mar/12  Updated: 21/Sep/12

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

Type: Wish Priority: Major
Reporter: Rene Krell 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   

Parsing XML documents in IzPack is currently incomplete. Even though the XML syntax is well-formatted, there are not recognized bad element or attribute names, thus using the IXmlElement is error-prone especially for typos. Parsing the installation descriptor (install.xml) and several XML resources could be migrated to a different approach.

Best choices might be:

  • JAXB
    Integrated to Java SE 6 and OpenJDK 6.
  • XStream
    Requires additional dependencies.

There is a good comparison available for both: How Does JAXB Compare to XStream?



 Comments   
Comment by Julien Ponge [ 14/Mar/12 ]

Let me give some background on the IXmlElement and related API.

In the early days of IzPack there was no XML parser in Java (1.2), so we went for a tiny library called NanoXML. This is where the IXmlElement interface comes from. Because it was a simple and flexible data containers, we opted to directly use the XML DOM trees to store data. Was it good or bad? At least it was very convenient.

Later on we refactored the code base to get rid of the unmaintained NanoXML, and take advantage of the JDK built-in parser. The adherence of the NanoXML to the rest of the codebase was high though, hence IXmlElement and related class serve as an adapter.

I agree that it would be great to further refactor the thing, but I am a bit skeptical about the proposed choices. XStream is not an option as it adds further dependencies. JAXB could do the job, but this is an API that can bite you hard at times.

If you really want to go this way then I suggest that you try to develop a proposal in a dedicated Git branch, preferably pushed to your GitHub clone. We can then easily discuss with the community on pull requests.

What do you think?

Comment by Julien Ponge [ 14/Mar/12 ]

I forgot to specify that the JDK 6+ come with a pull parser, which is easier to handle than SAX / DOM.

Comment by Rene Krell [ 14/Mar/12 ]

Of course, JAXB is a sign of the times. I have also been gone through the evolution from JRE 1.1. I didn't mean IXlElement is bad, it's just not up to time, and compared for instance to our business solutions hard to handle. And it was worth to mention together with the discussion about consolidating variables, where we discussed XML syntax changes.
This should be done completely separately. For IzPack this would be currently more a destabilization than vice-versa
There are many small issues which are more important at the moment towards a 5.0 release. Maybe something for 6.0 or 5.1

Comment by Rene Krell [ 15/Mar/12 ]

Regarding XStream: I could even imagine dividing XML parsing into compiler and installer.
From my point of view, on the compiler side, there can be as much dependencies as necessary in favour of a transparent code base. On the other hand, on the installer side there is no good reason for using an alternative to JAXB to make the installer as small as possible.

But JAXB seems not to be that bad. I would divide the code in clear XML data mapping objects and functionality using them. The data mapping objects could be serialized in a proper way and added to the installer, even as XML. This way the way JAXB offers XML handling without programatically changing the serialization behavior is sufficient.

Comment by Julien Ponge [ 15/Mar/12 ]

My take is that if you are willing to explore this path then a branch on your github is the way to go

Good luck, it could be interesting to successfully perform those changes with no overweight on the installers!

Comment by Daniel Abson [ 04/Apr/12 ]

There's some XStream parsing in the master git branch (see IZPACK-791). Was that supposed to be committed to the master repo?

Comment by Rene Krell [ 04/Apr/12 ]

This is just a recommendation, there hasn't been done anything with this officially, as far as I know.





[IZPACK-763] Make including of part of the Maven properties as IzPack info header optional Created: 05/Mar/12  Updated: 05/Mar/12  Resolved: 05/Mar/12

Status: Resolved
Project: IzPack
Component/s: Maven plugin
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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, there are automatically included project.url and the developer list from Maven as IzPack info header. This is a nice feature, but should not be enabled by default. The installers might not want to show a list of dozens of developers, especially in commercial products, where programemrs are employees.
The Maven properties, which are in scope of development, might differ from header information presented to the user in the installer.

The following Maven IzPack Plugin configuration options should be added to enable this feature:

  • autoIncludeDevelopers
  • autoIncludeUrl


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

For using auto-properties from Maven, configure The IzPack Maven plugin accordingly:

<configuration>
    ...
    <autoIncludeUrl>true</autoIncludeUrl>
    <autoIncludeDevelopers>true</autoIncludeDevelopers></configuration>




[IZPACK-762] All system properties are displayed on the console Created: 05/Mar/12  Updated: 05/Mar/12

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

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

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

 Description   

I am using izpack 4.3.5 .While running installer though command prompt after <panel classname="packpanel"> is executed ,immediately on command prompt so many system properties visible .but i dont want to show that variables on commandprompt .

Can anyone please help me as soon as possible






[IZPACK-761] Data validators with implicit fully qualified classname not creatable Created: 02/Mar/12  Updated: 02/Mar/12  Resolved: 02/Mar/12

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

Type: Bug 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

Number of attachments : 0

 Description   

There is a bug in DataValidatorFactory:

            try
            {
                validator = (DataValidator) Class.forName(className).newInstance();
                try
                {
                    // try fully qualified class name
                    validator = (DataValidator) Class.forName(className).newInstance();
                }
                catch (ClassNotFoundException e)
                {
                    validator = (DataValidator) Class.forName(
                            "com.izforge.izpack.installer.validator." + className).newInstance();
                }
            }
            ...
            catch (ClassNotFoundException e)
            {
                e.printStackTrace();
            }

The first instantiation try must be removed, otherwise there cannot be instantiated validators in the default package.



 Comments   
Comment by Rene Krell [ 02/Mar/12 ]

Data validators need to be documented





[IZPACK-760] Add a data validator checking conditions on each panel change - ConditionValidator Created: 02/Mar/12  Updated: 02/Mar/12  Resolved: 02/Mar/12

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

Type: New Feature 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   

I had this kind of validator already in some self-made branch of IzPack 4.3, now reintroducing this built-in validator in 5.0.



 Comments   
Comment by Rene Krell [ 02/Mar/12 ]

Documentation in progress





[IZPACK-759] Publisher size and version info missing from Programs and Features on Windows 7 Created: 01/Mar/12  Updated: 01/Mar/12

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

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

Windows 7 32-bit


Number of attachments : 0

 Description   

Seen with 4.3.1, may also affect other versions.






[IZPACK-758] CLONE - shortcuts are created when i run the intstaller on linux .but when i click on the uninstaller shortcut it is not working.please help me Created: 01/Mar/12  Updated: 01/Mar/12

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

Type: Test Priority: Major
Reporter: Nagaraju b 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 am using izpack -4.3.5 .When i run installer shortcuts are created in linux .but when we choose a shortcut is not working. Please help me



 Comments   
Comment by Nagaraju b [ 01/Mar/12 ]

shortcuts are created when i run the intstaller on linux .but when i click on the uninstaller shortcut it is not working.please help me

Comment by Nagaraju b [ 01/Mar/12 ]

shortcuts are created when i run the intstaller on linux .but when i click on the uninstaller shortcut it is not working.please help me





[IZPACK-757] Writing installer fails during serializing "ref" conditions - NotSerializableException: com.izforge.izpack.merge.resolve.ClassPathCrawler Created: 29/Feb/12  Updated: 02/Mar/12  Resolved: 02/Mar/12

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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Writing the final installer fails on serializing reference conditions. This happens as soon as there is added the entry "rules" which is a Map<String, Condition>. ReferenceCondition must get in ClassPathCrawler, which is currently not serializable.

Stacktrace:

java.io.NotSerializableException: com.izforge.izpack.merge.resolve.ClassPathCrawler
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
        at java.util.HashSet.writeObject(HashSet.java:267)
        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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:940)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
        at java.util.HashMap.writeObject(HashMap.java:1001)
        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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:940)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
        at com.izforge.izpack.compiler.packager.impl.Packager.writeInstallerObject(Packager.java:176)


 Comments   
Comment by Rene Krell [ 02/Mar/12 ]

Refactoried condition handling and tests





[IZPACK-756] shortcuts are created in linux .but when we choose a shortcut is not working Created: 29/Feb/12  Updated: 29/Feb/12

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

Type: Test Priority: Major
Reporter: Nagaraju b Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

 Description   

I am using izpack -4.3.5 .When i run installer shortcuts are created in linux .but when we choose a shortcut is not working. Please help me






[IZPACK-755] Compiler exception thrown if new PackFile equals the installation files base directory Created: 29/Feb/12  Updated: 02/Mar/12  Resolved: 02/Mar/12

Status: Resolved
Project: IzPack
Component/s: None
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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

During compilation, when processing filesets in install.xml, for example:

  <packs>
    <pack name="App Core" required="yes" id="core.package">
      <description>The core files required for this application</description>
      <fileset dir="@{staging.dir.app}" targetdir="${INSTALL_PATH}" override="true">
        <exclude name="*wrapper.conf"/>
        <exclude name="conf/*.properties"/>
        <exclude name="conf/*.xml"/>
      </fileset>
      <fileset dir="@{staging.dir.app}" targetdir="${INSTALL_PATH}" override="true" overrideRenameTo="*.configbak">
        <include name="*wrapper.conf"/>
        <include name="conf/*.properties"/>
        <include name="conf/*.xml"/>
      </fileset>
      ...

I get an exception of the following kind:

java.lang.StringIndexOutOfBoundsException: String index out of range: -1
        at java.lang.String.substring(String.java:1937)
        at java.lang.String.substring(String.java:1904)
        at com.izforge.izpack.api.data.PackFile.computeRelativePathFrom(PackFile.java:221)
        at com.izforge.izpack.api.data.PackFile.<init>(PackFile.java:201)
        at com.izforge.izpack.data.PackInfo.addFile(PackInfo.java:242)
        at com.izforge.izpack.compiler.CompilerConfig.processFileSetChildren(CompilerConfig.java:895)
        at com.izforge.izpack.compiler.CompilerConfig.addPacksSingle(CompilerConfig.java:759)
        at com.izforge.izpack.compiler.CompilerConfig.addPacks(CompilerConfig.java:651)
        at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:299)
        at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:95)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
        at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
        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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)





[IZPACK-754] Make UserInputPanel [in CLI] display international text Created: 28/Feb/12  Updated: 28/Feb/12

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

Type: Improvement Priority: Major
Reporter: Dustin Kut Moy Cheung 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   

Currently UserInputPanel [CLI] reads from UserInputSpec to get strings [txt] it needs to display.

In the UserInputPanel [GUI] we can omit the text and simply give an id; that id is defined in the respective langpacks.

For example:

<field type="password" variable="adminPassword">
<spec>
<pwd id="username.password.text" size="16" />
<pwd id="username.password.re.text" size="16" />
</spec>
...
</field>

And in CustomLangpack.xml_eng:

<str id="username.password.text" txt="Enter the admin password:"/>
<str id="username.password.re.text" txt="Re-Enter the admin password:"/>

Doing so is easier for internationalization of UserInputSpec. Currently the CLI version is broken and does not behave as expected. If the txt is omited, the UserInputPanel [CLI] will just output "null" and completely ignore the "id" part.



 Comments   
Comment by Dustin Kut Moy Cheung [ 28/Feb/12 ]

Waiting for https://github.com/jponge/izpack/pull/11 to be merged before submitting my proposed patch





[IZPACK-753] Uninstaller not launch itself with administrator permissions Created: 28/Feb/12  Updated: 28/Feb/12

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

Type: Bug Priority: Major
Reporter: Lukasz Padlo 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   

My configuration:
<run-privileged condition="izpack.windowsinstall.xp|izpack.windowsinstall.vista|izpack.windowsinstall.7"/>

I change standalone-compiler version from 4.3.4 to 4.3.5.
izpack-maven-plugin version: 1.0-alpha-5

When i run installation, it's prompt for administration permission but uninstaller doesn't, and when uninstalling is complete, nothing is removed. Whether the installation was successful or not.
Documentation does not say how to change the configuration in 4.3.5 version.






[IZPACK-752] JUnit URL/URI Created: 28/Feb/12  Updated: 24/Mar/12  Resolved: 24/Mar/12

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

Type: Bug Priority: Minor
Reporter: Guillaume Chauvet Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: URL, junit
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP 32 bits / Netbeans 7.0.1


Attachments: Text File izpack-5.0.0-gchauvet-URI-JUnit.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Unit tests fail if project path contains some spaces (ex: "My Documents" folder).



 Comments   
Comment by Julien Ponge [ 24/Mar/12 ]

Thanks!





[IZPACK-751] Infinite loop in console installer Created: 28/Feb/12  Updated: 27/Mar/12

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

Type: Bug Priority: Major
Reporter: Stefan Engel 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   

If you use an UserInputPanel which has a field with type="password" and a PasswordEqualityValidator, an infinite loop can be produced in the console installer.

In most cases, you have two password fields and both passwords must match. When the user is prompted to retype the password, the input from the first password field is the default value. This does not make much sense since the user can type in the password once and just hit return in the second field to pass the equality validation.

You can even cause an infinite loop, if you leave the first password field empty and enter something in the second password field. The input will be cached, and the installer requires the user to input nothing in the second field. However, if you type nothing, the cached default value will be filled in, and that does not equal the (empty) first password field, making it impossible to pass the equality validation.

To solve this problem, password fields in console mode should not cache the user input.



 Comments   
Comment by Dustin Kut Moy Cheung [ 16/Mar/12 ]

I commited something concerning passwords in a pull request: https://github.com/jponge/izpack/pull/11

[ See commit: 14dbaed]

If you are compiling from src, can you verify if that commit fixes your issues? I'm not really sure since this commit was intended to mask password. When I tried it, it seemed to have fixed it.

Comment by Stefan Engel [ 20/Mar/12 ]

I just compiled from src and the commit does indeed fix the issues I described. The user can no longer avoid the password validation by just hitting enter. It is also not longer possible to cause an infinite loop.

Comment by Julien Ponge [ 20/Mar/12 ]

Good to see this!

Comment by Dustin Kut Moy Cheung [ 27/Mar/12 ]

Actually it might have been Sergiy Shyrkov commit for IzPack 4.3.5 that might have fixed it.

I was trying to port Sergiy's changes to IzPack 5 and... it's confusing and messy to do that.





[IZPACK-750] I am using Izpack4.3.5, all system properties are displayed on the console Created: 27/Feb/12  Updated: 27/Feb/12

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

Type: Improvement Priority: Trivial
Reporter: Nagaraju b 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 am using izpack4.3.5 ,while installpanel is running all packs are copying into respective destination at the same time all system properties are dislayed on the command prompt when i run the install.jar from command line. I dont want to display the system properties on command prompt






[IZPACK-749] Access to Maven properties in IzPack compilation phase Created: 27/Feb/12  Updated: 27/Feb/12  Resolved: 27/Feb/12

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

Type: New Feature 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 IzPack 4.x, when using the IzPack Ant task for calling the standalone compiler, there could be directly accessed the Ant project properties in the install.xml using constructs like @

{ant.project.property.name}

. This has been achieved by adding implicit properties to the PropertyManager instance. Replacement of these properties has been taken place in attribute values or text contents in the install.xml before all other preprocessing tasks.

The similar behavior should work in the IzPack Maven plugin beginning from 5.0. Maven project properties should be added to the PropertyManager instance and substituted when found in constructs like @

{maven.project.property.name}

in install.xml.

Example:

POM:

  <properties>
    <!-- Installer variables -->
    <info.appName>My Application</info.appName>
    <info.appsubpath>my-company/my-app</info.appsubpath>
    <info.url>http://www.my-company.com</info.url>
    <info.company.name>My Company Name</info.company.name>
    <info.company.email>info@my-company.com</info.company.email>
  </properties>

install.xml:

  <info>
    <appname>@{info.appName}</appname>
    <appsubpath>@{info.appsubpath}</appsubpath>
    <appversion>@{project.version}</appversion>
    <authors>
      <author name="@{info.company.name}" email="@{info.company.email}"/>
    </authors>
    <url>@{info.url}</url>
    ...
  </info>


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

Will be documented along with the outstanding documentation of the <properties> element in the installer description.





[IZPACK-748] Console installation should be disabled if there is no console implementation of a panel Created: 27/Feb/12  Updated: 01/Apr/12  Resolved: 01/Apr/12

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

Type: Bug Priority: Major
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently the console installer skips panels if there is no corresponding console implementation of the panel.
This can mean that console installers are not functionally equivalent to the GUI installer. E.g. there is no ShortcutPanelConsoleHelper, nor is there any CheckedHelloPanelConsoleHelper.

If there is no ConsoleHelper equivalent of a panel, console installation should be disabled.



 Comments   
Comment by Tim Anderson [ 01/Apr/12 ]

Added com.izforge.izpack.integration.console.ConsoleInstallationTest.testUnsupportedInstaller() to verify fix





[IZPACK-747] I am using Izpack4.3.5, in shortcutspec.xml <createForPack="core"> is not working Created: 24/Feb/12  Updated: 24/Feb/12

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

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

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

 Description   

In shortcutspec.xml i use <createForPack="core">.Actully i want to create shortcut for only "core" package ,when it is install but it ( <createForPack="core"> )is created shortcut for always .Please help






[IZPACK-746] Izpack write uninstaller in regedit but uninstaller write="no" Created: 22/Feb/12  Updated: 24/Mar/12

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

Type: Bug Priority: Minor
Reporter: Guillaume Chauvet Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: disable, regedit, uninstaller, write
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP


Attachments: Text File izpack-gchauvet-uninstaller.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Izpack register uninstaller in regedit in despite of attribute <uninstaller write="no" />
I fix it but I think it's an hack...



 Comments   
Comment by Julien Ponge [ 24/Mar/12 ]

I can't apply the patch...





[IZPACK-745] Conditions without an "id" attribute cause NPE during installer creation Created: 17/Feb/12  Updated: 21/Feb/12  Resolved: 21/Feb/12

Status: Resolved
Project: IzPack
Component/s: Compiler
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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Testcase included: yes
Number of attachments : 0

 Description   

If there is a condition declaration in install.xml without an "id" attribute, for example:

<conditions>
  <condition type="and" id="show.db.setup.panel">
    <condition type="ref" refid="mode.db"/>
    <condition type="ref" refid="!mode.mtn"/>
  </condition>
</conditions>

this leads to the following NPE:

[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] com.izforge.izpack.api.exception.IzPackException: com.izforge.izpack.api.exception.IzPackException: java.lang.NullPointerException: componentKey
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.AssertionError: com.izforge.izpack.api.exception.IzPackException: com.izforge.izpack.api.exception.IzPackException: java.lang.NullPointerException: componentKey
        at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:94)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
        at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
        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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: com.izforge.izpack.api.exception.IzPackException: com.izforge.izpack.api.exception.IzPackException: java.lang.NullPointerException: componentKey
        at com.izforge.izpack.core.rules.RulesEngineImpl.instanciateCondition(RulesEngineImpl.java:201)
        at com.izforge.izpack.compiler.CompilerConfig.addConditions(CompilerConfig.java:2360)
        at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:291)
        at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:90)
        ... 19 more
Caused by: com.izforge.izpack.api.exception.IzPackException: java.lang.NullPointerException: componentKey
        at com.izforge.izpack.core.rules.RulesEngineImpl.instanciateCondition(RulesEngineImpl.java:201)
        at com.izforge.izpack.core.rules.logic.AndCondition.readFromXML(AndCondition.java:67)
        at com.izforge.izpack.core.rules.RulesEngineImpl.instanciateCondition(RulesEngineImpl.java:192)
        ... 22 more
Caused by: java.lang.NullPointerException: componentKey
        at org.picocontainer.adapters.AbstractAdapter.getComponentKey(AbstractAdapter.java:76)
        at org.picocontainer.behaviors.AbstractBehavior.getComponentKey(AbstractBehavior.java:52)
        at org.picocontainer.DefaultPicoContainer.addAdapterInternal(DefaultPicoContainer.java:436)
        at org.picocontainer.DefaultPicoContainer.addComponent(DefaultPicoContainer.java:548)
        at org.picocontainer.DefaultPicoContainer.addComponent(DefaultPicoContainer.java:518)
        at com.izforge.izpack.core.container.AbstractContainer.addComponent(AbstractContainer.java:35)
        at com.izforge.izpack.core.rules.RulesEngineImpl.instanciateCondition(RulesEngineImpl.java:190)
        ... 24 more


 Comments   
Comment by Rene Krell [ 21/Feb/12 ]
  • Refactored broken reference condition handling
  • Conditions of any type are no longer required to have an "id" for declaration
  • Improved error reporting during reading conditions when compiling




[IZPACK-744] eng.xml - capital letter in between Created: 17/Feb/12  Updated: 12/Jul/12  Resolved: 12/Jul/12

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.2, 4.3.3, 4.3.4, 4.3.5
Fix Version/s: 4.3.6, 5.0

Type: Bug Priority: Trivial
Reporter: cheah wei keng Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP sp3, English(en-us)


Attachments: Text File eng.xml.patch     PNG File test.png    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

Used to be:
<str id="PacksPanel.space" txt="Total space Required: "/>

Expected:
<str id="PacksPanel.space" txt="Total space required: "/>



 Comments   
Comment by Julien Ponge [ 24/Mar/12 ]

Done, thanks!

Comment by Tim Anderson [ 11/Jul/12 ]

Change needs to be applied to 5.0

Comment by Tim Anderson [ 11/Jul/12 ]

Fix for 5.0: https://github.com/izpack/izpack/pull/18

Comment by Tim Anderson [ 12/Jul/12 ]

Fix applied to 5.0





[IZPACK-743] Uninstall data written on quit from CheckedHelloPanel Created: 16/Feb/12  Updated: 13/Jun/12  Resolved: 13/Jun/12

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

Type: Bug Priority: Major
Reporter: Tim Anderson Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If CheckedHelloPanel determines there is an existing installation, and the user elects not to install twice, the uninstaller jar is written on quit.
This overwrites any existing uninstaller jar, losing the uninstall information.
This is due to:

  1. CheckedHelloPanel.panelActivate() disabling the next button, when there is an existing installation; and
  2. InstallerFrame.exit() thinking that installation is completed as the next button is disabled:
        public void exit()
        {
            // FIXME !!! Reboot handling
            if (installdata.isCanClose()
                    || ((!nextButton.isVisible() || !nextButton.isEnabled())
                    && (!prevButton.isVisible() || !prevButton.isEnabled())))
            {
                if (!writeUninstallData())
                {
                    // TODO - for now just shut down. Alternative approaches include:
                    // . retry
                    // . revert installation - which is what wipeAborted attempts to do, but fails to handle shortcuts and
                    //                         registry changes
                }
                shutdown();
            }
            else
            {
                // The installation is not over
                confirmExit();
            }
    

If quit is invoked from CheckedHelloPanel, then no uninstallation info should be written.



 Comments   
Comment by Daniel Abson [ 12/Jun/12 ]

Submitted pull request via GitHub with a solution.

Comment by Julien Ponge [ 13/Jun/12 ]

Merged pull request.





[IZPACK-742] Evaluate JNA as a replacement for JNI Created: 14/Feb/12  Updated: 06/Mar/12

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

Type: Wish 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   

For using native shared libraries in the installer, there is an interesting replacement for JNI:
Java Native Access (JNA), see https://github.com/twall/jna#readme.
This framework is stable, uses reflection and does not require any native code compiled for the target platform.

Advantages:

  • no native code, no compilers (Visual C, gcc & Co.) needed anymore
  • safer to implement, less crashes expected
  • 100% Java coding
  • easy deployment

Disadvantage:

  • takes some space, not sure whether it saves at least as much space as the packed shared libraries require.


 Comments   
Comment by Julien Ponge [ 15/Feb/12 ]

This sounds interesting indeed.

Comment by Rene Krell [ 15/Feb/12 ]

I made already some tests regarding the implementations of using the Windows Setup APi by JNA. This is very stable, I've just on open issue with handling a C callback function.
For IzPack purposes this could be useful. Maybe at the beginning JNA takes some KBytes more space than the libraries to be included in the installer, but each time you need to access native libraries you'll save space, later.
Something for the (nearer) future, nothing for IzPack 5.0, IMHO, currently there are more important issues to get it stable, I guess.

Comment by Tim Anderson [ 16/Feb/12 ]

JNA has LGPL licensing, according to https://github.com/twall/jna#readme although it also states that "Alternative license arrangements are negotiable."

Comment by Rene Krell [ 16/Feb/12 ]

Yes, you are right, it is declared to be licensed as "LGPL, version 2.1 or later", which is not so clear to me. Is it LGPL 2.1 or is it a later LGPL version? Anyway, in the source code can be actually found LGPL 2.1 and even LGPL 3 is less permissive, as explained in http://www.dwheeler.com/essays/floss-license-slide.html. From my understanding, using LGPL in IzPack would result in "the combined result effectively has the license of LGPL v3, possibly with additions from Apache License 2.0" in our case, loosing permissions is of course not good. Maybe there is someone who knows more details, because we wouldn't use the JNA source code, but just linking it. Does someone know more about this?

Comment by Julien Ponge [ 16/Feb/12 ]

LGPL v2.1 or later means that you have the freedom to use JNA under either the v2.1 or any subsequent version.

The LGPL is not intrusive, so we may combine ASL code (IzPack) with it. The only requirement is that JNA stays LGPL'd, but it does not force IzPack to be LGPL'd. You may mix LGPL + proprietary code if you like.

BTW the LGPL is ok at Codehaus, while the GPL and AGPL are not, see http://www.codehaus.org/customs/licenses.html





[IZPACK-741] FileExecutor executes each command twice Created: 14/Feb/12  Updated: 14/Feb/12  Resolved: 14/Feb/12

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

Type: Bug Priority: Major
Reporter: Tim Anderson Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

FileExecutor is currently executing each command twice, via the following code in executeCommand():

            if (dir != null)
            {
                if (dir.matches("^.*[\\\\/]+[\\.]+[\\\\/]+.*$"))
                {
                    dir = new File(dir).getCanonicalPath();
                }
                process = Runtime.getRuntime().exec(params, null, new File(dir));
            }
            else
            {
                process = Runtime.getRuntime().exec(params);
            }

            process = Runtime.getRuntime().exec(params);

The last line shouldn't be there.



 Comments   
Comment by Tim Anderson [ 14/Feb/12 ]

Updated ExecutableFileTest to verify the fix