[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





[IZPACK-740] TreePacksPanel java.lang.NoClassDefFoundError: com/izforge/izpack/panels/packs/PacksPanelInterface Created: 12/Feb/12  Updated: 17/Aug/12  Resolved: 17/Aug/12

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

Type: Bug Priority: Minor
Reporter: Christoph Panwinkler Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: exception, plugin
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, Java 1.6.0_26, Maven 3.0.4


Attachments: XML File install.xml     XML File pom.xml    
Number of attachments : 2

 Description   

izpack-maven-plugin does not pack depending classes for TreePacksPanel (com/izforge/izpack/panels/packs package does not get packed).
Using PacksPanel instead of TreePacksPanel works.

Following exception is thrown whenever I start the installer by java -jar target/test-1-0-SNAPSHOT-installer.jar

Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com/izforge/izpack/panels/packs/PacksPanelInterface
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
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)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at com.izforge.izpack.merge.resolve.ClassPathCrawler.searchClassInClassPath(ClassPathCrawler.java:120)
at com.izforge.izpack.installer.manager.PanelManager.loadPanelsInContainer(PanelManager.java:72)
at com.izforge.izpack.installer.base.InstallerController.preloadInstaller(InstallerController.java:30)
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:50)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
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: com.izforge.izpack.panels.packs.PacksPanelInterface
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)
... 32 more



 Comments   
Comment by Christoph Panwinkler [ 12/Feb/12 ]

I am using izpack-version 5.0.0-beta10

Comment by Tim Anderson [ 14/Aug/12 ]

Fix for this is available at https://github.com/izpack/izpack/pull/55





[IZPACK-739] Uninstaller on Windows uses application target Created: 09/Feb/12  Updated: 01/May/13

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

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

Windows


Number of attachments : 0

 Description   

I have windows shortcut specification with product and uninstaller that works in 4.3.2, but in 4.3.5 the Uninstaller target (set to javaw) uses application $INSTALL_PATH/myapplication.exe instead of javaw in Start menu shortcut. Here is the shortcut spec:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<shortcuts>
<skipIfNotSupported/>
<programGroup defaultName="MyApplication" location="startMenu"/>
<shortcut
name="MyApplication 4.0"
target="$INSTALL_PATH/myapplication.exe"
workingDirectory="$INSTALL_PATH"
description="MyApplication 4.0 Client"
type="Application"
iconFile="$INSTALL_PATH\img\MyApplication_new.ico"
iconIndex="0"
initialState="noShow"
programGroup="yes"
desktop="yes"
applications="no"
startMenu="yes"
startup="no">

<createForPack name="MyApplication Client"/>
</shortcut>

<shortcut
name="Globalyzer Uninstaller"
programGroup="yes"
desktop="no"
applications="no"
startMenu="yes"
startup="no"
target="javaw"
commandLine="-jar "$INSTALL_PATH/Uninstaller/uninstaller.jar""
initialState="noShow"
iconFile="$INSTALL_PATH\img\MyApplication_new.ico"
iconIndex="0"
workingDirectory="$INSTALL_PATH"
type="Application"
description="MyApplication uninstaller">

<createForPack name="MyApplication Client"/>
</shortcut>

</shortcuts>






[IZPACK-738] Uninstaller is always written regardless of write attribute or condition Created: 07/Feb/12  Updated: 17/May/12  Resolved: 16/Mar/12

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

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

5.0.0-beta9; java version "1.6.0_16"; Windows XP
5.0.0-beta10; java version "1.6.0_31"; Linux


Number of attachments : 0

 Description   

Uninstaller is always written regardless of write attribute or condition.

Source of the problem is in UninstallDataWriter.isUninstallShouldBeWriten
The write attribute is not checked at all.
The condition is not evaluated.

How to reproduce:
install.xml snippet
<installation version="1.0">
<info>
<uninstaller write="no" />
...

Possible workaround is to use an empty condition:
<uninstaller condition="" />



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

This is still the case even in the latest git snapshot, increased importance.

Comment by Jens Meissner [ 15/Mar/12 ]

But at least using a condition works now:
<info>
<uninstaller condition="WriteUninstallerCondition" />
</info>
<conditions>
<condition type="variable" id="WriteUninstallerCondition">
<name>WriteUninstallerVariable</name>
<value>true</value> <!-- Check for true -->
</condition>
</conditions>
<variables>
<variable name="WriteUninstallerVariable" value="false" />
</variables>

Comment by Rene Krell [ 16/Mar/12 ]

Should work now in the latest git 5.0.0-beta11-SNAPSHOT, give it a try.
To disable uninstallers the uninstaller path in Info is
set null (has an initial default after instantiation).
Added also a console installer test for that use case with <uninstaller write="no"/>.

Comment by John Mitchell [ 17/May/12 ]

Hopefully this will help someone else, but we are using 5.0.0-beta10 and adding the following fixes the problem for us.
<info>
<uninstaller write="null" />
</info>





[IZPACK-737] Console installer does not perform any action because helpers are not found Created: 07/Feb/12  Updated: 18/Aug/12  Resolved: 18/Aug/12

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

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

5.0.0-beta9; java version "1.6.0_16"; Windows XP


Number of attachments : 0

 Description   

Console installer does not perform any action because helpers are not found.
Therefore the process finishes immediately without any action being taken.

Source of the problem is in ConsoleInstaller.iterateAndPerformAction
It expects the helpers to be in the package com.izforge.izpack.panels, e.g. com.izforge.izpack.panels.HelloPanelConsoleHelper
Actually the helpers are in subpackages, e.g. com.izforge.izpack.panels.hello.HelloPanelConsoleHelper
All not found classes are skipped.

How to reproduce:
java -jar installer.jar -options C:/myinstaller.properties (As described http://docs.codehaus.org/display/IZPACK/Unattended+Installations)



 Comments   
Comment by Tim Anderson [ 18/Aug/12 ]

Console installer now fails if there is no console implementation of a panel





[IZPACK-736] Automated installer start fails with NullPointerException Created: 07/Feb/12  Updated: 07/Feb/12

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

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

5.0.0-beta9; java version "1.6.0_16"; Windows XP


Number of attachments : 0

 Description   

Automated installer start fails with NullPointerException.

Source of the problem may be in InstallerContainer.fillContainer
Commented line 47: // .addAdapter(new ProviderAdapter(new AutomatedInstallDataProvider()))

How to reproduce:
1. Create installer with FinishPanel at the end
2. In FinishPanel create automated install script: auto-install.xml
3. Run automated installer: java -jar installer.jar auto-install.xml (As described http://docs.codehaus.org/display/IZPACK/Unattended+Installations)

Stack trace:

  • ERROR -
    java.lang.NullPointerException
    java.lang.NullPointerException
    at com.izforge.izpack.installer.automation.AutomatedInstaller.init(AutomatedInstaller.java:117)
    at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:178)
    at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:149)
    at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:62)





[IZPACK-735] debug and trace attributes should be added to ant task Created: 07/Feb/12  Updated: 07/Feb/12

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

Type: Bug Priority: Major
Reporter: Mark McKay 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 moment, the 'debug' and 'trace' flags which can be passed to the JVM on the command line appear to be missing from the ant task.



 Comments   
Comment by Mark McKay [ 07/Feb/12 ]

I might be mistaken here. From reading the below thread, I was thinking that 'debug' and 'trace' were flags you passed to the installer compiler. If this is not the case, please ignore the above bug.

http://old.nabble.com/Dynamic-Variable-ignored-td33092109.html#a33276814





[IZPACK-734] In userinputspec.xml only first validator is woking for text field If i add one more validator to the same text field both not working at a time .Only first one works Created: 06/Feb/12  Updated: 06/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 userinputspec.xml    
Number of attachments : 1

 Description   

In below only first validator (com.izforge.izpack.util.ServerInstanceValidator) is working

<field type="text" align="left" variable="server.instance">
<spec txt="Jboss server instance #: " size="15" set="default" id="server"/>
<validator class="com.izforge.izpack.util.ServerInstanceValidator" txt="You Are Provide Wrong Server Instance" id="serverInstance" />
<validator class="com.izforge.izpack.util.NotEmptyValidator" txt="Server Instance is required field." id="serverInstance" />
</field>






[IZPACK-733] In userinputspec.xml only first validator is woking for text field If i add one more validator to the same text field both not working at a time .Only first one works Created: 06/Feb/12  Updated: 06/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 userinputspec.xml    
Number of attachments : 1

 Description   

I am using Izpack-4.3.5. I made one custom validator .Then i configure this in userinputspec.xml like
<field type="text" align="left" variable="server.instance">
<spec txt="Jboss server instance #: " size="15" set="default" id="server"/>
<validator class="com.izforge.izpack.util.ServerInstanceValidator" txt="You Are Provide Wrong Server Instance" id="serverInstance" />
<validator class="com.izforge.izpack.util.NotEmptyValidator" txt="Server Instance is required field." id="serverInstance" />
</field>

But it validates only the first validator but not second validator .Please help me






[IZPACK-732] userinputspec.xml Created: 06/Feb/12  Updated: 06/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 userinputspec.xml    
Number of attachments : 1

 Description   

I am using Izpack-4.3.5. I made one custom validator .Then i configure this in userinputspec.xml like
<field type="text" align="left" variable="server.instance">
<spec txt="Jboss server instance #: " size="15" set="default" id="server"/>
<validator class="com.izforge.izpack.util.ServerInstanceValidator" txt="You Are Provide Wrong Server Instance" id="serverInstance" />
<validator class="com.izforge.izpack.util.NotEmptyValidator" txt="Server Instance is required field." id="serverInstance" />
</field>

But it validates only the first validator but not second validator .Please help me






[IZPACK-731] Variable substitutor doesn't work in all cases Created: 02/Feb/12  Updated: 02/Feb/12

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

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

Build on Win 7 64 Bit, Maven 3.0.3.
tested on Win 7 32 Bit and Ubuntu 10.04 64 Bit


Number of attachments : 0

 Description   

In the custom langpack files some of the variables are substituted and others are not.

<str id="installer.reversetitle" txt="$APP_NAME $APP_VER - IzPack Wizard "/> <--- Those are replaced
<str id="installer.madewith" txt="$APP_NAME "/> <--- this one not
<str id="OurWelcomePanel.welcometext" txt="Willkommen bei der Installation von $APP_NAME." /> <--- this one neither






[IZPACK-730] I am using Izpack4.3.5, in this uninstaller title is hardcoded how i will be change the title Created: 01/Feb/12  Updated: 27/Feb/12  Resolved: 24/Feb/12

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

Type: Improvement Priority: Critical
Reporter: Nagaraju b Assignee: Julien Ponge
Resolution: Not A Bug Votes: 0
Labels: designer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File UninstallerFrame.class    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

I am using Izpack4.3.5, in this uninstaller title is hardcoded how i will be change the title



 Comments   
Comment by Nagaraju b [ 24/Feb/12 ]

please help me .No body is seeing my request still now .Is this site using anyone or not

Comment by Julien Ponge [ 24/Feb/12 ]

This is not a bug. You may change the title by modifying the source code if you like.

My words may sound rude, but technically we do not owe you any support by the way. Nobody gets paid for working on IzPack, so please do not be aggressive with us because nobody wanted to handle your request.

Thank you very much.

Comment by Nagaraju b [ 27/Feb/12 ]

Sorry sir , I changed the sourcecode for title in UnInstallerFrame class .But izpack overrided my UnInstallerFrame class at the time of packs are installing .So title not changing.

Please help me

Comment by Rene Krell [ 27/Feb/12 ]

This issue might be not nice, but a bad window's title in the uninstaller isn't neither a critical bug nor has a priority about other outstanding issues to be solved. If you have available the whole source code, you can change it in a manner which works and provide a patch, avoiding the override you mentioned. I'm sure a ready solution will be processed earlier than someone else cares about your special problem completely right now. How about that? There is no professional in-time support here. You're issue can be done by someone else as soon as there is time to do it.

Furthermore, if you'd like to reopen this, send some more information about what you tried, some .java file or your install.xml or whatever could be helpful to analyze.





[IZPACK-729] ExecutableFile missing from uninstaller Created: 28/Jan/12  Updated: 01/Apr/12  Resolved: 01/Apr/12

Status: Resolved
Project: IzPack
Component/s: Uninstaller
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 com.izforge.izpack.data.ExecutableFile class is not being merged into uninstallers.



 Comments   
Comment by Tim Anderson [ 01/Apr/12 ]

Added com.izforge.izpack.integration.ExecutableFileTest to verify fix





[IZPACK-728] Cyclic dependency between izpack-util and izpack-installer modules Created: 28/Jan/12  Updated: 13/Dec/12  Resolved: 01/Apr/12

Status: Resolved
Project: IzPack
Component/s: None
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 com.izforge.izpack.util.PrivilegedRunner class in izpack-util is dependent on two resources located in the izpack-installer module.
The izpack-installer module is dependent on the izpack-util module.
The two resources are:

  • /com/izforge/izpack/installer/elevate.js
  • /com/izforge/izpack/installer/run-with-privileges-on-osx

These should be moved to izpack-util



 Comments   
Comment by Tim Anderson [ 01/Apr/12 ]

Also added unit test com.izforge.izpack.util.PrivilegedRunnerTest





[IZPACK-727] Uninstaller doesn't elevate privileges on Windows 7 Created: 27/Jan/12  Updated: 28/Jan/12  Resolved: 28/Jan/12

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

Windows 7, jdk 1.6.0_25


Number of attachments : 0

 Description   

My application is installed under c:/Program Files/MyApp on Windows 7
I have administrator privileges, but cannot uninstall the application without elevating permissions.

The code in Uninstaller.isElevationNeeded() uses File.canWrite() to determine if the uninstaller can write to the install path. If it returns true, then it assumes that elevation is not needed.

For some reason, possibly related to the discussion in this bug, File.canWrite() returns true for both the install path and c:/Program Files. As a result, elevation does not occur and uninstall silently fails.






[IZPACK-726] Add support to debug uninstaller Created: 27/Jan/12  Updated: 27/Jan/12  Resolved: 27/Jan/12

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

To debug the uninstaller at present requires changing the SelfModifier class to uncomment the code:

// activate for debugging purposes.
//        command.add("-Xdebug");
//        int debugPort = 8000 + nextPhase;
//        command.add("-Xrunjdwp:transport=dt_socket,address=" + debugPort + ",server=y,suspend=y");

This enables debugging the two processes spawned by the uninstaller (i.e. for phase 2 and phase 3).
Typically you only want to debug phase 3.
Rather than modify the code, it would be nice to run:

java -Dself.mod.debugPort2=8002 -Dself.mod.debugPort3=8003 -jar uninstaller.jar

to enable debugging for phase2 and phase3.
These could be enabled individually to debug phase2 or phase3 e.g.:

java -Dself.mod.debugPort3=5005 -jar uninstaller.jar


 Comments   
Comment by Tim Anderson [ 27/Jan/12 ]

Changes documented at http://docs.codehaus.org/display/IZPACK/Debugging+Uninstallers





[IZPACK-725] Add TreePacksPanelConsoleHelper to Izpack 4.3.x Created: 26/Jan/12  Updated: 02/Aug/12  Resolved: 02/Aug/12

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

Type: New Feature Priority: Major
Reporter: Dustin Kut Moy Cheung Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Dustin Kut Moy Cheung [ 27/Mar/12 ]

Included with: https://github.com/jponge/izpack/pull/11

Comment by Tim Anderson [ 11/Jul/12 ]

Change needs to be applied to 5.0





[IZPACK-724] elevate.js missing from uninstaller Created: 26/Jan/12  Updated: 27/Jan/12  Resolved: 27/Jan/12

Status: Resolved
Project: IzPack
Component/s: Uninstaller
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 /com/izforge/izpack/installer/elevate.js script required to launch the uninstaller with elevated permissions on Vista/Windows 7 is not included in the uninstaller jar.






[IZPACK-723] UninstallDataWriter silently creates corrupt uninstaller.jar files on exception Created: 25/Jan/12  Updated: 26/Jan/12  Resolved: 26/Jan/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   

If a method invoked by UninstallDataWriter throws an exception, the jar file being written to is not flushed and closed.

Either a 0 length or partially written jar is left behind.
In the case of the latter, attempts to launch it give the error message:

Invalid or corrupt jarfile c:/Program Files/MyApp/Uninstaller/uninstaller.jar

If the write fails:

  • the uninstall jar should be removed
  • the GUI/console needs to notify the user that the uninstaller hasn't been written


 Comments   
Comment by Tim Anderson [ 26/Jan/12 ]

If the uninstall data cannot be written, it will be removed and an error dialog with the message "Failed to write uninstallation information." displayed.





[IZPACK-722] Add support for StartupWMClass entry in .desktop files Created: 16/Jan/12  Updated: 16/Jan/12

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

Type: New Feature Priority: Trivial
Reporter: Valentin Tablan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: wish
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Number of attachments : 0

 Description   

Modern Linux desktop environments (Gnome 3, Ubuntu Unity) use the WMClass property to associate windows with the owning application. Many Java-based applications have the problem where the windows created by the application are not associated with the shortcut used to start the application (so the dock contains multiple copies of the same icon).

This can be easily fixed by adding the correct StartupWMClass entry in the .desktop file created (see http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html). All Java applications get a WMClass value (the name of the main class used to start the parent application, where all '.' are replaced by '-'). Allowing the user to specify a value for StartupWMClass in the Unix-shortcuts.xml file would solve this.






[IZPACK-721] <info> section should be able to handle variable substitution Created: 12/Jan/12  Updated: 06/Feb/13

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

Type: New Feature Priority: Minor
Reporter: Mark McKay 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   

The <info> section of the IzPack install should be able to do variable substitution.






[IZPACK-720] Simple installation Created: 23/Dec/11  Updated: 23/Dec/11

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

Type: Improvement Priority: Major
Reporter: Tonio Barmadosa 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 been browsing the documentation, but it's pretty overwhelming to say the least!

It's very simple what I'd like to do!

1. Run an setup script (Install.java) that I wrote
2. Create shortcuts and check JRE version
3. Launch my app on system autostart
4. Specify the main class when the user clicks on the app icon.

That's it! I've spent about 4 hours going through the documentation about ProcessPancels, gui preferences, 150 pages of XML documentation. I don't need any of these. Is it possible to do the above 4 points with IzPack??

Thanks






[IZPACK-719] Tests in izpack-installer hang during local build on UNIX Created: 19/Dec/11  Updated: 27/Mar/13  Resolved: 19/Dec/11

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: maven
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Refreshing from origin/master and launching
mvn clean install
on a JDK 1.6.0_29 / Maven 2.2.1 (Linux x64) causes tests in module izpack-installer to hang.

Threaddump fo the main Maven process:

Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode):

"Thread-309" prio=10 tid=0x00007f1ca516c000 nid=0x75ba runnable [0x00007f1ca878a000]
   java.lang.Thread.State: RUNNABLE
        at java.io.FileInputStream.readBytes(Native Method)
        at java.io.FileInputStream.read(FileInputStream.java:220)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
        - locked <0x00000000f9a861b0> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:167)
        at java.io.BufferedReader.fill(BufferedReader.java:136)
        at java.io.BufferedReader.readLine(BufferedReader.java:299)
        - locked <0x00000000f9a861b0> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:362)
        at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:131)

"Thread-308" prio=10 tid=0x00007f1ca4287800 nid=0x75b8 runnable [0x00007f1ca8689000]
   java.lang.Thread.State: RUNNABLE
        at java.io.FileInputStream.readBytes(Native Method)
        at java.io.FileInputStream.read(FileInputStream.java:220)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
        - locked <0x00000000f9b79bc0> (a java.io.BufferedInputStream)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
        - locked <0x00000000f9a83678> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:167)
        at java.io.BufferedReader.fill(BufferedReader.java:136)
        at java.io.BufferedReader.readLine(BufferedReader.java:299)
        - locked <0x00000000f9a83678> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:362)
        at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:131)

"process reaper" daemon prio=10 tid=0x00007f1ca4197000 nid=0x75b6 runnable [0x00007f1ca8588000]
   java.lang.Thread.State: RUNNABLE
        at java.lang.UNIXProcess.waitForProcessExit(Native Method)
        at java.lang.UNIXProcess.access$900(UNIXProcess.java:20)
        at java.lang.UNIXProcess$1$1.run(UNIXProcess.java:132)

"pool-1-thread-5" prio=10 tid=0x00007f1ca43e4000 nid=0x72cd in Object.wait() [0x00007f1ca8923000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000e090d7d8> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
        at java.lang.Object.wait(Object.java:485)
        at edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
        - locked <0x00000000e090d7d8> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
        at java.lang.Thread.run(Thread.java:662)

"pool-1-thread-4" prio=10 tid=0x00007f1ca43c7800 nid=0x72cc in Object.wait() [0x00007f1ca8a24000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000e090d7d8> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
        at java.lang.Object.wait(Object.java:485)
        at edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
        - locked <0x00000000e090d7d8> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
        at java.lang.Thread.run(Thread.java:662)

"pool-1-thread-3" prio=10 tid=0x00007f1c64001000 nid=0x72cb in Object.wait() [0x00007f1ca8b2d000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000e090d7d8> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
        at java.lang.Object.wait(Object.java:485)
        at edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
        - locked <0x00000000e090d7d8> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
        at java.lang.Thread.run(Thread.java:662)

"pool-1-thread-2" prio=10 tid=0x00007f1ca422f800 nid=0x72ca in Object.wait() [0x00007f1ca8c2e000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000e090d7d8> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
        at java.lang.Object.wait(Object.java:485)
        at edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
        - locked <0x00000000e090d7d8> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
        at java.lang.Thread.run(Thread.java:662)

"pool-1-thread-1" prio=10 tid=0x00007f1ca41c4000 nid=0x72c9 in Object.wait() [0x00007f1ca8e5a000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000e090d7d8> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
        at java.lang.Object.wait(Object.java:485)
        at edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:316)
        - locked <0x00000000e090d7d8> (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$SerializableLock)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:994)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1054)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
        at java.lang.Thread.run(Thread.java:662)

"Low Memory Detector" daemon prio=10 tid=0x00007f1ca4090800 nid=0x72b8 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=10 tid=0x00007f1ca408e800 nid=0x72b7 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=10 tid=0x00007f1ca408b800 nid=0x72b6 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x00007f1ca4089800 nid=0x72b5 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x00007f1ca406c800 nid=0x72b4 in Object.wait() [0x00007f1ca951c000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000e094ef90> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
        - locked <0x00000000e094ef90> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x00007f1ca406a800 nid=0x72b3 in Object.wait() [0x00007f1ca961d000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000e094ef50> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x00000000e094ef50> (a java.lang.ref.Reference$Lock)

"main" prio=10 tid=0x00007f1ca4005800 nid=0x72ad in Object.wait() [0x00007f1caac77000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f9a82ec8> (a java.lang.UNIXProcess)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.UNIXProcess.waitFor(UNIXProcess.java:165)
        - locked <0x00000000f9a82ec8> (a java.lang.UNIXProcess)
        at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:173)
        at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:114)
        at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:231)
        at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnce(ForkStarter.java:125)
        at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:109)
        at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:619)
        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)

"VM Thread" prio=10 tid=0x00007f1ca4063800 nid=0x72b2 runnable

"GC task thread#0 (ParallelGC)" prio=10 tid=0x00007f1ca4019000 nid=0x72ae runnable

"GC task thread#1 (ParallelGC)" prio=10 tid=0x00007f1ca401b000 nid=0x72af runnable

"GC task thread#2 (ParallelGC)" prio=10 tid=0x00007f1ca401c800 nid=0x72b0 runnable

"GC task thread#3 (ParallelGC)" prio=10 tid=0x00007f1ca401e800 nid=0x72b1 runnable

"VM Periodic Task Thread" prio=10 tid=0x00007f1ca40a3800 nid=0x72b9 waiting on condition

JNI global references: 1776

Heap
 PSYoungGen      total 146240K, used 73099K [0x00000000f5560000, 0x00000000ffb50000, 0x0000000100000000)
  eden space 131648K, 55% used [0x00000000f5560000,0x00000000f9cc2df8,0x00000000fd5f0000)
  from space 14592K, 0% used [0x00000000fed10000,0x00000000fed10000,0x00000000ffb50000)
  to   space 19136K, 0% used [0x00000000fd5f0000,0x00000000fd5f0000,0x00000000fe8a0000)
 PSOldGen        total 144000K, used 84671K [0x00000000e0000000, 0x00000000e8ca0000, 0x00000000f5560000)
  object space 144000K, 58% used [0x00000000e0000000,0x00000000e52affe8,0x00000000e8ca0000)
 PSPermGen       total 83968K, used 56954K [0x00000000dae00000, 0x00000000e0000000, 0x00000000e0000000)
  object space 83968K, 67% used [0x00000000dae00000,0x00000000de59eb48,0x00000000e0000000)


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

Threaddump of:
rkrell 3400 0.4 0.6 3343732 49900 pts/1 Sl+ 11:23 0:00 /usr/lib64/jvm/java-1.6.0-sun-1.6.0/jre/bin/java -jar /home/rkrell/src/git/izpack/izpack-installer/target/surefire/surefirebooter472447547370662330.jar /home/rkrell/src/git/izpack/izpack-installer/target/surefire/surefire6090500005791191803tmp /home/rkrell/src/git/izpack/izpack-installer/target/surefire/surefire8128904398912440471tmp

Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode):

"Thread-18" daemon prio=10 tid=0x00007f4f502e6800 nid=0xd8f runnable [0x00007f4f553c3000]
   java.lang.Thread.State: RUNNABLE
        at java.io.FileInputStream.readBytes(Native Method)
        at java.io.FileInputStream.read(FileInputStream.java:220)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
        - locked <0x00000007d7f7b110> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:167)
        at java.io.BufferedReader.fill(BufferedReader.java:136)
        at java.io.BufferedReader.readLine(BufferedReader.java:299)
        - locked <0x00000007d7f7b110> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:362)
        at com.izforge.izpack.util.MonitorInputStream.run(MonitorInputStream.java:67)
        at java.lang.Thread.run(Thread.java:662)

"Thread-17" daemon prio=10 tid=0x00007f4f502d3800 nid=0xd8e runnable [0x00007f4f552c2000]
   java.lang.Thread.State: RUNNABLE
        at java.io.FileInputStream.readBytes(Native Method)
        at java.io.FileInputStream.read(FileInputStream.java:220)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
        - locked <0x00000007d8148010> (a java.io.BufferedInputStream)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
        - locked <0x00000007d7f79060> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:167)
        at java.io.BufferedReader.fill(BufferedReader.java:136)
        at java.io.BufferedReader.readLine(BufferedReader.java:299)
        - locked <0x00000007d7f79060> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:362)
        at com.izforge.izpack.util.MonitorInputStream.run(MonitorInputStream.java:67)
        at java.lang.Thread.run(Thread.java:662)

"process reaper" daemon prio=10 tid=0x00007f4f502df800 nid=0xd8c runnable [0x00007f4f551c1000]
   java.lang.Thread.State: RUNNABLE
        at java.lang.UNIXProcess.waitForProcessExit(Native Method)
        at java.lang.UNIXProcess.access$900(UNIXProcess.java:20)
        at java.lang.UNIXProcess$1$1.run(UNIXProcess.java:132)

"process reaper" daemon prio=10 tid=0x00007f4f502e3000 nid=0xd8a runnable [0x00007f4f550c0000]
   java.lang.Thread.State: RUNNABLE
        at java.lang.UNIXProcess.waitForProcessExit(Native Method)
        at java.lang.UNIXProcess.access$900(UNIXProcess.java:20)
        at java.lang.UNIXProcess$1$1.run(UNIXProcess.java:132)

"Low Memory Detector" daemon prio=10 tid=0x00007f4f500b7800 nid=0xd55 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=10 tid=0x00007f4f500b5000 nid=0xd54 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=10 tid=0x00007f4f500b2800 nid=0xd53 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x00007f4f500b0000 nid=0xd52 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x00007f4f50093800 nid=0xd51 in Object.wait() [0x00007f4f55a22000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000007d6ab1300> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
        - locked <0x00000007d6ab1300> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x00007f4f50091800 nid=0xd50 in Object.wait() [0x00007f4f55b23000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000007d6ab11d8> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x00000007d6ab11d8> (a java.lang.ref.Reference$Lock)

"main" prio=10 tid=0x00007f4f50005800 nid=0xd4a in Object.wait() [0x00007f4f57696000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000007d7f78c40> (a java.lang.UNIXProcess)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.UNIXProcess.waitFor(UNIXProcess.java:165)
        - locked <0x00000007d7f78c40> (a java.lang.UNIXProcess)
        at com.izforge.izpack.util.FileExecutor.executeCommand(FileExecutor.java:260)
        at com.izforge.izpack.util.FileExecutor.getExecOutput(FileExecutor.java:146)
        at com.izforge.izpack.util.FileExecutor.getExecOutput(FileExecutor.java:129)
        at com.izforge.izpack.util.unix.UnixUser.getXdgDesktopfolder(UnixUser.java:264)
        at com.izforge.izpack.util.unix.UnixUsers._getUsersWithValidShellsExistingHomesAndDesktops(UnixUsers.java:115)
        at com.izforge.izpack.util.unix.UnixUsers.getUsersWithValidShellsExistingHomesAndDesktops(UnixUsers.java:162)
        at com.izforge.izpack.util.os.Unix_Shortcut.<init>(Unix_Shortcut.java:221)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at java.lang.Class.newInstance0(Class.java:355)
        at java.lang.Class.newInstance(Class.java:308)
        at com.izforge.izpack.util.DefaultTargetPlatformFactory.create(DefaultTargetPlatformFactory.java:171)
        at com.izforge.izpack.util.InstallerTargetPlatformFactoryTest.checkCreate(InstallerTargetPlatformFactoryTest.java:111)
        at com.izforge.izpack.util.InstallerTargetPlatformFactoryTest.testShortcuts(InstallerTargetPlatformFactoryTest.java:61)
        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:44)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
        at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
        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:193)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
        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 $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)

"VM Thread" prio=10 tid=0x00007f4f5008a800 nid=0xd4f runnable

"GC task thread#0 (ParallelGC)" prio=10 tid=0x00007f4f50019000 nid=0xd4b runnable

"GC task thread#1 (ParallelGC)" prio=10 tid=0x00007f4f5001a800 nid=0xd4c runnable

"GC task thread#2 (ParallelGC)" prio=10 tid=0x00007f4f5001c800 nid=0xd4d runnable

"GC task thread#3 (ParallelGC)" prio=10 tid=0x00007f4f5001e800 nid=0xd4e runnable

"VM Periodic Task Thread" prio=10 tid=0x00007f4f500c2000 nid=0xd56 waiting on condition

JNI global references: 1395

Heap
 PSYoungGen      total 37056K, used 24408K [0x00000007d6ab0000, 0x00000007d9400000, 0x0000000800000000)
  eden space 31808K, 76% used [0x00000007d6ab0000,0x00000007d82861c8,0x00000007d89c0000)
  from space 5248K, 0% used [0x00000007d8ee0000,0x00000007d8ee0000,0x00000007d9400000)
  to   space 5248K, 0% used [0x00000007d89c0000,0x00000007d89c0000,0x00000007d8ee0000)
 PSOldGen        total 84672K, used 0K [0x0000000784000000, 0x00000007892b0000, 0x00000007d6ab0000)
  object space 84672K, 0% used [0x0000000784000000,0x0000000784000000,0x00000007892b0000)
 PSPermGen       total 21248K, used 6191K [0x000000077ee00000, 0x00000007802c0000, 0x0000000784000000)
  object space 21248K, 29% used [0x000000077ee00000,0x000000077f40bee0,0x00000007802c0000)
Comment by Rene Krell [ 19/Dec/11 ]

According to the threaddumps, debugging in Eclipse of the hanging JUnit test
com.izforge.izpack.util.InstallerTargetPlatformFactoryTest.testShortcuts()
leads me to
com.izforge.izpack.util.unix.UnixUser.getXdgDesktopfolder(UnixUser.java:264).

In this line there is executed the local command

/bin/su rkrell -c /tmp/com.izforge.izpack.util.unix.UnixUser13242974209688613595214473020674.sh

The contents of this script generated dynamically by IzPack are:

#!/usr/bin/env sh

# This is an automatically generated Script.
# Usually this can be removed if the Generator
# was unable to remove the script after execution.

# Generator: com.izforge.izpack.util.unix.ShellScript
# $Id$
# Author: marc.eppelmann_at_gmx.de
# $Revision$
# Generated at: Mon Dec 19 13:23:40 CET 2011

. /home/rkrell/.config/user-dirs.dirs

echo $XDG_DESKTOP_DIR

# /tmp/com.izforge.izpack.util.unix.UnixUser13242974209688613595214473020674.sh

This script hangs even if I call the generated command line manually in the given manner, most probably because su prompts for a password (openSUSE 12.1).

Comment by Rene Krell [ 19/Dec/11 ]

Do not use 'su' in non-interactive script execution.

BTW - there are several unused methods in the UnixUser class, general cleanup would not be that bad.

Comment by Sreram Balasubramaniyan [ 27/Mar/13 ]

Btw how do you execute scripts which need to have admin rights for its execution? Will <run-priviledged /> tag help to login first as administrator then execute the script without interruption or exception?

And in ubuntu (and probably in other OSes as well), if i do use <run-priviledged /> it gives an error saying 'Cannot login as administrator'. Is there any workaround for this?





[IZPACK-718] UserInputPanel dir element does not create directory with create="true" and mustExist="false" Created: 07/Dec/11  Updated: 08/Dec/11

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

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

Windows 7, Suse Linux


Number of attachments : 0

 Description   

UserInputPanel dir element does not create directory with element create="true" and mustExist="false" when the set element is populated with a path that does not exist.

The installer keeps complaining "The directory you have chosen either does not exist or is not valid".

Here is the sample field element that reproduces this issue:

<field type="dir" align="right" variable="DATABASE_PATH" >
<createForPack name="Database Server" />
<spec id="input.db.path" size="20" set="$

{USER_HOME}

$

{FILE_SEPARATOR}

dbase" create="true" mustExist="false" />
</field>

The expectation in this case is to create directories that make this path valid.

Many thanks.



 Comments   
Comment by Rehan Mahmood [ 08/Dec/11 ]

In the new documentation, there is a mention that the mustExist="true" for create option. However, that also presents the same message and do not create the folder.





[IZPACK-717] WinLibEnv.cxx references NativeLibException in wrong package Created: 01/Dec/11  Updated: 19/Dec/11  Resolved: 19/Dec/11

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   

Windows registry handling via com.coi.tools.os.win.RegistryImpl is broken in 5.0.0-beta9 and head due NativeLibException being moved from the com.coi.tools.os.win package to com.izforge.izpack.api.exception.
The WinLibEnv C++ class still refers to the old location i.e:


ExceptionNameRecord WinLibEnv::ExceptionNameMap[] =

{ .... ExceptionNameRecord("NativeLibException", "com/coi/tools/os/win/NativeLibException", 2, 2 ), ... }

Either NativeLibException should be moved back to com.coi.tools.os.win in the izpack-core module (along with RegistryImpl etc) or WinLibEnv needs to be updated to reflect the new package name.



 Comments   
Comment by Julien Ponge [ 01/Dec/11 ]

If you have a Windows environment to fix and build then you are more than welcome!

Comment by Tim Anderson [ 19/Dec/11 ]

I've updated WinLibEnv.cxx to reference NativeLibException's new package name.
I've also restructured the build so that the native dlls can be built as part of the maven build process.

As not everyone can/will have a windows C++ compiler installed, this is optional. Its invoked by activating the buildDLL profile i.e.:

> mvn -DbuildDLL=true install

The izpack-native module has now been renamed and split into:

  • izpack-native-parent - parent module for native support
    • izpack-native-maven-plugin - extension to the native-maven-plugin to allow builds with Microsoft Visual C++ 2010 Express
    • izpack-native-coioshelper - builds COIOSHelper.dll
    • izpack-native-coioshelper-x64 - builds COIOSHelper_x64.dll
    • izpack-native-setupapi - builds WinSetupAPI.dll
    • izpack-native-setupapi-x64 - builds WinSetupAPI_x64.dll
    • izpack-native-shelllink - builds ShellLink.dll
    • izpack-native-shelllink-x64 builds ShellLink_x64.dll
    • izpack-native-package - copies dlls from the above modules to the izpack-native module, where they can be checked in manually
    • izpack-native - now just holds the checked in dlls

The buildDLL profile requires Microsoft Visual C++ 2010 Express (the free edition), and Windows SDK 7.1 installed. The latter is required as the VC 2010 Express doesn't come with x64 support. It should also work with the full Microsoft Visual C++ version. YMMV





[IZPACK-716] CheckedHelloPanel no longer able to access Win_RegistryHandler Created: 01/Dec/11  Updated: 15/Dec/11  Resolved: 15/Dec/11

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   

CheckedHelloPanel is broken in 5.0.0-beta-10, (and possibly as far back as 21/1/10) due to the move of RegistryHandler from the com.izforge.izpack.util.os to the com.izforge.izpack.core.os package.
CheckedHelloPanel uses RegistryDefaultHandler.getInstance() which in turn invokes TargetFactory.getInstance().makeObject("com.izforge.izpack.core.os.RegistryHandler");
The makeObject() method tries to create a platform-specific version of RegistryHandler using the package name (com.izforge.izpack.core.os) and os, and class name.
As the Win_RegistryHandler is in com.izforge.izpack.util.os package, it cannot be resolved and TargetFactory.getInstance() returns null.
As a result CheckedHelloPanel is effectively a no-op.

A hack workaround is to invoke TargetFactory.getInstance().makeObject("com.izforge.izpack.util.os.RegistryHandler") if the former invocation returns null.

A better approach would be to register available targets in property files, with the key being the interface/class name, optional os family and architecture and the values the implementation class e.g.:

RegistryHandler,windows = com.izforge.izpack.util.os.Win_RegistryHandler
RegistryHandler = com.izforge.izpack.core.os.RegistryHandler
Shortcut,windows = com.izforge.izpack.util.os.Win_Shortcut
Shortcut,unix =com.izforge.izpack.util.os.Unix_Shortcut
Shortcut = com.izforge.izpack.util.os.Shortcut

Main advantage is that classes don't have to reside in any particular package nor do they have to follow a class name format.



 Comments   
Comment by Tim Anderson [ 01/Dec/11 ]

Actually, the workaround isn't sufficient as TargetFactory always returns a RegistryHandler instance if it cannot find a platform specific implementation.

Comment by Tim Anderson [ 15/Dec/11 ]

TargetFactory now delegates creation of platform specific implementations to a new factory, TargetPlatformFactory which uses configuration rather than class naming conventions to create appropriate implementations.
The original TargetFactory implementation is used if TargetPlatformFactory throws an exception.

TargetPlatformFactory is configured via one or more TargetPlatformFactory.properties files located in the class path under com/izforge/izpack/util/ e.g.:

#
# Properties used by TargetPlatformFactory to create platform specific implementations of interfaces.
#
# The format is as follows:                 \
#
# <interface>[,name[,arch]] = <implementation>
#
# Where:
# . interface      - is the fully qualified interface
# . name           - is the platform name corresponding to those defined in com.izforge.izpack.util.Platforms, as lowercase
# . arch           - is the platform architecture corresponding to com.izforge.izpack.util.Platform.Arch, as lowercase
# . implementation - is the implementation of the interface for the OS version
#
# E.g.:
# com.izforge.izpack.util.os.NativeWrapper,windows = com.izforge.izpack.util.os.WinWrapper
# com.izforge.izpack.util.os.NativeWrapper,windows,x64 = com.izforge.izpack.util.os.Win64Wrapper
# com.izforge.izpack.util.os.NativeWrapper,windows_xp = com.izforge.izpack.util.os.Windows7Wrapper
# com.izforge.izpack.util.os.NativeWrapper,windows_7,x86 = com.izforge.izpack.util.os.Windows7x86Wrapper
# com.izforge.izpack.util.os.NativeWrapper,windows_7,x64 = com.izforge.izpack.util.os.Windows7x64Wrapper
# com.izforge.izpack.util.os.NativeWrapper,unix = com.izforge.izpack.util.os.GenericUnixWrapper
# com.izforge.izpack.util.os.NativeWrapper,debian_linux = com.izforge.izpack.util.os.DebianLinuxWrapper
# com.izforge.izpack.util.os.NativeWrapper,mac_osx = com.izforge.izpack.util.os.MacOSXWrapper
# com.izforge.izpack.util.os.NativeWrapper = com.izforge.izpack.util.os.DefaultWrapper

#
# Configures platform specific shortcuts
#
com.izforge.izpack.util.os.Shortcut,windows = com.izforge.izpack.util.os.Win_Shortcut
com.izforge.izpack.util.os.Shortcut,unix    = com.izforge.izpack.util.os.Unix_Shortcut
com.izforge.izpack.util.os.Shortcut         = com.izforge.izpack.util.os.Shortcut

#
# Configures platform specific registry handling
#
com.izforge.izpack.core.os.RegistryHandler,windows = com.izforge.izpack.util.os.Win_RegistryHandler
com.izforge.izpack.core.os.RegistryHandler = com.izforge.izpack.core.os.RegistryHandler

OsVersion has been refactored to use two new classes, Platforms and Platform for platform identification, for the pursposes of testability.





[IZPACK-715] Shortcuts created in wrong group when desktop="no" Created: 30/Nov/11  Updated: 11/Dec/11  Resolved: 11/Dec/11

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

Attachments: Text File ShortcutPanel.diff.txt    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

In 5.0.0-beta-9 and head, shortcuts are being created in the root program group if the shortcut spec has desktop="no"

This is due to allowDesktopShortcut being null in ShortcutPanel.isValidated():

        try
        {
            shortcutPanelLogic.setGroupName(programGroup.getText());
            shortcutPanelLogic.setCreateDesktopShortcuts(allowDesktopShortcut.isSelected());
            shortcutPanelLogic.setCreateShortcuts(createShortcuts.isSelected());
        }
        catch (Throwable exception)
        {
            // ignore exception
            shortcutPanelLogic.setGroupName("");
        }

A NullPointerException is thrown causing shortcutPanelLogic.setGroupName("") to be invoked.

Its not clear why the code is in a try/catch block in the first place, but if this should be the case, the exception should be logged to make problems easier to track down.



 Comments   
Comment by Tim Anderson [ 11/Dec/11 ]

Fixed ShortcutPanel.isValidated() as described





[IZPACK-714] Shortcuts broken on windows due to packaging of dlls Created: 30/Nov/11  Updated: 11/Dec/11  Resolved: 11/Dec/11

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

Attachments: Text File Librarian.diff.txt    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Shortcuts are currently broken in 5.0.0-beta-9 and head on windows installers, as the dlls required to create shortcuts cannot be resolved.
This is due to the way dlls are packaged in izpack-native.jar and the manner Librarian tries to locate them.

The izpack-native jar packages dlls as follows:

 com/izforge/izpack/bin/native/3rdparty/COIOSHelper.dll
 com/izforge/izpack/bin/native/3rdparty/COIOSHelper_x64.dll
 com/izforge/izpack/bin/native/izpack/ShellLink.dll
 com/izforge/izpack/bin/native/izpack/ShellLink_x64.dll

When looking for dlls, com.izforge.izpack.util.Librarian looks for them in:
1. <name>.dll
2. com/izforge/izpack/bin/native/<name>.dll

As a result it cannot find ddls in 3rdparty/ nor izpack/.

A workaround is to Librarian.openInputStream()

if (input == null)
{
    input = clientClass.getResourceAsStream('/' + nativeDirectory + "/izpack/" + name + extension);
}

if (input == null)
{
    input = clientClass.getResourceAsStream('/' + nativeDirectory + "/3rdparty/" + name + extension);
}

Ideally however, the type attribute of the dll from install.xml would be used when resolving dlls i.e.:

    <natives>
       <native type="izpack" name="ShellLink.dll"/>
        <native type="izpack" name="ShellLink_x64.dll"/>
        <native type="izpack" name="WinSetupAPI.dll"/>
        <native type="izpack" name="WinSetupAPI_x64.dll"/>
        <native type="3rdparty" name="COIOSHelper.dll" stage="both"/>
        <native type="3rdparty" name="COIOSHelper_x64.dll" stage="both"/>
    </natives>

Doesn't look like the above is available without refactoring however.



 Comments   
Comment by Tim Anderson [ 11/Dec/11 ]

Fixed using the workaround i.e. changed Librarian to look for dlls in well known locations.





[IZPACK-713] NullPointerException Created: 23/Nov/11  Updated: 18/Aug/12  Resolved: 18/Aug/12

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

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

I tried to migrate an valid 4.3 izpack configuration to 5.0 and got the exception bellow.
Also please improve the 5.0 documentation, I coudn't find any references for :
1. the 4.3 native entries were rejected in 5.0, I had to remove them. Is this correct ?
2. the ant task in 4.3 needed to load only standalone-compiler.jar. Now should load all libraries from /lib folder. I had to change the task as in the sample in the bottom. Many users may not know how to change this, it would be nice to document.
3. you have introduced a new task to copy the embedded jre folder. Where I can read about it.
Answers to this questions would be appreciated.

Exception in thread "AWT-EventQueue-0" com.izforge.izpack.api.exception.IzPackException: java.lang.NullPointerException
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:57)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
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.NullPointerException
at com.izforge.izpack.core.container.filler.EventFiller.loadCustomData(EventFiller.java:56)
at com.izforge.izpack.installer.container.impl.InstallerContainer.fillContainer(InstallerContainer.java:95)
at com.izforge.izpack.core.container.AbstractContainer.initBindings(AbstractContainer.java:25)
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:47)
... 8 more

— Sample ant task under 5.0

<taskdef name="IzPack" classpathref="izp" classname="com.izforge.izpack.ant.IzPackTask">
<classpath id="izp">
<fileset id="lib" dir="$

{application.izpack_path}

/lib">
<include name="*/.jar"/>
</fileset>
</classpath>
</taskdef>



 Comments   
Comment by Eugene Ustimenko [ 07/Aug/12 ]

May be, you should change install.xml in guiprefs section. You should not use metouia style there, change it to substance or looks.

Comment by Tim Anderson [ 18/Aug/12 ]

1. See http://docs.codehaus.org/display/IZPACK/Upgrading+from+IzPack+4.3+to+5.0
2. I've added documentation for the Ant task: http://docs.codehaus.org/display/IZPACK/Compiling+using+Ant
3. No idea what you mean here.

Direct questions to the izpack-user mailing list. See https://izpack.github.io/mailing-lists/





[IZPACK-712] Problem with the Ukrainian translation Created: 17/Nov/11  Updated: 26/Nov/11  Resolved: 24/Nov/11

Status: Closed
Project: IzPack
Component/s: Translations
Affects Version/s: 4.3.0, 4.3.3, 4.3.4, 4.3.5, 5.0
Fix Version/s: 4.3.5, 5.0

Type: Bug Priority: Minor
Reporter: kytv Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: i18n
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File ukrnew-2.xml    
Number of attachments : 1

 Description   

The Ukrainian langpack is corrupt or uses non-standard UTF-8 characters. This is apparent by opening ukr.xml in a UTF-8 text editor or by selecting Ukrainian in izpack's own installer. Our bug report is at http://trac.i2p2.de/ticket/550

We verified this in izpack 4.3.0, 4.3.3, 4.3.4, and 5.0.0-beta8. "rndnick" from our project has done a new translation from scratch using the eng.xml from 4.3.0 as a base.

Attached to this ticket is his translation which can also be found in our bugtracker at http://trac.i2p2.de/raw-attachment/ticket/550/ukrnew-2.xml



 Comments   
Comment by Julien Ponge [ 24/Nov/11 ]

Thanks!





[IZPACK-711] Change AutomatedInstallData FQN in BSFAction Created: 11/Nov/11  Updated: 18/Aug/12  Resolved: 18/Aug/12

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

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

Please change

manager.declareBean("installData", idata, Class.forName("com.izforge.izpack.installer.AutomatedInstallData"));

to

manager.declareBean("installData", idata, Class.forName("com.izforge.izpack.api.data.AutomatedInstallData"));

in /izpack-event/src/main/java/com/izforge/izpack/event/BSFAction.java



 Comments   
Comment by Tim Anderson [ 18/Aug/12 ]

BSFAction now does:

   manager.declareBean("installData", installData, InstallData.class);




[IZPACK-710] NullPointerException in AbstractInstallDataProvider.addCustomLangPack() Created: 10/Nov/11  Updated: 24/Nov/11  Resolved: 24/Nov/11

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

Attachments: File GUIInstallDataProvider.diff    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

In 5.0.0-beta8, the following line from AbstractInstallDataProvider.addCustomLangPack():

idata.getLangpack().add(resourceManager.getInputStream(LANG_FILE_NAME));

throws a NullPointerException as idata.getLangPack() is null.

This is because GUIInstallDataProvider.provide(...) invokes addCustomLangPack() before loadDefaultLocale() - the latter is responsible for creating the LocaleDatabase returned by getLangPack().


...
// Load custom langpack if exist.
addCustomLangpack(guiInstallData);
loadDefaultLocale(guiInstallData);
{noformat

A simple fix is to change the order of invocation. See attached patch.



 Comments   
Comment by Julien Ponge [ 24/Nov/11 ]

Thanks!





[IZPACK-709] DirInputField.validateField() returns true for empty path when mustExist is true Created: 09/Nov/11  Updated: 24/Nov/11  Resolved: 24/Nov/11

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: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File DirInputField.diff    
Testcase included: yes
Patch Submitted:
Yes
Number of attachments : 1

 Description   

If a DirInputField is created with mustExist="true", the field is flagged as valid if it is empty.

        <field type="dir" align="left" variable="some.dir">
            <spec txt="" size="25" set="" mustExist="true"/>
        </field>

This occurs in 5.0.0-beta8 and head (5.0.0-beta9-SNAPSHOT).

Test case and fix attached.



 Comments   
Comment by Julien Ponge [ 24/Nov/11 ]

Thanks!





[IZPACK-708] make <refpack> use also <locale> tag from the referenced XML Created: 01/Nov/11  Updated: 01/Nov/11

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

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

At the moment for <refpack> "the only elements that are used from referenced XML file are the <packs> and the <resources> elements".

I think it would be also useful to use <locale> tag.

Example.
<refpack>s reference application language packs (e.g. SWE, FIN, RUS) included/excluded by some condition during installer compilation.
If, for example, FIN is included, I would like installer provide selection of the corresponding language (basically <locale> tag to contain <langpack iso3="fin" /> tag). But if FIN is excluded than <langpack iso3="fin" /> will not appear in <locale>.






[IZPACK-707] Going back to ShortcutPanel then forward again creates duplicate shortcuts Created: 26/Oct/11  Updated: 26/Oct/11

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

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

Linux Ubuntu 10.04 64-bit


Number of attachments : 0

 Description   

In a simple installer configuration, I step through the panels. I click Next from the ShortcutPanel to the next configured panel; in this case, SummaryPanel. If I then clcik back, then forward, it creates a new set of shortcuts each time. On completion of the installation, I will have as many duplicate sets of shortcuts in the same group as I repeated the backward/forward step from the ShortcutPanel.






[IZPACK-706] Web installer with htaccess only works with Windows Created: 17/Oct/11  Updated: 01/May/13

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

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

Windows 7 with Java 1.6, MAC os x with Java 1.5, Ubuntu Linux with Java 1.6


Number of attachments : 0

 Description   

I created website, where i have .htaccess protection for my folder and packs that can be installed thru webinstaller. Installer works fine with Windows, it asks for password and downloads everything, but with mac and linux, after i type in correct username and password, it shows Installation failed and i get this message to console with debug enabled:

java.lang.NullPointerException while trying to download http://www.www.arkistossa.com/downloads/webdir/updater.pack-pack.tool.jar
com.izforge.izpack.installer.InstallerException: Installation failed
at com.izforge.izpack.installer.Unpacker.getPackAsStream(Unknown Source)
at com.izforge.izpack.installer.Unpacker.run(Unknown Source)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at com.izforge.izpack.installer.WebRepositoryAccessor.getCachedUrl(Unknown Source)
... 3 more

If i remove .htaccess file from webdir, it installs fine with mac and linux, so there is some strange problem with unix environments not working at all with htaccess protection. This makes server password protection with Izpack unusable.






[IZPACK-705] Install over 4.x fails Created: 13/Oct/11  Updated: 01/Oct/12  Resolved: 01/Aug/12

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

Type: Bug Priority: Major
Reporter: Julien CARSIQUE Assignee: Tim Anderson
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If installing 5.x over 4.x, installation fails because of com.izforge.izpack.Pack was moved to com.izforge.izpack.api.data.Pack

13 oct. 2011 16:42:46 com.izforge.izpack.installer.base.InstallerFrame hasNavigateNext
INFO: The next panel of 6 is panel number 7
java.lang.ClassNotFoundException: com.izforge.izpack.Pack
  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)
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:247)
  at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603)
  at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574)
  at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
  at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
  at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
  at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
  at java.util.ArrayList.readObject(ArrayList.java:593)
  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.invokeReadObject(ObjectStreamClass.java:974)
  at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
  at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
  at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
  at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
  at com.izforge.izpack.installer.unpacker.UnpackerBase.writeInstallationInformation(UnpackerBase.java:597)
  at com.izforge.izpack.installer.unpacker.Unpacker.run(Unpacker.java:419)
  at java.lang.Thread.run(Thread.java:680)

This should be caught and ask the user either to choose another target directory, either first uninstall previous version.



 Comments   
Comment by Tim Anderson [ 29/Jul/12 ]

Now verify that any exising .installationinformation can be read before allowing installation to the directory

Fix available at: https://github.com/izpack/izpack/pull/39

Included in this pull request:
. added tests for TargetPanel, TargetPanelAutomation and TargetPanelConsole to check incompatible version handling
. added TargetPanel.incompatibleInstallation to eng.xml. Being mono-lingual, haven't updated any of the other locales
. renamed TargetPanelAutomationHelper to TargetPanelAutomation
. rolled izpack-test-panel module into izpack-panel. Separation was unnecessary

Comment by Tim Anderson [ 01/Aug/12 ]

Pull request merged

Comment by Eugene Ustimenko [ 01/Oct/12 ]

I had reproduce it at izpack5.0.0-beta10

Comment by Tim Anderson [ 01/Oct/12 ]

Its fixed in 5.0.0-beta11-SNAPSHOT.





[IZPACK-704] Environment variables having wrong character encoding Created: 13/Oct/11  Updated: 01/May/13

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

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

Microsoft Windows 7, Microsoft Windows XP


Attachments: PNG File izpack_character_encoding_problem.png    
Number of attachments : 1

 Description   

I have defaultTargetPanel and packs are installing to this location:
<file override="true" src="C:\kiln\installer\install_files\launcher\MinecraftEdu\" targetdir="$

{ENV[APPDATA]}

" os="windows"></file>

It works fine, BUT if username contains special characters, like À or ö, it converts them into: ,,
So when my username is kylmÀoja, special characters show as ,, and installer fails.

I tried inputting direct path to my appdata folder (without environment variable) and it worked, so environment variables have wrong encoding data.

This has been tested with Windows XP and Windows 7 on separate computers.



 Comments   
Comment by Aleksi [ 07/Nov/11 ]

I bypassed the problem with packs by defining every pack path separately for every OS Family (and running into few more problems, like .zip archives for every defined OS family are added into package size, even if it has been already added), but the same problem still occurs when creating shortcuts (and i don't think you can define OS family dependent paths to shortcuts?).

Comment by Dmitry Rykovanov [ 14/Nov/11 ]

I have the same problem with cyrillic chars in APPDATA variable.
I'm using it through TargetPanelDir.txt as described in PathInputPanel.java





[IZPACK-703] NPE if guiprefs is missing Created: 23/Sep/11  Updated: 27/Sep/11  Resolved: 27/Sep/11

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

Type: Bug Priority: Major
Reporter: Mykola Nikishov Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

IzPack Maven2 plugin and IzPack compiler 5.0.0-beta8


Number of attachments : 0

 Description   

When building my installer, Maven build fails due to NPE in Packager's writeManifest method:

[INFO] Trace
java.lang.AssertionError: java.lang.NullPointerException
  at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:94)
  at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
    ...
Caused by: java.lang.NullPointerException
  at com.izforge.izpack.compiler.packager.impl.Packager.writeManifest(Packager.java:226)
  at com.izforge.izpack.compiler.packager.impl.PackagerBase.writeInstaller(PackagerBase.java:350)
  at com.izforge.izpack.compiler.packager.impl.Packager.createInstaller(Packager.java:123)
  at com.izforge.izpack.compiler.Compiler.createInstaller(Compiler.java:132)
  at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:256)
  at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:90)
  ... 19 more
[INFO] ------------------------------------------------------------------------

A very simple workaround is to place a useless (I'm writing a headless installer) guiprefs element:

diff --git a/src/izpack/install.xml b/src/izpack/install.xml
index 1e22c33..233813b 100644
--- a/src/izpack/install.xml
+++ b/src/izpack/install.xml
@@ -14,6 +14,8 @@
    <url>http://www.anotherworld-inspace-website.net/</url>
   </info>

+    <guiprefs resizable="yes" width="800" height="600" />
+
  <locale>
    <langpack iso3="eng" />
  </locale>


 Comments   
Comment by Mykola Nikishov [ 23/Sep/11 ]

I've just created a pull request @ Github. It's based on izpack-5.0.0-beta8 tag and cleanly applies to current codehaus/master @ 0cd7229cf58bc6.

Comment by Julien Ponge [ 27/Sep/11 ]

Thanks!





[IZPACK-702] JDKPathPanelAutomationHelper.runAutomated throws NullPointerException Created: 14/Sep/11  Updated: 14/Jun/12  Resolved: 14/Jun/12

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

Type: Bug Priority: Critical
Reporter: Francis De Brabandere Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: exception, runtime
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux & Windows


Number of attachments : 0

 Description   

We used this maven antifact to build the installer
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-standalone-compiler</artifactId>
<version>4.3.4</version>

works with 4.3.2 but with 4.3.4 I get this:

seems that line number info is missing:
03:11:45,414 INFO [installer] [ Starting automated installation ]
03:11:45,414 INFO [installer] java.lang.NullPointerException
03:11:45,414 INFO [installer] java.lang.NullPointerException
03:11:45,414 INFO [installer] at com.izforge.izpack.panels.JDKPathPanelAutomationHelper.runAutomated(Unknown Source)
03:11:45,414 INFO [installer] at com.izforge.izpack.installer.AutomatedInstaller.installPanel(Unknown Source)
03:11:45,414 INFO [installer] at com.izforge.izpack.installer.AutomatedInstaller.doInstall(Unknown Source)
03:11:45,430 INFO [installer] at com.izforge.izpack.installer.Installer.main(Unknown Source)
03:11:45,430 INFO [installer] [ Automated installation FAILED! ]

Further the installer returns exit code 0 (succes) if this happens, should be something else



 Comments   
Comment by Dustin Kut Moy Cheung [ 14/Jun/12 ]

Hi Francis! Could you post your install.xml?

I tried to reproduce your error but failed. [I installed in GUI first to generate the automation xml file, then ran java -jar installer.jar automated.xml]

Comment by Francis De Brabandere [ 14/Jun/12 ]

Hi Dustin, I fear I don't have access to that file any more as I switched jobs since then.

Since nobody else had this issue and I am the only one watching it I suggest you just close it as not reproducible.

Comment by Dustin Kut Moy Cheung [ 14/Jun/12 ]

Thanks for the answer!

I can't really close that JIRA since I don't have permissions to do so. Maybe you can do it?

Comment by Francis De Brabandere [ 14/Jun/12 ]

See previous comments





[IZPACK-701] NPE during uninstall creation at 4.3.5-SNAPSHOT Created: 12/Sep/11  Updated: 26/Nov/11  Resolved: 24/Nov/11

Status: Closed
Project: IzPack
Component/s: Uninstaller
Affects Version/s: 4.3.5
Fix Version/s: 4.3.5

Type: Bug Priority: Blocker
Reporter: Dan Tran 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   

detail discussion is at http://groups.google.com/group/izpack-user/browse_thread/thread/538f357c4517a83b



 Comments   
Comment by Alexander Maslov [ 09/Nov/11 ]

I made a pull request for this issue fix https://github.com/jponge/izpack/pull/8





[IZPACK-700] HTMLHelloPanel fails - stack trace indicates missing HTMLInfoPanel class Created: 08/Sep/11  Updated: 28/Sep/12  Resolved: 18/Aug/12

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

Type: Bug Priority: Major
Reporter: Steve Wadsworth Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux 64-bit


Attachments: XML File installer.xml     HTML File splash.html    
Number of attachments : 2

 Description   

I am working on a demonstration of IzPack's capabilities for an upcoming product release and was trying different panels to see what would make the best presentation. When I tried to use HTMLHelloPanel, the installer fails. I can use HTMLInfoPanel with the same HTML resource, so the content itself doesn't seem to be the issue. It looks like HTMLHelloPanel uses HTMLInfoPanel in some way, but the latter class isn't included in the installer package.

Here's the beginning of the stack trace:

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(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at com.izforge.izpack.merge.resolve.ClassPathCrawler.searchClassInClassPath(ClassPathCrawler.java:120)
at com.izforge.izpack.installer.manager.PanelManager.loadPanelsInContainer(PanelManager.java:72)
at com.izforge.izpack.installer.base.InstallerController.preloadInstaller(InstallerController.java:30)
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:50)
[...]



 Comments   
Comment by Steve Wadsworth [ 12/Sep/11 ]

I tried the HTMLHelloPanel again, this time in a configuration that also included an instance of the HTMLInfoPanel. In this case, the HTMLHelloPanel worked properly. When the HTMLHelloPanel is used, whatever determines what classes need to be included in the installer package needs to include HTMLInfoPanel.

Comment by Steve Wadsworth [ 13/Sep/11 ]

What version are you using? I am able to easily reproduce this with 5.0 Beta8.

Comment by Steve Wadsworth [ 13/Sep/11 ]

I've attached a pair of files. This is an exrtremely stripped-down installer. If I have only the HTMLHelloPanel, I get this:

stevew@ubuntu:~$ java -jar install.jar
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com/izforge/izpack/panels/htmlinfo/HTMLInfoPanel
at java.lang.ClassLoader.defineClass1(Native Method)

but the installer proceeds withouit error if I also include the HTMLInfoPanel.

Comment by Tim Anderson [ 18/Aug/12 ]

Fixed by changes made for IZPACK-740

Comment by Eugene Ustimenko [ 28/Sep/12 ]

I have the same bug with izpack-5.0.0beta10

Comment by Tim Anderson [ 28/Sep/12 ]

It was fixed for 5.0.0-beta11.

Comment by Eugene Ustimenko [ 28/Sep/12 ]

I can not found the 5.0.0-beta11 at Maven Repository

Comment by Tim Anderson [ 28/Sep/12 ]

5.0.0-beta11 is not yet released. You'll have to use a recent snapshot which you can find it in the Codehaus repository.
See https://nexus.codehaus.org/content/groups/snapshots-group/org/codehaus/izpack/izpack-dist/5.0.0-beta11-SNAPSHOT/

Comment by Eugene Ustimenko [ 28/Sep/12 ]

Tim, when you going to release 5.0.0-beta11





[IZPACK-699] It is impossible to use native libraries after rev: 28aa48 (15.05.11 16:48) Created: 07/Sep/11  Updated: 22/Oct/11  Resolved: 22/Oct/11

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

Type: Bug Priority: Critical
Reporter: Bobin Fedor Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

5.0.0-beta8


Number of attachments : 0

 Description   

Libraries are placed in com/izforge/izpack/bin/native/** but Librarian still try to find it in /native/**



 Comments   
Comment by Julien Ponge [ 07/Sep/11 ]

Did you try fixing it / have a patch / pull request?

I am asking because you investigated in the Git history

Thanks

Comment by Bobin Fedor [ 08/Sep/11 ]

No. But I have a workaround

1) create native jar with libraries in "native" folder
2) add this line to your install.xml <jar src="../src/main/izpack/native.jar" stage="both"/>

Also I can not build project from sources. In head revision some tests are failing.

Comment by Julien Ponge [ 22/Oct/11 ]

Fixed!





[IZPACK-698] UserInput panel is ignored under console install Created: 04/Sep/11  Updated: 04/Sep/11  Resolved: 04/Sep/11

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

Type: Bug Priority: Blocker
Reporter: Dan Tran Assignee: Dan Tran
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

my installer building with izpack 4.3.4 runs fines in GUI mode, how ever when run with console mode, the installer skips UserInput pannel, intercepted by Panel's validator which rejects the unassigned inputs, and therefor running into infinite loop



 Comments   
Comment by Dan Tran [ 04/Sep/11 ]

sorry, false alarm, my UserInput pannel is not invoked by installer due to missed configuration.





[IZPACK-697] UserInputPanel does not changes the binding's dynamicvariable Created: 04/Sep/11  Updated: 12/Dec/12  Resolved: 12/Dec/12

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

Type: Bug Priority: Blocker
Reporter: Dan Tran Assignee: Rene Krell
Resolution: Cannot Reproduce Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When user change a field in UserInputPanel which binds to an existing dynamic variable with a default value, the user inputs does not dynamically change the var.

To produce this, debug thru UserInputPanel's validator



 Comments   
Comment by Tim Anderson [ 13/Apr/12 ]

Can you attach a minimalist install.xml and userInputSpec.xml that can be used to reproduce the behaviour?
It will make it easier to diagnose and develop a test case.

Comment by CM [ 23/May/12 ]

I'm experiencing(with beta11 build locally) the same thing only when I'm accessing dynamic variable(DV) "DV_JBOSS_MASTER_ADDRESS" in my java class called by process panel, but the DV gets correctly replaced with the modified value when called <parsable/> node over the file on which I've putted the DV(in my case a BAT file).

My snippet code:
install.xml
<installation version="1.0">
...
<variables>
...
<variable name="V_DEFAULT_JBOSS_MASTER_ADDRESS" value="localhost" />
...
</variables>
<dynamicvariables>
...
<variable name="DV_JBOSS_MASTER_ADDRESS" value="$

{VI_MASTER_ADDRESS}

" condition="C_NODE" />
<variable name="DV_JBOSS_MASTER_ADDRESS" value="$

{V_DEFAULT_JBOSS_MASTER_ADDRESS}" condition="!C_NODE" />
...
</dynamicvariables>
...
</installation>

userInputSpec.xml
<userInput>
...
<panel id="P_userinput_master">
<field type="text" variable="VI_MASTER_ADDRESS">
<spec txt="CRE Master Address:" id="input.dg.cre.master.address" size="20" set="${V_DEFAULT_JBOSS_MASTER_ADDRESS}

" />
</field>
</panel>
...
</userInput>

Comment by Tim Anderson [ 21/Sep/12 ]

I can't reproduce this locally with the latest 5.0.0-beta11-SNAPSHOT.
One thing to be aware of is that dynamic variables are only updated when navigating to the next or previous panel.

Comment by Rene Krell [ 12/Dec/12 ]

I can't reproduce this problem here with the current 5.0.0-beta11-SNAPSHOT, neither.

As Tim already wrote, as long as the given pabnel (in your case "P_userinput_master") is active, the variable can't be resolved, because it can't be assigned in you usecase. Therefore, in that moment the value of DV_JBOSS_MASTER_ADDRESS is $

{VI_MASTER_ADDRESS}

(unresolved) according to the specification of resolving variables in IzPack.

As soon as you change to the next panel, VI_MASTER_ADDRESS gets assigned and DV_JBOSS_MASTER_ADDRESS receives the resolved value.

This does definitely work with the current implementation.

Comment by Rene Krell [ 12/Dec/12 ]

Hint: Please launch the installer with -DTRACE=true and watch the variable and condition value transitions along with switching between the panels.

Comment by CM [ 12/Dec/12 ]

I had to downgrade izpack version to the ones mentioned below, being able to fulfill my task of building the installer for my project.

<izpack.maven-plugin.version>1.0-alpha-5</izpack.maven-plugin.version>
<izpack.standalone-compiler.version>4.3.2</izpack.standalone-compiler.version>

So, I'm not able at the moment to change all my configuration and retest with snapshot beta 11.

As Dan mentioned at the beginning, the value for input panel doesn't get updated when adding a validator or a process panel get executed, after the value is filled and next button is pressed(debug in Validator/ProcessExecutor and see that the initial value is set to the dynamic variable).
Define a Validator for the input panel and check if the dynamic variable(initially set to a default value) gets updated with the one from input, which I'm expected to be updated accordingly with the one filled in input, in order to be able do my validation. Am I approaching it wrong?





[IZPACK-696] <variables>does not understand built-in var ( ie $INSTALL_PATH) Created: 04/Sep/11  Updated: 02/Sep/12  Resolved: 02/Sep/12

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

Type: Bug Priority: Critical
Reporter: Dan Tran Assignee: Tim Anderson
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   

<variables>
<variable name="InstallerFrame.logfilePath" value="$INSTALL_PATH" />
</variable>

when trying to retrieve this var via Panel's validator. the AutomatedInstallData.getVariable() does not intepolate $INSTALL_PATH in this case.

workround is to define it under <dynamicvariables>



 Comments   
Comment by Dan Tran [ 04/Sep/11 ]

this also happens on izpack 4.3.x. So the doc is wrong.

Comment by Tim Anderson [ 18/Feb/12 ]

Could dynamicvariables be merged with variables?
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.

Comment by Julien Ponge [ 20/Feb/12 ]

I agree with Tim's proposal.

Comment by Rene Krell [ 20/Feb/12 ]

I'd also appreciate uniting <variables> and <dynamicvariables>, this should be files in a separate issue, of course (and breaks the compatibility against previous install.xml's).

Comment by Tim Anderson [ 19/Jul/12 ]

The InstallerFrame.logfilePath variable actually has substitution performed on it by UninstallerFrame.getExternalLogFile(). I don't think its intended to be used as a dynamic variable.

The documentation at http://docs.codehaus.org/display/IZPACK/Variables has:

<variables>
  <variable name="InstallerFrame.logfilePath" value="$INSTALL_PATH/My-install.log"/>
  <!-- This means that the log name will be My-install and that it will be stored at the root of the installation. -->
  <!-- Any path is fine. If value is set to "Default" then "$INSTALL_PATH/uninstall/install.log" is used. -->
  <!-- And if variable isn't defined then no log is written. -->
  <variable name="desktopshortcutcheckboxenabled" value="true"/>
  <!-- This automatically checks the "Create Desktop Shortcuts" button. Default value is "False". -->
</variables>

I don't think this is incorrect. If you think there is other documentation which is incorrect, then include a link, otherwise I think this JIRA can be closed.

Comment by Tim Anderson [ 02/Sep/12 ]

To avoid confusion, I've removed the reference to $INSTALL_PATH in the "Understanding Variables" section of http://docs.codehaus.org/display/IZPACK/Variables
If a variable defined in <variables/> is expanded in the code, then this should be documented elsewhere.





[IZPACK-695] uninstaller.jar does not have the configured merge contents in <jar> Created: 03/Sep/11  Updated: 25/Jan/12  Resolved: 25/Jan/12

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

Type: Bug Priority: Blocker
Reporter: Dan Tran 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   

detailed discussions are at IZPACK-688.

We need to get installer to load resources/customData which has the list to files to be merged into uninstaller.jar



 Comments   
Comment by Dan Tran [ 03/Sep/11 ]

UninstallDataWriter is responsible to pull data out of UninstallData and write 'additionalData' into the uninstaller.jar. However, there is no logical place where I can see where to fill UninstallData with the contents of installer's resource/customData

Unless there is better solution, I may need to load resources/customData into UninstallData inside UninstallDataWriter ( a bit of hacky )

Comment by Tim Anderson [ 20/Dec/11 ]

Running into this from a different angle - namely uninstaller listeners not being written to the uninstaller jar.

In izpack 4.3.x, uninstaller listeners are written out by Unpacker using UnpackerBase.handleAdditionalUninstallData(UninstallData udata, List[] customData)
This is no longer available in 5.x ( as of revision ce0b55aea271fe284a7271561e82e1a85effb111 ), and its not clear to me where it should now go:

  • AutomatedInstallDataProvider has loadCustomData(...) commented out
  • Unpacker.run() has handleAdditionalUninstallData(...) commented out
  • CustomDataContainer is incomplete

Looks like it was being refactored but fell by the wayside.

Comment by Tim Anderson [ 25/Jan/12 ]

Custom data (installer listeners, uninstaller listeners, uninstaller jars and uninstaller native libs) are now read in by EventFiller and appropriate classes populated.

UninstallDataWriter has been updated to write the uninstaller listeners, jars and native libs to the uninstaller jar. Some packages required for events and Windows uninstallation are also now merged to the uninstaller.

Added 2 new integration tests:

  • com.izforge.izpack.integration.InstallerListenerTest - verifies installer listeners are invoked by the installer
  • com.izforge.izpack.integration.UninstallerListenerTest - verifies uninstaller listeners are invoked by Destroyer

Updated integration tests:

  • UninstallDataWriterTest
  • EventTest




[IZPACK-694] Panel Validator does not get called Created: 03/Sep/11  Updated: 03/Sep/11  Resolved: 03/Sep/11

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

Type: Bug Priority: Blocker
Reporter: Dan Tran Assignee: Dan Tran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently Panel's validator

<panel...>
<validator .../>
</panel>

does not get called due to 2 issues:

1. Before the validator get called, it must be checked against dynamic condition which is not currently loaded automatically ( see AbstractInstallDataProvider.loadDynamicConditions )

2. Even if dynamic condition is loaded and empty, the validation does not get call either since it is default to not calling
(see IzPanel.validatePanel )



 Comments   
Comment by Dan Tran [ 03/Sep/11 ]

fixed at

commit 26ad940b983936cf6497373236656fb718ff2603
Author: dantran <dantran@gmail.com>
Date: Fri Sep 2 21:56:31 2011 -0700

IZPACK-694 load dynamic condition, and correctly implement IzPanel.validatePanel according to its java doc. This way Panel's validator get invoked

-----------------------------------------------------------------------

Summary of changes:
.../com/izforge/izpack/installer/base/IzPanel.java | 2 +-
.../provider/AutomatedInstallDataProvider.java | 1 +
.../container/provider/GUIInstallDataProvider.java | 1 +
3 files changed, 3 insertions, 1 deletions





[IZPACK-693] izpack-ini4j junit test failures on windows Created: 02/Sep/11  Updated: 13/Dec/12  Resolved: 22/Dec/11

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

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

Attachments: Text File org.ini4j.IniTest.txt     Text File org.ini4j.OptionsTest.txt     Text File org.ini4j.spi.IniFormatterTest.txt     Text File org.ini4j.spi.IniParserTest.txt     Text File org.ini4j.spi.IniSourceTest.txt     Text File org.ini4j.spi.OptionsFormatterTest.txt     Text File org.ini4j.spi.OptionsParserTest.txt    
Number of attachments : 7

 Description   

here is the test summay

Tests in error:
testStore(org.ini4j.IniTest): parse error (at line: 3): Licensed under the Apache License, Version 2.0 (the "License");
testFormat(org.ini4j.spi.OptionsFormatterTest): parse error (at line: 3): Licensed under the Apache License, Version 2.0 (the "License");
testReadWrite(org.ini4j.RegTest): ERROR: Error accessing the registry.

Tests run: 175, Failures: 14, Errors: 3, Skipped: 0



 Comments   
Comment by Dan Tran [ 02/Sep/11 ]

can we drop izpack-ini4j and use http://ini4j.sourceforge.net/apidocs/index.html instead?

Comment by Dan Tran [ 02/Sep/11 ]

I replace izpack-ini4j with ini4j-0.5.2, after that all i need is to comment out 2 lines

public void execute() throws Exception
{
Config.getGlobal().setHeaderComment(false);
//Config.getGlobal().setEmptyLines(true);
//Config.getGlobal().setAutoNumbering(true);
checkAttributes();
readConfigurable();
readSourceConfigurable();
patchConfigurable();
executeNestedEntries();
writeConfigurable();

at SingleConfigurableTask

Comment by Dan Tran [ 02/Sep/11 ]

FYI: the same tests pass on linux

Comment by Rene Krell [ 02/Sep/11 ]

Not a good idea so far, because it breaks the expected behavior.
There are fixes and enhancements in izpack-ini4j against the ini4j, which haven't been yet backported to ini4j (although I sent patches).
I'd rather prefer to fix the failing test.

Comment by Dan Tran [ 02/Sep/11 ]

Rene, its seems like your patch is rejected http://sourceforge.net/tracker/index.php?func=detail&aid=3023687&group_id=129580&atid=715136

since ini4j has work around. my be for the long term we should try to use the work around so that we dotn have to maintain our own version of ini4j

Comment by Rene Krell [ 02/Sep/11 ]

The problem ist the changed behavior for configuration actions, which I already documented for IzPack 5 (configuration action).
It seems like the test fails due to a platform problem, trying to read from registry on a non-Windows platform. As soon as I can I'll have a look at it.

Comment by Rene Krell [ 02/Sep/11 ]

Regarding the original project - in worst case we can also put it as utility into IzPack no longer calling it ini4j.

Comment by Rene Krell [ 20/Sep/11 ]

Zarro test failures on Bamboo:
http://bamboo.ci.codehaus.org/browse/IZPACK-DEF-1145

Dan, please retry on Windows, I don't have a test platform here for it, just testing on Linux. Thx.

Comment by Dan Tran [ 20/Sep/11 ]

still failing

Tests in error:
testStore(org.ini4j.IniTest): parse error (at line: 3): Licensed under the Apache License, Version 2.0 (the "License")
;
testFormat(org.ini4j.spi.OptionsFormatterTest): parse error (at line: 3): Licensed under the Apache License, Version 2
.0 (the "License");
testReadWrite(org.ini4j.RegTest): ERROR: Error accessing the registry.

Tests run: 175, Failures: 14, Errors: 3, Skipped: 0

No sure how to can fix this issue with out a windows to test with

Comment by Rene Krell [ 20/Sep/11 ]

You are right, this was a clear hypothetical fix :-|
I will try to set up a test environment, later. Meanwhile I'll exclude the failing tests separately.

Comment by Emmanuel Hugonnet [ 04/Nov/11 ]

Most of the problems were linked to end of lines when parsing files.
Removed the SampletestRunner errors with some tests (reg permissions on windows 7 and one beanshell test)

Comment by Tim Anderson [ 20/Dec/11 ]

This is still failing on window (windows 7, JDK 1.6)
surefire reports attached

Comment by Tim Anderson [ 20/Dec/11 ]

Failures on windows

Comment by Rene Krell [ 22/Dec/11 ]

This was the final cut to throw out the izpack-ini4j module completely and move the necessary code for IzPack to izpack-util.
All dependencies to ini4j have been removed, there are no longer remaining dependencies on ini4j at all. Using parts of ini4j and override classes made no sense, there were too many cross-dependencies regarding the patches of the izpack-ini4j code against the original code.
The original unit tests have been left out completely for now, they might be reintroduced according to the needs in IzPack. I'm currently about testing the code in an IzPack-centric manner, in real-world production installers, which uses reading and writing of property and other config files and merging of XML files. I'm still on an own, private branch of IzPack 4 and merging tested changes to IzPack 5, but will use IzPack 5 in the near future for newer versions of our company project. This will stabilize it as a whole.

Comment by Rene Krell [ 22/Dec/11 ]

For those who are interested in what is the actually functional difference of the original ini4j 0.5.2 to the currently committed code in izpack-util:

  • Support preserving empty lines in config files (preserves formatting especially in big configuration files).
  • Support for automatic numbering of properties, for instance my.prop.1, my.prop.2, ... This makes it possible to add numbered property entries with without knowing the last order number in the target file, the tool does handle this for you.
  • Support for overriding the operator. The original code uses always the " = " operator for saving files, regardless which operator was in the original config file loaded (for instance ": ". This makes the code more universal for different config file formats.

Currently, the discussed code is used in the ConfigurationInstallerListener custom action, for further information see http://docs.codehaus.org/display/IZPACK/ConfigurationInstallerListener.

If the built-in code for handling Windows registry entries works fine (currently not tested by me), it could replace the native COIOSHelper code for that purpose in future.





[IZPACK-692] Put back izpack-maven-plugin-1.0 features Created: 01/Sep/11  Updated: 29/Jul/12  Resolved: 29/Jul/12

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

Type: Bug Priority: Major
Reporter: Dan Tran Assignee: Tim Anderson
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   

we should put back the features and introduce deprecation as needed.



 Comments   
Comment by Tim Anderson [ 29/Jul/12 ]

You're need to be a little more specific. What features are no longer present?

Comment by Dan Tran [ 29/Jul/12 ]

i am withdrawing this request since it is not worth to keep izpack-maven plugin backward compatible between izpack 4.3 and 5.0





[IZPACK-691] Unable to create eclipse workspace via eclipse:configure-workspace Created: 01/Sep/11  Updated: 13/Dec/12  Resolved: 13/Dec/12

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

Type: Bug Priority: Major
Reporter: Dan Tran Assignee: Dan Tran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

mvn eclipse:configure-workspace

throws this error

Failed to execute goal org.apache.maven.plugins:maven-eclipse-plugin:2.8:configure-workspace (default-cli) on project izpack: Unable to parse existing file: file://../src/eclipse-code-formatter.xml.

Can we check this file into izpack under root directory?



 Comments   
Comment by Dan Tran [ 01/Sep/11 ]

actually the format file is already under root/src dir. Just need to correct the pom

Comment by Dan Tran [ 02/Sep/11 ]

fixed at

  • Log -----------------------------------------------------------------
    commit 417cadb0128345b471e3a55202e3ff53cf81a397
    Author: dantran <dantran@gmail.com>
    Date: Thu Sep 1 18:52:56 2011 -0700

ignore eclipse ide files and directory

-----------------------------------------------------------------------





[IZPACK-690] Version 5.0 does not have Ant task Created: 31/Aug/11  Updated: 08/Sep/11  Resolved: 07/Sep/11

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

Type: Bug Priority: Minor
Reporter: mcdev1 Assignee: Julien Ponge
Resolution: Not A Bug Votes: 0
Labels: Ant
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

IzPack 5.0.0-beta8 does not include an Ant task for running IzPack through Ant.

In version 4, the Ant task is class com.izforge.izpack.ant.IzPackTask which is located in lib/compiler.jar.

I have searched all of the jars in the lib directory of version 5 and cannot find anything equivalent. Adding all of the jars to the Ant classpath does not help either.

The src directory of version 5 does include IzPackTask at src/izpack/izpack-ant/src/main/java/com/izforge/izpack/ant.



 Comments   
Comment by Julien Ponge [ 07/Sep/11 ]

I just build a fresh IzPack and it properly generates lib/izpack-ant-5.0.0-beta9-SNAPSHOT.jar whose content is just fine:

Archive:  target/izpack-ant-5.0.0-beta9-SNAPSHOT.jar
    testing: META-INF/                OK
    testing: META-INF/MANIFEST.MF     OK
    testing: com/                     OK
    testing: com/izforge/             OK
    testing: com/izforge/izpack/      OK
    testing: com/izforge/izpack/ant/   OK
    testing: com/izforge/izpack/ant/langpacks/   OK
    testing: com/izforge/izpack/ant/ConfigHolder.class   OK
    testing: com/izforge/izpack/ant/IzpackAntRunnable.class   OK
    testing: com/izforge/izpack/ant/IzPackTask$InstallerType.class   OK
    testing: com/izforge/izpack/ant/IzPackTask.class   OK
    testing: com/izforge/izpack/ant/langpacks/messages.properties   OK
    testing: com/izforge/izpack/ant/langpacks/messages_en.properties   OK
    testing: com/izforge/izpack/ant/langpacks/messages_en_AU.properties   OK
    testing: com/izforge/izpack/ant/Property.class   OK
    testing: META-INF/maven/          OK
    testing: META-INF/maven/org.codehaus.izpack/   OK
    testing: META-INF/maven/org.codehaus.izpack/izpack-ant/   OK
    testing: META-INF/maven/org.codehaus.izpack/izpack-ant/pom.xml   OK
    testing: META-INF/maven/org.codehaus.izpack/izpack-ant/pom.properties   OK
No errors detected in compressed data of target/izpack-ant-5.0.0-beta9-SNAPSHOT.jar.

Cheers

Comment by mcdev1 [ 08/Sep/11 ]

No lib/izpack-ant* file exists in the 5.0.0 distribution created by izpack-dist-5.0.0-beta8-installer.jar.

I searched izpack-dist-5.0.0-beta8-installer.jar itself and cannot find anything related to ant other than ant-1.7.1.jar and ant-launcher-1.7.1.jar.





[IZPACK-689] panel's custom action throws java.io.NotSerializableExcepti on: Created: 31/Aug/11  Updated: 02/Sep/11  Resolved: 02/Sep/11

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

Type: Bug Priority: Blocker
Reporter: Dan Tran Assignee: Dan Tran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

detail discussion and solution is at http://groups.google.com/group/izpack-user/browse_thread/thread/554a6740f84f531d



 Comments   
Comment by Dan Tran [ 02/Sep/11 ]

fixed at

commit 09aeae327ac2ab41c8687fb337728caba1772658
Author: dantran <dantran@gmail.com>
Date: Thu Sep 1 19:00:46 2011 -0700

IZPACK-689 Serialize Action to turn off exception during panel action compilation





[IZPACK-688] <jar stage=install> are ignored Created: 31/Aug/11  Updated: 03/Sep/11  Resolved: 03/Sep/11

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

Type: Bug Priority: Blocker
Reporter: Dan Tran Assignee: Dan Tran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

<jar src="..." stage="..." /> not working at all

here is indication from izpack compiler output

Merging 0 jars into installer



 Comments   
Comment by Dan Tran [ 01/Sep/11 ]

turn out the jar merge does work, here are some observations:

  • stage=install is ignored
  • stage=both only merge for installer, uninstaller does not merge
  • stage=uninstall does not merge
Comment by Dan Tran [ 03/Sep/11 ]

The root causes are:

1. stage=install and stage is empty are totally ignored

2. the compiler does keep a list of jar entry under resources/customData, but the installer never load the customData back
and therefor it does not merge the necessary content into uninstaller.jar

For this fix, i am going to split this into 2 issues. One to solve case 1 and another one to fix the uninstaller merging issue

Comment by Dan Tran [ 03/Sep/11 ]

fixed at

  • Log -----------------------------------------------------------------
    commit 34d02b2614d7aab89228d24869c7181bb48feb2c
    Author: dantran <dantran@gmail.com>
    Date: Sat Sep 3 00:01:44 2011 -0700

IZPACK-688 merge external jars into the installer regarless of its stage's value. Ensure customData resource has the list of files be merged into uninstaller.jar

-----------------------------------------------------------------------

Summary of changes:
.../izforge/izpack/compiler/CompilerConfig.java | 25 ++++++++-----------
.../compiler/packager/impl/PackagerBase.java | 6 ++++-
2 files changed, 16 insertions, 15 deletions





[IZPACK-687] IZPACK_HOME is set incorrectly or Izpack could not be located. Please set IZPACK_HOME. Created: 30/Aug/11  Updated: 23/Apr/12  Resolved: 23/Apr/12

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

Type: Bug Priority: Major
Reporter: Mulcamd Assignee: Julien Ponge
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP


Attachments: File Compile_4_3.bat     File compile_5_beta_10.bat     File Compile_5_beta_8.bat     Text File log_compile_4_3.txt     Text File log_compile_5_beta_8.txt     Text File log_compile_5_beta_8.txt    
Testcase included: yes
Number of attachments : 6

 Description   

Using the script according the documentation 4.3. version is Ok.
"c:\Program Files\IzPack_4_3\bin\compile.bat" install.xml -b . -o install.jar -k standard >log_compile_4_3.txt

Using excactly the same script with version 5 I get the error:
IZPACK_HOME is set incorrectly or Izpack could not be located. Please set IZPACK_HOME.
The script I use is:
"C:\Program Files\IzPack_Beta_8\bin\compile.bat" install.xml -b . -o install.jar -k standard >log_compile_5_beta_8.txt

Both script are executed from the C:\Program Files\IzPack_4_3\sample\simple directory.



 Comments   
Comment by Mulcamd [ 30/Aug/11 ]

Batch file used to compile the sample with version 4.3.4

Comment by Mulcamd [ 30/Aug/11 ]

Batch file to compile the sample with version 5 beta 8

Comment by Mulcamd [ 30/Aug/11 ]

Log of compiling the sample with 4.3.4.

This is Ok.

Comment by Mulcamd [ 30/Aug/11 ]

Log of compiling the sample with version 5 beta 8.

This is the error message.

Comment by Julien Ponge [ 07/Sep/11 ]

The script is probably more picky now. It tries searching for IzPack in common places when IZPACK_HOME is not set: on the system drive / program files then c: / program files.

If your setup is different then you need to set the environment variable correctly.

Comment by Mulcamd [ 14/Sep/11 ]

Based on your comment I checked it further and I think I found the problem in beta 8:
standalone-compiler.jar is not found, see line 126 in log file of the attachment.
Doing a file search in the IZpack directory there is no standalone-compiler.jar at all.

Version 5 is installed in the C:\Izpack\ directory and is correctly found.

I started the script from the sample\simple directory.
C:\Program Files\IzPack_4_3\sample\simple>if not exist C:\Izpack\lib\standalone-compiler.jar goto noIzpackHome

C:\Program Files\IzPack_4_3\sample\simple>echo IZPACK_HOME is set incorrectly or Izpack could not be located. Please set IZPACK_HOME.
IZPACK_HOME is set incorrectly or Izpack could not be located. Please set IZPACK_HOME.

Comment by Mulcamd [ 14/Sep/11 ]

Based on your comment I checked it further and I think I found the problem in beta 8:
standalone-compiler.jar is not found, see line 126 in log file of the attachment.
Doing a file search in the IZpack directory there is no standalone-compiler.jar at all.

Version 5 is installed in the C:\Izpack\ directory and is correctly found.

I started the script from the sample\simple directory.
C:\Program Files\IzPack_4_3\sample\simple>if not exist C:\Izpack\lib\standalone-compiler.jar goto noIzpackHome

C:\Program Files\IzPack_4_3\sample\simple>echo IZPACK_HOME is set incorrectly or Izpack could not be located. Please set IZPACK_HOME.
IZPACK_HOME is set incorrectly or Izpack could not be located. Please set IZPACK_HOME

Comment by Mulcamd [ 14/Sep/11 ]

See line 126 in last uploaded log file

Comment by Chris Gebert [ 20/Oct/11 ]

If you code around the missing standalone-compiler.jar, the script also refers to bin\lcp.bat, which also doesn't exist.

Comment by Daniel Abson [ 29/Mar/12 ]

The compile script works fine under 5.0.0-beta10 if you change the first test for IZPACK_HOME at lines 45-46. Since standalone-compiler.jar no longer exists, check for the existence of izpack-compiler-<VERSION_NUMBER>.jar like this:

set IZPACK_JAR=lib\izpack-compiler-*.jar

See attachment.

Comment by Julien Ponge [ 23/Apr/12 ]

Thanks!





[IZPACK-686] Registration-only mode Created: 06/Aug/11  Updated: 06/Aug/11

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

Type: Wish Priority: Major
Reporter: Marcin Wisnicki 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   

Many projects distribute both IzPack generated installer and a plain zip file for manual installation.

It would be highly desirable if IzPack could generate some sort of registration-only installer for inclusion in zip distribution.
Generated application should do the same things that are done during installation (creation of shortcuts, file type associations, add/remove registration) except actually installing anything.






[IZPACK-685] Uninstaller does not check that file deletion is successful Created: 03/Aug/11  Updated: 05/Sep/12  Resolved: 05/Sep/12

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

Type: Bug Priority: Major
Reporter: Earl Hood Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Attachments: Java Source File Izpack685UninstallListener.java    
Number of attachments : 1

 Description   

Examining the source code for 4.3.0 and latest in anonymous git, izpack
does not check that file.delete() returns a true status.

The status indicator in the uninstaller dialog gives the false impression
everything worked, but if a file (or multiple files) could not be removed
(e.g. due to permissions), no indication is provided.



 Comments   
Comment by Earl Hood [ 11/Aug/11 ]

I've attached an uninstall listener that
provides a work-around to the problem.

The listener checks after file deletion for
any files that still exist. If so, a
warning dialog is raised listing out the
files that could not be deleted.

I think IzPack itself should intrinsically
do something similar, but it is good to
know that the existing API does allow for
one to provide appropriate feedback w/o
modifying IzPack code itself.

Comment by Tim Anderson [ 02/Sep/12 ]

I've rolled the display portion of your listener into UninstallerFrame and changed the console based uninstaller to log the files not deleted.
Fix is at https://github.com/izpack/izpack/pull/65





[IZPACK-684] want to change builtin variable fileseprator Created: 27/Jul/11  Updated: 31/Aug/12

Status: Open
Project: IzPack
Component/s: Compiler, Installer, Translations, Utilities
Affects Version/s: 4.3.4
Fix Version/s: 5.0

Type: Improvement Priority: Major
Reporter: bhanu pratap Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


Number of attachments : 0

 Description   

there should be way to override file separator built in variable like app path but its not provided



 Comments   
Comment by Tim Anderson [ 19/Jul/12 ]

Why? What are you trying to do?





[IZPACK-683] Regression: jars are only merged with stage='both' attribute Created: 26/Jul/11  Updated: 03/Sep/11  Resolved: 03/Sep/11

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

Type: Bug Priority: Major
Reporter: Julien Ponge Assignee: Dan Tran
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Testcase included: yes
Number of attachments : 0

 Description   

From the mailing-list:

I did some more checks and it seems that <jar> element works but only
with attribute 'stage="both"'; the JARs are not merged into the
installer JAR if 'stage="install"'.



 Comments   
Comment by Dan Tran [ 03/Sep/11 ]

IZPACK-688





[IZPACK-682] The TreePackPanel is not displayed properly - only the first line of the tree is shown Created: 14/Jul/11  Updated: 26/Nov/11  Resolved: 07/Sep/11

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.1, 4.3.4
Fix Version/s: 4.3.5

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
Environment:

OS: Fedora 14
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.8)


Attachments: PNG File izpackissue.png     Text File izpack.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

The TreePackPanel is not displayed properly-only the first line of the tree is shown. This bug is known to exist in 4.3.4 and 4.3.1 but it might have been present in other versions as well (I only tested on 4.3.4 and 4.3.1)

This bug is related to the JDK you are using. On IBM JDK, this issue is not present. The temporary fix is to add a setPreferredSize() method to the TreePackPanel.java.



 Comments   
Comment by Julien Ponge [ 07/Sep/11 ]

Thanks!





[IZPACK-681] panelDeactivate() does not work in Finish panel Created: 13/Jul/11  Updated: 26/Aug/11  Resolved: 26/Aug/11

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

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

I am using panelDeactivate() function in my ExtendedFinishPanel, but the control never reaches in it.

---------------

/**

  • Called when the panel becomes deactive.
    */
    @Override
    public void panelDeactivate() {
    Debug.trace("in panelDeactivate!" + flag);





[IZPACK-680] IzPack installer shell icon on Mac Created: 07/Jul/11  Updated: 07/Jul/11

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

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

MAC OS X Snow Leopard & Leopard


Number of attachments : 0

 Description   

When application installer is running shell icon is presented on dock bar (instead of installer icon or IzPack icon). This also occurs when using Cmd + Tab. How can I force IzPack installer to use application icon in this case ?

Regards,
Miłosz Mazur






[IZPACK-679] dialog for downloading components show only a part of filename Created: 06/Jul/11  Updated: 06/Jul/11

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

Type: Improvement Priority: Minor
Reporter: Milosz Mazur Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MAC OS X Snow Leopard & Leopard


Number of attachments : 0

 Description   

dialog for downloading components show only a part of filename, for example:

/Users/...partoffilename.tgz

(user can see also download speed next to file name)

IzPack should allow to display component name (description?) in place of file path.






[IZPACK-678] Provision to create a Properties file with the variables substituted, before installation. Created: 05/Jul/11  Updated: 05/Jul/11

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

Type: New Feature Priority: Major
Reporter: Rohit Ganjam 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 have a lot of configurable parameters in our installer, and entering the data becomes tedious every single time. If we create an empty property file, however, its pretty easy to get confused as to which fields are absolutely necessary for the installed software to work properly, as some variables are not mandatory, and are dependent on other variable values. So the need here is to be able to generate a properties file (maybe a new panel, or a part of install panel itself), which can be used for future installations.






[IZPACK-677] Provision to create a Property file with the valiadles Created: 05/Jul/11  Updated: 05/Jul/11  Resolved: 05/Jul/11

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

Type: New Feature Priority: Major
Reporter: Rohit Ganjam 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 Rohit Ganjam [ 05/Jul/11 ]

Incomplete information





[IZPACK-676] On the 4.3.3 stream IZpack sets the timestamp of a file to be the source file last modification date. This can cause checkin problems when files added to source. Created: 01/Jul/11  Updated: 01/Jul/11

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

Type: Bug Priority: Major
Reporter: Niambh Scullion Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 12 hours
Time Spent: Not Specified
Original Estimate: 12 hours

Patch Submitted:
Yes
Number of attachments : 0

 Description   

On the 4.3.3 stream IZpack sets the timestamp of a file to be the source file last modification date. This can cause checkin problems when files added to source.



 Comments   
Comment by Niambh Scullion [ 01/Jul/11 ]

Hi Julian,
I am looking at patching the issue on a 4.3.3 codebase (if that’s OK). I suppose the first thing is I have never contributed to an Open Source Project before and am not familiar with your protocols…. Would you mind Julian sending me on some information, if available on doing this.

Secondly, what I propose is that that all files installed by IZPack should use the Install Date, rather than the source modified date. There are two benefits of this update:
1) IZpack does not get involved with FileSystem settings – this is left to the machine the application is installer to
2) A previously installed source controlled application can be successfully updated and checked in.

To meet this requirement what I propose to deliver are the following updates:

Unpacker.java/MultiVolumeUnpacker.java:
As files are being unpacked, the following check is done to determine if an update is required:
If(pf.override() == PackFile.OVERRIDE_UPDATE)

{ overwritefile = (pathFile.lastModified() < pf.lastModified() }

I propose that the time the installer is being executed is used.

If(pf.override() == PackFile.OVERRIDE_UPDATE)

{ overwritefile = (pathFile.lastModified() < System.currentTimeMillis()); }

In addition to the above check I am also proposing that the IZPack source does not set the date modified field.
The following snippet of code is removed:

// Set file modification time if specified
if (pf.lastModified() >= 0)

{ pathFile.setLastModified(pf.lastModified()); }

This means the PackFile class has a redundant property set (see below):
this.mtime = src.lastModified();

My proposed patch would remove all references of this unused property from PackFile.java.

So far, my internal testing of this update has been successful, to verify the update what I have done is:
Test A:
1) Run main application installer. Do not update file timestamps.
2) Run patch installer.
3) Files updated, as expected the Date Modified field is set to the time the installer was run.
Test B:
1) Run main application installer. Update file timestamps.
2) Run patch installer.
3) Files updated, as expected the Date Modified field is set to the time the installer was run.
Test C:
1) Run main application installer. Update file timestamps.
2) Run patch installer.
3) Files updated, as expected the Date Modified field is set to the time the installer was run.
4) Run the patch installer.
5) As the installer is running, the files being re-installed by are overwritten

Potential impact,
The only impact that I can see from making this change is as follows:
1) If I run an installer and the application timestamp is not modified.
2) Then for some reason I have to re-run the installer.
3) The previously the already installed files will be overwritten by the latest installation.

I have no problems issuing a patch for this update, as I am familiar with the IZPack source, however my scope of Installation is limited to internal requirements. My question is, are there any other impacts to this change?

Many thanks in advance,
Niambh





[IZPACK-675] Uninstaller choose escalation of privileges to quickly Created: 21/Jun/11  Updated: 20/Sep/13  Resolved: 22/Oct/11

Status: Closed
Project: IzPack
Component/s: Uninstaller
Affects Version/s: 4.3.4
Fix Version/s: 4.3.5, 5.0

Type: Bug Priority: Minor
Reporter: Fabien Nisol Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows


Attachments: Text File Uninstaller.patch     Text File Uninstaller.patch     File Uninstaller.upatch    
Patch Submitted:
Yes
Number of attachments : 3

 Description   

The uninstaller choose to escalade privileges on the assumption that it requires access to the Program Files directory on windows.
In the case where the application was installed on a directory where the user has rights, this escalation is not necessary and can cause problems.

The cause is in Uninstaller.java

 private static void checkForPrivilegedExecution()
    {
        if (PrivilegedRunner.isPrivilegedMode())
        {
            // We have been launched through a privileged execution, so stop the checkings here!
            return;
        }

        if (elevationShouldBeInvestigated())
        {
            PrivilegedRunner runner = new PrivilegedRunner();
            if (runner.isPlatformSupported() && runner.isElevationNeeded())
            {
                try
                {
                    if (runner.relaunchWithElevatedRights() == 0)
                    {
                        System.exit(0);
                    }
                    else
                    {
                        throw new RuntimeException("Launching an uninstaller with elevated permissions failed.");
                    }
                }
                catch (Exception e)
                {
                    e.printStackTrace();
                    JOptionPane.showMessageDialog(null, "The uninstaller could not launch itself with administrator permissions.\n" +
                        "The uninstallation will still continue but you may encounter problems due to insufficient permissions.");
                }
            }
            else if (!runner.isPlatformSupported())
            {
                JOptionPane.showMessageDialog(null, "This uninstaller should be run by an administrator.\n" +
                    "The uninstallation will still continue but you may encounter problems due to insufficient permissions.");
            }
        }
    }

On windows, runner.isElevationNeeded() checks systematically for access to Program Files.

public boolean isElevationNeeded()
    {
        if (vetoed)
        {
            return false;
        }

        if (OsVersion.IS_WINDOWS)
        {
            return !isPrivilegedMode() && !canWriteToProgramFiles();
        }
        else
        {
            return !System.getProperty("user.name").equals("root");
        }
    }

It is not absolutely certain the user installed the application in Program Files.

I think the code should be something like:

if (runner.isPlatformSupported()
    && !getInstallPath().canWrite()) {

which would avoid unecessary privilege escalation.

I included a patch that could do the trick



 Comments   
Comment by Fabien Nisol [ 22/Jun/11 ]

The first patch was not working

Comment by Julien Ponge [ 22/Jun/11 ]

Did you actually try the patch or not?

Cheers

Comment by Julien Ponge [ 07/Sep/11 ]

No news, hence won't fix.

Comment by Fabien Nisol [ 07/Sep/11 ]

Sorry, I did not see you question when it was asked and I forgot to check about the status of this problem.

Yes, I did test the patch and it seemed to work as expected. If the application was installed in a directory that does not need escalation when uninstallation is tried, escalation is not executed. Before the patch, it did.

Comment by Julien Ponge [ 07/Sep/11 ]

Which tool did you use to generate the patch?

I would be able to apply it if in "unified" format which is somehow standard. Thanks!

Comment by Fabien Nisol [ 07/Sep/11 ]

I used a simple diff format (diff file1 file2). I can re-issue the patch using diff -u if you prefer

Comment by Julien Ponge [ 07/Sep/11 ]

Yes please

Comment by Fabien Nisol [ 07/Sep/11 ]

patch generated using diff -u

Comment by Fabien Nisol [ 07/Sep/11 ]

Attached the patch generated using diff -u, difference with source code extracted from git jponge-izpack-v4.3.4-0-g8de14a0.zip

Comment by Julien Ponge [ 22/Oct/11 ]

Fixed for both versions, thanks!

Comment by Paul Rosen [ 20/Sep/13 ]

On Windows 7, I have found the code getInstallPath().canWrite() (in the patch above) returns true for a directory that the user cannot write to due to insufficient privileges. This causes the uninstaller not to escalate privileges when it needs to, so the uninstaller fails to do its job.

I am getting round this for now by using my own canWrite method:

+    private static boolean canWrite(String path)
+    {
+        File dir = new File(path);
+        if (!dir.canWrite())
+            return false;
+
+        //Can't rely on the above test alone, as it has proved unreliable in Windows 7.
+        File dummy = new File(path,"empty.txt");
+        try
+        {
+            //Create and delete a dummy file in order to check file permissions.
+            dummy.createNewFile();
+            dummy.delete();
+        }
+        catch(IOException e)
+        {
+            return false;
+        }
+        return true;
+    }

To integrate, I made the following changes:

     /**
      * Gets the installation path from the log file.
      *
      * @throws Exception Description of the Exception
      */
-    private static File getInstallPath() {
+    private static String getInstallPath() {
         try {
             InputStream in = Uninstaller.class.getResourceAsStream("/install.log");
             InputStreamReader inReader = new InputStreamReader(in);
             BufferedReader reader = new BufferedReader(inReader);
             String installPath = reader.readLine();
             reader.close();
-            return new File(installPath);
+            return installPath;
         } catch (IOException ex) {
             throw new RuntimeException(ex);
         }
     }

     private static boolean isElevationNeeded() {
-        return !getInstallPath().canWrite();
+        return !canWrite(getInstallPath());
     }





[IZPACK-674] Error with the IzPack ProcessPanel when process is in errror Created: 20/Jun/11  Updated: 01/Sep/12  Resolved: 01/Sep/12

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

Type: Bug Priority: Major
Reporter: Emmanuel Hugonnet Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux 64 bits


Number of attachments : 0

 Description   

When a script is failing is ProcessPanel I got the following exception and the OptionPane is not displayed :
org.pushingpixels.substance.api.UiThreadingViolationException: Component creation must be done on Event Dispatch Thread
at org.pushingpixels.substance.internal.utils.SubstanceCoreUtilities.testComponentCreationThreadingViolation(SubstanceCoreUtilities.java:1921)
at org.pushingpixels.substance.internal.ui.SubstanceOptionPaneUI.createUI(SubstanceOptionPaneUI.java:82)
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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:37)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:244)
at javax.swing.UIDefaults.getUI(UIDefaults.java:752)
at javax.swing.UIManager.getUI(UIManager.java:989)
at javax.swing.JOptionPane.updateUI(JOptionPane.java:1859)
at javax.swing.JOptionPane.<init>(JOptionPane.java:1822)
at javax.swing.JOptionPane.showOptionDialog(JOptionPane.java:841)
at javax.swing.JOptionPane.showConfirmDialog(JOptionPane.java:779)
at javax.swing.JOptionPane.showConfirmDialog(JOptionPane.java:741)
at com.izforge.izpack.installer.base.IzPanel.askQuestion(IzPanel.java:419)
at com.izforge.izpack.panels.process.ProcessPanelWorker$ExecutableFile.run(ProcessPanelWorker.java:501)
at com.izforge.izpack.panels.process.ProcessPanelWorker$ProcessingJob.run(ProcessPanelWorker.java:397)
at com.izforge.izpack.panels.process.ProcessPanelWorker.run(ProcessPanelWorker.java:309)



 Comments   
Comment by Tim Anderson [ 29/Aug/12 ]

This is occurring because the process panel worker thread is triggering the error dialog display outside of the event dispatch thread.
The Substance L&F doesn't like this; background can be found at http://www.pushing-pixels.org/2008/07/15/stricter-checks-on-edt-violations-in-substance.html
A workaround is to use a different L&F.

Comment by Tim Anderson [ 31/Aug/12 ]

Fix is at https://github.com/izpack/izpack/pull/64





[IZPACK-673] ShortcutPanel does not work on 64-bit Windows 7 Created: 16/Jun/11  Updated: 13/Feb/13  Resolved: 13/Feb/13

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

Type: Bug Priority: Major
Reporter: Casey Jones Assignee: Tim Anderson
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64, IzPack 4.3.4


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

 Description   

When I try to run an IzPack installer I created on Windows 7 x64 the shortcut panel displays nothing and it outputs a backtrace on the command line (backtrace attached). I tried the same installer on a 32-bit install of Windows 7 and it worked as expected.

The only clue the backtrace gave me was "java.lang.Exception: error loading library" as well as "java.lang.Exception: can't locate library".
I don't know what library it's looking for, however.



 Comments   
Comment by Tim Anderson [ 27/Jan/12 ]

Have you included the x64 versions of the dlls in your install.xml?
E.g.

<native type="izpack" name="ShellLink.dll"/>
<native type="izpack" name="ShellLink_x64.dll"/>




[IZPACK-672] izpack2exe parameter 'launch-file' broken by IZPACK-647 Created: 09/Jun/11  Updated: 31/Aug/12  Resolved: 31/Aug/12

Status: Resolved
Project: IzPack
Component/s: Utilities
Affects Version/s: 4.3.4, 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Eric Thomas Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Attachments: Zip Archive izpack2exe_py_et_20110609.zip    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The changes to "utils\wrappers\izpack2exe\izpack2exe.py" via issue IZPACK-647 have broken the functionality of the 'launch-file' parameter. In the previous version, with modifications from Ben Golding, the parameter was working, but the installer jar-file launch was dependent on the ".jar" file type being associated with Java. The IZPACK-647 changes addressed this by launching the jar-file via 'javaw'.

I believe the attached version of "izpack2exe.py" will address the IZPACK-647 issue and keep the 'launch-file' parameter functional. If 'launch-file' is not used then the jar-file is launched using 'javaw'. Also, I've removed the "\r" strings from the generated line-ends, as these just resulted in "\r\r\n" line-ends in the generated "config.txt" file.



 Comments   
Comment by Julien Ponge [ 07/Sep/11 ]

Sounds globally good and sorry to get back to you just now.

Why do you change things like:

-                      default="launcher.exe",
+                      default="",
Comment by Eric Thomas [ 07/Sep/11 ]

The script needs to do the default action of launching via "javaw -jar" if the 'launch-file' parameter is not given on the command line. If it is given then it's used for the launch of the installer. (I think the "launcher.exe" filename was some kind of sample value; it won't apply to most setups.)

The 'filename' variable is only used with the "javaw -jar" command, so it didn't make sense to set it to "settings.launch" when 'launch-file' is used.

--ET

Comment by Tim Anderson [ 31/Aug/12 ]

Patch was applied in revision d0a38b90f3ea54d84a95e2885bc112653a2f8cda on 22/10/11





[IZPACK-671] Invalid base directory Created: 26/May/11  Updated: 21/Aug/11  Resolved: 26/May/11

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

Type: Bug Priority: Blocker
Reporter: Daniel Svennberg Assignee: Julien Ponge
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   

When running:

<plugin>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-maven-plugin</artifactId>
<version>5.0.0-beta7</version>
<configuration>
<installFile>target/staging/install.xml</installFile>
</configuration>
<executions>
<execution>
<id>windows-installer</id>
<phase>package</phase>
<goals>
<goal>izpack</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-standalone-compiler</artifactId>
<version>4.3.4</version>
</dependency>
</dependencies>
</plugin>

I get the following error:

[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] com.izforge.izpack.compiler.CompilerException: Invalid base directory: C:\myprogram\target\staging\install.xml
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.AssertionError: com.izforge.izpack.compiler.CompilerException: Invalid base directory: C:\myprogram\target\staging\install.xml
at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:94)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
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)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:115)
Caused by: com.izforge.izpack.compiler.CompilerException: Invalid base directory: C:\myprogram\target\staging\install.xml
at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(Unknown Source)
at org.izpack.mojo.IzPackNewMojo.execute(IzPackNewMojo.java:90)
... 23 more



 Comments   
Comment by Julien Ponge [ 26/May/11 ]

Mixing 4.3.4 and 5.0.0-beta7 plugins is probably not a very good idea.

You should choose either version and go from here, as the Maven plugins are not the same between the 2.

Cheers

Comment by Daniel Svennberg [ 26/May/11 ]

Thanks for fast answer, I removed the dependency to 4.3.4 standalone-compiler and it worked!

Comment by Manos Batsis [ 21/Aug/11 ]

Thanks, worked for me as well. I followed examples found online and updated to what I saw as recent versions so others my stumble upon this one.





[IZPACK-670] Console installer does nothing Created: 21/May/11  Updated: 18/Jan/12  Resolved: 18/Jan/12

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

Type: Bug Priority: Blocker
Reporter: Tom Grünheit Assignee: Julien Ponge
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 32bit


Attachments: Java Source File AbstractPanelConsoleHelper.java     Java Source File DelegatePanelConsoleHelper.java     Java Source File JDKPathPanelConsoleHelper.java     Java Source File TargetPanelConsoleHelper.java    
Number of attachments : 4

 Description   

I use the install.xml from http://docs.codehaus.org/display/IZPACK/Writing+Installation+Descriptions:

<installation version="1.0">

  <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="plain" targetdir="${INSTALL_PATH}" override="true"/>
      <parsable targetfile="${INSTALL_PATH}/test.properties"/-->
    </pack>
  </packs>

</installation>

When I run IzPack 5.0.0-beta5 compiler on it with:

compile c:\projects\test25\src\main\resources\install.xml -b c:\projects\test25\target\staging

I have installer.jar created. But when I launch it it silently fails.
If I launch it through:

java -classpath install.jar com.izforge.izpack.installer.bootstrap.Installer

I get

c:\Program Files\IzPack\bin>java -classpath install.jar com.izforge.izpack.installer.bootstrap.Installer
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider loadLookAndFeel
INFO: Using laf org.pushingpixels.substance.api.skin.SubstanceMistAquaLookAndFeel
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: PanelUI : org.pushingpixels.substance.internal.ui.SubstancePanelUI
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: ClassLoader : null
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: Cached class : null
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: Using system loader to load org.pushingpixels.substance.internal.ui.SubstancePanelUI
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: Done loading
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: Loaded class : org.pushingpixels.substance.internal.ui.SubstancePanelUI
Exception in thread "AWT-EventQueue-0" com.izforge.izpack.api.exception.IzPackException: com.izforge.izpack.api.exception.MergeException: Could not find class TargetPanel : Current classpath is
        at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:57)
        at java.awt.event.InvocationEvent.dispatch(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: com.izforge.izpack.api.exception.MergeException: Could not find class TargetPanel : Current classpath is
        at com.izforge.izpack.merge.resolve.ClassPathCrawler.searchClassInClassPath(ClassPathCrawler.java:125)
        at com.izforge.izpack.installer.manager.PanelManager.loadPanelsInContainer(PanelManager.java:72)
        at com.izforge.izpack.installer.base.InstallerController.preloadInstaller(InstallerController.java:30)
        at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:50)
        ... 8 more

If I add ..\lib* to the classpath explicitly during running the installer, it works perfectly:

java -classpath install.jar;..\lib\* com.izforge.izpack.installer.bootstrap.Installer


 Comments   
Comment by Tom Grünheit [ 21/May/11 ]

I'm using the izpack-maven-plugin 5.0.0-beta7 and I still have the problem.

Here the output of the Maven Plugin

[INFO] — izpack-maven-plugin:5.0.0-beta7:izpack (default) @ xxxx —
<?xml version="1.0" encoding="UTF-8"?><installation version="1.0">

<info>
<appname>TestInstaller</appname>
<appversion>1</appversion>
<uninstaller write="no"/>
<javaversion>1.6</javaversion>
</info>

<variables>
<variable name="InstallerFrame.logfilePath" value="$INSTALL_PATH/install.log"/>
</variables>

<guiprefs resizable="no" width="480" height="360">
<laf name="looks">
<param name="variant" value="windows"/>
<os family="windows"/>
</laf>
</guiprefs>

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

<panels>
<panel classname="TargetPanel"/>
<panel classname="InstallPanel"/>
<panel classname="SimpleFinishPanel"/>
</panels>

<packs>
<pack name="core" required="yes">
<description>MCCore2 packages</description>
<fileset dir="app" targetdir="$

{INSTALL_PATH}/app" override="true"/>
</pack>

<pack name="web" required="yes">
<description>WEB Applications</description>
<fileset dir="webapp" targetdir="${INSTALL_PATH}

/webapp" override="true"/>
</pack>

</packs>

</installation>
Setting the installer information
Setting the GUI preferences
Adding langpack: eng
Adding resource: flag.eng
Adding panel: UNKNOWN (TargetPanel) :: Classname : TargetPanel
Adding panel: UNKNOWN (InstallPanel) :: Classname : InstallPanel
Adding panel: UNKNOWN (SimpleFinishPanel) :: Classname : SimpleFinishPanel
[ Begin ]

Copying the skeleton installer
Copying 2 files into installer
Merging 0 jars into installer
Writing 2 Packs into installer
Writing Pack 0: core
Writing Pack 1: web

[ End ]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

Here the Exception when I execute the installer:

java -jar installer.jar

Exception in thread "AWT-EventQueue-0" com.izforge.izpack.api.exception.IzPackException: com.izforge.izpack.api.exception.MergeException: Could not find class TargetPanel : Current classpath is
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:57)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
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.MergeException: Could not find class TargetPanel : Current classpath is
at com.izforge.izpack.merge.resolve.ClassPathCrawler.searchClassInClassPath(ClassPathCrawler.java:125)
at com.izforge.izpack.installer.manager.PanelManager.loadPanelsInContainer(PanelManager.java:72)
at com.izforge.izpack.installer.base.InstallerController.preloadInstaller(InstallerController.java:30)
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:50)
... 8 more

jar -tvf installer.jar|grep TargetPanel

2373 Fri Apr 29 09:51:02 CEST 2011 com/izforge/izpack/panels/target/TargetPanel.class
2148 Fri Apr 29 09:51:02 CEST 2011 com/izforge/izpack/panels/target/TargetPanelAutomationHelper.class
3553 Fri Apr 29 09:51:02 CEST 2011 com/izforge/izpack/panels/target/TargetPanelConsoleHelper.class

Comment by Julien Ponge [ 07/Jun/11 ]

Can you try with a beta8-SNAPSHOT?

Comment by Tom Grünheit [ 07/Jun/11 ]

Gui installer works with beta8-SNAPSHOT.

But console mode does nothing. It directly shows "[ Console installation done ]" without asking for target directory or copying files.

Comment by Dan Tran [ 03/Sep/11 ]

confirm that console mode ( java -jar installer-xyz.jar -console ) does nothing, and ends with "[ Console installation done ]"

I am going to rename the topic to get better meaning

Comment by Martin Michna [ 03/Jan/12 ]

Problem is in your configuration. PLS change your configuration:

<panels>
  <panel classname="TargetPanel"/> <!-- Missing empty constructor -->
  <panel classname="com.izforge.izpack.panels.install.InstallPanel"/>
  <panel classname="com.izforge.izpack.panels.simplefinish.SimpleFinishPanel"/>
</panels>

Second problem is with JDKPathPanelConsoleHelper and TargetPanelConsoleHelper console helpers - because missing empty constructor. I fixed this problem using delegate console helper. See java classes in attachement

But there is still NPE problem in com.izforge.izpack.installer.console.ConsoleInstaller.ConsoleInstaller(AutomatedInstallData, RulesEngine, ResourceManager, ConditionCheck)

public ConsoleInstaller(AutomatedInstallData installdata, RulesEngine rules, ResourceManager resourceManager, ConditionCheck checkCondition) throws Exception
{
...
    this.rules = rules;
...
    this.rules = this.installdata.getRules(); //------ bad code
//------ new code: this.installdata.setRules(this.rules);
}
Comment by Julien Ponge [ 18/Jan/12 ]

Fixed in https://github.com/jponge/izpack/pull/9





[IZPACK-669] Console mode doesn't work Created: 18/May/11  Updated: 03/Mar/12  Resolved: 03/Mar/12

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

Type: Bug Priority: Major
Reporter: Julien CARSIQUE Assignee: Tim Anderson
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Using izpack-maven-plugin 5.0.0-beta8-SNAPSHOT, installation still doesn't work in console mode.

On a headless server, I got the HeadlessException with or without "-console" keyword:
$ java -jar nuxeo-cap-5.4.2-RC1-tomcat-izpack-installer.jar

  • ERROR -
    java.awt.HeadlessException:
    No X11 DISPLAY variable was set, but this program performed an operation which requires it.
    java.awt.HeadlessException:
    No X11 DISPLAY variable was set, but this program performed an operation which requires it.
    at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:159)
    at java.awt.Window.<init>(Window.java:432)
    at java.awt.Frame.<init>(Frame.java:403)
    at java.awt.Frame.<init>(Frame.java:368)
    at javax.swing.JFrame.<init>(JFrame.java:158)
    at com.izforge.izpack.installer.container.impl.InstallerContainer.initFrame(InstallerContainer.java:103)
    at com.izforge.izpack.installer.container.impl.InstallerContainer.fillContainer(InstallerContainer.java:84)
    at com.izforge.izpack.core.container.AbstractContainer.initBindings(AbstractContainer.java:25)
    at com.izforge.izpack.installer.bootstrap.Installer.initContainer(Installer.java:74)
    at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:183)
    at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:149)
    at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:62)

On a desktop computer, using the "-console", there's no issue raised but nothing seems to happen:
$ java -jar target/nuxeo-cap-5.4.2-RC1-tomcat-izpack-installer.jar -console
[ Console installation done ]



 Comments   
Comment by Tim Anderson [ 18/Feb/12 ]

In console mode, izpack looks for classes named com.izforge.izpack.panels.<Panel Name>ConsoleHelper that implement the console equivalent of the panel.
If the class cannot be found, the panel is skipped.
In 5.0, packages have been moved round and the panels are no longer in the expected com.izforge.izpack.panels package.

The compiler should be emitting the fully qualified class name of the panel so this kind of guesswork is not required.

Comment by Tim Anderson [ 27/Feb/12 ]

The compiler now emits fully qualified class names, so the console installer doesn't need to guess as to their package names.

Comment by Tim Anderson [ 29/Feb/12 ]

The console dependency on swing based components still exists.
Need to refactor InstallerContainer into a GUI and console version, and any classes required by both that use swing (e.g. ConditionCheck)

Comment by Rene Krell [ 29/Feb/12 ]

The Swing installation on a headless server could be worked around setting the java.awt.headless=true JVM system property on the command line, thus:

java -Djava.awt.headless=true -jar nuxeo-cap-5.4.2-RC1-tomcat-izpack-installer.jar

This is of course just a temporary solution, unless it is fixed.

Comment by Tim Anderson [ 03/Mar/12 ]

Some of the classes used by the console installer displayed swing dialogs on error - these have now been split into console and GUI implementations.





[IZPACK-668] Add ability to attach the artifact Created: 17/May/11  Updated: 18/Oct/13  Resolved: 22/Jan/13

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

Type: New Feature Priority: Minor
Reporter: Julien CARSIQUE 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   

Before 5.0, that feature was managed with "attach" property.

This feature is required at least for signing Jar files.
Currently, the workaround in that case is to use "archive" or "archiveDirectory" properties of maven-jarsigner-plugin.



 Comments   
Comment by Rene Krell [ 01/Oct/12 ]

Please have a look at:
http://docs.codehaus.org/display/IZPACK/IzPack+Maven+Plugin+Reference

Isn't already there what you're looking for at least with the current development snapshot?

Comment by Rene Krell [ 22/Jan/13 ]

Please try 5.0.0-beta11 or the recent 5.0.0-rc1-SNAPSHOT from master. Attaching the installer as artifact can be done by enableAttachArtifact=true according to the documentation mentioned above. Otherwise there is no need to do more from my point of view. Please reopen if the current behavior is not what you imagine to do.





[IZPACK-667] When using conditions with expressions (+, |, \\, !) the condition's AutomatedInstallData is set to null Created: 13/May/11  Updated: 26/Nov/11  Resolved: 13/Aug/11

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

Type: Bug Priority: Major
Reporter: Sergiy Shyrkov Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Attachments: File patch.diff    
Number of attachments : 1

 Description   

Method com.izforge.izpack.rules.RulesEngine.getConditionByExpr(StringBuffer) when creates "and", "or", "not" and "xor" conditions calls first the constructor only only after sets the AutomatedInstallData instance, i.e.:

result = new AndCondition(op1, getConditionByExpr(conditionexpr));
result.setInstalldata(RulesEngine.installdata);

The AndCondition constructor itself does the following:

this.leftoperand = operand1;
if (this.leftoperand != null)

{ this.leftoperand.setInstalldata(this.installdata); }

at that point the this.installdata of the AndCondition is null, because it was not initialized yet.

This results in conditions being evaluated to false.

I would suggest to add "AutomatedInstallData instance" as an additional constructor parameter to those "and", "or", "not" and "xor" condition classes.

Thank you in advance!

Kind regards
Sergiy Shyrkov



 Comments   
Comment by Sergiy Shyrkov [ 13/May/11 ]

Attaching an approximate diff for the patch

Comment by Sergiy Shyrkov [ 20/Jul/11 ]

I've sent a pull request for the change: https://github.com/jponge/izpack/pull/3
Thank you!





[IZPACK-666] Console mode fails with TransformerException Created: 03/May/11  Updated: 05/May/11  Resolved: 05/May/11

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

Type: Bug Priority: Major
Reporter: Tom Grünheit Assignee: David Duponchel
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


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

 Description   

I'm using izpack-maven-plugin : 5.0.0-beta7

GUI Installation works (java -jar installer.jar)
Console mode fails with following Exception (java -jar installer.jar -console)

ERROR:  ''
ERROR:  'com.sun.org.apache.xml.internal.utils.WrappedRuntimeException'
- ERROR -
com.izforge.izpack.api.adaptator.XMLException: javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException
com.izforge.izpack.api.adaptator.XMLException: javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException
  at com.izforge.izpack.api.adaptator.impl.XMLParser.parseLineNrFromInputSource(XMLParser.java:167)
  at com.izforge.izpack.api.adaptator.impl.XMLParser.parse(XMLParser.java:184)
  at com.izforge.izpack.api.data.LocaleDatabase.add(LocaleDatabase.java:89)
  at com.izforge.izpack.api.data.LocaleDatabase.<init>(LocaleDatabase.java:74)
  at com.izforge.izpack.installer.console.ConsoleInstaller.<init>(ConsoleInstaller.java:81)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
  at org.picocontainer.injectors.AbstractInjector.newInstance(AbstractInjector.java:147)
  at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:332)
  at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:269)
  at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:354)
  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:40)
  at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:184)
  at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:149)
  at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:62)
Caused by: javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException
  at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:719)
  at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313)
  at com.izforge.izpack.api.adaptator.impl.XMLParser.parseLineNrFromInputSource(XMLParser.java:146)
  ... 21 more
Caused by: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException
  at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(TransformerImpl.java:546)
  at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:709)
  ... 23 more
Caused by: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException
  at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:446)
  at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:234)
  at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(TransformerImpl.java:524)
  ... 24 more


 Comments   
Comment by Tom Grünheit [ 04/May/11 ]

GUI installation fails also with the same Exception if I provide an options file (-options install.properties).

Comment by David Duponchel [ 05/May/11 ]

Corrected for both cases, thanks for the bug report.





[IZPACK-665] Wrong Data is read from autoinstall.xml if panel of same class is disabled by os condition Created: 03/May/11  Updated: 02/May/13  Resolved: 02/May/13

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

Type: Bug Priority: Major
Reporter: Patrick Zbinden Assignee: Rene Krell
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

does not matter


Number of attachments : 0

 Description   

I have multiple UserInputPanels. If one of them is disabled by os condition then the next UserInputPanel gets the wrong XML-root to parse for input variables.

As I can see, the problem is that panelInstanceCount is not incremented in that case.
I'll submit a patch as suggestion.



 Comments   
Comment by Patrick Zbinden [ 03/May/11 ]

Have problems with git, so I'll explain my suggestion:
In AutomatedInstaller.doInstall method, after if (!OsConstraintHelper.oneMatchesCurrentSystem(p.getOsConstraints()))
just a continue is done. This is not correct. We need to increment panelInstanceCount also, as done in the block before:
if (this.panelInstanceCount.containsKey(p.className))

{ // get number of panel instance to process this.panelInstanceCount.put(p.className, this.panelInstanceCount.get(p.className) + 1); }

else

{ this.panelInstanceCount.put(p.className, 1); }

continue;

Best would be to extract the logic in a method and call this one.

Another idea: Would it not be better just to use panel id's. Of course, people would be forced to use unique panel id's, but it would simplify a lot

Thank you in advance
Patrick

Comment by Rene Krell [ 01/May/13 ]

Is this still relevant at all in the 4.X branch?

Regarding:

Another idea: Would it not be better just to use panel id's. Of course, people would be forced to use unique panel id's, but it would simplify a lot

The panel instance and order numbers (order numbers are no longer parsed, but ignored) have been removed in IzPack 5.0, panel IDs are required in install.xml and the UserInputSpec resource and cross-checked now. Please retry with this version, if possible.

Comment by Patrick Zbinden [ 02/May/13 ]

Hi Rene

For us it is not relevant anymore, as we consequently use panel id's. And if it is solved in IzPack 5.0 it is ok for us

Regards
Patrick

Comment by Rene Krell [ 02/May/13 ]

Thank you. For 4.x this might still be problematic, but I'd not make a big deal of it, people might migrate in the near future. If anyone gets into similar trouble please reopen.





[IZPACK-664] No longer builds in Maven 2.1.1 Created: 19/Apr/11  Updated: 27/Apr/11  Resolved: 27/Apr/11

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

Type: Bug Priority: Minor
Reporter: Phillip Davey Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Fedora Core 14 x64


Number of attachments : 0

 Description   

Commit 071143d2e1c623aa31002c68751b2823f370185c introduces the maven-site-plugin with a version that requires Maven 3. Is izpack dropping Maven 2.1+ support? The main site (izpack.org) under the section "Developers" states that izpack is build-able with Maven 2.1+ or Maven 3.



 Comments   
Comment by Julien Ponge [ 22/Apr/11 ]

Ok, I am on Maven 3 so I had to upgrade the plugin version. This is not an intended drop of v2.1+.

Would you be able to create a patch with a profile for 2.1?

Comment by Julien Ponge [ 27/Apr/11 ]

I found a profile on the maven-site-plugin page. You should now be able to build again with Maven 2.1.1





[IZPACK-663] Using native libraries on Mac not working Created: 19/Apr/11  Updated: 22/Feb/12

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

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

Max Os X


Number of attachments : 0

 Description   

Cannot use native libraries with IzPack on Mac Os. On Mac, the native libraries are usually
called libMyLibrary.jnilib. To load it one would use code like System.loadLibrary("MyLibrary"). Notice that the lib prefix is missing. TargetFactory.LIBRARY_EXTENSION should be completed to include jnilib extension for Mac. Also, Librarian.loadArchSpecificLibrary() should be modified to deal with the lib prefix.



 Comments   
Comment by Julien Ponge [ 19/Apr/11 ]

Good point... if you can investigate this then it would be awesome

Comment by Guillaume Chauvet [ 22/Feb/12 ]

Same problem under Linux with my own 3rd shared library. To fix it, I changed LIBRARY_EXTENSION in TargetFactory by :
static final String[] LIBRARY_EXTENSION =

{"dll", "so", "so", ""}

;





[IZPACK-662] Uninstall jar is being created with ZipOutputStream rather than JarOutputStream, causes jexec to fail Created: 06/Apr/11  Updated: 10/Apr/11  Resolved: 10/Apr/11

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

Type: Bug Priority: Minor
Reporter: Cory Downey Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Attachments: Text File uninstaller_jaroutputstream.patch    
Number of attachments : 1

 Description   

com.izforge.izpack.installer.data.UninstallDataWriter creates the uninstall jar using java.util.zip.ZipOutputStream. It should be using java.util.jar.JarOutputStream. JarOutputStream extends ZipOutputStream. The JarOutputStream adds an extra field to the entries that contain a magic number 0xCAFE. jexec looks for this magic number to determine if the binary file is an executable jar. jexec is a linux kernel service that allows executing a java jar file (that has user execute permission) without directly invoking java.

For example, rather than typing:
$ java -jar uninstaller.jar

a user only needs to type
$ ./uninstaller.jar

Trying to execute the uninstaller jar created using the ZipOutputStream causes the following error:
invalid file (bad magic number): Exec format error

Suggested solution:
Replace uses of ZipOutputStream/ZipEntry/ZipException with JarOutputStream/JarEntry/JarException in com.izforge.izpack.installer.data.UninstallDataWriter. Changes may also need to be made in com.izforge.izpack.api.data.AutomatedInstallData.

I can try to create a patch, but I am still trying to get familiar with git

jexec Reference
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6211008



 Comments   
Comment by Cory Downey [ 08/Apr/11 ]

git patch file

Comment by Julien Ponge [ 10/Apr/11 ]

Thanks!





[IZPACK-661] JDKPathPanel fails on console JDK path check on Mac OS X Created: 04/Apr/11  Updated: 29/Apr/11  Resolved: 10/Apr/11

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

Type: Bug Priority: Major
Reporter: Samuel García Martínez Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS X and Java 1.6.0


Number of attachments : 0

 Description   

Running a console version, when you select a valid JDK path (or even default, which due to this check is blank) the following error appears:

"Path /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/ is not valid."

According to JDKPathPanelConsoleHelper ( http://git.codehaus.org/gitweb.cgi?p=izpack.git;a=blob;f=izpack-panel/src/main/java/com/izforge/izpack/panels/jdkpath/JDKPathPanelConsoleHelper.java;h=69608c1f35e50c67d98d7b693ebe801228509b6d;hb=cb3628f4dd9b80b6953a10a4c8bb06c33ed645d1 ) this occurs due an existence check for lib/tools.jar file. In Mac OS X, JVM has its own structure, and this file does not exist.



 Comments   
Comment by Samuel García Martínez [ 04/Apr/11 ]

Related to IZPACK-636

Comment by Julien Ponge [ 10/Apr/11 ]

I am closing the issue as a linked issue is resolved.





[IZPACK-660] ProcessPanelWorker does not clear old jobs, it keeps adding additional jobs Created: 31/Mar/11  Updated: 29/Apr/11  Resolved: 12/Apr/11

Status: Closed
Project: IzPack
Component/s: Installer, Panels
Affects Version/s: 4.3.3
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Minor
Reporter: Manny Lim Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All platforms


Attachments: Text File ProcessPanel.patch.txt     Text File ProcessPanelWorker.patch.txt    
Number of attachments : 2

 Description   

The com.izforge.izpack.installer.ProcessPanelWorker maintains a list of the jobs that it will execute (ArrayList<ProcessingJob> jobs). When the ProcessPanelWorker runs, it parses the ProcessPanel.Spec.xml to create jobs for the currently selected packs (AutomatedInstallData.selectedPacks) and adds them to the list. Unfortunately, this list is never cleared. Each time the ProcessPanelWorker runs, it will keep adding or re-adding jobs to this list.

We use the ProcessPanel to execute 3rd party installers based on a user's selection from the PacksPanel (via executeForPack in ProcessPanel.Spec.xml). If I allow users to navigate back to the PacksPanel to revise their packs selection, the jobs for the new selection are added on to this list of jobs. When the user proceeds to the ProcessPanel again, the old jobs will still be executed and the total number of jobs will be the sum of the old jobs and the new jobs. For example (assuming 1 job per pack), if I choose pack A, the process panel will show 1, but if I go back and select packs B and C and de-select pack A, the process panel will now show 3 rather than 2 and it will execute the jobs for packs A, B and C.

I believe the jobs list should be cleared each time before the ProcessPanelWorker parses the ProcessPanel.Spec.xml.



 Comments   
Comment by Julien Ponge [ 10/Apr/11 ]

Would you be able to contribute a patch?

Comment by Manny Lim [ 11/Apr/11 ]

I've attached two patches. ProcessPanelWorker.patch.txt will clear the jobs list before parsing the ProcessPanel.Spec.xml. ProcessPanel.path.txt zeroes out the "currentJob", which was continuing to increment every time the user returned to the ProcessPanel. Please review them, thanks.

Comment by Julien Ponge [ 12/Apr/11 ]

Wonderful, I even was able to forward-port to v5!





[IZPACK-659] Exception with izpack 5.0 and ant integration Created: 30/Mar/11  Updated: 27/Jan/12  Resolved: 27/Jan/12

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

Type: Bug Priority: Major
Reporter: Mehul Sanghvi Assignee: Tim Anderson
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian/testing, Apache Ant version 1.8.0 compiled on March 11 2010, java version "1.6.0_24"


Number of attachments : 0

 Description   

With IzPack 5.0, standalone-compiler.jar no longer seems to be
there anymore. I tried the following:

<!-- IzPack related setup -->
<property name="izpack.home" value="/usr/local/IzPack" />
<path id="izpack.classpath">
<fileset dir="$

{izpack.home}

/lib" >
<include name="*.jar" />
</fileset>
</path>
<taskdef name="izpack"
classpathref="izpack.classpath"
classname="com.izforge.izpack.ant.IzPackTask"
/>

% ant
Buildfile: build.xml

fubar-selection:
[izpack] <?xml version="1.0" encoding="UTF-8"?><installation version="1.0">
[izpack] <info>
[izpack] <appname>fubar-selection</appname>
[izpack] <appversion>1.0</appversion>
[izpack] <authors>
[izpack] <author email="info@fubar.org" name="FuBar"/>
[izpack] </authors>
[izpack] <url>http://www.fubar.org</url>
[izpack] <uninstaller name="Uninstaller.jar" write="yes"/>
[izpack] <javaversion>1.5</javaversion>
[izpack] <requiresjdk>no</requiresjdk>
[izpack] <writeinstallationinformation>yes</writeinstallationinformation>
[izpack] <pack200/>
[izpack] <run-privileged condition="izpack.windowsinstall.vista|izpack.windowsinstall.7"/>
[izpack] </info>
[izpack] <guiprefs height="480" resizable="no" width="640">
[izpack] <modifier key="useFlags" value="yes"/>
[izpack] <modifier key="langDisplayType" value="default"/>
[izpack] <modifier key="headingPanelCounter" value="progressbar"/>
[izpack] <modifier key="headingPanelCounterPos" value="inNavigationPanel"/>
[izpack] </guiprefs>
[izpack] <locale>
[izpack] <langpack iso3="eng"/>
[izpack] </locale>
[izpack] <listeners>
[izpack] <listener installer="RegistryInstallerListener" uninstaller="RegistryUninstallerListener">
[izpack] <os family="windows"/>
[izpack] </listener>
[izpack] </listeners>
[izpack]
[izpack] <dynamicvariables>
[izpack] <variable name="ConfigNames" checkonce="true" regkey="HKLM\\SOFTWARE
FuBar" regvalue="Configurations"/>
[izpack] </dynamicvariables>
[izpack]
[izpack] <native type="3rdparty" name="COIOSHelper.dll" stage="both">
[izpack] <os family="windows"/>
[izpack] </native>
[izpack] <resources>
[izpack] <res id="userInputSpec.xml" src="fubar-selection_userInputSpec.xml"/>
[izpack] </resources>
[izpack] <panels>
[izpack] <panel classname="UserInputPanel"/>
[izpack] </panels>
[izpack] <packs>
[izpack] <pack name="fubar" preselected="no" required="no">
[izpack] <description/>
[izpack] </pack>
[izpack] </packs>
[izpack] </installation>
[izpack] Exception in thread "Thread-2" com.thoughtworks.xstream.converters.ConversionException: native : native : native : native
[izpack] ---- Debugging information ----
[izpack] message : native : native
[izpack] cause-exception : com.thoughtworks.xstream.mapper.CannotResolveClassException
[izpack] cause-message : native : native
[izpack] class : com.izforge.izpack.api.data.binding.IzpackProjectInstaller
[izpack] required-type : com.izforge.izpack.api.data.binding.IzpackProjectInstaller
[izpack] path : /installation/native
[izpack] line number : 35
[izpack] -------------------------------
[izpack] at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:89)
[izpack] at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63)
[izpack] at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76)
[izpack] at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60)
[izpack] at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:137)
[izpack] at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:33)
[izpack] at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:923)
[izpack] at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:909)
[izpack] at com.thoughtworks.xstream.XStream.fromXML(XStream.java:853)
[izpack] at com.thoughtworks.xstream.XStream.fromXML(XStream.java:845)
[izpack] at com.izforge.izpack.compiler.container.provider.IzpackProjectProvider.provide(IzpackProjectProvider.java:122)
[izpack] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[izpack] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[izpack] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[izpack] at java.lang.reflect.Method.invoke(Method.java:597)
[izpack] at org.picocontainer.injectors.MethodInjector.invokeMethod(MethodInjector.java:142)
[izpack] at org.picocontainer.injectors.MethodInjector.access$000(MethodInjector.java:38)
[izpack] at org.picocontainer.injectors.MethodInjector$2.run(MethodInjector.java:126)
[izpack] at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:274)
[izpack] at org.picocontainer.injectors.MethodInjector.decorateComponentInstance(MethodInjector.java:133)
[izpack] at org.picocontainer.injectors.CompositeInjector.decorateComponentInstance(CompositeInjector.java:58)
[izpack] at org.picocontainer.injectors.Reinjector.reinject(Reinjector.java:142)
[izpack] at org.picocontainer.injectors.ProviderAdapter.getComponentInstance(ProviderAdapter.java:96)
[izpack] at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
[izpack] at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
[izpack] at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
[izpack] at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:641)
[izpack] at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:630)
[izpack] at org.picocontainer.parameters.BasicComponentParameter$1.resolveInstance(BasicComponentParameter.java:105)
[izpack] at org.picocontainer.parameters.ComponentParameter$1.resolveInstance(ComponentParameter.java:136)
[izpack] at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:76)
[izpack] at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:286)
[izpack] at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:312)
[izpack] at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:274)
[izpack] at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:341)
[izpack] at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
[izpack] at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
[izpack] at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
[izpack] at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:641)
[izpack] at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:630)
[izpack] at org.picocontainer.parameters.BasicComponentParameter$1.resolveInstance(BasicComponentParameter.java:105)
[izpack] at org.picocontainer.parameters.ComponentParameter$1.resolveInstance(ComponentParameter.java:136)
[izpack] at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:76)
[izpack] at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:286)
[izpack] at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:312)
[izpack] at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:274)
[izpack] at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:341)
[izpack] at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
[izpack] at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
[izpack] at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
[izpack] at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:641)
[izpack] at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:630)
[izpack] at org.picocontainer.parameters.BasicComponentParameter$1.resolveInstance(BasicComponentParameter.java:105)
[izpack] at org.picocontainer.parameters.ComponentParameter$1.resolveInstance(ComponentParameter.java:136)
[izpack] at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:76)
[izpack] at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:286)
[izpack] at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:312)
[izpack] at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:274)
[izpack] at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:341)
[izpack] at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
[izpack] at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
[izpack] at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
[izpack] at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:641)
[izpack] at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:666)
[izpack] at com.izforge.izpack.core.container.AbstractContainer.getComponent(AbstractContainer.java:40)
[izpack] at com.izforge.izpack.ant.IzpackAntRunnable.run(IzpackAntRunnable.java:43)
[izpack] at java.lang.Thread.run(Thread.java:662)
[izpack] Caused by: com.thoughtworks.xstream.mapper.CannotResolveClassException: native : native
[izpack] at com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:68)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:71)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.PackageAliasingMapper.realClass(PackageAliasingMapper.java:88)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:86)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.ArrayMapper.realClass(ArrayMapper.java:96)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:38)
[izpack] at com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:52)
[izpack] at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.determineType(AbstractReflectionConverter.java:347)
[izpack] at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:208)
[izpack] at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162)
[izpack] at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82)
[izpack] ... 66 more

all:

BUILD SUCCESSFUL
Total time: 1 second



 Comments   
Comment by Tim Anderson [ 27/Jan/12 ]

Your stacktrace indicates a different problem:

[izpack] Exception in thread "Thread-2" com.thoughtworks.xstream.converters.ConversionException: native : native : native : native
[izpack] ---- Debugging information ----
[izpack] message : native : native
[izpack] cause-exception : com.thoughtworks.xstream.mapper.CannotResolveClassException
[izpack] cause-message : native : native
[izpack] class : com.izforge.izpack.api.data.binding.IzpackProjectInstaller
[izpack] required-type : com.izforge.izpack.api.data.binding.IzpackProjectInstaller
[izpack] path : /installation/native
[izpack] line number : 35

The syntax for both listeners and native libraries have changed for 5.0. See http://docs.codehaus.org/display/IZPACK/Migration+to+IzPack+5 for more details





[IZPACK-658] ShortcutPanel crashes on page flipping Created: 25/Mar/11  Updated: 17/May/13

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

Type: Bug Priority: Critical
Reporter: Marcelo Marzola Bossoni Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64


Attachments: Text File ShortcutPanel.java.patch    
Number of attachments : 1

 Description   

Create an install like this.

<listeners>
<listener installer="LateShortcutInstallListener" />
</listeners>

<panel classname="CheckedHelloPanel"/>
<panel classname="LicencePanel"/>
<panel classname="TargetPanel"/>
<panel classname="PacksPanel"/>
<panel classname="ShortcutPanel"/>
<panel classname="SummaryPanel"/>
<panel classname="InstallPanel"/>
<panel classname="SimpleFinishPanel"/>

When you reach ShortcutPanel press back and then next.
The panel will not show correctly and the following stacktrace is provided

java.lang.Exception: could not get an instance of IShellLink, failed to co-create instance
at com.izforge.izpack.util.os.ShellLink.initialize(ShellLink.java:536)
at com.izforge.izpack.util.os.ShellLink.<init>(ShellLink.java:374)
at com.izforge.izpack.util.os.Win_Shortcut.initialize(Win_Shortcut.java:82)
at com.izforge.izpack.panels.ShortcutPanel.panelActivate(ShortcutPanel.java:812)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(InstallerFrame.java:839)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(InstallerFrame.java:1451)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(InstallerFrame.java:1419)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.navigate(InstallerFrame.java:1582)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.access$0(InstallerFrame.java:1577)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler$1.run(InstallerFrame.java:1566)
at java.lang.Thread.run(Unknown Source)

java.lang.NullPointerException
at com.izforge.izpack.util.os.Win_Shortcut.getProgramsFolder(Win_Shortcut.java:679)
at com.izforge.izpack.panels.ShortcutPanel.getProgramsFolder(ShortcutPanel.java:915)
at com.izforge.izpack.panels.ShortcutPanel.panelActivate(ShortcutPanel.java:826)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(InstallerFrame.java:839)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(InstallerFrame.java:1451)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(InstallerFrame.java:1419)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.navigate(InstallerFrame.java:1582)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.access$0(InstallerFrame.java:1577)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler$1.run(InstallerFrame.java:1566)
at java.lang.Thread.run(Unknown Source)

Maybe only checking for shortcut field not initialized solves the problem, but I didn't go that far in finding what is causing the problem.



 Comments   
Comment by Markus Schlegel [ 28/Apr/11 ]

Same problem here. I am using IzPack 4.3.3 on Windows 7 64-bit, but using a 32-bit JRE (therefore os.arch is x86).
Same Problem occurred on Windows Vista, 32-bit.

Comment by &#321;ukasz Kuczera [ 05/Jan/12 ]

Same problem appears in 4.3.5

Comment by Sreram Balasubramaniyan [ 07/Dec/12 ]

Any updates for this bug? Its been more than a year and this bug is yet unresolved.

I get the same problem in 4.3.5 on Windows. Linux to be tested but no hope in believing this bug will not occur in Linux.

Comment by Christoph Panwinkler [ 24/Apr/13 ]

I've attached a patch for 4.3.5 that works for me on Windows 7 x64.

Shortcut is just initialized in a static context, so I guess if Shortcuts are used in ShortcutPanel only the patch would be sufficient

Comment by Rene Krell [ 30/Apr/13 ]

Seems like no one of the original maintainers of the IzPack 4 branch is currently active. Will have a look at the state of the IzPack 4 branch next time, hopefully, but personally I do not intend to spent too much time with it. There is too much work with the 5.0. So this is also a call in the wild, whether there is still someone listening who initiated or maintained the IzPack 4 branch some time ago. A sent patch is worth at least checking it.

Can you please check whether this applies also on IzPack 5.0.0 >= beta11, thus whether it is reproducable and the patch fixes it also there?
I'm not sure whether the same OS conditions apply on the virtual test machine of Win 7 I have available and your one.

Comment by Christoph Panwinkler [ 17/May/13 ]

ShortcutPanel works out of the box with IzPack 5.0.0-beta11, so nothing to do with IzPack 5.





[IZPACK-657] izpack-standalone-compiler 4.3.4-RC1 in maven central Created: 25/Mar/11  Updated: 29/Apr/11  Resolved: 29/Mar/11

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

Type: Bug Priority: Major
Reporter: Francis De Brabandere 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   

izpack-standalone-compiler 4.3.4-RC1 does not seem to be available in maven central:

http://repo1.maven.org/maven2/org/codehaus/izpack/izpack-standalone-compiler/



 Comments   
Comment by Francis De Brabandere [ 25/Mar/11 ]

see also IZPACK-548

Comment by Julien Ponge [ 29/Mar/11 ]

We will do, but for the real release.

Cheers





[IZPACK-656] SimpleFinishPanel has hardcoded path for uninstaller Created: 24/Mar/11  Updated: 29/Apr/11  Resolved: 29/Mar/11

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.3
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Minor
Reporter: Marcelo Marzola Bossoni Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All OS


Number of attachments : 0

 Description   

See similar issue at http://jira.codehaus.org/browse/IZPACK-610

The problem is that solution for this problem was not ported to simple finish panel.



 Comments   
Comment by Julien Ponge [ 29/Mar/11 ]

Would you have a chance to prepare a patch?

Comment by Marcelo Marzola Bossoni [ 29/Mar/11 ]

Nope, but the solution is the very same from IZPACK-610

Replace line
String path = translatePath("$INSTALL_PATH") + File.separator + "Uninstaller";
by this
String path = translatePath(idata.info.getUninstallerPath());

in the SimpleFinishPanel

Comment by Julien Ponge [ 29/Mar/11 ]

The fix is in, thanks!





[IZPACK-655] Duplicate Entries in Add/Remove programs in windows Created: 16/Mar/11  Updated: 20/Sep/13

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

Type: Improvement Priority: Major
Reporter: Timothy Fridey Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Registry problem


Number of attachments : 0

 Description   

When a user installs a new version of my software over the top of a previous version they usually do so in the same directory. This causes duplicate entrys in the windows add/remove control panel, which results in a LOT of negitive feedback. Since they can not be removed without editing the registry.

There is a number of solutions to this and the simplest would seem to be allowing a check for a "previous" (I know you can already detect if the same version is installed) version then either disallow the install with a message, or even allow an unistall to kick of (I noticed the the CheckedHelloPanel does look for the uninstall string).

I see time and again questions about this very issue and the answer seems to be, "you should uninstall first", how about a mechinism to stop users who dont follow this convention, which in my experience is most of them.

If I get some free time and submit a patch is it likely to be included? I'm reluctent to make that kind of change then have to continually repatch Izpack each time it came out. Feedback on my suggestion, improvements, how to get it merged to the source, and other solutions would all be greatly appreaciated before I start work.

Thanks,
Tim



 Comments   
Comment by Julien Ponge [ 16/Mar/11 ]

In such cases people may suffix the target install directory with the version number or something similar. Or you may change the registry keys, or something like that.

Comment by Timothy Fridey [ 17/Mar/11 ]

Hi Julien,
At first I thought of course adding the version number to the install dir what a simeple solution. However I quickly realised that this has more side affects.

For example, in Windows 7/Vista you need to install datafiles that are to be edited in the AppData directory (otherwise you need to run your program with special privleges to be able to edit files under the 'Program Files' directory ).
If you change the suffix you can install two versions and you can now remove both including the add/remove programs entries. However when the user removes one of the versions this will remove the files installed to the AppData directory, and thus the remaining intalled program will not run without these files. I dont want to sufix this directory as I would like to continue using the other data from this directory, such as user profiles which are not removed by the uninstaller.

I still believe detecting a previous version and stopping the install is the best way around this whole issue.

Comment by Timothy Fridey [ 17/Mar/11 ]

Ok, I have taken a look at the code behind CheckedHelloPanel and it looks as though it should be easy enough to create something I'm after.

Restrictions/Problems:
Currently Registry entries are matched on there uninstallName which is a combination of APP_NAME and APP_VER variables. Now as there is currently nothing in Izpack inforcing that APP_VER is a numerical value this makes determining the uninstallName for previous versions of software using a generic method impossible (e.g APP_VER name could be 'version 7 contains spaces whats the app name? whats the version?'). Not sure if the Izpack team plans on tighening up restrictions on things like this, it would make any future upgrade features built into Izpack much easier in my opinion.

Workaround:
I may be able to use a variable to accept a pattern matching string that can be used to identify the uninstallName. Along with checking some of the entries to be sure it is indead an Izpack entrie.

Again any feedback, suggetions, comments on this idea, are appreciated.

Comment by Daniel Abson [ 20/Jul/12 ]

This would be an incredibly useful complement to the ConfigurationInstallationListener in 5.0, for enabling upgrade-type installs.

The reporter's suggestion of using APP_NAME + patternMatching(APP_VER) to detect previous installs on Windows, plus checking the installation directory for .installationInformation, uninstaller, etc (which would work for other platforms too), seems like the only way to do it without major changes. You'd also want to allow configurable prefixes for APP_VER (defaults e.g. 'v', 'ver', 'version') and a configurable hierarchy of post-fixes (default e.g. 'alpha' < 'beta' < 'rc' < 'none').

Is anybody working on anything like this right now?

Comment by Daniel Abson [ 20/Sep/13 ]

A partial fix for this exists on my GitHub fork branch for this issue. It introduces optional functionality to interactively trigger the uninstaller for an existing instance, and use the installation path of an existing instance.

Further changes required to fully address this issue would be:

  • 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?".
  • Add a new "Remove all files?" checkbox on the uninstaller, to control the removal of files marked "optional" by the uninstall attribute in the install XML.
  • Add a new fuzzymatch config parameter to CheckedHelloPanel that only matches registry entries on APP_NAME (instead of APP_NAME + APP_VER).

Taken together, all these changes would allow rudimentary upgrade installers and prevent the duplicate registry uninstaller entries. A previous version of the application would be detected (using fuzzymatch on CheckedHelloPanel), prompt the user to uninstall it (using uninstallexisting on CheckedHelloPanel), and the uninstaller would skip deleting profile/configuration/preference files (using uninstall="optional" in the install spec).

I'd like to continue implementing these ideas in my branch. Is this an acceptable approach, and would these changes make it into 5.1?

Comment by Rene Krell [ 20/Sep/13 ]

Hi Daniel, it would be better to discuss this in one or more separate issues for 5.1. For 5.1, it looks convenient.

Comment by Daniel Abson [ 20/Sep/13 ]

Sounds good. Raised separately as IZPACK-981 (CheckedHelloPanel changes) and IZPACK-982 (uninstaller changes). Renamed my GitHub branch.





[IZPACK-654] The installer should simply switch to console mode when a headless env is detected, even if the user has not passed the -console cmd Created: 15/Mar/11  Updated: 29/Apr/11  Resolved: 16/Mar/11

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

Type: Improvement Priority: Minor
Reporter: Mark Miller 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   

Currently you get a stack trace - makes much more sense to launch the console installer.



 Comments   
Comment by Mark Miller [ 15/Mar/11 ]

https://github.com/lucidimagination/izpack/commit/02fe9a3b7675c8ca33fd9af0bbb5ea6fb234d0d3

Comment by Julien Ponge [ 16/Mar/11 ]

Thanks, this will be in 4.3.4 as it's ok to be included after the RC1.

I am going to backport to 5 also.

Comment by Mark Miller [ 16/Mar/11 ]

Thanks Julien! I had done a quick scan of my izpack mail but had missed you had already dropped the RC1. That's great, I'll try out.





[IZPACK-653] Run-privileged on Mac 10.6.6 issue Created: 11/Mar/11  Updated: 15/Mar/11

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

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

When installer is created with run-privileged option and runned on Mac 10.6.6, installation fails (it interrogates the user about admin password, but it fails to write in /Applications, although the admin user has write permission).
This works ok on Mac 10.5.8.



 Comments   
Comment by Florin B [ 15/Mar/11 ]

The received error message is "This directory can not be written ...."
It seams that on Mac 10.6.6 java.io.File.canWrite returns false, even after the installer is relaunched with elevated permissions.





[IZPACK-652] Allow ProcessPanel to have a working directory Created: 04/Mar/11  Updated: 14/Mar/11  Resolved: 14/Mar/11

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

Type: Improvement Priority: Minor
Reporter: Phillip Davey Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all


Attachments: Text File izpack-processpanel.patch     Text File variable-substitution-for-workingDir.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

When the ProcessPanel's executeFile is used and the specified file relies on relative paths, being able to specify a working directory (typically $INSTALL_PATH) would be useful.



 Comments   
Comment by Julien Ponge [ 07/Mar/11 ]

Are you willing to update and/or add the missing bits at https://docs.codehaus.org/display/IZPACK/User+documentation ?

If so then I will gladly accept the patch.

Comment by Phillip Davey [ 07/Mar/11 ]

Gladly. I poked around but could not find a documentation standards doc. Is there such a document, or just try to adhere to what I see?

Comment by Phillip Davey [ 09/Mar/11 ]

The documentation has been updated to reflect the new attribute.

Comment by Julien Ponge [ 09/Mar/11 ]

Great!

Comment by Julien Ponge [ 09/Mar/11 ]

It's in, thanks.

Comment by Phillip Davey [ 10/Mar/11 ]

This jira and documentation talks about using substitution variables in the value of workingDir, but the patch did not have that functionality, it only exposed the ability to set the value of workingDir.

Comment by Phillip Davey [ 10/Mar/11 ]

This patch runs the workingDir through the IOHelper.translatePath function. I picked this over just the raw variable substitution, but I'm not sure it matters.

Comment by Julien Ponge [ 11/Mar/11 ]

Ok, so is the issue resolved now?

Comment by Phillip Davey [ 11/Mar/11 ]

Yes, I didn't quite do due diligence in testing, I think it's good now.





[IZPACK-651] Could not final class "panel class" on installer launch Created: 24/Feb/11  Updated: 17/May/11  Resolved: 21/Mar/11

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

Type: Bug Priority: Blocker
Reporter: Maksim Sorokin Assignee: Anthonin Bonnefoy
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 32bit


Attachments: Text File 0001-Modify-IzPacknewMojoTest-to-create-an-installer-that.patch    
Number of attachments : 1

 Description   

I use the install.xml from http://docs.codehaus.org/display/IZPACK/Writing+Installation+Descriptions:

<installation version="1.0">

  <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="plain" targetdir="${INSTALL_PATH}" override="true"/>
      <parsable targetfile="${INSTALL_PATH}/test.properties"/-->
    </pack>
  </packs>

</installation>

When I run IzPack 5.0.0-beta5 compiler on it with:

compile c:\projects\test25\src\main\resources\install.xml -b c:\projects\test25\target\staging

I have installer.jar created. But when I launch it it silently fails.
If I launch it through:

java -classpath install.jar com.izforge.izpack.installer.bootstrap.Installer

I get

c:\Program Files\IzPack\bin>java -classpath install.jar com.izforge.izpack.installer.bootstrap.Installer
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider loadLookAndFeel
INFO: Using laf org.pushingpixels.substance.api.skin.SubstanceMistAquaLookAndFeel
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: PanelUI : org.pushingpixels.substance.internal.ui.SubstancePanelUI
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: ClassLoader : null
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: Cached class : null
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: Using system loader to load org.pushingpixels.substance.internal.ui.SubstancePanelUI
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: Done loading
24-02-2011 15:22:22 com.izforge.izpack.installer.container.provider.GUIInstallDataProvider checkSubstanceLafLoaded
INFO: Loaded class : org.pushingpixels.substance.internal.ui.SubstancePanelUI
Exception in thread "AWT-EventQueue-0" com.izforge.izpack.api.exception.IzPackException: com.izforge.izpack.api.exception.MergeException: Could not find class TargetPanel : Current classpath is
        at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:57)
        at java.awt.event.InvocationEvent.dispatch(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: com.izforge.izpack.api.exception.MergeException: Could not find class TargetPanel : Current classpath is
        at com.izforge.izpack.merge.resolve.ClassPathCrawler.searchClassInClassPath(ClassPathCrawler.java:125)
        at com.izforge.izpack.installer.manager.PanelManager.loadPanelsInContainer(PanelManager.java:72)
        at com.izforge.izpack.installer.base.InstallerController.preloadInstaller(InstallerController.java:30)
        at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:50)
        ... 8 more

If I add ..\lib* to the classpath explicitly during running the installer, it works perfectly:

java -classpath install.jar;..\lib\* com.izforge.izpack.installer.bootstrap.Installer


 Comments   
Comment by Maksim Sorokin [ 24/Feb/11 ]

Sorry, forgot to add, that when I do compilation the same way with IzPack 4.3.3, it works perfectly.

Comment by Julien Ponge [ 24/Feb/11 ]

Hi Anthonin,

Sounds like a path / class resolving issue, don't you think so?

Cheers

Comment by Phillip Davey [ 04/Mar/11 ]

I get this also, and I'm using artifacts built from a git of HEAD (5.0.0-beta7-SNAPSHOT) on Linux x86_64.

Comment by Phillip Davey [ 10/Mar/11 ]

As stated before, I'm having a similar problem, though in a Maven project, and I've spent some time looking for this issue (and in the process, familiarizing myself with the code). I am attaching a small patch that makes the izpack maven plugin test suite produce an installer jar that doesn't work and produces what I believe is the same error. It's a strange one. If the output (and by extension Info.installerBase) is not set so the filename starts with "izpack", it fails. I'm not positive that is must be "izpack", because I can't find the exact code...originally I thought this issue was this line from Packager.java (replaceAll is regex which means that "." causes matches on ".jar", "ajar", "1jar", etc.:

Packager.java
public void createInstaller() throws Exception
{
   // preliminary work
   info.setInstallerBase(compilerData.getOutput().replaceAll(".jar", ""));
...

which should probably be

Packager.java
public void createInstaller() throws Exception
{
   // preliminary work
   info.setInstallerBase(compilerData.getOutput().replaceAll("\\.jar", ""));
...

but no dice. If I find anything else, I'll post it.

Comment by Anthonin Bonnefoy [ 21/Mar/11 ]

The example now works.
There was some problems with the jar generation which caused problems to the panel detection. Should be ok now.

Comment by Tom Grünheit [ 03/May/11 ]

I'm using the izpack-maven-plugin 5.0.0-beta7 and I still have the problem.

Here the output of the Maven Plugin

[INFO] — izpack-maven-plugin:5.0.0-beta7:izpack (default) @ xxxx —
<?xml version="1.0" encoding="UTF-8"?><installation version="1.0">

<info>
<appname>TestInstaller</appname>
<appversion>1</appversion>
<uninstaller write="no"/>
<javaversion>1.6</javaversion>
</info>

<variables>
<variable name="InstallerFrame.logfilePath" value="$INSTALL_PATH/install.log"/>
</variables>

<guiprefs resizable="no" width="480" height="360">
<laf name="looks">
<param name="variant" value="windows"/>
<os family="windows"/>
</laf>
</guiprefs>

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

<panels>
<panel classname="TargetPanel"/>
<panel classname="InstallPanel"/>
<panel classname="SimpleFinishPanel"/>
</panels>

<packs>
<pack name="core" required="yes">
<description>MCCore2 packages</description>
<fileset dir="app" targetdir="$

{INSTALL_PATH}/app" override="true"/>
</pack>

<pack name="web" required="yes">
<description>WEB Applications</description>
<fileset dir="webapp" targetdir="${INSTALL_PATH}

/webapp" override="true"/>
</pack>

</packs>

</installation>
Setting the installer information
Setting the GUI preferences
Adding langpack: eng
Adding resource: flag.eng
Adding panel: UNKNOWN (TargetPanel) :: Classname : TargetPanel
Adding panel: UNKNOWN (InstallPanel) :: Classname : InstallPanel
Adding panel: UNKNOWN (SimpleFinishPanel) :: Classname : SimpleFinishPanel
[ Begin ]

Copying the skeleton installer
Copying 2 files into installer
Merging 0 jars into installer
Writing 2 Packs into installer
Writing Pack 0: core
Writing Pack 1: web

[ End ]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

Here the Exception when I execute the installer:

java -jar installer.jar

Exception in thread "AWT-EventQueue-0" com.izforge.izpack.api.exception.IzPackException: com.izforge.izpack.api.exception.MergeException: Could not find class TargetPanel : Current classpath is
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:57)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
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.MergeException: Could not find class TargetPanel : Current classpath is
at com.izforge.izpack.merge.resolve.ClassPathCrawler.searchClassInClassPath(ClassPathCrawler.java:125)
at com.izforge.izpack.installer.manager.PanelManager.loadPanelsInContainer(PanelManager.java:72)
at com.izforge.izpack.installer.base.InstallerController.preloadInstaller(InstallerController.java:30)
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:50)
... 8 more

jar -tvf installer.jar|grep TargetPanel

2373 Fri Apr 29 09:51:02 CEST 2011 com/izforge/izpack/panels/target/TargetPanel.class
2148 Fri Apr 29 09:51:02 CEST 2011 com/izforge/izpack/panels/target/TargetPanelAutomationHelper.class
3553 Fri Apr 29 09:51:02 CEST 2011 com/izforge/izpack/panels/target/TargetPanelConsoleHelper.class

Comment by Patrick Aikens [ 13/May/11 ]

I am also seeing this with the released 5.0.0-beta7 maven plugin

Comment by Patrick Aikens [ 13/May/11 ]

It's not fixed as of the released 5.0.0-beta7

Comment by Tom Grünheit [ 17/May/11 ]

reopen please ...





[IZPACK-650] itemState change events from UserInputPanel combos unconditionally cause revalidation; behavior should be controlled by REVALIDATE attribute instead Created: 11/Feb/11  Updated: 29/Apr/11  Resolved: 26/Feb/11

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.3
Fix Version/s: 4.3.4

Type: Improvement Priority: Major
Reporter: mark sipos Assignee: Julien Ponge
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 0090-UserInputPanel-comboboxes-no-longer-unconditionally-.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Every time the user selects a different item in a ComboBox on the UserInputPanel, the entire panel is revalidated. This is very distracting if one or more Validators are attached to fields on the same panel and they display their error dialogs one after the other
Instead use the REVALIDATE attribute for ComboBoxes in the same way as Check Boxes.
Patch attached.



 Comments   
Comment by Adam Lehenbauer [ 11/Feb/11 ]

this would help us a lot.

Comment by Julien Ponge [ 26/Feb/11 ]

A fix has been provided.





[IZPACK-649] Uninstall is not deleting directories Created: 08/Feb/11  Updated: 08/Feb/11

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

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

Windows 7 and Linux Fedora


Number of attachments : 0

 Description   

I have an issue with uninstall not deleting directories.

My installation does three things:
installs to installation directory
copies files to the library directory(specified with UserPathPanel)
copies config.properties file to $USER_HOME/myprojdir

The uninstall does the following (the problem is indicated by **):
(1)
Windows 7
Deletes all files from all directories.
Deletes config.properties
*Does not delete any directories.*

(2)
Linux Fedora
Deletes all files from all directories.
Deletes config.properties
Deletes the install directory
*Does not delete the directory specified in the UserPathPanel.*

I'm running version 4.3.3.
I see the code in Uninstaller.java that was documented as a fix for izpack-387 which was also having problems with uninstall not deleting directories.






[IZPACK-648] optional elevation does not work for non-admin users Created: 07/Feb/11  Updated: 07/Feb/11

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

Type: Bug Priority: Major
Reporter: w.pasman 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 have an installer that allows the user to install anywhere, either in his local directory or for example in ProgramFiles directory.

What we want is to ask the user for admin permission ONLY IF REALLY NECESSARY (for example, when the user selects Program Files directory as target).

As izPack is now, we either ask for <run-privileged/> or not.

If we do, then users ALWAYS have to enter name&password (unless they ARE already admin of course). On OSX a user that has no admin rights (or does not want to install as admin) can still cancel and proceed as normal user. But on Windows the install aborts in that case.

If we do not, then normal users can not install in privilleged directories, getting an access denied exception.

BTW we are using IZPACK 4.3.1 because there is a related issue with 4.3.3: http://jira.codehaus.org/browse/IZPACK-555

As a side note, <run-privilleged> has a conditional but we failed to use that to solve above issue. We tried to use that but it throws a NullpointerException if we use a variable that is set up somewhere later, eg after the user selected where to install a pack. This is the exception as appearing on the console on OSX. I am not sure if this should be considered a separate bug or part of this same issue.

  • ERROR -
    java.lang.NullPointerException
    java.lang.NullPointerException
    at com.izforge.izpack.installer.InstallerBase.checkForPrivilegedExecution(Unknown Source)
    at com.izforge.izpack.installer.InstallerBase.loadInstallData(Unknown Source)
    at com.izforge.izpack.installer.GUIInstaller.init(Unknown Source)
    at com.izforge.izpack.installer.GUIInstaller.<init>(Unknown Source)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    at java.lang.Class.newInstance0(Class.java:355)
    at java.lang.Class.newInstance(Class.java:308)
    at com.izforge.izpack.installer.Installer.main(Unknown Source)





[IZPACK-647] Unable to launch wizard (panel) after creating the setup.exe in windows 7 Created: 03/Feb/11  Updated: 29/Apr/11  Resolved: 21/Mar/11

Status: Closed
Project: IzPack
Component/s: Native launcher
Affects Version/s: 4.3.3
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Blocker
Reporter: vinay Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: Text File izpack2exe.py    
Number of attachments : 1

 Description   

I am trying to create SFX image for jar from the IZPACK installer in windows7 for win 32 machines.

How i created : executed the below commands
compile install.xml -k web
izpack2exe --file=install.jar

Result : Setup.exe will be created.

problem : Double click on the setup.exe will just extract and explore the files of exe instead of showing setup wizards



 Comments   
Comment by Julien Ponge [ 04/Feb/11 ]

Check that the target operating system has a working Java installation. More specifically, check that opening a Jar file does not trigger some weird compressed file management program.

Comment by Timothy Fridey [ 18/Mar/11 ]

This is a duplicate of IZPACK-560 and IZPACK-30

I had a bit of a play today, I never knew python could create executable files for windows, was a pleasant surprise. I'm not sure what the reason is for 7zipping the jar since it is already compressed.

Anyway, I have a patch for this issue that I have tested on WinXP and Win7. It works the same in every other way that I can tell. However I uncovered another bug in Win7 (not caused by my fix, is in current version also where the install crashes if there are any execution parameters e.g. --launch-args ) I will open a new issue for this bug, just though you should be aware its not caused by my fix.

Comment by Timothy Fridey [ 18/Mar/11 ]

Until I can work out how to create a patch in git here is the whole file.

The change is:
config.write('ExecuteFile="javaw"')
config.write('ExecuteParameters="-jar \\\"%s\\\"' % filename)
if settings.launchargs != '':
config.write(' %s"\r\n' % settings.launchargs)
else:
config.write('"\r\n')

Comment by Julien Ponge [ 21/Mar/11 ]

It's in, thanks!





[IZPACK-646] uninstaller requests elevation to non-admin user Created: 03/Feb/11  Updated: 03/Feb/11

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

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

win7 32bit (and probably other windows)


Number of attachments : 0

 Description   

We have an installer that installs fine for a non-admin user (he installs for instance on the Desktop).

BUT if that same user now runs the uninstaller he gets an elevation prompt for admin rights which of course he can not fulfill (he's non-admin user).

This is a major problem for us as
1. most of our users are normal users that have no admin rights but still want a proper uninstall.
2. we have a pretty high update rate of our installer so many users require to de-install and install the latest version.

For now we roll back to 4.3.1 that does not have this issue. But by that we will lose the fixes made since 4.3.1...

related issues:
http://jira.codehaus.org/browse/IZPACK-430
http://jira.codehaus.org/browse/IZPACK-386






[IZPACK-645] Null pointer exception at automated install Created: 20/Jan/11  Updated: 29/Apr/11  Resolved: 17/Feb/11

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.3
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Major
Reporter: Laurian Vostinar Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File NPE_UserPathPanel.patch     Text File UserPathPanelAutomationHelper.java.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

I am getting a Null Pointer Exception when doing an automated install.

java.lang.NullPointerException
java.lang.NullPointerException
at com.izforge.izpack.panels.UserPathPanelAutomationHelper.runAutomated(Unknown Source)
at com.izforge.izpack.installer.AutomatedInstaller.installPanel(Unknown Source)
at com.izforge.izpack.installer.AutomatedInstaller.doInstall(Unknown Source)
at com.izforge.izpack.installer.Installer.main(Unknown Source)

The UserPathPanel is optional in installer and was not selected when sabing the xml file. When running the xml file for automated it will fail with above error. A git pack has been included.



 Comments   
Comment by Julien Ponge [ 23/Jan/11 ]

Well this patch is huge and makes edits were it should not (e.g., the KEYS files, the README file, etc).

Would you be able to come up with one that focuses only on the fix of this issue?

Thanks

Comment by Stuart Wallis [ 16/Feb/11 ]

Added simpler/smaller patch from 4.3.3 source.

Comment by Julien Ponge [ 17/Feb/11 ]

Fixed in both branches, thanks.





[IZPACK-644] IOException when launching the uninstaller Created: 19/Jan/11  Updated: 26/Feb/11  Resolved: 26/Feb/11

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

Type: Bug Priority: Major
Reporter: Rémi Baptiste Assignee: David Duponchel
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, Java 1.6, maven-plugin


Number of attachments : 0

 Description   

After a successful installation, I tried to launch the uninstaller but nothing happened.
So I tried to launch it with trace. Here is the output :

$ java -DTRACE=true -jar uninstaller.jar > uninstaller.log
Cannot run program "C:\Program": CreateProcess error=193, %1 n'est pas une application Win32 valide
java.io.IOException: Cannot run program "C:\Program": CreateProcess error=193, %1 n'est pas une application Win32 valide
        at java.lang.ProcessBuilder.start(Unknown Source)
        at java.lang.Runtime.exec(Unknown Source)
        at java.lang.Runtime.exec(Unknown Source)
        at java.lang.Runtime.exec(Unknown Source)
        at com.izforge.izpack.util.SelfModifier.initJavaExec(SelfModifier.java:364)
        at com.izforge.izpack.util.SelfModifier.<init>(SelfModifier.java:308)
        at com.izforge.izpack.uninstaller.Uninstaller.main(Uninstaller.java:71)
Caused by: java.io.IOException: CreateProcess error=193, %1 n'est pas une application Win32 valide
        at java.lang.ProcessImpl.create(Native Method)
        at java.lang.ProcessImpl.<init>(Unknown Source)
        at java.lang.ProcessImpl.start(Unknown Source)
        ... 7 more
Unable to exec java as a subprocess.
The uninstall may not fully complete.
ERREUR :  ''
ERREUR :  'com.sun.org.apache.xml.internal.utils.WrappedRuntimeException'
- Error -
com.izforge.izpack.api.adaptator.XMLException: javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException
        at com.izforge.izpack.api.adaptator.impl.XMLParser.parseLineNrFromInputSource(XMLParser.java:172)
        at com.izforge.izpack.api.adaptator.impl.XMLParser.parse(XMLParser.java:189)
        at com.izforge.izpack.api.data.LocaleDatabase.add(LocaleDatabase.java:89)
        at com.izforge.izpack.api.data.LocaleDatabase.<init>(LocaleDatabase.java:74)
        at com.izforge.izpack.uninstaller.UninstallerFrame.<init>(UninstallerFrame.java:103)
        at com.izforge.izpack.uninstaller.Uninstaller$1.run(Uninstaller.java:176)
        at java.awt.event.InvocationEvent.dispatch(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: javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
        at com.izforge.izpack.api.adaptator.impl.XMLParser.parseLineNrFromInputSource(XMLParser.java:151)
        ... 13 more
Caused by: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException
        at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source)
        ... 16 more
Caused by: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException
        at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
        at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
        ... 17 more

I looked at the source code but I don't find any clue about this bug.

Rémi



 Comments   
Comment by Julien Ponge [ 23/Jan/11 ]

David, would you be able to investigate that one? There's some XML stuff in the exception, so I thought you may be concerned

Comment by David Duponchel [ 25/Jan/11 ]

I reproduced it on linux (except the win32 part ). It's an issue with url encoded path ('folder with spaces' versus 'folder%20with%20spaces'). The uninstaller didn't find its own jar file (first stack trace), and passed null to the xml parser (second stack trace).
I will investigate further since it seems to come from IZPACK-612.





[IZPACK-643] TargetPanel do not create the directory Created: 18/Jan/11  Updated: 18/Aug/12  Resolved: 18/Aug/12

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

Type: Bug Priority: Major
Reporter: Rémi Baptiste Assignee: Tim Anderson
Resolution: Cannot Reproduce 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 tried to use the TargetPanel to let the user choose the install path.
The Panel is working as it should exept that after asking if izpack need to create the directory since it doesn't exist, nothing happened. The install process continue as normal but failed when trying to write information data on installation at the end of the InstallPanel because the directory doesn't exist.

I'm using the maven plugin (5.0.0-beta5).

This is how i'm using the TargetPanel :

<panel classname="TargetPanel" id="targetPanel"/>


 Comments   
Comment by Tim Anderson [ 18/Aug/12 ]

The target directory should be created during unpacking.
Try a recent snapshot of 5.0.0-beta-11.





[IZPACK-642] Variable executable property not working. Created: 18/Jan/11  Updated: 18/Jul/12  Resolved: 18/Jul/12

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

Type: Bug Priority: Major
Reporter: Mark Poole Assignee: Rene Krell
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux 10.10 x86_64


Number of attachments : 0

 Description   

I have the following code taken from the docs:

<variable name="hostname" checkonce="true"
executable="hostname"
type="process"/>

When running the installer the result is: (If I run the installer
without this option it works fine)

INFO: refreshing dynamic variables
Jan 17, 2011 5:46:28 PM
com.izforge.izpack.installer.base.InstallerBase
refreshDynamicVariables
INFO: Dynamic variable: hostname
Jan 17, 2011 5:46:28 PM
com.izforge.izpack.core.substitutor.VariableSubstitutorBase substitute
SEVERE: Error when substituting variables
java.lang.NullPointerException
at com.izforge.izpack.core.substitutor.VariableSubstitutorBase.substitute(VariableSubstitutorBase.java:286)
at com.izforge.izpack.core.substitutor.VariableSubstitutorBase.substitute(VariableSubstitutorBase.java:172)
at com.izforge.izpack.core.variable.ExecValue.resolve(ExecValue.java:121)
at com.izforge.izpack.core.variable.ValueImpl.resolve(ValueImpl.java:44)
at com.izforge.izpack.core.data.DynamicVariableImpl.evaluate(DynamicVariableImpl.java:86)
at com.izforge.izpack.installer.base.InstallerBase.refreshDynamicVariables(InstallerBase.java:93)
at com.izforge.izpack.installer.language.LanguageDialog.initLangPack(LanguageDialog.java:522)
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:52)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:226)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:602)
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)
Exception in thread "AWT-EventQueue-0" java.lang.Error:
java.lang.NullPointerException
at com.izforge.izpack.core.substitutor.VariableSubstitutorBase.substitute(VariableSubstitutorBase.java:177)
at com.izforge.izpack.core.variable.ExecValue.resolve(ExecValue.java:121)
at com.izforge.izpack.core.variable.ValueImpl.resolve(ValueImpl.java:44)
at com.izforge.izpack.core.data.DynamicVariableImpl.evaluate(DynamicVariableImpl.java:86)
at com.izforge.izpack.installer.base.InstallerBase.refreshDynamicVariables(InstallerBase.java:93)
at com.izforge.izpack.installer.language.LanguageDialog.initLangPack(LanguageDialog.java:522)
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:52)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:226)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:602)
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: java.lang.NullPointerException
at com.izforge.izpack.core.substitutor.VariableSubstitutorBase.substitute(VariableSubstitutorBase.java:286)
at com.izforge.izpack.core.substitutor.VariableSubstitutorBase.substitute(VariableSubstitutorBase.java:172)
... 14 more



 Comments   
Comment by Rene Krell [ 18/Jan/11 ]

Fixed in master, commit 44bbf91b8c9b39268981ad8e04a66c8b96060d51.
IzPack 4.3.x should not be concerned, no backport necessary.

Comment by Mark Poole [ 18/Jan/11 ]

The error is no longer thrown but the variable does not get set.

I tried using:

<variable name="hostname" checkonce="true"
executable="/bin/hostname"
type="process"/>

and also:

<variable name="hostname" checkonce="true"
executable="hostname"
type="process"/>

Both times the variable is displayed in "java -jar -DTRACE=TRUE install.jar" but it's empty.

Comment by Rene Krell [ 25/Jan/11 ]

Does the variable have any value using the following definition?

<variable name="hostname" checkonce="true"
          executable="/bin/hostname" stderr="true"
          type="process"/>
Comment by Tim Anderson [ 18/Jul/12 ]

No response from original poster, closing.





[IZPACK-641] Hitting Previous on the Shortcut Panel causes the Install Panel to re-install the selected packs Created: 12/Jan/11  Updated: 12/Jan/11

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

Type: Bug Priority: Major
Reporter: Will Roberts 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 the ShortcutPanel immediately following the InstallPanel and accidentally click the Previous button the installer will switch back to the InstallPanel and re-install all the packs.






[IZPACK-640] "Error: Failed to send command: 500 command not parseable" on Linux Created: 06/Jan/11  Updated: 06/May/11  Resolved: 06/May/11

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

Type: Bug Priority: Major
Reporter: Bruno Medeiros Assignee: David Duponchel
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 10.04 LTS 64 bits


Number of attachments : 0

 Description   

After install, I went to terminal and tried to run IzPack as follows:

bruno.medeiros@brunojcm-laptop:~/IzPack$ ./bin/start.sh
found Desktop: gnome
found Gecko: firefox
Launching: firefox
bruno.medeiros@brunojcm-laptop:~/IzPack$ Error: Failed to send command: 500 command not parseable

Don't know what is going on, but I hope you can fix it. Just ask any more info if you need.



 Comments   
Comment by David Duponchel [ 06/May/11 ]

The start.sh script launches a specified url with firefox and is used by IzPack's unix shortcuts. It requires one argument, the url to open. Without, the script asks firefox to open "" and fails.
I added a "usage" function to avoid confusion.





[IZPACK-639] TreePacksPanel layout issues on linux Created: 05/Jan/11  Updated: 22/Jun/12  Resolved: 22/Jun/12

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

Type: Bug Priority: Minor
Reporter: Mathieu Gond Assignee: Julien Ponge
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, OpenJDK 1.6


Attachments: PNG File Capture.png    
Number of attachments : 1

 Description   

When executing my installer and Linux platform ( tested on Ubuntu and RedHat) I have weird layout behavior on the TreePacksPanel. ( see the attached screenshot for more details )

Basically only one pack is shown, not all the tree. I can look at the others using a scroll bar.
My guiprefs are only about headers :
<guiprefs width="600" height="480" resizable="yes">
<modifier key="useHeadingPanel" value="yes"/>
<modifier key="headingImageOnLeft" value="yes"/>
<modifier key="headingLineCount" value="1"/>
<modifier key="headingFontSize" value="1.5"/>
<modifier key="headingBackgroundColor" value="0x00ffffff"/>
<modifier key="headingPanelCounter" value="text"/>
<modifier key="headingPanelCounterPos" value="inHeading"/>
<modifier key="langDisplayType" value="native"/>
</guiprefs>



 Comments   
Comment by Tom Hauser [ 25/May/11 ]

I have the same issues, with the same JDK. Have you tried other JDKs? It may be an OpenJDK specific problem.

Comment by Dustin Kut Moy Cheung [ 22/Jun/12 ]

This was fixed in IZPACK-682!

Julien: You should mark that JIRA as resolved.





[IZPACK-638] Update for Finnish langpack Created: 19/Dec/10  Updated: 13/Dec/12  Resolved: 13/Dec/12

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

Type: Improvement Priority: Trivial
Reporter: Ari Voutilainen Assignee: Ari Voutilainen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0




[IZPACK-637] JDKPathPanel does not work in automated mode Created: 16/Dec/10  Updated: 29/Apr/11  Resolved: 18/Dec/10

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.3
Fix Version/s: 4.3.4, 5.0

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

needs a JDKPathPanelAutomationHelper



 Comments   
Comment by Mark Miller [ 16/Dec/10 ]

A simple untested impl: https://github.com/lucidimagination/izpack/commit/34b0d0029ffdc7e5f85c624da8084f81e7aeab72

Comment by Mark Miller [ 17/Dec/10 ]

tested impl: https://github.com/lucidimagination/izpack/commit/06a1d16f7a7e6446463b53b10940a933f4c059da

Comment by Stuart Wallis [ 19/Dec/10 ]

The final line of the JDKPathPanelAutomationHelper at github will overwrite the INSTALL_PATH variable. I think you should use this instead:

idata.setVariable(JDK_PATH, jdkPath);

Comment by Mark Miller [ 19/Dec/10 ]

Thanks for the review Stuart!

Fixed that one yesterday (can't remember who emailed me to point it out): https://github.com/lucidimagination/izpack/commit/ad81d5f4fd5bee68b07d3c3d9ccb6ced2a445ff0

I had tested that it wrote the xml and then ran fine after - but not what actually got read from the xml. Copy paste bug from the target panel automation class.





[IZPACK-636] JDKPathPanel does not work in console mode Created: 16/Dec/10  Updated: 29/Apr/11  Resolved: 18/Dec/10

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.3
Fix Version/s: 4.3.4, 5.0

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

from user-list:

I'm looking at JDKPathPanel and I see no JDKPathPanelAutomationHelper
class in the IzPack v4.3.3 distribution.

So it appears that the JDKPath variable won't get set and substituted
during an automated installation, right?

Andrew "bummed" Warinner



 Comments   
Comment by Mark Miller [ 16/Dec/10 ]

fixed in 4.3.3 at https://github.com/lucidimagination/izpack/commit/d9a6a714126b1a13ad472b7b7f5f4ccc6cf011f0

Comment by Mark Miller [ 16/Dec/10 ]

later in the thread, Andrew pointed out that the proper entry console helper entry was missing in build.xml





[IZPACK-635] User input panels: add message digest algorithms to encrypt passwords Created: 15/Dec/10  Updated: 21/Sep/12

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

A the moment, password encryption of a password input field requires a secret key, which must be somehow provided to the installer and also to the running application later, see http://jira.codehaus.org/browse/IZPACK-65

For several purposes it might be useful to use a simple message digest algorithm as SHA-1 to generate just a unique hash-code without the need of providing a secret key. In that case, just the algorithm must be known for encryption and decryption, and password verification can be done by comparing the produced hashcodes.

In that case, the example referred to above can be simplified as follows:

<field type="password" align="left" variable="the.password">
  <spec>
    <pwd txt="The Password:" size="25" />
    <pwd txt="Retype Password:" size="25" />
  </spec>
  <validator class="com.izforge.izpack.util.PasswordEqualityValidator" txt="Both passwords must match." id="key for the error text"/>
  <validator class="com.izforge.izpack.util.PasswordDigestValidator" txt="Could not encrypt password." id="key for the error text">
    <param name="algorithm" value="SHA-1"/>
  </validator>
</field>

Here is some code snippet how this could be achieved:

public static byte[] encrypt(String plainpass) throws Exception {
  java.security.MessageDigest d = java.security.MessageDigest.getInstance("SHA-1");
  d.reset();
  d.update(plainpass.getBytes());
  return d.digest();
}





[IZPACK-634] Console installations based on Curses Created: 07/Dec/10  Updated: 25/Jan/13

Status: Open
Project: IzPack
Component/s: Build, Compiler, Documentation, Installer, Panels, Showcases, Uninstaller
Affects Version/s: None
Fix Version/s: 6.0

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

Issue Links:
Duplicate
duplicates IZPACK-274 Implement a JavaCurses or CHARVA base... Open
Number of attachments : 0

 Description   

The current IzPack console installations offer a very "raw" user interface.

I would like to evaluate and possibly use a Curses library to get them looking more like a GUI in terminals. Nevertheless, Curses libraries are platform-dependent and require JNI, the implementation should run on the most major platforms IzPack supports.

Conditions:

  • Compatibility minimally with Windows, Linux and MacOS
  • on-demand integration into installer (pluggable)

The current console installations interface should not be replaced, curses installations should be launched by a separate command line option.

This would be a major an issue for some unkown version after 5.0.



 Comments   
Comment by Emmanuel Hugonnet [ 10/Dec/10 ]

Maybe we should take a look at Charva (http://www.pitman.co.za/projects/charva/index.html) for this.

Comment by Rene Krell [ 10/Dec/10 ]

I saw this already and Charva is worth to give a try and to be compared against JCurses (http://javacurses.sourceforge.net/). Both are licensed under LGPL, hopefully this will match the needs for IzPack.

I did not deal with those Java front-end frameworks in particular, but in Charva I liked the matching GUI component class name concept, while just replacing the package name javax.swing by charvax.swing. This could simplify something.

Comment by Julien Ponge [ 10/Dec/10 ]

LGPL is fine, as per our policy and the one of Codehaus

Comment by Rene Krell [ 10/Dec/10 ]

Another point is how to handle the native, platform-dependent part - in the Charva case: ncurses. I would rather favor requiring ncurses preinstalled than packaging precompiled native libraries for several OS and architectures into an IzPack installer. On standard desktop Unixes, this should be no problem at all, for MacOS one might use Fink (http://www.finkproject.org/) and there are also Windows ports (http://gnuwin32.sourceforge.net/packages/ncurses.htm, not sure whether PDCurses http://pdcurses.sourceforge.net/ provides also a usable interface). On the other hand side, preinstalling some kind of additional runtime components for IzPack can be painful for users. We might also use a mixed mode, for instance to favor pre-installed NCurses and package those which are mostly used as fallback.

There might be also design and implementation effort on IzPack class loading and on how we do switching the front-end for the installation. Currently, I see some limits in the way how we totally differently launch a GUI and a console installation. Charva might help here, because it overloads AWT and Swing classes.

There will be many ideas necessary to design this well, probably not of matter in 5.0.X

Comment by Rene Krell [ 25/Jan/13 ]

As a reminder, a current list of frameworks possible to use:





[IZPACK-633] TargetPanel - default directories defined by resources don't work in console installations Created: 07/Dec/10  Updated: 18/Dec/10  Resolved: 07/Dec/10

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.3
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 console installations, resource definitions like

<res id="TargetPanel.dir.windows" src="installpath.windows.txt"/>
<res id="TargetPanel.dir.unix" src="installpath.unix.txt"/>
...

do not have any affect. Currently, this works only for GUI installers.
This should work for console installations, also, there is nothing GUI-special with this.



 Comments   
Comment by Mark Miller [ 18/Dec/10 ]

I'm going to back port this one for 4.3.4 - I'd like this fixed as well.





[IZPACK-632] User input panels - directory chooser not implemented for console installations Created: 07/Dec/10  Updated: 07/Dec/10  Resolved: 07/Dec/10

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

When using dir input fields in user input panels, for instance

<field type="dir" variable="install.home">

this field is implemented for GUI installations only. During a console installation there appears an error message "dir field collection not implemented", and the field is skipped, instead.



 Comments   
Comment by Rene Krell [ 07/Dec/10 ]

Implemented like for file chooser - simple command line input (no auto-completion or something similar)





[IZPACK-631] Allow vetoing deletion of files during uninstall. Created: 24/Nov/10  Updated: 05/Jan/12

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

Type: Improvement Priority: Major
Reporter: Bjorn Beskow 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 need to prevent the Uninstaller to delete a settings file, and have found no clean way to do that. The beforeDeletion callback of UninstallerListener doesn't seem to allow that.

The workaround I have used so far is to make a copy of the file in beforeDeletion() and restore the file from the copy in afterDeletion(). It works, but is ugly.

I would suggest that the beforeDeletion() callback would be able to explicitly veto a file deletion, for instance by throwing a VetoException that is honored by the Destroyer.



 Comments   
Comment by Presidente Lula [ 05/Jan/12 ]

I've just had the same problem. I would like to keep some files from being deleted, and then first of all i tried to remove them from the List. But, not worked as expected: on further job, something else throws an exception OutOfBounds meaning that i should not remove stuff from that List.
I also had to work around and them what i did was to create a new fake file and to replace on the list, the file i wanted to keep, by this fake file.
It worked for this while, but let's wait for some cleaner solution.

Here is my code;

//l.remove( f ); // IzPack doesn't yet allow vetoing a file from being removed
l.set( l.indexOf( f ), new File("") );
Comment by Presidente Lula [ 05/Jan/12 ]

 





[IZPACK-630] i have an executable file created with izpack sfx. but it wont execute. it only extracts the files and won't install the program. is there something missing that is required to execute the program Created: 21/Nov/10  Updated: 22/Nov/10  Resolved: 21/Nov/10

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

Type: Bug Priority: Major
Reporter: kathy kinsella Assignee: Julien Ponge
Resolution: Fixed 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 have an executable file created with izpack sfx. but it wont execute. it only extracts the files and won't install the program. is there something missing that is required to execute the program. the progrom I am trying to execute is Snappy music.



 Comments   
Comment by Julien Ponge [ 21/Nov/10 ]

This is not an IzPack issue. The usual problems in this case are:

  • There is no Java Runtime on the Windows operating system, or
  • Another program (mostly compression ones such as 7-Zip / WinZip / WinRAR) have taken over the association of .jar files, resulting in broken behavior with executable Jar files.
Comment by kathy kinsella [ 21/Nov/10 ]

I have removed and uninstalled my winzip, 7zip and winrar compression programs and it is still not installing. Now it goes to extract and asks me which program do I want to use to open this file. Which compression software do I use?

Comment by Julien Ponge [ 21/Nov/10 ]

You need to get Java from http://java.com/

Comment by kathy kinsella [ 22/Nov/10 ]

Yes that worked. Thanks so much





[IZPACK-629] Take advantage of some informations from the POM when using Maven Created: 18/Nov/10  Updated: 13/Dec/12  Resolved: 04/Dec/10

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

Type: New Feature Priority: Minor
Reporter: Julien Ponge Assignee: Emmanuel Hugonnet
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

On Maven-based scenario, one could take advantage of informations from the POM (e.g., project name, authors, version, ...). Having it in both the POM and the IzPack descriptor is annoying for maintenance purposes.



 Comments   
Comment by Emmanuel Hugonnet [ 04/Dec/10 ]

The informations are merged between the POML.xml and the Izpack descriptor when using the izpack maven plugin.

Comment by vignesh [ 19/Jul/12 ]

This gets merged. My pom has all the developer details but when installing all I want to show is the companies details. Since it's getting merged I wish there is a way to not merge the information and just use the install.xml's info.

Comment by Rene Krell [ 19/Jul/12 ]

For being sure, please use the latest IzPack snapshot 5.0.0-beta11.
The developers aren't any longer merged automatically from the POM, I added a couple of switches to the IzPack Maven plugin some time ago. In your case this is autoIncludeDevelopers (default: false).

Example usage:

<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>
    <mkdirs>true</mkdirs>
    <autoIncludeUrl>false</autoIncludeUrl>
    <autoIncludeDevelopers>false</autoIncludeDevelopers>
  </configuration>
</plugin>




[IZPACK-628] Support shortcut file shortcutSpec.xml Created: 14/Nov/10  Updated: 14/Nov/10

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

Type: New Feature Priority: Major
Reporter: Dan Billings 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 the user to specify a shortcut file in izpack:izpack goal






[IZPACK-627] The installer exit when the filename or path dooes not contain "izpack" Created: 09/Nov/10  Updated: 18/Aug/12  Resolved: 18/Aug/12

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

Type: Bug Priority: Major
Reporter: Robert Csakany Assignee: Tim Anderson
Resolution: Fixed Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)


Number of attachments : 0

 Description   

The installer exits unexpedly when the name of JAR file dois not contan "izpack" or the path.

Exception in thread "AWT-EventQueue-0" com.izforge.izpack.api.exception.IzPackException: com.izforge.izpack.api.exception.MergeException: Could not find class SummaryLoggerInstallerListener : Current classpath is
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:54)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:633)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: com.izforge.izpack.api.exception.MergeException: Could not find class SummaryLoggerInstallerListener : Current classpath is
at com.izforge.izpack.merge.resolve.ClassPathCrawler.searchClassInClassPath(ClassPathCrawler.java:125)
at com.izforge.izpack.core.container.filler.EventFiller.loadCustomData(EventFiller.java:59)
at com.izforge.izpack.installer.container.impl.InstallerContainer.fillContainer(InstallerContainer.java:95)
at com.izforge.izpack.core.container.AbstractContainer.initBindings(AbstractContainer.java:25)
at com.izforge.izpack.installer.bootstrap.InstallerGui$1.run(InstallerGui.java:47)
... 8 more

I've debugged and I found the following:

ClassPathCrawler.filterUrl(Collection<URL>, List<String>) line: 182

The urlCollection is the following:

[jar:file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar!/META-INF/, jar:file:/System/Library/Java/Extensions/j3daudio.jar!/META-INF/, file:/Project/liveSense/org.liveSense.portal-dist/target/installer.jar, jar:file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext/sunjce_provider.jar!/META-INF/, jar:file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext/sunpkcs11.jar!/META-INF/, jar:file:/System/Library/Java/Extensions/vecmath.jar!/META-INF/, jar:file:/System/Library/Java/Extensions/mlibwrapper_jai.jar!/META-INF/, jar:file:/System/Library/Java/Extensions/j3dutils.jar!/META-INF/, jar:file:/System/Library/Java/Extensions/jai_codec.jar!/META-INF/, jar:file:/Project/liveSense/org.liveSense.portal-dist/target/installer.jar!/META-INF/, jar:file:/System/Library/Java/Extensions/MRJToolkit.jar!/META-INF/, jar:file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext/localedata.jar!/META-INF/, jar:file:/System/Library/Java/Extensions/dns_sd.jar!/META-INF/, jar:file:/System/Library/Java/Extensions/AppleScriptEngine.jar!/META-INF/, jar:file:/System/Library/Java/Extensions/j3dcore.jar!/META-INF/, jar:file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar!/META-INF/, jar:file:/System/Library/Java/Extensions/QTJava.zip!/META-INF/, jar:file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/jce.jar!/META-INF/, jar:file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext/dnsns.jar!/META-INF/, jar:file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext/apple_provider.jar!/META-INF/, jar:file:/System/Library/Java/Extensions/jai_core.jar!/META-INF/, jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaRuntimeSupport.framework/Versions/A/Resources/Java/JavaRuntimeSupport.jar!/META-INF/, jar:file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar!/META-INF/, jar:file:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar!/META-INF/]

and the List<String> acceptedJar = Arrays.asList(".event.", ".panel.", ".izpack.");

Because non of the classpath matches with the acceptedJar expressions, the classpath is null, so the classloader cannot load the classes.



 Comments   
Comment by Wilhelm Peraud [ 26/Apr/11 ]

I'm facing the same issue with izpack-maven-plugin 5.0.0-beta6.

Details at http://stackoverflow.com/questions/5788910/izpack-install-jar-works-only-in-a-folder-starting-with-izpack

Comment by Tom Grünheit [ 03/May/11 ]

I have the same problem with 5.0.0-beta7 ... see my comment in IZPACK-651

Rgds
Tom

Comment by Tim Anderson [ 18/Aug/12 ]

The compiler now emits fully qualified class names, so the ClassPathCrawler is not required to located unqualified classes.





[IZPACK-626] Usibility -Incomplete Message displayed in the confirmation window displayed during QUIT Action Created: 04/Nov/10  Updated: 04/Nov/10

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

Type: Bug Priority: Trivial
Reporter: Niambh Scullion Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP


Attachments: File changed display type.bmp    
Number of attachments : 1

 Description   

hi Guys, Testers have been running our installers (based on IZPack), and they have seen this Usibility issue, which I have replicated when build and run the sample installer shipped with IZpack 4.3.3

Following are the setting where this issue was seen:
1. Themes : Window XP
2. DPI Setting : Large size (120 DPI)

Steps to apply these changes:

1. Right Click on Desktop
2. Click on Properties
3. Click on Themes - Select "Windows XP".
4. Click on Settings->Advanced->Set DPI Setting to "Large size (120 DPI)" and restart the machine for changes to reflect.



 Comments   
Comment by Niambh Scullion [ 04/Nov/10 ]

Apologies, I meant to also say,
Many thanks in advance,
Niambh





[IZPACK-625] Panels are incorrectly merged Created: 21/Oct/10  Updated: 21/Oct/10  Resolved: 21/Oct/10

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

Type: Bug Priority: Major
Reporter: Anthonin Bonnefoy Assignee: Anthonin Bonnefoy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The InstallationTypePanel is merged in com/izforge/izpack/panels/install/ationtype/InstallationTypePanel



 Comments   
Comment by Anthonin Bonnefoy [ 21/Oct/10 ]

The regexp to capture the merge destination has been corrected.





[IZPACK-624] ProcessPanelWorker is not added in container Created: 21/Oct/10  Updated: 21/Oct/10  Resolved: 21/Oct/10

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

Type: Bug Priority: Major
Reporter: Anthonin Bonnefoy Assignee: Anthonin Bonnefoy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

ProcessPanel depends on class in the same package (com.izforge.izpack.panels.process.ProcessPanelWorker) but those class are not added in the container.
Thus, the installer fails with unsatisfied dependencies.



 Comments   
Comment by Anthonin Bonnefoy [ 21/Oct/10 ]

All concrete classes in the same package of the panels are now inserted in the container.





[IZPACK-623] TreePacksPanel shows the first tree pack greyed out Created: 20/Oct/10  Updated: 22/Jun/12  Resolved: 22/Jun/12

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

Type: Bug Priority: Minor
Reporter: Johan Bos Assignee: Unassigned
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, Sun JVM 1.5


Attachments: PNG File Izpack-4.3.1-treepacks.png     PNG File Izpack-4.3.4-treepacks.png    
Number of attachments : 2

 Description   

When using the TreePacksPanel, the first "tree" pack is always greyed out

I thought only unselectable (disabled from condition) packs are greyed out. But the one I used, is setup to be not required and not preselected. It is confusing.

Example install.xml, where pack1 will not be selected at init, font is grey but selectable:

<packs>
<pack name="pack1" required="no">
...
</pack>
<pack name="pack11" required="no" preselected="no" parent="pack1">
...
</pack>
<pack name="pack12" required="no" preselected="no" parent="pack1">
...
</pack>
<pack name="pack2" required="no" preselected="no">
...
</pack>
</packs>



 Comments   
Comment by Stéphan AIME [ 08/Jun/11 ]

I tried to add a first dummy hidden pack:

<packs>
<pack name="dummy" required="no" preselected="no" hidden="yes">
...
</pack>
<pack name="pack1" required="no" preselected="no">
...
</pack>
...
</packs>

But this leads into an ArrayOutOfBoundsException:

Exception in thread "AWT-EventQueue-0" java.lang.IndexOutOfBoundsException: Index: 9, Size: 9
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at com.izforge.izpack.panels.PacksModel.getValueAt(Unknown Source)
at com.izforge.izpack.panels.TreePacksPanel.updateModel(Unknown Source)
at com.izforge.izpack.panels.TreePacksPanel.updateModel(Unknown Source)
at com.izforge.izpack.panels.TreePacksPanel.updateModel(Unknown Source)
at com.izforge.izpack.panels.TreePacksPanel.fromModel(Unknown Source)
at com.izforge.izpack.panels.CheckBoxNodeRenderer.getTreeCellRendererComponent(Unknown Source)
at javax.swing.plaf.basic.BasicTreeUI$NodeDimensionsHandler.getNodeDimensions(BasicTreeUI.java:2712)
at javax.swing.tree.AbstractLayoutCache.getNodeDimensions(AbstractLayoutCache.java:475)
at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.updatePreferredSize(VariableHeightLayoutCache.java:1342)
at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.getPreferredWidth(VariableHeightLayoutCache.java:1159)
at javax.swing.tree.VariableHeightLayoutCache.getMaxNodeWidth(VariableHeightLayoutCache.java:990)
at javax.swing.tree.VariableHeightLayoutCache.getPreferredWidth(VariableHeightLayoutCache.java:291)
at javax.swing.plaf.basic.BasicTreeUI.updateCachedPreferredSize(BasicTreeUI.java:1823)
at javax.swing.plaf.basic.BasicTreeUI.getPreferredSize(BasicTreeUI.java:1921)
at javax.swing.plaf.basic.BasicTreeUI.getPreferredSize(BasicTreeUI.java:1909)
at javax.swing.JComponent.getPreferredSize(JComponent.java:1634)
at javax.swing.ScrollPaneLayout.layoutContainer(ScrollPaneLayout.java:769)
at java.awt.Container.layout(Container.java:1421)
at java.awt.Container.doLayout(Container.java:1410)
at java.awt.Container.validateTree(Container.java:1507)
at java.awt.Container.validateTree(Container.java:1513)
at java.awt.Container.validateTree(Container.java:1513)
at java.awt.Container.validateTree(Container.java:1513)
at java.awt.Container.validateTree(Container.java:1513)
at java.awt.Container.validateTree(Container.java:1513)
at java.awt.Container.validate(Container.java:1480)
at javax.swing.RepaintManager.validateInvalidComponents(RepaintManager.java:669)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:124)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
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)

Comment by Dustin Kut Moy Cheung [ 22/Jun/12 ]

This was already fixed in 4.3.4. Should be marked as resolved.

Comment by Dustin Kut Moy Cheung [ 22/Jun/12 ]

I had to use Izpack 4.3.1 since my build strangely does not work with Izpack 4.3.3.

Bottom screenshot is Izpack 4.3.4.





[IZPACK-622] No previous button in panels (izpack5-beta) Created: 11/Oct/10  Updated: 11/Oct/10  Resolved: 11/Oct/10

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

Type: Bug Priority: Major
Reporter: Anthonin Bonnefoy Assignee: Anthonin Bonnefoy
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 no previous button on panels.



 Comments   
Comment by Anthonin Bonnefoy [ 11/Oct/10 ]

Corrected the previous button visibility management.





[IZPACK-621] izpack2exe.py on Linux -> No such file or directory: 'installer.7z' Created: 07/Oct/10  Updated: 21/Nov/10  Resolved: 21/Nov/10

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

Type: Bug Priority: Major
Reporter: chris snow Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Ubuntu 10.04 LTS x64


Number of attachments : 0

 Description   

Steps to reproduce:

java -jar /home/snowch/Downloads/izpack-dist-5.0.0-beta2-installer.jar  # Accept defaults
cd ~/IzPack/utils/wrappers/izpack2exe
chmod +x *
./izpack2exe --file=myjar

Error:

Error:
Incorrect command line
Traceback (most recent call last):
  File "./izpack2exe.py", line 116, in <module>
    main()
  File "./izpack2exe.py", line 113, in main
    create_exe(parse_options())
  File "./izpack2exe.py", line 96, in create_exe
    in_file = open(f, 'rb')
IOError: [Errno 2] No such file or directory: 'installer.7z'


 Comments   
Comment by Julien Ponge [ 19/Oct/10 ]

installer.7z is your installer Jar that gets compressed by 7Zip. Can you check that you actually have 7-Zip (or p7zip) on your system?

Cheers

Comment by chris snow [ 20/Oct/10 ]

I have p7zip installed:

snowch@euc-nc:~/IzPack/utils/wrappers/izpack2exe$ p7zip -h
Usage: /usr/bin/p7zip [-d] [-h|--help] [file]
snowch@euc-nc:~/IzPack/utils/wrappers/izpack2exe$ dpkg --listfiles p7zip
/.
/usr
/usr/bin
/usr/bin/p7zip
/usr/bin/7zr
/usr/share
/usr/share/doc
/usr/share/doc/p7zip
/usr/share/doc/p7zip/ChangeLog.gz
/usr/share/doc/p7zip/README.gz
/usr/share/doc/p7zip/TODO
/usr/share/doc/p7zip/DOCS
/usr/share/doc/p7zip/DOCS/lzma.txt.gz
/usr/share/doc/p7zip/DOCS/MANUAL
/usr/share/doc/p7zip/DOCS/MANUAL/style.css
/usr/share/doc/p7zip/DOCS/MANUAL/syntax.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches
/usr/share/doc/p7zip/DOCS/MANUAL/switches/stdin.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/update.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/overwrite.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/yes.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/style.css
/usr/share/doc/p7zip/DOCS/MANUAL/switches/type.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/charset.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/ar_include.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/sfx.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/volume.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/method.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/password.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/recurse.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/ssc.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/exclude.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/index.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/stop_switch.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/list_tech.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/working_dir.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/include.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/ar_exclude.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/ar_no.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/stdout.htm
/usr/share/doc/p7zip/DOCS/MANUAL/switches/output_dir.htm
/usr/share/doc/p7zip/DOCS/MANUAL/commands
/usr/share/doc/p7zip/DOCS/MANUAL/commands/extract.htm
/usr/share/doc/p7zip/DOCS/MANUAL/commands/extract_full.htm
/usr/share/doc/p7zip/DOCS/MANUAL/commands/list.htm
/usr/share/doc/p7zip/DOCS/MANUAL/commands/update.htm
/usr/share/doc/p7zip/DOCS/MANUAL/commands/style.css
/usr/share/doc/p7zip/DOCS/MANUAL/commands/test.htm
/usr/share/doc/p7zip/DOCS/MANUAL/commands/index.htm
/usr/share/doc/p7zip/DOCS/MANUAL/commands/add.htm
/usr/share/doc/p7zip/DOCS/MANUAL/commands/bench.htm
/usr/share/doc/p7zip/DOCS/MANUAL/commands/delete.htm
/usr/share/doc/p7zip/DOCS/MANUAL/index.htm
/usr/share/doc/p7zip/DOCS/MANUAL/exit_codes.htm
/usr/share/doc/p7zip/DOCS/readme.txt.gz
/usr/share/doc/p7zip/DOCS/7zC.txt.gz
/usr/share/doc/p7zip/DOCS/Methods.txt
/usr/share/doc/p7zip/DOCS/7zFormat.txt.gz
/usr/share/doc/p7zip/DOCS/history.txt.gz
/usr/share/doc/p7zip/README.Debian
/usr/share/doc/p7zip/copyright
/usr/share/doc/p7zip/changelog.Debian.gz
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/7zr.1.gz
/usr/share/man/man1/p7zip.1.gz
/usr/lib
/usr/lib/p7zip
/usr/lib/p7zip/7zr
/usr/share/doc/p7zip/changelog.gz
Comment by Julien Ponge [ 22/Oct/10 ]

What if you run ./izpack2exe --file=myjar --with-7z=p7zip ?

Comment by chris snow [ 23/Oct/10 ]

snowch@euc-nc:~/IzPack/utils/wrappers/izpack2exe$ ./izpack2exe.py --file=my.jar --with-7z=/usr/bin/p7zip
Usage: /usr/bin/p7zip [-d] [-h|--help] [file]

    -h print this help
    -d decompress file

f= /usr/bin/7zS.sfx
Traceback (most recent call last):
  File "./izpack2exe.py", line 117, in <module>
    main()
  File "./izpack2exe.py", line 114, in main
    create_exe(parse_options())
  File "./izpack2exe.py", line 97, in create_exe
    in_file = open(f, 'rb')
IOError: [Errno 2] No such file or directory: '/usr/bin/7zS.sfx'
Comment by Julien Ponge [ 25/Oct/10 ]

How about with '--with-7z=7zr'?

The thing here is just that izpack2exe needs to find a proper 7Zip archiver. It does not look like an IzPack issue at all.

You can use the --help flag to get all the options. You may also look at the code of the script, it's straightforward Python code.

Comment by chris snow [ 27/Oct/10 ]

The problem seems to be with this line:

p7zcmd = '"%s" a -mmt -t7z -mx=9 -sm=on installer.7z "%s"' % (p7z, files)

It seems that IzPack/utils/wrappers/izpack2exe/7za doesn't like the option -sm=on

I removed the -sm=on option and setup.exe was created with no error:

p7zcmd = '"%s" a -mmt -t7z -mx=9 installer.7z "%s"' % (p7z, files)
Comment by Julien Ponge [ 21/Nov/10 ]

Ok thanks

Comment by Julien Ponge [ 21/Nov/10 ]

Fixed.





[IZPACK-620] Installation doesn't show scandinavian letters (äö) correctly after choosing Finnish language Created: 04/Oct/10  Updated: 25/Oct/10  Resolved: 25/Oct/10

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

Type: Bug Priority: Minor
Reporter: Jukka Aalto Assignee: Ari Voutilainen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP
izPack 5.0 beta 2


Attachments: GIF File FinnishFirstPage.gif     XML File fin.xml    
Number of attachments : 2

 Description   

Scandinavian letters (äö) are replaced with other characters, when installing izPack. Check out the attachment. The red arrow shows one place where the replace occurred. There should be text "Tämän".

It seems that this problem occurs only when choosing Finnish language.



 Comments   
Comment by Julien Ponge [ 19/Oct/10 ]

Looks like the file has an encoding issue of some sort. Would you be able to recode it in UTF-8?

Comment by Ari Voutilainen [ 19/Oct/10 ]

Unfortunatelly character encoding has been changed when the code has been copied into git. In SVN characters are correct. There is encoding info inside fin.xml file which is "iso-8859-1". That is the same as in eng.xml. At this moment I wasn't able to find out what encoding has been used with the file so I wasn't able to reproduce back to Finnish characters. I hope that only way isn't to rewrite all messages...

Comment by Julien Ponge [ 19/Oct/10 ]

Well the SVN repo is still alive, we just don't commit to it, so the files can be taken there to Git and re-encoded if need be.

Comment by Ari Voutilainen [ 19/Oct/10 ]

Ok. I'll check this. All possible missing strings are simplier to add afterwards than start to correct all those letters.

Comment by Ari Voutilainen [ 19/Oct/10 ]

Finnish translation taken from SVN. At the moment I have no any way to update this file to git.

Comment by Ari Voutilainen [ 19/Oct/10 ]

Use this file instead: taken from IzPack copy in Git. Content is reformatted and Finnish characters are correct.

Comment by Ari Voutilainen [ 25/Oct/10 ]

Updated.





[IZPACK-619] Allow dev to set window icon for installer Created: 01/Oct/10  Updated: 19/Oct/10

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

Type: New Feature Priority: Major
Reporter: Brendan Graetz Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 8.04
(platform agnostic)


Patch Submitted:
Yes
Number of attachments : 0

 Description   

IzPack currently provides a means for the user to set the icon for the desktop shortcut and the applications menu (or Program Files menu in Windows). It also allows you to display images in the "heading" panel.
https://izpack.github.io/documentation/advanced-features.html#picture-in-the-installer

However, currently there does not appear to be any means to set the icons for the window manager of the installer itself - the icon that appears in the top-left corner of the frame, in the title bar; Instead it always defaults to the default IzPack icon.

Could I request that IzPack allow us to specify this icon via the resources section.

Perhaps in `install.xml`:
<resources>
<res id="Installer.windowIcon" src="src/com/xyz/xyz_logo.png"/>
</resources>

And in the source for the main IzPack JFrame:
List<Image> windowIcons = new LinkedList<Image>();
Image imageIcon = null;
String resourceName = installerData.getProperty("Installer.windowIcon");
//attempt to load resource (the icon image file)
try

{ imageIcon = new ImageIcon( getClass().getResource(resourceName)).getImage(); windowIcons.add(imageIcon); }

catch (Exception e)

{ //do nothing, handle subsequently }

if (windowIcons.size() == 0)

{ //use default IzPack icon, add this to windowIcons list }

//set icons used by window manager
this.setIconImages(windowIcons);



 Comments   
Comment by Brendan Graetz [ 01/Oct/10 ]

After a more careful inspection of the source code, it appears that IzPack does indeed have some support for custom icons.

However, this functionality is not exposed to the developer via install.xml or any of the other configuration files.

See `com.izforge.izpack.installer.InstallerFrame.java`:

public InstallerFrame(String title, InstallData installdata, InstallerBase parentInstaller)

{ ... // Builds the GUI loadIcons(); loadCustomIcons(); ... }

protected void loadCustomIcons()

{

...

// We try to load and add a custom langpack.

InputStream inXML = null;

try

{ inXML = ResourceManager.getInstance().getInputStream(CUSTOM_ICONS_RESOURCEFILE); }

...

// We load the Swing-specific icons

children = data.getChildrenNamed("sysicon");

size = children.size();

for (int i = 0; i < size; i++)

{ icon = children.get(i); url = InstallerFrame.class.getResource(icon.getAttribute("res")); img = new ImageIcon(url); //problem UIManager.put(icon.getAttribute("id"), img); }

}

/**

  • Resource name for custom icons
    */

private static final String CUSTOM_ICONS_RESOURCEFILE = "customicons.xml"; //problem

The last line where CUSTOM_ICONS_RESOURCEFILE is problematic; developer does not have any means of specifying this is install.xml.

Also, in the loadCustomIcons method, `new ImageIcon(url)` is used; another method `loadIcon(String resPrefix, int PanelNo, boolean tryBaseIcon)` looks like it might be a better choice.

Comment by Julien Ponge [ 19/Oct/10 ]

Thanks for your report. If you have the time, would you be able to provide us with a patch?

Cheers





[IZPACK-618] Updated norwegian translation Created: 26/Sep/10  Updated: 30/Sep/10  Resolved: 30/Sep/10

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

Type: Improvement Priority: Minor
Reporter: Håvard Mork Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

 Description   

Updated norwegian translation is attached. Needed it for my project, so I can just as well contribute it.

Please committ to izpack-core/src/main/resources/bin/langpacks/installer/nor.xml

Fixed a few syntactic errors in original translation; added a lot of new strings (as of current Git head revision); changed xml header to indicate UTF-8.



 Comments   
Comment by Julien Ponge [ 30/Sep/10 ]

Thanks!





[IZPACK-617] IZPack ant task is failing with "com.izforge.izpack.api.exception.CompilerException: Neither install file nor text specified " Created: 24/Sep/10  Updated: 24/Oct/10  Resolved: 24/Oct/10

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

Type: Bug Priority: Critical
Reporter: Mark Miller Assignee: Anthonin Bonnefoy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

izpack 5 beta 2 tag


Number of attachments : 0

 Description   

I'm trying to build using the ant task plugin.

I've been trying to track down what is causing this.

I see that the ant task is creating a compilerData without the install
file or install text.

CompilerData compilerData = new CompilerData(compression, kind, null,
configText, basedir, output, compressionLevel);

Instead, it tries to set it with:
propertyManager.setProperty("izpack.file", file.toString());

But then it seems that when i get to CompilerConfig#getXMLTree(), it
bails because neither the install file nor install text have been set on
the CompilerConfig.



 Comments   
Comment by Mark Miller [ 24/Sep/10 ]

from the mailing list:

Can you fill a Jira ticket? I will take care of it.

Cheers,
Anthonin

Comment by Anthonin Bonnefoy [ 11/Oct/10 ]

Pico container was not correctly initialised.
The ant task should work now.

Comment by Mark Miller [ 14/Oct/10 ]

I just tried the beta3 and I still have the same problem unfortunately...

Comment by Mark Miller [ 24/Oct/10 ]

Okay, I think this is actually good now.

Was getting caught up on "Added ant task to distribution" I think - missed that I hadn't replaced my old jar because the new jar was not in the dist.

I've run into another issue right after, but I'm beyond this issue it looks.

Thanks,

Mark





[IZPACK-616] IzPack Auto-Install: Discrepancy between Auto Install and GUI Created: 24/Sep/10  Updated: 24/Sep/10

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

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

Fedora 12 2.6.32.21-166.fc12.i686
Java:
OpenJDK Runtime Environment (IcedTea6 1.8.1) (fedora-40.b18.fc12-i386)
OpenJDK Server VM (build 14.0-b16, mixed mode)


Number of attachments : 0

 Description   

When attempting to use the auto-install feature (using an xml generated by the FinishPanel), I have what I feel is incorrect Precedence in conditions.

I have a pack, Pack1, which is marked "Required", and is also controlled by a condition called A. A is decided through a radio button on a UserInputPanel.
A can be either 1, or 2. If A is 1, the pack is not installed. If A is 2, the pack is installed.

Everything works fine in the GUI side.
Using the auto-install, Pack1 is always installed, regardless of A's value.

The behaviours of the GUI vs. Auto install do not match up. The GUI has the effect of not allowing the user to deselect or select the pack on the TreePacksPanel, just see whether it is to be installed or not (this is the desired behaviour for me). The Auto install just installs it, completely ignoring the condition A.

Please contact me if more information is needed. Thanks

Here is some snips from my auto-install.xml:
<userInput>
<entry key="A.choice" value="1"/>
</userInput>
</com.izforge.izpack.panels.UserInputPanel>
<com.izforge.izpack.panels.TreePacksPanel id="UNKNOWN (com.izforge.izpack.panels.TreePacksPanel)">
<pack index="11" name="Pack1" selected="true"/>
</com.izforge.izpack.panels.TreePacksPanel>

The Pack1 definition:
<pack name="Pack1" id="Pack1" condition="!A"
required="yes">
<description>Pack1</description>
<fileset dir="....">
<include name="**" />
</fileset>
</pack>

The A definition in conditions.xml:
<condition type="variable" id="A">
<name>A.choice</name>
<value>1</value>
</condition>

The A selection in userInputSpec.xml:
<field type="radio" variable="A.choice">
<description align="left" txt="Choices for A"
id="A.description"/>
<spec>
<choice txt="A = 1" id="A.1" value="1" set="true"/>
<choice txt="A = 2" id="A.2" value="2" />
</spec>
</field>






[IZPACK-615] ClassCastException on Uninstall Created: 21/Sep/10  Updated: 27/Jan/12  Resolved: 27/Jan/12

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

Type: Bug Priority: Major
Reporter: Gregor B. Rosenauer Assignee: Tim Anderson
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64


Number of attachments : 0

 Description   

Install went fine, but when uninstalling fails.
When launching the uninstaller and pressing "uninstall" (with or without deleting files), the user is greeted with the following error

java.lang.ClassCastException: com.izforge.izpack.event.SummaryLoggerInstallerListener cannot be cast to com.izforge.izpack.event.UninstallerListener
at com.izforge.izpack.uninstaller.Destroyer.getListenerLists(Unknown Source)
at com.izforge.izpack.uninstaller.Destroyer.run(Unknown Source)


 Comments   
Comment by Mark Curtin [ 13/Oct/10 ]

Any update on the resolution of this issue?

Comment by Julien Ponge [ 13/Oct/10 ]

This may be specific to your installer, but this is hard to tell without further details.

Comment by Niambh Scullion [ 03/Nov/10 ]

Hi Julian,

In our install.xml file we have the following entry
<listeners>
<listener installer="SummaryLoggerInstallerListener"
uninstaller="SummaryLoggerInstallerListener" >
</listener>
</listeners>

To resolve/workaround the issue I have removed uninstaller="SummaryLoggerInstallerListener.

Regards,
Niambh

Comment by Julien Ponge [ 03/Nov/10 ]

Just for the record, can you try with a 5.0 beta?

I am asking because we won't make any further 4.3 release anyway.

Comment by Tim Anderson [ 27/Jan/12 ]

SummaryLoggerInstallerListener is only valid during installation - it cannot be used as an uninstall listener.

Comment by Gregor B. Rosenauer [ 27/Jan/12 ]

Oh, I see, so is there something like a SummaryLoggerUninstallerListener then?
I often see this in uninstallers and really like the transparency and usability of a uninstall log that can be presented to the user.

Comment by Tim Anderson [ 27/Jan/12 ]

No, but you would write your own. See http://izpack.codehaus.org/izpack-api/apidocs/com/izforge/izpack/api/event/UninstallerListener.html





[IZPACK-614] Variable passing to file selector via InstallData#setVariable or InstallData#setAttribute not working Created: 17/Sep/10  Updated: 17/Sep/10

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

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

Ubuntu 8.04 & Windows XP (not relevant to issue)


Number of attachments : 0

 Description   

I am customising my IzPack, I have a custom IzPanel which parses some files (created by a previous installation of the same program), and is attempting to populate the

In MyCustomIzPanel.java (a customised IzPanel)

//idata is the InstallData object
String oLicenceFile = ... // Code to obtain where this file is
idata.setVariable("license_locn", oLicenceFile);
idata.setAttribute("license_locn", oLicenceFile);
idata.setVariable("license_locn_str", oLicenceFile);
idata.setAttribute("license_locn_str", oLicenceFile);

In userInputSpec.xml (which defines the UserInputPanel)

<field type="search" variable="license_locn">
<description
align="left"
txt="Please select a license file."
id="description.license_locn"/>
<spec txt="Path to license file:" id="description.license_path"
type="file" result="file"
set="$license_locn_str">
<choice value="~/license.bin" os="unix" />
<choice value="C:\My Documents\license.bin" os="windows" />
</spec>
</field>

When the UserInputPanel displays the search field remains blank; thus neither the setVariable nor the setAttribute properties appear to get the job done. Even when explicitly specified using the set attribute of the <spec> tag.

[more detail]

I should mention that when the field type is text, instead of search (for a file), the variable gets passed from MyCustomIzPanel to UserInputPanel successfully.

In MyCustomIzPanel.java

idata.setVariable("user_email_address", oEmail);

In userInputSpec.xml (which defines the UserInputPanel)

<field type="text" variable="user_email_address">
<description align="left" txt="Please enter your email address."
id="user.email"/>
<spec txt="email:" id="text.label" size="30" set="user@host"/>
</field>

So the problem breaks down to: why it works when the filed type is "text" but not "search"?



 Comments   
Comment by Brendan Graetz [ 17/Sep/10 ]

Note that this happens for "search" fields for both type "file" and type "directory".





[IZPACK-613] maven-plugin fails with unsatisfied dependency Created: 16/Sep/10  Updated: 11/Oct/10  Resolved: 11/Oct/10

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

Type: Bug Priority: Major
Reporter: Gregor B. Rosenauer Assignee: Anthonin Bonnefoy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64, Eclipse 3.6, Maven 2.2.1 (also tried 3.0-latest snapshot), izPack-5.0-beta1


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

 Description   

When trying to compile with the attached POM, I always get this: (4.3 worked)

[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for at.sozvers.seucc:ta30j-referenzinstallation:pom:3.5.2_0.8.0
[WARNING] 'repositories.repository.layout = legacy' is deprecated: Hastings-Maven1-Repo @ at.sozvers.seucc:ta30j-referenzinstallation:3.5.2_0.8.0, C:\ta30\Projekte\eclipse_ri\ta30j-referenzinstallation\pom.xml
[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]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building TA3.0J Referenzinstallation 3.5.2_0.8.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] — maven-resources-plugin:2.4.3:copy-resources (copy-resources) @ ta30j-referenzinstallation —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 25 resources
[INFO]
[INFO] — izpack-maven-plugin:5.0.0-beta1:izpack (default) @ ta30j-referenzinstallation —
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
org.apache.maven.plugin.MojoExecutionException: IzPack compilation ERROR
at org.izpack.mojo.IzPackMojo.buildInstaller(IzPackMojo.java:280)
at org.izpack.mojo.IzPackMojo.execute(IzPackMojo.java:173)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:577)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:324)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:247)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:104)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:427)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:157)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:121)
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: org.picocontainer.injectors.AbstractInjector$UnsatisfiableDependenciesException: com.izforge.izpack.compiler.helper.AssertionHelper has unsatisfied dependency: class java.lang.String among unsatisfiable dependencies: [[class java.lang.String]] where org.picocontainer.DefaultPicoContainer@512d8ecd:25<(empty) was the leaf container being asked for dependencies.
at org.picocontainer.injectors.ConstructorInjector.getGreediestSatisfiableConstructor(ConstructorInjector.java:188)
at org.picocontainer.injectors.ConstructorInjector.getGreediestSatisfiableConstructor(ConstructorInjector.java:110)
at org.picocontainer.injectors.ConstructorInjector.access$100(ConstructorInjector.java:51)
at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:308)
at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:274)
at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:341)
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:641)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:630)
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:76)
at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:286)
at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:312)
at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:274)
at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:341)
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:641)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:630)
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:76)
at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:286)
at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:312)
at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:274)
at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:341)
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:641)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:630)
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:76)
at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:286)
at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:312)
at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:274)
at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:341)
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:641)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:666)
at com.izforge.izpack.core.container.AbstractContainer.getComponent(AbstractContainer.java:40)
at org.izpack.mojo.IzPackMojo.buildInstaller(IzPackMojo.java:268)
... 17 more
[INFO]
[INFO] — maven-install-plugin:2.3:install (default-install) @ ta30j-referenzinstallation —
[INFO] Installing C:\ta30\Projekte\eclipse_ri\ta30j-referenzinstallation\pom.xml to C:\Users\rosenauer\.m2\repository\at\sozvers\seucc\ta30j-referenzinstallation\3.5.2_0.8.0\ta30j-referenzinstallation-3.5.2_0.8.0.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.423s
[INFO] Finished at: Thu Sep 16 12:59:31 CEST 2010
[INFO] Final Memory: 6M/143M
[INFO] ------------------------------------------------------------------------



 Comments   
Comment by Anthonin Bonnefoy [ 11/Oct/10 ]

The problem was due to some remains of non-functional maven plugin.
The new maven plugin is now called with the "izpack" goal (instead of the unknown "compile" goal) and thus replace the old plugin.





[IZPACK-612] Beta installer crashes in java -jar syntax Created: 14/Sep/10  Updated: 23/Sep/10  Resolved: 23/Sep/10

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

Type: Bug Priority: Major
Reporter: Michael Bowker Assignee: Anthonin Bonnefoy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows xp java 1.6


Number of attachments : 0

 Description   

C:\Documents and Settings\mbowker\My Documents\My Downloads\Installers>java -jar izpack-dist-5.0.0-beta1-installer.jar
com.izforge.izpack.api.exception.MergeException: Could not find class SummaryLog gerInstallerListener : Current classpath is file:/C:/Documents%20and%20Settings/
mbowker/My%20Documents/My%20Downloads/Installers/izpack-dist-5.0.0-beta1-install
er.jar!/META-INF/
/C:/Documents%20and%20Settings/mbowker/My%20Documents/My%20Downloads/Installers/
izpack-dist-5.0.0-beta1-installer.jar

at com.izforge.izpack.merge.resolve.ClassPathCrawler.searchClassInClassP
ath(ClassPathCrawler.java:123)
at com.izforge.izpack.core.container.filler.EventFiller.loadCustomData(E
ventFiller.java:59)
at com.izforge.izpack.installer.container.impl.InstallerContainer.fillCo
ntainer(InstallerContainer.java:95)
at com.izforge.izpack.core.container.AbstractContainer.initBindings(Abst
ractContainer.java:25)
at com.izforge.izpack.installer.bootstrap.Installer.initContainer(Instal
ler.java:77)
at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:
64)

On windows xp, java 1.6



 Comments   
Comment by Anthonin Bonnefoy [ 15/Sep/10 ]

Reproducible on linux and windows :
Launch the installer in a path with a space.

Comment by Anthonin Bonnefoy [ 23/Sep/10 ]

Fix in 5.0.0-beta2
The problem came from a bad use of url.getFile().

new File(url.getFile()) won't work if there is special character in the url. The url should be decoded with URLDecoder.decode beforehand.





[IZPACK-611] Console Installer misspelling: Install was successeful Created: 14/Sep/10  Updated: 29/Apr/11  Resolved: 15/Sep/10

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.3
Fix Version/s: 4.3.4, 5.0

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

Install was successeful should be Install was successeful



 Comments   
Comment by Julien Ponge [ 15/Sep/10 ]

The string is not in 5.0 anymore.

Comment by Mark Miller [ 16/Dec/10 ]

FWIW: it should be: should be Install was successful in the description

Comment by Mark Miller [ 16/Dec/10 ]

fixed it on 4.3.3 here: https://github.com/lucidimagination/izpack/commit/eccf2443cb39015689f7cab227ebd90214c1a81b





[IZPACK-610] FinishPanel has hardcoded path for Uninstaller location Created: 10/Sep/10  Updated: 29/Apr/11  Resolved: 17/Feb/11

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: None
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Minor
Reporter: Mark Miller 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   

Say you change the installer dir, or even just make it uninstaller rather than Uninstaller:

<uninstaller name="uninstaller.jar" path="$INSTALL_PATH/uninstaller"/>

FinishPanel doesn't respect that when it tells the user where to find the uninstaller:

// We prepare a message for the uninstaller feature
String path = translatePath("$INSTALL_PATH") + File.separator + "Uninstaller";

Instead, it should pick up the correct uninstaller path.



 Comments   
Comment by Mark Miller [ 10/Sep/10 ]

Say you change the installer dir

should be:

Say you change the uninstaller dir

Comment by Mark Miller [ 15/Dec/10 ]

I have made a fix for this off 4.3.3 here:
https://github.com/lucidimagination/izpack/commit/418de508a67a14dfc7413ddb319c7418c0c18664

Comment by Julien Ponge [ 17/Feb/11 ]

I am closing since that was merged.





[IZPACK-609] Treepackpanel: single child cannot be excluded from install Created: 10/Sep/10  Updated: 10/Sep/10

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

Type: Bug Priority: Minor
Reporter: Gregor B. Rosenauer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x65


Number of attachments : 0

 Description   

When using a TreePackPanel and defining a package with a single "child" (package with parent-ref), you cannot deselect the child package without also automatically deselecting the parent.
This is unwanted when the parent package is not just a holder but includes files itself.

E.g. a package "documentation" with custom documentation and a single child "Javadocs":

        <pack name="Dokumentation" required="no" id="docs"
            <file src="Dokumentation" targetdir="$INSTALL_PATH" />
        </pack>
            <pack name="Javadocs JDK6" required="no" parent="docs">
                <file src="Java/$JAVADOCS_NAME" targetdir="$INSTALL_PATH/Dokumentation" unpack="true" />
            </pack>

The user has to install all documentation and cannot exclude the Javadocs-package.
This is a bug in izPack's package handling.



 Comments   
Comment by Julien Ponge [ 10/Sep/10 ]

Did you test with our Git master?

Otherwise check back next wednesday as we release our first 5.0 beta.





[IZPACK-608] deseclect is misspelled in console installer mode for checkboxes Created: 06/Sep/10  Updated: 29/Apr/11  Resolved: 07/Sep/10

Status: Closed
Project: IzPack
Component/s: None
Affects Version/s: 4.3.3
Fix Version/s: 4.3.4, 5.0

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

in UserInputPanelConsoleHelper.java

input 1 to select, 0 to deseclect:


 Comments   
Comment by Julien Ponge [ 07/Sep/10 ]

Thanks!

Comment by Mark Miller [ 16/Dec/10 ]

backported to 4.3.3: https://github.com/lucidimagination/izpack/commit/a86ae8cc6a5c655770241bbfa70cc3cae24d5bd1





[IZPACK-607] Documentation for creating custom panels (now) incorrect Created: 01/Sep/10  Updated: 01/Sep/10  Resolved: 01/Sep/10

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

Type: Bug Priority: Minor
Reporter: mark sipos 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   

Part of the documentation on creating new panels is (now) incorrect
link: https://izpack.github.io/documentation/creating-panels.html

Source (Next Steps Section)

Once you have a successful compilation, you must [emphasis added] place the compiled result of your panel code at a special place, so that the installer compiler can fetch it when building an installer that uses your panel. Go to: /bin/panels You will see that there is a subdirectory for each panel. Make a subdirectory for your new panel with the exact same name as your panel and place your compiled panel code there.

This is no longer true as of at least 4.3.3, where custom panels can be built independently and then merged in by using the <jar> element. I'm quite pleased with this as I think keeping the base package and custom bits separate is the way to go.



 Comments   
Comment by Julien Ponge [ 01/Sep/10 ]

You may fix that at http://docs.codehaus.org/display/IZPACK/User+documentation

Cheers





[IZPACK-606] Support the creation of a temporary directory at install time which is cleaned up when install completes Created: 25/Aug/10  Updated: 31/Aug/10  Resolved: 31/Aug/10

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

Type: New Feature Priority: Major
Reporter: Sean O'Loughlin Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File temp_directory_support.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

A temporary directory which can be referenced in the install.xml would make the management of files needed at install time much simpler. The attached patch (to the git head as of 2010/08/24) adds support for one or more temporary directories which are automatically cleaned up when the installer completes. To aid in debugging temporary directories are not deleted when tracing is enabled.



 Comments   
Comment by Julien Ponge [ 30/Aug/10 ]

I don't quite get the use-case for this feature.

Would you have a concrete scenario to justify the need for this, and how it helps?

Thanks

Comment by Sean O'Loughlin [ 31/Aug/10 ]

This feature would be useful in a couple of scenarios;
If your installer needs to install a third party product or library by executing that products installer, but you don't want that installer around afterwards. You can do this with the delete attribute on the execute tag but that won't clean up any supporting files.
If you have some sql scripts or any other files which need to be run through an interpreter and you don't want them hanging around after the install completes.
If you need to create a file, populate it with values from the installers gui and pass that file off to another program for some reason, after which you no longer need the file.

Often in the process of installing something you create temporary files. IzPack currently provides no mechanism for deleting these files so you potentially need a set of OS dependant executables to clean up. A temporary directory allows all of the temporary files created during installation to be kept together and neatly cleaned up automatically at the end of the install, and does so in an OS independent manner.

Comment by Julien Ponge [ 31/Aug/10 ]

Now I got it. Your comment is actually a nice piece of documentation.

Comment by Julien Ponge [ 31/Aug/10 ]

Thanks for the feature.

You may check the documentation at http://docs.codehaus.org/display/IZPACK/Info

Cheers





[IZPACK-605] JAR File merge should not copy signatures to destination setup.jar Created: 20/Aug/10  Updated: 02/Aug/12  Resolved: 02/Aug/12

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

Type: Improvement Priority: Major
Reporter: Florian Buehlmann 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   

If additional jar files where merged to setup.jar by the jar tag in the install.xml file all META-INF information is also copied to the destination jar.
If the source jar is signed the signature files are also copied to the setup.jar we build.
If then an installation is started we get a SecurityExcpetion because of the wrong signature for this jar file.

java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:221)
at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:176)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:288)
at java.util.jar.JarVerifier.update(JarVerifier.java:199)
at java.util.jar.JarFile.initializeVerifier(JarFile.java:323)
at java.util.jar.JarFile.getInputStream(JarFile.java:388)
at sun.misc.JarIndex.getJarIndex(JarIndex.java:120)
at sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:608)
at java.security.AccessController.doPrivileged(Native Method)
at sun.misc.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:599)
at sun.misc.URLClassPath$JarLoader.<init>(URLClassPath.java:583)
at sun.misc.URLClassPath$3.run(URLClassPath.java:333)
at java.security.AccessController.doPrivileged(Native Method)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:322)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:299)
at sun.misc.URLClassPath.getResource(URLClassPath.java:168)
at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: com.izforge.izpack.installer.Installer. Program will exit.

When merging jar files into installer setup.jar we should not copy signatures and it could be a good idea to merge manifest files from all merged jars instead to overwrite one manifest with an other, depending on the order we merge the jars.



 Comments   
Comment by Florian Buehlmann [ 23/Aug/10 ]

One possible way could be to save a signed jar als resource in the setup.jar. During load of the installer we could then modify the URL ClassLoader and add the signed jars directly to the ClassPath even if the are in packed in the setup.jar

Comment by Florian Buehlmann [ 23/Aug/10 ]

The one-jar project points in that direction. http://one-jar.sourceforge.net/

Comment by Tim Anderson [ 31/Jul/12 ]

Pull request is at https://github.com/izpack/izpack/pull/40





[IZPACK-604] The ability manipulate the Quit button and process Quit events Created: 17/Aug/10  Updated: 21/Jul/12  Resolved: 21/Jul/12

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

Type: Improvement Priority: Critical
Reporter: Alwyn Schoeman Assignee: Tim Anderson
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently Izpack has the following limitations:
a) You cannot hide or disable the Quit button on the InstallerFrame. In our scenario we have optional panels for rollback if anything should fail during installation and we definitively don't want the user to be able to Quit before we can do rollback.
b) The Quit button doesn't allow custom handling of events. If a user chooses yes, I would like to be able to veto his decision and do different processing like displaying a message, or just add some logic to the quit process.

Please give panels access to the quit button and also the ability process the quit events.



 Comments   
Comment by Tim Anderson [ 13/Apr/12 ]

Would an API like the following suffice?
You would have access to the 3 buttons, 'Next', 'Previous' and 'Quit' and be able to register a VetoableEventListener for each to veto the default behaviour of next(), previous() and quit().


public class InstallerFrame  {

     public Navigator getNavigator() { ... }

}

public interface Navigator
{

    /**
     * Returns the button to navigate to the next panel.
     *
     * @return the 'next' button
     */
    JButton getNext();

    /**
     * Registers a listener that may veto navigation to the next panel.
     *
     * @param listener the listener. May be <tt>null</tt>
     */
    void setNextListener(VetoableEventListener listener);

    /**
     * Returns the button to navigate to the previous panel.
     *
     * @return the 'previous' button
     */
    JButton getPrevious();

    /**
     * Registers a listener that may veto navigation to the previous panel.
     *
     * @param listener the listener. May be <tt>null</tt>
     */
    void setPreviousListener(VetoableEventListener listener);

    /**
     * Returns the button to quit installation.
     *
     * @return the 'quit' button
     */
    JButton getQuit();

    /**
     * Registers a listener that may veto quitting installation.
     *
     * @param listener the listener. May be <tt>null</tt>
     */
    void setQuitListener(VetoableEventListener listener);

    /**
     * Navigates to the next panel.
     *
     * @return <tt>true</tt> if the next panel was displayed, or <tt>false</tt> if the last panel is displayed or
     *         navigation is vetoed
     */
    boolean next();

    /**
     * Navigates to the previous panel.
     *
     * @return <tt>true</tt> if the previous panel was displayed, or <tt>false</tt> if the first panel is displayed or
     *         navigation is vetoed
     */
    boolean previous();

    /**
     * Quits installation.
     *
     * @return <tt>true</tt> if installation was quit, or <tt>false</tt> if quit failed was vetoed
     */
    boolean quit();

}

public interface VetoableEventListener extends EventListener
{

    /**
     * Invoked to determine if an event should be vetoed.
     *
     * @param source the source that triggered the event
     * @return <tt>true</tt> if the event should be vetoed, or <tt>false</tt> if it should proceed
     */
    boolean veto(Object source);
}

Comment by Alwyn Schoeman [ 13/Apr/12 ]

It would definitively help in the cases where you want to be able to tell the user he can't quit right now. Obviously this doesn't give the ability to disable or hide the quit button.

Comment by Tim Anderson [ 13/Apr/12 ]

You can via:

navigator.getQuit().setEnabled(false);
navigator.getQuit().setVisible(false);
Comment by Tim Anderson [ 18/Jul/12 ]

Here's the new API. Amongst other things, it allows you enable/disable quit, and make it visible/invisible.

public interface Navigator
{

    /**
     * Determines if the next panel may be navigated to.
     *
     * @return {@code true} if the next panel may be navigated to
     */
    boolean isNextEnabled();

    /**
     * Determines if the next panel may be navigated to.
     *
     * @param enable if {@code true}, enable navigation, otherwise disable it
     */
    void setNextEnabled(boolean enable);

    /**
     * Makes the 'next' button visible or invisible.
     *
     * @param visible if {@code true} makes the button visible, otherwise makes it invisible.
     */
    void setNextVisible(boolean visible);

    /**
     * Sets the text for the 'next' button.
     *
     * @param text the button text. May be {@code null}
     */
    void setNextText(String text);

    /**
     * Sets the icon for the 'next' button.
     *
     * @param icon the icon. May be {@code null}
     */
    void setNextIcon(Icon icon);

    /**
     * Determines if the previous panel may be navigated to.
     *
     * @return {@code true} if the previous panel may be navigated to
     */
    boolean isPreviousEnabled();

    /**
     * Determines if the previous panel may be navigated to.
     *
     * @param enable if {@code true}, enable navigation, otherwise disable it
     */
    void setPreviousEnabled(boolean enable);

    /**
     * Makes the 'previous' button visible/invisible.
     *
     * @param visible if {@code true} makes the button visible, otherwise makes it invisible.
     */
    void setPreviousVisible(boolean visible);

    /**
     * Sets the text for the 'previous' button.
     *
     * @param text the button text. May be {@code null}
     */
    void setPreviousText(String text);

    /**
     * Sets the icon for the 'previous' button.
     *
     * @param icon the icon. May be {@code null}
     */
    void setPreviousIcon(Icon icon);

    /**
     * Determines if the 'quit' button is enabled.
     *
     * @return {@code true} if the 'quit' button is enabled
     */
    boolean isQuitEnabled();

    /**
     * Determines if the 'quit' button is enabled.
     *
     * @param enable if {@code true}, enable quit, otherwise disable it
     */
    void setQuitEnabled(boolean enable);

    /**
     * Makes the 'quit' button visible/invisible.
     *
     * @param visible if {@code true} makes the button visible, otherwise makes it invisible.
     */
    void setQuitVisible(boolean visible);

    /**
     * Sets the text for the 'quit' button.
     *
     * @param text the button text. May be {@code null}
     */
    void setQuitText(String text);

    /**
     * Sets the icon for the 'quit' button.
     *
     * @param icon the icon. May be {@code null}
     */
    void setQuitIcon(Icon icon);

    /**
     * Navigates to the next panel.
     *
     * @return {@code true} if the next panel was displayed, or {@code false} if the last panel is displayed
     */
    boolean next();

    /**
     * Navigates to the previous panel.
     *
     * @return {@code true} if the previous panel was displayed, or {@code false} if the first panel is displayed
     */
    boolean previous();

    /**
     * Quits installation, if quit is enabled, and installation is complete.
     * <p/>
     * This method does not return if the quit is accepted.
     */
    void quit();
}

To use this, either specify it in your panel/installer listener constructor, and it will be injected, or use InstallerFrame.getNavigator().

The changes can be accessed via https://github.com/izpack/izpack/pull/24

I've ditched the VetoableEventListener support for now. If you want it, raise a new JIRA.

Comment by Tim Anderson [ 21/Jul/12 ]

Pull request merged.





[IZPACK-603] UserInputPanel: inputs should not be validated when panel is reloaded due to checkbox/radiobutton having revalidate="yes" in their spec Created: 06/Aug/10  Updated: 29/Apr/11  Resolved: 27/Apr/11

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.1
Fix Version/s: 4.3.4

Type: Bug Priority: Major
Reporter: Kshitiz Saxena Assignee: Julien Ponge
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Generic


Attachments: Text File diff1.txt     Text File diff.txt    
Issue Links:
Duplicate
duplicates IZPACK-427 UserInputPanel: inputs should not be ... Closed
Related
relates to IZPACK-602 CLONE -UserInputPanel: File/directory... Resolved
Patch Submitted:
Yes
Number of attachments : 2

 Description   

Reload of panel calls all validator added to panel. Validator are executed even on reload, which should not be the case. Validator should only be executed when "next" button is clicked.

Following changes in izpack-src-trunk/src/lib/com/izforge/izpack/panels/UserInputPanel.java helps avoid validation in case of panel reload.
Variable "validating" already exists in code, however its usage has been commented out . I used it in few more places

Index: UserInputPanel.java
===================================================================
— UserInputPanel.java (revision 2817)
+++ UserInputPanel.java (working copy)
@@ -1196,7 +1196,7 @@
try
{
FileInputField panel = (FileInputField) field.getComponent();

  • result = panel.validateField();
    + result = !validating || panel.validateField();
    if (result)
    {
    idata.setVariable(field.getAssociatedVariable(), panel.getSelectedFile()
    @@ -1221,7 +1221,7 @@
    try
    {
    FileInputField input = (FileInputField) field.getComponent();
  • result = input.validateField();
    + result = !validating || input.validateField();
    if (result)
    {
    idata.setVariable(field.getAssociatedVariable(), input.getSelectedFile()
    @@ -1246,7 +1246,7 @@
    try
    {
    MultipleFileInputField input = (MultipleFileInputField) field.getComponent();
  • result = input.validateField();
    + result = !validating || input.validateField();
    if (result)
    {
    List<String> files = input.getSelectedFiles();
    @@ -1834,7 +1834,7 @@

// validate the input
Debug.trace("Validating text field");

  • boolean success = textField.validateContents();
    + boolean success = !validating || textField.validateContents();
    if (!success) { Debug.trace("Validation did not pass, message: " + message); @@ -3909,7 +3909,11 @@ // readInput(); // panelActivate(); // validating = true; + Debug.trace("Setting validating to false"); + validating=false; updateDialog(); + Debug.trace("Setting validating back to true"); + validating=true; }


 Comments   
Comment by Julien Ponge [ 30/Aug/10 ]

Formatting broke your patch. Could you please upload it as an attachment?

Comment by Kshitiz Saxena [ 30/Aug/10 ]

Fix for issue 602, 603

Comment by Julien Ponge [ 30/Aug/10 ]

The patch does not apply on the Git master branch.

Comment by Kshitiz Saxena [ 01/Oct/10 ]

Latest code diff with 4.3 source trunk

Comment by Julien Ponge [ 19/Oct/10 ]

Sorry, it does not apply against the current Git master. I should have mentioned this, as we are not going to do any further release on the 4.3 code branch.





[IZPACK-602] CLONE -UserInputPanel: File/directory is filled will value even if provided empty value, even with allowEmptyValue="true" added to file/directory spec Created: 06/Aug/10  Updated: 07/Sep/11  Resolved: 07/Sep/11

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

Type: Bug Priority: Major
Reporter: Kshitiz Saxena Assignee: Julien Ponge
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Generic


Attachments: Text File diff1.txt     Text File diff.txt    
Issue Links:
Related
is related to IZPACK-603 UserInputPanel: inputs should not be ... Closed
Patch Submitted:
Yes
Number of attachments : 2

 Description   

Even if I add allowEmptyValue="true" to file/directory spec, there is a value provided for file/directory. The value provided is directory from where izpack jar is executed.

Below code changes in UserInputPanel.java is needed to fix this issue:
Index: UserInputPanel.java
===================================================================
— UserInputPanel.java (revision 2817)
+++ UserInputPanel.java (working copy)
@@ -1195,14 +1195,17 @@
boolean result = false;
try
{
FileInputField panel = (FileInputField) field.getComponent();
result = panel.validateField();
if (result)
{

  • idata.setVariable(field.getAssociatedVariable(), panel.getSelectedFile()
  • .getAbsolutePath());
  • entries.add(new TextValuePair(field.getAssociatedVariable(), panel
  • .getSelectedFile().getAbsolutePath()));
    + String value = "";
    + File inputFile = input.getSelectedFile();
    + if(inputFile != null && !inputFile.getName().equals("")) { + value = input.getSelectedFile().getAbsolutePath(); + }
    + idata.setVariable(field.getAssociatedVariable(), value);
    + entries.add(new TextValuePair(field.getAssociatedVariable(), value));
    }
    }
    catch (Exception e)
    @@ -1221,13 +1224,16 @@
    try
    {
    FileInputField input = (FileInputField) field.getComponent();
    result = input.validateField();
    if (result)
    {
    - idata.setVariable(field.getAssociatedVariable(), input.getSelectedFile()
    - .getAbsolutePath());
    - entries.add(new TextValuePair(field.getAssociatedVariable(), input
    - .getSelectedFile().getAbsolutePath()));
    + String value = "";
    + File inputFile = input.getSelectedFile();
    + if(inputFile != null && !inputFile.getName().equals("")){+ value = input.getSelectedFile().getAbsolutePath();+ }

    + idata.setVariable(field.getAssociatedVariable(), value);
    + entries.add(new TextValuePair(field.getAssociatedVariable(), value));
    }
    }
    catch (Exception e)



 Comments   
Comment by Julien Ponge [ 30/Aug/10 ]

Formatting broke your patch. Could you please upload it as an attachment?

Comment by Kshitiz Saxena [ 30/Aug/10 ]

Fix for issue 602 and 603

Comment by Kshitiz Saxena [ 01/Oct/10 ]

Latest code diff with respect to 4.3 branch

Comment by Julien Ponge [ 19/Oct/10 ]

Same as for IZPACK-603, this applies on a code base that we are not going to release from.

Would you be able to port it to 5.0?

Cheers





[IZPACK-601] Installation does not continue if the JRE needs to be installed Created: 04/Aug/10  Updated: 04/Aug/10

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

Type: Test Priority: Major
Reporter: Alex Peter-Contesse Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, Windows 7, OSX, others?


Number of attachments : 0

 Description   

When installing our product using IzPack on a system that does not have a JRE, the installer correctly directs the user to the appropriate web site for installing it. When the installation of the JRE is complete, it is expected that IzPack will continue.
What appears to be happening is that the installer exits after bringing up a browser. In main.cpp, it calls launcher.downloadJRE(), which eventually calls process.waitForFinished(-1). I suspect that when the browser is launched, it assumes it is finished.
One solution is to sit in a loop checking if the JRE is there every 5 seconds or so. Kind of ugly but straight forward.






[IZPACK-600] Obsolete / replace / document several features beginning from IzPack 5.0 which might break existing IzPack < 5.0 environments Created: 03/Aug/10  Updated: 21/Sep/12  Resolved: 21/Sep/12

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

Number of attachments : 0

 Description   

There are several features in IzPack which could be replaced by their smarter counterparts.
Example:

  • the os attribute ("unix", "windows", "macosx") has already the cleaner alternative of the nested <os family="..."/> tag
  • the VariableExistence condition has been replaced by the Exists condition, which accepts more object types to test for existance than only variables.

Since those changes might break previous installation descriptions and require to adapt them this should be well-marked in the documentation.



 Comments   
Comment by Rene Krell [ 21/Sep/12 ]

This seems to be done and documented, no bigger leaks so far in the documentation.





[IZPACK-599] Don't allow pack names in custom action listeners which are not defined in the installation Created: 02/Aug/10  Updated: 02/Aug/10

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

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   

Currently, using a custom action listener, there is no check at compilation time whether a pack referenced in the listener's resource is really defined. A t the end, the custom action listener is silently ignored during installation, too.

The compilation should fail, if a referenced pack in a custom action listener doesn't actually exist.






[IZPACK-598] IzPack compilation ERROR - class AssertionHelper: "class java.lang.String among unsatisfiable dependencies" (picocontainer) Created: 30/Jul/10  Updated: 29/Nov/10  Resolved: 02/Aug/10

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: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

openSUSE 11.3 x86_64, Sun JRE 1.6.0_20-b02


Number of attachments : 0

 Description   

Actually testing the first IzPack 5.0 snapshot (izpack-maven-plugin) and running into this stacktrace:

org.apache.maven.plugin.MojoExecutionException: IzPack compilation ERROR
        at org.izpack.mojo.IzPackMojo.buildInstaller(IzPackMojo.java:280)
        at org.izpack.mojo.IzPackMojo.execute(IzPackMojo.java:173)
        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: org.picocontainer.injectors.AbstractInjector$UnsatisfiableDependenciesException: com.izforge.izpack.compiler.helper.AssertionHelper has unsatisfied dependency: class java.lang.String among unsatisfiable dependencies: [[class java.lang.String]] where org.picocontainer.DefaultPicoContainer@ba3bff5:25<(empty) was the leaf container being asked for dependencies.
        at org.picocontainer.injectors.ConstructorInjector.getGreediestSatisfiableConstructor(ConstructorInjector.java:156)
        at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:184)
        at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:289)
        at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:229)
        at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:66)
        at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:92)
        at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:607)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:572)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:562)
        at org.picocontainer.parameters.BasicComponentParameter.resolveInstance(BasicComponentParameter.java:188)
        at org.picocontainer.parameters.ComponentParameter.resolveInstance(ComponentParameter.java:123)
        at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:72)
        at org.picocontainer.injectors.SingleMemberInjector.getMemberArguments(SingleMemberInjector.java:58)
        at org.picocontainer.injectors.ConstructorInjector.getMemberArguments(ConstructorInjector.java:240)
        at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:199)
        at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:289)
        at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:229)
        at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:66)
        at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:92)
        at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:607)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:572)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:562)
        at org.picocontainer.parameters.BasicComponentParameter.resolveInstance(BasicComponentParameter.java:188)
        at org.picocontainer.parameters.ComponentParameter.resolveInstance(ComponentParameter.java:123)
        at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:72)
        at org.picocontainer.injectors.SingleMemberInjector.getMemberArguments(SingleMemberInjector.java:58)
        at org.picocontainer.injectors.ConstructorInjector.getMemberArguments(ConstructorInjector.java:240)
        at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:199)
        at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:289)
        at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:229)
        at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:66)
        at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:92)
        at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:607)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:572)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:562)
        at org.picocontainer.parameters.BasicComponentParameter.resolveInstance(BasicComponentParameter.java:188)
        at org.picocontainer.parameters.ComponentParameter.resolveInstance(ComponentParameter.java:123)
        at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:72)
        at org.picocontainer.injectors.SingleMemberInjector.getMemberArguments(SingleMemberInjector.java:58)
        at org.picocontainer.injectors.ConstructorInjector.getMemberArguments(ConstructorInjector.java:240)
        at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:199)
        at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:289)
        at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:229)
        at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:66)
        at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:92)
        at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:607)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:572)
        at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:580)
        at com.izforge.izpack.core.container.AbstractContainer.getComponent(AbstractContainer.java:40)
        at org.izpack.mojo.IzPackMojo.buildInstaller(IzPackMojo.java:268)
        ... 20 more


 Comments   
Comment by Rene Krell [ 30/Jul/10 ]

Should work in commit 6fd98288e12a96fea16daa0bc5ea9221723d5eb8

Comment by Rene Krell [ 02/Aug/10 ]

The right solution was in using the goal "izpack" by mistake, which used the old IzPack Maven plugin, which does not inject the installerFile String in pico container. Reevaluating...

Comment by Rene Krell [ 02/Aug/10 ]

The right usage is like this:

<properties>
    <izpack.version>5.0.0-SNAPSHOT</izpack.version>
</properties>
<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.izpack</groupId>
            <artifactId>izpack-maven-plugin</artifactId>
            <version>${izpack.version}</version>
            <configuration>
              <baseDir>${staging.dir}</baseDir>
              <installFile>${basedir}/src/main/izpack/install.xml</installFile>
            </configuration>
            <executions>
              <execution>
                <id>standard-installer</id>
                <phase>package</phase>
                <goals>
                  <goal>compile</goal>
                </goals>
              </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Thanks to Anthonin for decalaring this.

Comment by Sebastien Bordes [ 29/Nov/10 ]

The documentation is not updated with this relevant information

http://izpack.codehaus.org/izpack-maven-plugin/usage.html

Thanks for the solution





[IZPACK-597] Default installation directory is not used when TargetPanel.dir resource evaluate to nothing Created: 14/Jul/10  Updated: 21/Jul/10  Resolved: 19/Jul/10

Status: Resolved
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.1, 4.3.2, 4.3.3
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Kareem Shehata Assignee: Julien Ponge
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS X, Debian Linux 4.0


Attachments: Text File IzPack-4.3.3-TargetPanel.dir.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The TargetPanel.dir resource is used to indicate the default install path. If empty, the default install path should be used. If the resource references a variable (environment or otherwise), and that substitution leads to an empty string, then the current implementation leaves the install path as being an empty string. It should go back to the default path generated by IzPack.

The attached patch does the check for empty strings after doing variable replacements, fixing the problem described.



 Comments   
Comment by Julien Ponge [ 19/Jul/10 ]

The patch does not apply against our current master tree.

Comment by Kareem Shehata [ 19/Jul/10 ]

I couldn't get the current master at the time to build. I can make a patch for the code, but can't test it on my system. Would you like that or does the master now build?

Comment by Julien Ponge [ 21/Jul/10 ]

The master builds fine, and you can expect tests to pass, at least in the -Pbamboo Maven profile.





[IZPACK-596] Ubuntu 10+ needs .desktop files to be executable Created: 13/Jul/10  Updated: 29/Apr/11  Resolved: 19/Jul/10

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.3
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Major
Reporter: Matthew John Toseland Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 10.04 at least is affected.


Attachments: File executable-desktop-files.diff    
Patch Submitted:
Yes
Source ID: https://bugs.freenetproject.org/view.php?id=4225
Number of attachments : 1

 Description   

Creating desktop shortcuts on Ubuntu doesn't work. The following error is shown:
Untrusted application launcher: The application launcher "Browse-Freenet-1278868750884.desktop" has not been marked as trusted. If you do not know the source of this file, launching it may be unsafe.

Ubuntu people tell me this is simply caused by the .desktop items not being +x.

I have attached a patch but unfortunately I have not been able to build from source yet, so I cannot guarantee that it works. It is however trivial.



 Comments   
Comment by Julien Ponge [ 19/Jul/10 ]

Thanks!

Comment by Mark Miller [ 16/Dec/10 ]

cherry picked for 4.3.4 https://github.com/lucidimagination/izpack/commit/cd007faf98cc6595aed7ace4ee8470e59d625e4b





[IZPACK-595] Executable stage="never" should be processed first Created: 13/Jul/10  Updated: 13/Jul/10  Resolved: 13/Jul/10

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

Type: Bug Priority: Minor
Reporter: drekbour 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   

On *nix platforms my <executable stage="postinstall"> is perfectly reasonably trying to use some of the files installed as part of that pack (my usecase is installing a service using Tanuki Java Service Wrapper). It fails because the executables and libraries have not yet had the +x executable bit set on them.

Unless there is a reason why, "never" should be processed before "postinstall".



 Comments   
Comment by drekbour [ 13/Jul/10 ]

Ok, going to close this one myself. I did not realise the ordering of XML elements within the pack drives the execution. The frontend I was trying to use (PackJacket) is didn't offer options to re-order items.





[IZPACK-594] Panel action configuration shared between all actions with same class name Created: 29/Jun/10  Updated: 29/Jun/10

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

Type: Bug Priority: Major
Reporter: Alwyn Schoeman 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 want to be able to call the same action class multiple times in the same panel, but with different configurations.

Configurations are currently implemented in such a way that they are stored in a hash map with key the action class name. This results in all my actions with the same class name ending up with the configuration specified in the last action definition for that class name.

Please modify so that each configuration is associated with an action instance instead of its class name.






[IZPACK-593] TreePackPanel - Required pack bug Created: 29/Jun/10  Updated: 29/Jun/10

Status: Open
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.1, 4.3.2, 4.3.3
Fix Version/s: None

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

Lets say there is a parent pack called a which is marked as required and has children packs b and c (these pack's parent is a) which are not marked as required. Also pack a, b, c all contain files to be installed in it. Once we run the installer with this configuration, we notice that since it is required, the space taken by the files in pack a is listed under total space required which is seen below on the panel. But if we select either pack b or c and then unselect the one we selected, the total space required goes to 0 bytes even though pack a is required. Since it is a required pack, we also don't have the ability to select pack a again. I believe that when pack a or b or any children pack is selected and then deselected, pack a or the parent pack shouldn't get unselected when it is marked as a required pack.






[IZPACK-592] Packages installed with loose pack does not get uninstalled Created: 12/Jun/10  Updated: 12/Jun/10

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

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

WinXP


Number of attachments : 0

 Description   

I have a jre that gets installed as a loose pack as I ship it in a 7z file with SFX module to run the izpack installer. This same jre is then installed as a loose pack into the product install directory. When the uninstaller is run, the installed jre does not get removed. If the same jre is installed without the loose set to true, it gets removed fine.






[IZPACK-591] XOR with more than 2 operands behaviour not as expected Created: 04/Jun/10  Updated: 02/Nov/10  Resolved: 02/Nov/10

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

Type: Improvement Priority: Minor
Reporter: Sean O'Loughlin 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   

Looking at the recent patch enabling more than 2 operands for boolean operators I see a potential disconnect between what people are likely to expect and how the XOR function will actually behave. (others may disagree since there really isn't a well defined behavior for XOR with more than 2 operands that I can find).

Basically the problem is that the existing implementation will return true if the number of operands which are true is an uneven number and false if it is an even number. So if I have 5 operands and 3 of them are true then I get true, if 4 are true then it's false. I suspect the intent of a multi-operand xor will be that it returns true if and only if exactly one operand is true. (Or at least I see this as a more useful feature)

The quick fix for this would be to change

if (result.booleanValue() && condition.isTrue())

{ // in case both are true result = new Boolean(false); }

to

if (result.booleanValue() && condition.isTrue())

{ // in case both are true return Boolean.FALSE; }

I think either way there needs to be an update to the documentation to describe exactly what happens here since it's not going to be obvious.



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

Hi Sean,

I'm the author of this patch. There are the following aspects of it:
1. To this time, you can define an unlimited number of nested operands in a logic condition, but there are taken only the first two into account, which has been wrong and led several times to confusion, not only to mine. This is the intent of the multi-operand operation you asked for.
2. The logic behind all is that there is taken the first and second operand, and the result of the operation is taken as operand for the same operation with the third operand and so on, thus for example: ((op1 XOR op2) XOR op3).
3. The result of XOR is by definition false if both operands are equal, thus
true XOR true = false
false XOR false = false
true XOR false = true
false XOR true = false
There should be no change for two operands with this patch, so, it doesn't break any existing installer.
For 3 operands you are right with the result, but this is still what I would expect of it.

Nevertheless, in particular XOR broke some automatic test, so I will have a look at it asap.

You're absolutely right with the documentation. If no one else will do it I add it as soon as I have some time for it.

BTW: This patch came from a requirement in a productive environment. We use still the old 4.4 trunk there, and I ported it to IzPack5. For the OR and AND operations, this worked very well, XOR we don't use at the moment. So there might still be a pitfall with it.

Comment by Sean O'Loughlin [ 04/Jun/10 ]

Hi René,
Like you I've had scenarios where I needed to use AND or OR with more than 2 operands but never XOR. I agree that what you have is a perfectly reasonable interpretation of what a multi-operand XOR should do. The reason I raise this is that I think there are scenarios in which an "Exactly one of" condition would be useful, but I can't think of any cases where "An odd number of" condition (Or any of the other possible interpretations I can think of) would be of much use.

Given that for cases with 2 operands (all existing code) the result would be identical, and given that technically XOR with more than 2 operands doesn't make sense anyway (So the actual behavior will never be obvious without looking at the documentation anyway), I think that "Exactly one of" is the way to go.

AND and OR work well how you have them because saying (a && b) && c is equivalent to saying "a, b and c must all be true" which is generally what you're trying to get across in an installer. Similarly (a || b) || c is the same as "at least one of a, b or c must be true". For XOR it's a different story, with 2 operands the user might mean "a and b must be different" or "exactly one of a or be must be true" or "at least one must be true and at least one must be false". They're all the same with 2 operands and they're all reasonable expressions of what XOR means, but when you have more than 2 operands it starts to make a difference which one you meant.

I guess there needs to be one well documented solution, which is ideally the most useful one, or an XOR with more than 2 operands should just be disallowed and it should throw a compile time exception. (It could be replaced by less ambiguously named operations like "EXACTLY_ONE_OF" and "ODD_NUMBER_OF" if they were considered sufficiently useful).

Comment by Rene Krell [ 07/Jun/10 ]

Hi Sean, I agree with you, that there seems not to be a real use case for having more than two operands in a logical XOR operation between conditions in IzPack. I'd personally prefer not to allow this case. I will look at it soon and change it in that manner. Any other opinions?

Comment by Rene Krell [ 02/Nov/10 ]

There has been a check added during compile time. Compiling should always fail if there was something wrong on parsing this condition.





[IZPACK-590] UserInputPanel: Error message for MultiFileField Created: 04/Jun/10  Updated: 04/Jun/10

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

Type: Improvement Priority: Major
Reporter: Dirk Räder Assignee: Dennis Reil
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   

UserInputPanel's MultiFileField does not show an error message if there's no file selected and allowEmptyValue is false.
This should be changed.






[IZPACK-589] Can someone please uploade a complete installation example (including source code) Created: 31/May/10  Updated: 13/Dec/12  Resolved: 13/Dec/12

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

Type: Improvement Priority: Major
Reporter: tomer kushnir 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   

Hi,

I have started working on IzPack and I am finding it real hard to do everything by trial and error.

I looked at the glassfish and groovy examples but they are very simple and don't show custom panel, user input panel with complex field types etc...
I would very much appreciate if someone would upload a couple of IzPack installations including the source code.

I would like to ask for installations that has a user input panel and custom panel that uses the variables entered in that user input panel.

Thank you for your help and support.

Tomer






[IZPACK-588] UserInputPanel text handling broken Created: 20/May/10  Updated: 20/May/10

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

Type: Bug Priority: Major
Reporter: Jeff Gordon 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 UserInputPanel the calls to LocaleDatabase.getString(key) are expected to throw an exception if the key is not found so the corresponding value in the userInputSpec.xml txt attribute can be used for display.

Instead, the getString() call returns the key value which ends up being displayed if no userInputLang.xml file is configured.

Recommend either making the LocaleDatabase.getString() throw an exception or remove the txt attribute from the userInputSpec.xml definition and exit the installation if it is present (notifying developers/users they have configured the install definition incorrectly).

A workaround is to add:

if (text.equalsIgnoreCase(key))

{ text=null; }

to UserInputPanel.getText(IXMLElement element) to trigger the code that expects the exception to be thrown.

    private String getText(IXMLElement element)
    {
        if (element == null) { return (null); }

        String key = element.getAttribute(KEY);
        String text = null;

        if ((key != null) && (langpack != null))
        {
            try
            {
                text = langpack.getString(key);
                if (text.equalsIgnoreCase(key)) {
                  text=null;
                }
            }
            catch (Throwable exception)
            {
                text = null;
            }
        }

        // if there is no text in the description, then
        // we were unable to retrieve it form the resource.
        // In this case try to get the text directly from
        // the IXMLElement
        if (text == null)
        {
            text = element.getAttribute(TEXT);
        }

        // try to parse the text, and substitute any variable it finds
        VariableSubstitutor vs = new VariableSubstitutor(idata.getVariables());

        return (vs.substitute(text, null));
    }





[IZPACK-587] In the language selection combo box, flag icons for the languages should not be greyed out Created: 15/May/10  Updated: 15/May/10

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

Type: Improvement Priority: Major
Reporter: Peter BetBasoo 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   

When selecting a language from the Language Selection dialog, the flag icon for each language in the drop-down list is disabled. This does not make sense, because the icons are a visual mnemonic, and if they all look grey it is difficult to distinguish between them and they are of no use then. The flags should not be greyed out at anytime.






[IZPACK-586] Spaces in install path break shortcuts in Linux/Unix Created: 15/May/10  Updated: 21/Nov/11

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

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

Linux/Unix


Number of attachments : 0

 Description   

If there are spaces in the install path, the installer does not correctly generate the scripts to launch an app in Linux/Unix. It looks like spaces in the install path are not properly escaped.

I did the following after installing my app on Ubuntu 8.10:

1. Opened the text editor

2. Dragged the app's desktop icon onto the Text Editor.

3. Removed the opening and closing quote (") from the lines that begin with Exec=, Icon= and Path=

4. In the line that begins with Exec= I put a backslash () before every space

5. Saved the script

6. Double clicked on it to test it and it worked.

I did the same thing to the menu item for the app and that worked.

So it possible to fix izpack to correctly escape spaces in the install path? Is this the general solution?



 Comments   
Comment by Andrew Stockton [ 21/Nov/11 ]

Here are fixes for this and the other issues that stop Unix shortcuts from working when there is a space in the install path. (Using code from IzPack 4.3)

Issue 1: In the generated .desktop files, the opening and closing quote should be removed from the line beginning with Path= . (See original bug report.)
This can be done by changing line

hlp.append("Path=" + $P_QUOT + $Path + $P_QUOT + N);
to
hlp.append("Path=" + $Path + N);

in the source file lib/com/izforge/izpack/util/os/Unix_Shortcut.java.

The value for Icon should NOT be enclosed in quotation marks or have escaped spaces. (e.g. Icon=/home/andrew/my favorite program/icon/Icon.png)
The value for Exec SHOULD be enclosed in quotation marks, or have escaped spaces. (e.g. Exec="/home/andrew/my favorite program/bin/program")

Issue 2: While installing shortcuts, the installer tries to execute a script located in $INSTALL_PATH/Shortcuts. However, if the INSTALL_PATH has a space in it, the installer cannot find the script to run, and the shortcuts are not installed to the desktop. The instruction to execute the script needs to have spaces escaped.
This is accomplished by changing lines

myInstallScript.appendln(new String[]

{ myXdgDesktopIconCmd, "install", "--novendor", StringTool.escapeSpaces(writtenDesktopFile.toString())}

);
to
myInstallScript.appendln(new String[]

{ StringTool.escapeSpaces(myXdgDesktopIconCmd), "install", "--novendor", StringTool.escapeSpaces(writtenDesktopFile.toString())}

);

in the source file lib/com/izforge/izpack/util/os/Unix_Shortcut.java.

The same problem exists when uninstalling, i.e. the instruction to run the script needs to have spaces escaped.
This is accomplished by changing the line

myUninstallScript.appendln(new String[]

{ myXdgDesktopIconCmd, "uninstall", "--novendor", StringTool.escapeSpaces(writtenDesktopFile.toString())}

);
to
myUninstallScript.appendln(new String[]

{ StringTool.escapeSpaces(myXdgDesktopIconCmd), "uninstall", "--novendor", StringTool.escapeSpaces(writtenDesktopFile.toString())}

);

in the same file.

Issue 3: The xdgdesktopiconscript.sh script that the installer calls during shortcut installation fails to copy the .desktop file to the desktop if there are spaces in the install path. This problem can be fixed by putting quotation marks around three variables in the script.
The line

eval 'cp $desktop_file $x/$basefile'$xdg_redirect_output
should be changed to
eval 'cp "$desktop_file" "$x/$basefile"'$xdg_redirect_output

in the file lib/com/izforge/izpack/util/os/unix/xdgdesktopiconscript.sh.

After implementing these fixes, installation and uninstallation of shortcuts on Unix using IzPack worked perfectly for me, even when there were spaces in the install path.

Comment by Andrew Stockton [ 21/Nov/11 ]

After more testing, I've discovered that there is still one problem that occurs if shortcuts are being installed for all users: When desktop shortcuts are installed for all users, the actual entries on the desktop have the permissions rwx-----. So although all users can see the file on their desktops, they can't actually read the file, or run it as a shortcut.





[IZPACK-585] Command line uninstall switches to GUI if privileged escalation required Created: 14/May/10  Updated: 14/May/10

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

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

Windows 7


Number of attachments : 0

 Description   

Command line argument not passed to runner.relaunchWithElevatedRights() in checkForPrivilegedExecution() method of Uninstaller.java.

Suggest calling checkForPrivilegedExecution(cmduninstall) passing boolean, then in checkForPrivilegedExecution(boolean cmduninstall):

if (cmduninstall) {
    args = new String[]{"-c"};
}

and if required call runner.relaunchWithElevatedRights(args)

PrivilegedRunner would then need something like:

    public int relaunchWithElevatedRights() throws IOException, InterruptedException
    {
      return relaunchWithElevatedRights(null);
    }

    public int relaunchWithElevatedRights(String[] args) throws IOException, InterruptedException
    {
        String javaCommand = getJavaCommand();
        String installer = getInstallerJar();
        ProcessBuilder builder = new ProcessBuilder(getElevator(javaCommand, installer, args));
        builder.environment().put("izpack.mode", "privileged");
        return builder.start().waitFor();
    }

    private List<String> getElevator(String javaCommand, String installer, String[] args) throws IOException, InterruptedException
    {
        List<String> elevator = new ArrayList<String>();

        if (OsVersion.IS_OSX)
        {
            elevator.add(extractMacElevator().getCanonicalPath());
            elevator.add(javaCommand);
            elevator.add("-jar");
            elevator.add(installer);
            if (args != null) {
              elevator.addAll(Arrays.asList(args));
            }
        }
        else if (OsVersion.IS_UNIX)
        {
            elevator.add("xterm");
            elevator.add("-title");
            elevator.add("Installer");
            elevator.add("-e");
            elevator.add("sudo");
            elevator.add(javaCommand);
            elevator.add("-jar");
            elevator.add(installer);
            if (args != null) {
              elevator.addAll(Arrays.asList(args));
            }
        }
        else if (OsVersion.IS_WINDOWS)
        {
            elevator.add("wscript");
            elevator.add(extractVistaElevator().getCanonicalPath());
            elevator.add(javaCommand);
            elevator.add("-Dizpack.mode=privileged");
            elevator.add("-jar");
            elevator.add(installer);
            if (args != null) {
              elevator.addAll(Arrays.asList(args));
            }
        }
        return elevator;
    }






[IZPACK-584] IzPack compiler fails without giving proper information Created: 14/May/10  Updated: 21/Sep/10

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

Type: Improvement Priority: Major
Reporter: Gregor B. Rosenauer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64, JDK 1.6.0_20


Number of attachments : 0

 Description   

When the izpack compiler encounters an error with ZIP archives, it does not show which package caused the error, but only gives a generic error message:

IzPack compilation ERROR: error in opening zip file -> [Help 1]

This message should be improved to allow poor installer developers to pinpoint the problem to the exact position in the installer.xml



 Comments   
Comment by Gregor B. Rosenauer [ 21/Sep/10 ]

btw I always get this error when building an installer with the <pack200/> option...

Comment by Gregor B. Rosenauer [ 21/Sep/10 ]

Without the option, it works.
See also: http://stackoverflow.com/questions/325202/java-util-zip-zipexception-error-in-opening-zip-file
Maybe an issue with my temp space - the installer is 86MB at the end? However, pack200 is supposed to generate smaller files, and with normal zipping, it works...





[IZPACK-583] Remove Documentation License Created: 13/May/10  Updated: 26/Nov/11  Resolved: 07/Sep/11

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

Type: Task Priority: Minor
Reporter: Jeff Gordon Assignee: Julien Ponge
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   

I suggest we remove the documentation license as it conflicts with the product as a whole license, is not "business-friendly", and is not stated on the web site of in any other place the IzPack license is discussed. It is subtly included only buried within the documentation as a link.

  • Jeff

Creative Commons Attribution-ShareAlike 3.0 Unported License



 Comments   
Comment by Julien Ponge [ 07/Sep/11 ]

It's not business unfriendly





[IZPACK-582] MultiVolumePackager: can't handle different source files for same target file Created: 12/May/10  Updated: 31/May/10  Resolved: 31/May/10

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

Type: Bug Priority: Critical
Reporter: Dirk Räder Assignee: Unassigned
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Installer running on Windows 7, 2008, 2008 R2, 2003, 2003 R2.


Number of attachments : 0

 Description   

I need my installer to install two different source files (compiled for 32 XOR 64 bit Windows OS) into the same target file. The selection of the source files happens automatically via conditions so that they are mutual exclusive.

With the default packager, this is no problem. With the MultiVolumePackager and neither of the packages selected, this is also no problem.

If one of the packages is selected, the MultiVolumePackager aborts with "Unexpected end of stream - installer corrupt?".



 Comments   
Comment by Dirk Räder [ 14/May/10 ]

The bug is worse than I thought: The MultiVolumePackager crashes, if there are two packages trying to write to the same directory. They don't even have to try to write to the same file.

Comment by Dirk Räder [ 31/May/10 ]

The bug was a PEBKAC: I wanted to install hidden packages and listed them rather early in the package list. As IzPack handles hidden packages after non-hidden packages, this caused the MultiVolumePackager to crash.





[IZPACK-581] Continuation of IZPACK-577 - extending RulesEngine Created: 10/May/10  Updated: 30/Jul/13

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

Type: Improvement Priority: Major
Reporter: Dirk Räder Assignee: Unassigned
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-577 Improving RulesEngine's handling of c... Resolved
Number of attachments : 0

 Comments   
Comment by Dirk Räder [ 10/May/10 ]

The complex expressions now supported by RulesEngine should support XOR (\\), too. It has the same precedence level as OR (||).

Comment by Dirk Räder [ 10/May/10 ]

Sorry, bitwise XOR in Java has even higher precedence than &&. I will change the parser accordingly. The correct symbol in Java code is ^, which will be used for bitwise XOR instead of
.

Comment by Dirk Räder [ 10/May/10 ]

Patch available at http://github.com/db6edr/izpack/commit/46705192f80decf68dcdfeb927db3042461fc272

Comment by Rene Krell [ 01/Feb/13 ]

Is this still valid? Unfortunately the patch isn't available any longer.





[IZPACK-580] Incorrect logic in Installer to handle fully-qualified panel class names Created: 06/May/10  Updated: 07/May/10  Resolved: 07/May/10

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

Type: Bug Priority: Major
Reporter: Patrick Aikens Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File contains.patch    
Number of attachments : 1

 Description   

In AutomatedInstaller.java, this code is supposed to add a package name to the panel class name if it's missing:


        String praefix = "com.izforge.izpack.panels.";
        if (p.className.compareTo(".") > -1)
        // Full qualified class name
        {
            praefix = "";
        }

        String automationHelperClassName = praefix + p.className + "AutomationHelper";

The code seems to be trying to determine if the class name contains a ".", and if so, assume that it's a fully qualified class name. The correct method for that would be "contains", rather than "compareTo" - the code as written will always return true and wipe out the praefix variable every time regardless of p.className's contents. The upshot of this is that if a panel classname somehow ends up NOT being fully qualified (which happened to me recently when using a custom panel), then the automation helper can't be found since it won't have a package prepended to it.

This DOESN'T happen if the custom panel is in it's own jar in bin/panels, since the code which inspects the contents of the jar will cause Class.className to be fully qualified. If the panel is simply placed in the proper location directly in the installer jar, then Class.className won't be fully qualified due to the way the class was instantiated, and the bug will appear.

This same error also shows up in ConsoleInstaller.iterateAndPerformAction().



 Comments   
Comment by Patrick Aikens [ 06/May/10 ]

Patch for this fix

Comment by Julien Ponge [ 07/May/10 ]

Great, thanks!





[IZPACK-579] com.izforge.izpack.util.OsVersion does not detect (K|X)Ubuntu linux Created: 05/May/10  Updated: 05/May/10  Resolved: 05/May/10

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

Type: Improvement Priority: Minor
Reporter: Dirk Räder 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   

The class provides several methodes to detect many operating systems.
A detection for Ubuntu linux and derivatis is not (yet) present.



 Comments   
Comment by Dirk Räder [ 05/May/10 ]

Patch available at http://github.com/db6edr/izpack/commit/d0ee804cfc269644d8fbd26724f6530f2c13fee1

Comment by Julien Ponge [ 05/May/10 ]

You should work on the master branch for us to pull your changes. You may still have your own 4.3 branch of course.

Comment by Julien Ponge [ 05/May/10 ]

Got it applied through cherry-picking thanks to the power of Git





[IZPACK-578] com.izforge.izpack.util.OsVersion does not detect x64/AMD64 architecture Created: 05/May/10  Updated: 05/May/10

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

Type: Improvement Priority: Minor
Reporter: Dirk Räder 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 class provides several methodes to detect many architecture types.
A detection for x64/AMD64 architecture is not (yet) present.






[IZPACK-577] Improving RulesEngine's handling of complex condition IDs Created: 05/May/10  Updated: 30/Jul/13  Resolved: 07/May/10

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

Type: Improvement Priority: Minor
Reporter: Dirk Räder Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
relates to IZPACK-581 Continuation of IZPACK-577 - extendin... Open
Number of attachments : 0

 Description   

As described in IZPACK-575, RulesEngine does not follow the usual boolean logic for complex expressions.

I want to be able to use the three common boolean operators ! (NOT), && (AND) and || (OR) when attaching a condition to a pack, parsable, executable, whatever.

The operators have to follow the usual precedence rules:
!A && B && !C <=> (!A) && B && (!C)
A && B || C <=> (A && B) || C



 Comments   
Comment by Dirk Räder [ 05/May/10 ]

To ensure that the complex condition expressions do not interfere with the existing simple expression language, the complex expression have to start with an @ or another delimiter.

Comment by Dirk Räder [ 06/May/10 ]

Patch available at https://github.com/db6edr/izpack/commit/2bbaf9f2fae4eab1a8481247063b8187f08f5b66

Comment by Julien Ponge [ 06/May/10 ]

See my comments on GitHub: http://github.com/db6edr/izpack/commit/2bbaf9f2fae4eab1a8481247063b8187f08f5b66#commitcomment-75455

Comment by Julien Ponge [ 07/May/10 ]

Thanks for the patches and doc!





[IZPACK-576] Updated documentation on conditions Created: 04/May/10  Updated: 04/May/10  Resolved: 04/May/10

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

Type: Improvement Priority: Minor
Reporter: Dirk Räder Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 0001-Updating-documentation-installation-files.txt-on-con.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Updating documentation on conditions. See attached patch against.



 Comments   
Comment by Julien Ponge [ 04/May/10 ]

How about fixing it directly on the wiki? The documentation is planned to move there

Comment by Dirk Räder [ 04/May/10 ]

Already did: https://docs.codehaus.org/display/IZPACK/The+Conditions+Element

Comment by Dennis Reil [ 04/May/10 ]

has been added to confluence





[IZPACK-575] RulesEngine: Combined conditions do not follow default Java precedence for logical operators Created: 03/May/10  Updated: 04/May/10  Resolved: 04/May/10

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

Type: Bug Priority: Major
Reporter: Dirk Räder Assignee: Dennis Reil
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   

The RulesEngine extension which allows composition of conditions like "ConditionA+ConditionB" does not follow the common precedence for logical operators:

Expectation:
The boolean expression !a+b+!c should be interpreted as ((!a)b(!c)).

Current behavior:
The expression is interpreted as (!(a+b+)) according to the code.

Please assign the bug to Dennis Reil.



 Comments   
Comment by Dirk Räder [ 03/May/10 ]

Great. I used some icon-tags. Here's the fix:

Expectation:
The boolean expression !a+b+!c should be interpreted as ((!a) + b + (!c)).

Current behavior:
The expression is interpreted as (!(a + b + ( !c ))) according to the code.

Comment by Dennis Reil [ 04/May/10 ]

This is the intended behavior. It's not intended to write such a complex query in the short expression. To do this, you'll have to use the xml to write down this.





[IZPACK-574] NullPointerException on InstallPanel - Unsupported character in generated XML file Created: 02/May/10  Updated: 02/May/10

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

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

Windows XP, 2003 server, seven - the bug is not due to the environment


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

 Description   

A NullPointerException occurs on the InstallPanel when user inputs the '&' character in a field.

This error occurs when there is AntActionsSpec defined.

This error is due to class SpecHelper.java. In fact, AntActionsSpec.xml is rewritten in temporary file named "izpacksubs" to substitue variables with their values. The problem is that file type is not specified in substitutor.substitute(input, fos, null, "UTF-8"); call in the method substituteVariables.

As the type of file is not specified, the method escapeSpecialChars does not escape any characters and the temporary XML file is created with '&' character and not & ,so there is an error when installer tries to read this file.

I meet this error with '&' but i suppose the error must occur with all characters forbidden in XML file : <,>,',",&.

By replacing null by "xml" in substitutor.substitute(input, fos, null, "UTF-8"); => substitutor.substitute(input, fos, "xml", "UTF-8"); seems to fix the error.

That is my first issue, if more information are required or if that is not the right way to describe error, let me know what i have to do and i will.

I send stacktrace error in attachment.

Thanks in advance for your response.






[IZPACK-573] UserInputPanel variables only substituted on first install, not on subsequent installs Created: 02/May/10  Updated: 02/May/10

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

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

Windows XP


Number of attachments : 0

 Description   

UserInputPanel variable substitution works OK on first install.
However, variables are NOT substituted on subsequent installs when trying to overwrite existing installed files.

Workaround: Uninstall, or manually delete installed files, then UserInputPanel variable substitution will work OK on next install.






[IZPACK-572] WebInstaller does not encode the URL Created: 19/Apr/10  Updated: 24/Apr/10  Resolved: 24/Apr/10

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

Type: Bug Priority: Major
Reporter: Dirk Schnelle-Walka Assignee: Julien Ponge
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 the pack name contains spaces, the downloaded pack contains the following:
<html>
<head><title>400 Bad Request</title></head> <body bgcolor="white"> <center><h1>400 Bad Request</h1></center> <hr><center>nginx/0.7.63</center> </body> </html>

The installer reports an error:

C:\Entwicklung\jvoicexml\org.jvoicexml>java -jar jvxml-install-0.7.3.EA.jar
com.izforge.izpack.installer.InstallerException: jar:file:///c:\Entwicklung\Programs\JVoiceXM\Uninstaller\IzpackWebTemp\izpacktempfile6051811661354631227jar!/packs/pack-JVoiceXML Core not available
at com.izforge.izpack.installer.Unpacker.getPackAsStream(Unknown Source)

at com.izforge.izpack.installer.Unpacker.run(Unknown Source)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.FileNotFoundException: jar:file:///c:\Entwicklung\Programs\JVoiceXM2\Uninstaller\IzpackWebTemp\izpacktempfile6051811661354631227jar!/packs/pa
ck-JVoiceXML Core
... 3 more

The web installer was build with:
<info>
<appname>JVoiceXML</appname>
<appversion>@

{jvxml.version}</appversion>
<authors>
<author name="Dirk Schnelle-Walka" email="..." />
<author name="Spencer Lord" email="..."/>
<author name="and many more..." email="none"/>
</authors>
<url>http://www.jvoicexml.org/</url>
<javaversion>1.6</javaversion>
<webdir>http://jvoicexml.sourceforge.net/install-@{jvxml.version}

</webdir>
</info>

The ANT snippet to create the installer is the following:
<taskdef classname="com.izforge.izpack.ant.IzPackTask" name="izpack">
<classpath refid="izpack.path" />
</taskdef>

<izpack input="$

{etc}

/install.xml" output="$

{dist.install.jar}

"
installerType="web" basedir="$

{distFolder}

" inheritall="true" />

Jvxml.version is injected via an ANT property and set to 0.7.3.EA. I also had a look into the generated jvxml-install-0.7.3.EA.jar. The Info file contains the link http://jvoicexml.sourceforge.net/install-0.7.3.EA in the end. You may also click on the URL to have the directory listed.

So I created a small test client to check if the error is due to the encoding:

Using
public class Test {
public static void main(String[] args) throws Exception {
URL url = new
URL("http://jvoicexml.sourceforge.net/install-0.7.3.EA/pack-JVoiceXML
Core.jar");
InputStream in = url.openStream();
byte[] buffer = new byte[1024];
int read;
do {
read = in.read(buffer);
if (read > 0)

{ String str = new String(buffer, 0, read); System.out.print(str); }

} while (read > 0);
System.out.println();
}
}
I get exactly that error, but if I change the URL to http://jvoicexml.sourceforge.net/install-0.7.3.EA/pack-JVoiceXML%20Core.jar
everything works fine. It seems that it is exactly as I expected in one of my previous mails: The space is not encoded correctly.



 Comments   
Comment by Dirk Schnelle-Walka [ 20/Apr/10 ]

The following patch of izpack/izpack-installer/src/main/java/com/izforge/izpack/installer/web/WebAccessor.java should do the trick:
public URL encode(URL url) {
String str = url.toExternalForm();
StringBuilder result = new StringBuilder();
for (int i=0; i<str.length(); i++) {
char ch = str.charAt;
if (ch == ' ')

{ result.append("%20"); // TODO handle other chars }

else

{ result.append(ch); }

}
try

{ return new URL(result.toString()); }

catch (MalformedURLException e)

{ return url; }

}

/**

  • Opens a URL connection and returns it's InputStream for the specified URL.
    *
  • @param url the url to open the stream to.
  • @return an input stream ready to read, or null on failure
    */
    public InputStream openInputStream(URL url)
    {
    url = encode(url);
    setUrl(url.toExternalForm());
    ...

Dirk





[IZPACK-571] InstallationTest fails when building (mvn install) Created: 19/Apr/10  Updated: 27/Jun/12  Resolved: 27/Jun/12

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

Type: Bug Priority: Major
Reporter: Stephan Pabinger Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Debian, maven2, java version "1.6.0_18"


Attachments: Text File com.izforge.izpack.integration.InstallationTest.txt    
Number of attachments : 1

 Description   

Installation Test (com.izforge.izpack.integration.InstallationTest) fails when compiling izpack.
Maven task: mvn install

Stacktrace:
at org.fest.swing.core.BasicComponentFinder.componentNotFound(BasicComponentFinder.java:269)
at org.fest.swing.core.BasicComponentFinder.find(BasicComponentFinder.java:258)
at org.fest.swing.core.BasicComponentFinder.find(BasicComponentFinder.java:253)
at org.fest.swing.core.BasicComponentFinder.findByName(BasicComponentFinder.java:191)
at org.fest.swing.fixture.ContainerFixture.findByName(ContainerFixture.java:527)
at org.fest.swing.fixture.ContainerFixture.textBox(ContainerFixture.java:457)
at com.izforge.izpack.integration.InstallationTest.testBasicInstall(InstallationTest.java:132)
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:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at com.izforge.izpack.test.junit.UnloadJarRule$1.evaluate(UnloadJarRule.java:24)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
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.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)



 Comments   
Comment by Tim Anderson [ 27/Jun/12 ]

Fixed some time ago





[IZPACK-570] moved debug message from system.err to debug.trace Created: 16/Apr/10  Updated: 04/Aug/10  Resolved: 04/Aug/10

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

Type: Improvement Priority: Major
Reporter: Katarzyna Czeczot Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 0001-weird-message-moved-to-debug-trace-from-system.err.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

moved debug message from system.err to debug.trace



 Comments   
Comment by Julien Ponge [ 26/Apr/10 ]

I will look into this, but lots of System.err.(...) statements had been moved to the logger recently.





[IZPACK-569] File Creation on Desktop rather than in Installation Folder Created: 13/Apr/10  Updated: 01/May/13

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

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

Any Operating System. Java 1.6.0_18.


Number of attachments : 0

 Description   

The installer created by IzPack works perfectly fine. It created the shortcuts on Desktop, Start and Start-> Programs. These shortcuts when clicked also work fine. It calls the executable Jar file located in the Installed Folder.

First Issue, when I click the shortcut created on the Desktop, my application creates files.
Now these files are meant to be created in the Installation folder. But with IzPack these files are being created on the Desktop.

Second Issue, when I click the shortcut created on Start-> Programs, the files created by my application are created in the C:\Documents and Settings\admin\ folder and not in the Installation folder.



 Comments   
Comment by Dirk Räder [ 12/May/10 ]

This reads as if there's no working directory set in the shortcuts. Please attach your shortcut specification files to this bug.





[IZPACK-568] Create izpack2sh wrapper (self extracting Linux executable) Created: 09/Apr/10  Updated: 07/Sep/11

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

Type: Wish Priority: Major
Reporter: Ben Golding Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days
Environment:

Any Linux


Attachments: Zip Archive izpack2sh.zip    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Enhancement: Add a small utility script 'izpack2sh' which creates a self-extracting linux script or binary. Similar to izpack2exe for Windows or izpack2app for Mac.

Requirements:

  • It should allow an optionally bundled JRE as izpack2exe now does, see enhancement IZPACK-561.
  • It should have the best possible compression ratio, as good as izpack2exe which uses 7zip.
  • It should add minimal overhead to the .jar installer.
  • It should require minimal extra /tmp space to unpack itself.
  • The RAM required for decompression should be reasonable.
  • The utility script should run on as many platforms as possible, not only Linux.

======= PATCH DESCRIPTION =======
Attached is my implementation, which aims to fulfil the above requirements. The utility script is written in Java, but uses native 'tar' and 'xz' to compress the package.

The self-extracting package consists of three parts concatenated together:
(1) sh script (dynamically generated from Java) which extracts parts (2) and (3), launches IzPack installer. About 200 bytes.
(2) xzminidec Linux binary supporting LZMA2 and X86 BCJ decompression. About 9K bytes.
(3) .tar.xz compressed archive, containing IzPack .jar file, optional bundled JRE, etc.

We assume that the Linux end user has certain basic tools available (sh, head/tail, chmod, mkdir, rm, tar).

======= PATCH FILES =======
Binaries for Windows, downloaded prebuilt:
tar.exe http://sourceforge.net/projects/unxutils
xz.exe,libiconv-2.dll http://sourceforge.net/projects/mingw

Binaries for Linux, downloaded and built on Red Hat Enterprise Linux 3.0 Update 7:
xz http://tukaani.org/xz
xzdec http://tukaani.org/xz/embedded.html

Utility written by me:
IzPack2Sh.java



 Comments   
Comment by Ben Golding [ 16/Apr/10 ]

I recommend to remove the compression switch "--x86" from IzPack2Sh.java since this frequently results in slightly worse compression ratio, even when the package contains a substantial amount of x86 code.

Comment by Julien Ponge [ 22/Apr/10 ]

Sounds great. Do you have a Git repository somewhere I could pull from? There is a Maven submodule for izpack2* projects.

Comment by Ben Golding [ 27/Apr/10 ]

I didn't make these changes in git and besides, I'm behind a firewall so you wouldn't be able to pull.

I'm not familiar with Maven etc so you will need to help me turn this patch into something which is ready to commit.

These guys need to be part of the IzPack installer:
tar.exe
xz.exe
libiconv-2.dll
xz
xzdec

This also needs to be in git:
IzPack2Sh.java

It should probably be compiled into IzPack2Sh.jar by Maven (similar to the build process izpack2exe.py --> izpack2exe.exe). Then there is no need to force the end user to have a JDK installed too. That's the part I need some help with.

Comment by Dan Tran [ 03/Sep/11 ]

another option is http://megastep.org/makeself/





[IZPACK-567] FinishPanel (SimpleFinishPanel) repaint Created: 07/Apr/10  Updated: 01/Oct/12  Resolved: 08/Apr/10

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.3
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Minor
Reporter: Roman Musil Assignee: Julien Ponge
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, Linux Ubuntu 9.10


Attachments: Text File FinishPanel.java.patch     Text File SimpleFinishPanel.java.patch    
Number of attachments : 2

 Description   

Very often is not SimpleFinishPanel painted successfully. Text is not painted at the first moment, but later: in the moment of resizing the panel (by the mouse).
It never happened with 4.3.1.
(With installation/guiprefs/laf "substance" on Windows it works OK, but not on Linux. Strange.)



 Comments   
Comment by Julien Ponge [ 08/Apr/10 ]

This looks like a Look and Feel issue.

Comment by David Duponchel [ 09/Apr/10 ]

It seems that Anthonin has solved this issue, see http://old.nabble.com/Empty-FinishPanel-td27769884.html#a27901352
Those changes are already on the master repository, so this issue should be fixed in IzPack 5.

Comment by Mark Miller [ 15/Dec/10 ]

I have backported a fix for this off 4.3.3 here:
https://github.com/lucidimagination/izpack/commit/418de508a67a14dfc7413ddb319c7418c0c18664

The spacing is a little wonky - I tried to fix it a bit, but could still be better. Not sure if this is a problem in 5 (as I cannot get 5 working), but the layout spacing was bad with a straight port of the code.

Comment by Stuart Wallis [ 22/Feb/11 ]

Patch for SimpleFinishPanel.java (from 4.3.3)

Comment by Stuart Wallis [ 22/Feb/11 ]

Patch for FinishPanel.java based on Mark Miller's changes with better layout (IMO) from 4.3.3 source

Comment by Earl Hood [ 29/Jul/11 ]

Blank SimpleFinishPanel happens under IzPack 4.3.4 under Windows 7.
When I resize the panel with the mouse, the text finally appears.

Running java 1.6.0_26 on 32bit Windows 7.

Comment by bflorat [ 07/Sep/12 ]

This is not fixed in 4.3.5 at least under Seven 64 bits[1], JRE Oracle 7.

SimpleFinishPanel text only appears when resizing the dialog. Several users reported it on my own application, they think that the application is not installed (it is a strong issue for us).

[1] I already experienced this randomly under XP and maybe Seven 32 bits but it is always reproducible under Seven 64 bits for some reasons.

I found a workaround : using FinishPanel instead of SimpleFinishPanel works for me all the time (10 launches so far).

Comment by Martin Ždila [ 01/Oct/12 ]

workaround is to add following line at the end of panelActivate method:

parent.setSize(parent.getWidth() + 1, parent.getHeight());





[IZPACK-566] allow multiple validators for text field in user input panel Created: 07/Apr/10  Updated: 08/Apr/10

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

Type: Improvement Priority: Major
Reporter: Katarzyna Czeczot Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 0001-allow-for-multiple-validators-in-text-field.patch     Text File 0001-allow-multiple-validators-for-text-field.patch    
Number of attachments : 2

 Description   

allow multiple validators for text field in user input panel



 Comments   
Comment by Julien Ponge [ 08/Apr/10 ]

The patch does not apply against our current Git master.

Comment by Katarzyna Czeczot [ 08/Apr/10 ]

against master but not tested

Comment by Julien Ponge [ 08/Apr/10 ]

It still doesn't apply:

infinity:izpack jponge$ git reset --hard
HEAD is now at 566daf4 Refactoring: encapsulate fields.
infinity:izpack jponge$ git apply 0001-allow-for-multiple-validators-in-text-field.patch
0001-allow-for-multiple-validators-in-text-field.patch:69: trailing whitespace.
        }
0001-allow-for-multiple-validators-in-text-field.patch:110: space before tab in indent.
          message = textField.getValidatorMessage();
0001-allow-for-multiple-validators-in-text-field.patch:151: trailing whitespace.

0001-allow-for-multiple-validators-in-text-field.patch:185: trailing whitespace.

0001-allow-for-multiple-validators-in-text-field.patch:214: trailing whitespace.
    {
warning: squelched 4 whitespace errors
warning: 9 lines add whitespace errors.
Comment by Julien Ponge [ 08/Apr/10 ]

Ooops, it's only warnings

Let me check and reformat.

Comment by Julien Ponge [ 08/Apr/10 ]

It doesn't work either. Thanks for getting back to us when you can test it.





[IZPACK-565] pre activate actions should be execetued when no automation helper is provided for the panel Created: 07/Apr/10  Updated: 08/Apr/10  Resolved: 08/Apr/10

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

Type: Bug Priority: Major
Reporter: Katarzyna Czeczot Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 0001-execute-pre-activate-actions.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

pre activate actions should be execetued when no automation helper is provided for the panel



 Comments   
Comment by Julien Ponge [ 08/Apr/10 ]

Thanks!





[IZPACK-564] Support running izpack2exe from Linux host Created: 05/Apr/10  Updated: 11/Aug/10  Resolved: 07/Apr/10

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

Type: Improvement Priority: Major
Reporter: Ben Golding Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Red Hat Enterprise Linux 3.0 Update 7


Number of attachments : 0

 Description   

Problem: izpack2exe does not run on a Linux host.

This would be a useful enhancement when wrapping the same cross-platform installer (.jar) for both Linux and Windows.

7ZA command line for Linux: http://sourceforge.net/projects/p7zip/files/p7zip/4.65/p7zip_4.65_x86_linux_bin.tar.bz2/download
UPX command line for Linux: http://upx.sourceforge.net/#download
Python script izpack2exe.py can be made portable very easily.



 Comments   
Comment by Ben Golding [ 05/Apr/10 ]

Also consider use of bbfreeze to convert izpack2exe.py to izpack2exe (linux binary).
http://pypi.python.org/pypi/bbfreeze

This would be similar to the build process which creates izpack2exe.exe, bundled with the installer for IzPack itself.

Comment by Julien Ponge [ 07/Apr/10 ]

Would you be able to provide a patch for that?

Comment by alberto aresca [ 11/Aug/10 ]

I've tried the last git version of the izpack-utils maven module on my ubuntu powered laptop (where I installed all the needed dependencies before using it) but I keep getting the error:
[exec]
[exec] Error:
[exec] Incorrect command line
[exec] Traceback (most recent call last):
[exec] File "/workspace/smartrm-workspace/smartrm-trunk/smartrm-izpack/src/main/resources/utils/wrappers/izpack2exe/izpack2exe.py", line 116, in <module>
[exec] main()
[exec] File "/workspace/smartrm-workspace/smartrm-trunk/smartrm-izpack/src/main/resources/utils/wrappers/izpack2exe/izpack2exe.py", line 113, in main
[exec] create_exe(parse_options())
[exec] File "/workspace/smartrm-workspace/smartrm-trunk/smartrm-izpack/src/main/resources/utils/wrappers/izpack2exe/izpack2exe.py", line 96, in create_exe
[exec] in_file = open(f, 'rb')
[exec] IOError: [Errno 2] No such file or directory: 'installer.7z'
[exec] Result: 1
Any suggestion or work around?





[IZPACK-563] can't download the glassfish scripts from the link http://svn.izpack.codehaus.org/browse/izpack/izpack-showcases/ Created: 01/Apr/10  Updated: 01/Apr/10  Resolved: 01/Apr/10

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

Type: Bug Priority: Major
Reporter: tomer kushnir Assignee: David Duponchel
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

izpack web site, download the GlassFish installers scripts


Number of attachments : 0

 Description   

when trying to download the GlassFish installers scripts

the error received:
The requested resource cannot be found.Path "izpack-showcases" does not exist.



 Comments   
Comment by tomer kushnir [ 01/Apr/10 ]

can someone provide working linkgs to download the sources from?

Comment by David Duponchel [ 01/Apr/10 ]

IzPack recently switched from svn to git, breaking some links. The old izpack svn repo is now called izpack-svn and the new git repo doesn't have ( ? ) yet those files.
You can find "izpack-showcases" at http://svn.codehaus.org/izpack-svn/izpack-showcases/ (strange, the corrected fisheye link doesn't work correctly).

Comment by Julien Ponge [ 01/Apr/10 ]

+ the FishEye instance at Codehaus is broken these days (the Git repo should work too).





[IZPACK-562] Use solid archive with 7-Zip for better compression ratio (izpack2exe) Created: 31/Mar/10  Updated: 13/Dec/12  Resolved: 07/Apr/10

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

Type: Improvement Priority: Minor
Reporter: Ben Golding Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP2


Number of attachments : 0

 Description   

Issue: Switches used with 7-Zip (7za.exe) when invoked by izpack2exe.

Currently this uses -ms=off to disable 'solid' archives.
However I found an improvement of compression ratio by 10% (maybe more) is possible with -ms=on.

The 4.xx versions of 7-Zip have an issue with adding files to solid archives. So maybe that is the reason that 'solid' was disabled.
This is fixed in 7-Zip 9.xx (beta), but this version does not have a stable branch yet.

Fix: IMO it is better to have the maximum compression ratio possible. If someone needs to add a file to the .7z archive, they can extract it and recreate the archive. So I would suggest to change izpack2exe to have -ms=on, and to update 7za to 9.xx version when it is stable.






[IZPACK-561] Use bundled JRE in EXE package Created: 30/Mar/10  Updated: 30/Mar/10

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

Type: Wish Priority: Major
Reporter: Ben Golding Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP2


Number of attachments : 0

 Description   

Enhancement:

The izpack2exe utility should allow the user to provide a JRE to be bundled as part of the .exe installer.

The self-extracting EXE would extract both the IzPack installer (install.jar) and 'bundled_jre' directory. It would then execute something like 'bundled_jre\javaw.exe -jar install.jar' to launch the installer. This means the end user does not need to first download and install the Java JRE, before installing his other application. Also we have complete control that the right version of Java is used.

Additionally the bundled JRE should be available as a 'Pack' for the application itself to use (if a Java application) and not only the installer.

This enhancement should also avoid the related issue IZPACK-560.






[IZPACK-560] .exe package uses .jar association, not JRE Created: 30/Mar/10  Updated: 28/Sep/12

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

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

Windows XP SP2


Number of attachments : 0

 Description   

Problem: The end-user must have associated .jar files with a JRE in Windows.

If associated with another app e.g. WinZip then the installer will not launch as expected, but instead something else (e.g. WinZip) appears, after the EXE has extracted.

Note, this issue also happens with the PackJacket 0.4.2 installer from http://packjacket.sf.net/download

Fix: Look for the JRE somehow using JAVA_HOME or JRE_HOME environment variables, the registry, something else...?

Steps to reproduce:
cd /d "C:\Program Files\IzPack\sample\simple"
"C:\Program Files\IzPack\bin\compile.bat" install.xml
cd /d "C:\Program Files\IzPack\utils\wrappers\izpack2exe"
izpack2exe.exe --file=..\..\..\sample\simple\install.jar --output=..\..\..\sample\simple\install.exe
start ..\..\..\sample\simple\install.exe

Workaround: change the association manually, before running the installer. I tried to do this - seems it is not so easy.

Relying on the default association of JAR files is a hack IMO. The point of an installer is that we do not know what environment the end user will have.



 Comments   
Comment by Joachim G [ 28/Apr/10 ]

This was mentionned in IZPACK-30 as well.
I'm also interested in a solution to this issue....

Comment by Jonas Stenberg [ 28/Sep/12 ]

We solved this by having an install.bat script for windows containing the following lines:
___________
CD %~dp0
java -jar installer.jar %*
___________

...then we package the install.bat and the installer.jar in a zip file for distribution.
We also have a similar install.sh script for unix/linux/mac users.





[IZPACK-559] izpack2exe doesn't handle spaces in path Created: 30/Mar/10  Updated: 07/Apr/10  Resolved: 07/Apr/10

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

Type: Bug Priority: Minor
Reporter: Ben Golding Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP2


Number of attachments : 0

 Description   

Problem: izpack2exe seems not to work when the path to input file contains spaces.

Steps to reproduce:
cd /d "C:\Program Files\IzPack\sample\simple"
"C:\Program Files\IzPack\bin\compile.bat" install.xml
cd /d "C:\Program Files\IzPack\utils\wrappers\izpack2exe"
izpack2exe.exe --file="C:\Program Files\IzPack\sample\simple\install.jar" --output="C:\Program Files\IzPack\sample\simple\install.exe"

7-Zip (A) 4.64 Copyright (c) 1999-2009 Igor Pavlov 2009-01-03
Scanning

C:\Program: WARNING: The system cannot find the file specified.
Files: WARNING: The system cannot find the file specified.

Creating archive installer.7z

WARNINGS for files:
C:\Program : The system cannot find the file specified.
Files : The system cannot find the file specified.
----------------
WARNING: Cannot find 2 files
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2008
UPX 3.03w Markus Oberhumer, Laszlo Molnar & John Reiser Apr 27th 2008

File size Ratio Format Name
-------------------- ------ ----------- -----------
upx: C:\Program: FileNotFoundException: C:\Program
upx: Files\IzPack\sample\simple\install.exe: FileNotFoundException: Files\IzPack\sample\simple\install.exe

Packed 0 files.

Workaround: use a relative path
izpack2exe.exe --file=..\..\..\sample\simple\install.jar --output=..\..\..\sample\simple\install.exe



 Comments   
Comment by Ben Golding [ 31/Mar/10 ]

See also http://bugs.python.org/issue1524

It seems that os.system() doesn't handle more than one double-quoted path correctly, subprocess.call() is better [requires Python >= 2.4]





[IZPACK-558] Need chdir before using izpack2exe Created: 30/Mar/10  Updated: 07/Apr/10  Resolved: 07/Apr/10

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

Type: Improvement Priority: Trivial
Reporter: Ben Golding Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP2


Number of attachments : 0

 Description   

Problem: you need to change to izpack2exe dir before using it.

Fix: Instead the directory part of '$0' should be used (I'm not sure of the equivalent to $0 in Python).

To reproduce:
> cd /d "C:\Program Files\IzPack\sample\simple"
> "C:\Program Files\IzPack\bin\compile.bat" install.xml
> "C:\Program Files\IzPack\utils\wrappers\izpack2exe\izpack2exe.exe" --file=install.jar --output=install.exe

'7za' is not recognized as an internal or external command,
operable program or batch file.
Traceback (most recent call last):
File "izpack2exe.py", line 90, in <module>
File "izpack2exe.py", line 87, in main
File "izpack2exe.py", line 74, in create_exe
IOError: [Errno 2] No such file or directory: 'installer.7z'

Workaround:
> cd /d "C:\Program Files\IzPack\utils\wrappers\izpack2exe"
> izpack2exe.exe --file=..\..\..\sample\simple\install.jar --output=..\..\..\sample\simple\install.exe






[IZPACK-557] JVM crash when launching IzPack-install-4.3.3.jar under Mandriva Linux 2010 Created: 29/Mar/10  Updated: 04/Aug/10  Resolved: 04/Aug/10

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

Type: Bug Priority: Blocker
Reporter: Julien Gouesse Assignee: Julien Ponge
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mandriva Linux 2010, Sun JDK 1.6 update 16


Number of attachments : 0

 Description   

Enter java -jar IzPack-install-4.3.3.jar in a terminal. The JVM crashes immediately:
#

  1. A fatal error has been detected by the Java Runtime Environment:
    #
  2. SIGBUS (0x7) at pc=0xb7649077, pid=2786, tid=3067104112
    #
  3. JRE version: 6.0_16-b01
  4. Java VM: Java HotSpot(TM) Client VM (14.2-b01 mixed mode, sharing linux-x86 )
  5. Problematic frame:
  6. C [libc.so.6+0x74077] memset+0x37
    #
  7. An error report file with more information is saved as:
  8. /home/gouessej/Téléchargements/hs_err_pid2786.log
    Erreur de segmentation

The log file contains this:
#

  1. A fatal error has been detected by the Java Runtime Environment:
    #
  2. SIGBUS (0x7) at pc=0xb762d077, pid=5801, tid=3066989424
    #
  3. JRE version: 6.0_16-b01
  4. Java VM: Java HotSpot(TM) Client VM (14.2-b01 mixed mode, sharing linux-x86 )
  5. Problematic frame:
  6. C [libc.so.6+0x74077] memset+0x37
    #
  7. If you would like to submit a bug report, please visit:
  8. http://java.sun.com/webapps/bugreport/crash.jsp
    #

--------------- T H R E A D ---------------

Current thread is native thread

siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0xb6c61000



 Comments   
Comment by Julien Gouesse [ 29/Mar/10 ]

I don't succeed in reproducing this bug. It seems to happen only when there is not enough free space on the hard drive AND after a reboot. Maybe lower the criticity of this bug and add a check to avoid this problem to happen later.

Comment by Dirk Räder [ 04/May/10 ]

I experienced a similar error using SUN JDK 1.6.0_18 on SuSE Linux Enterprise 10. The log stated a SIGSEGV in libjvm.so.

The bug is reproducible on exactly this one machine with this JVM. Changing the machine or updating the JVM to U19/U20 solved the problem.

I think that's a bug in the JVM itself. According to several blog and forum posts, it also occurs with the OpenJDK and on several operating systems, beginning with Java 6 update 17.

More information can be found by googling "Java SIGSEGV" and now probably "Java SIGBUG", too.

Regards, Dirk

Comment by Julien Ponge [ 04/Aug/10 ]

That's an external bug.





[IZPACK-556] Uninstaller removes all symbolic links to directories Created: 29/Mar/10  Updated: 29/Mar/10

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

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

When using the uninstaller all the (manually created) symbolic links underneath the install directory that point to a directory are removed. The uninstaller should only remove file/directories/symbolic links that the installer created and should leave the other stuff alone.
Symbolic links to files are not removed!






[IZPACK-555] Non-Admin can't install at all when <run-privileged /> is set Created: 26/Mar/10  Updated: 07/Apr/10

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

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

Windows XP Professional


Number of attachments : 0

 Description   

When an installer is created with <run-privileged /> the created exe file is started with privilege elevation, opening a user selection dialog, so that an Admin user can be selected. But selecting a non-admin user results in a "This directory can not be written! Please choose another directory!" (UserPathPanel.notwritable) error message later when selecting a directory, even when the given directory is writable by the user.

I guess, during further installation, again, the program files directory is checked for write access and results in this message (am I right?). So, the message is completely misleading, because the selected directory may be writable by the non-admin user.

Either the run-privileged should be taken serious and the selected user must already have Admin rights (e.g. because the installer really needs it for proper operation) before starting the installer and giving the error, but I would prefer that the selected directory is checked for write access. This would come much closer to the real intention of the privilege elevation dialog: You may want to install a program as admin by default, but as unprivileged user selecting a writable directory makes it possible to install and use the software anyway.

My favorite universal solution could look like this:
By giving an attribute

<run-privileged check="strict" />

the installing user must have admin rights for installation.
By using the default <run-privileged />-tag the installing user can select a non-admin account and he can install the software into a private writable directory.

Personally, for me the second option is important: to only start with the dialog, because the default installation directory is in program files and a usual user doesn't have write access to it. Showing this dialog gives him the background, that he either needs admin rights or he must select another directory where he has write access to. This is the common scenario in a business environment - the user doesn't have admin rights, but I want to give him the chance to install the software into a local folder.



 Comments   
Comment by Julien Ponge [ 07/Apr/10 ]

Would you be able to investigate and provide a patch?

Cheers





[IZPACK-554] spec txt and id set without localization files shows the id in the panel Created: 25/Mar/10  Updated: 29/Apr/11  Resolved: 07/Apr/10

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.2
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Major
Reporter: Francis De Brabandere 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   

I'm using the latest version available in maven central: 4.3.2

In our install.xml we have this:
<res id="userInputSpec.xml" src="panel-configuration.xml" />

this panel-configuration.xml contains as example this:
<panel order="1" id="clustering.panel">
<field type="text" variable="JBOSS_PARTITION_NAME">
<spec txt="Partition name :" size="20" set="foo" id="jbosspartition"/>
</field>
...

If we now run the installer we see a stacktrace about the localization file that could not be loaded and the panel itself shows "jbosspartition" as label instead of "Partition name :"

As a temporary fix we removed all our id attributes. But the documentation states that when no localisation file is found he should fall back to the txt



 Comments   
Comment by Julien Ponge [ 07/Apr/10 ]

Indeed it does not fall back to the @txt attribute. I'm having a look at a potential fix.

Comment by Julien Ponge [ 07/Apr/10 ]

Found a fix!

Comment by Francis De Brabandere [ 07/Apr/10 ]

Thanks for the quick fix. Will this 5.0 once it is done be released to maven central?

Comment by Mark Miller [ 16/Dec/10 ]

cherry picked to 4.3.3 in my github repo at https://github.com/lucidimagination/izpack/commit/6171f9d4de7b5b999fe827831acd50aae7b2b13a





[IZPACK-553] In german translation have same buttons different labels ("Auswählen..." vs. "Durchsuchen...") Created: 23/Mar/10  Updated: 24/Mar/10  Resolved: 24/Mar/10

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

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

In the german translation,
when I have to choose the intall path, the button says "Auswählen..."
<str id="TargetPanel.browse" txt="Auswählen..."/>
when I have to choose a directory in the userpanel, the button says "Durchsuchen..."
<str id="UserInputPanel.search.browse" txt="Durchsuchen..."/>

In both cases, I choose a directoy, the label should be the same "Auswählen...".



 Comments   
Comment by Julien Ponge [ 24/Mar/10 ]

Ok thanks





[IZPACK-552] Empty "Directory Field" in "User Panel" will result to "Application Home" (but should be NULL) Created: 23/Mar/10  Updated: 05/Oct/11  Resolved: 07/Sep/11

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

Type: Bug Priority: Major
Reporter: Tian Schellenberg Assignee: Julien Ponge
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File FileInputField.java     Java Source File StringTool.java     Java Source File UserInputPanel.java     XML File userInputSpec.xml    
Number of attachments : 4

 Description   

In the current Version (IzPack-install-4.3.3.jar) in the UserPanel I want to use a field with type="dir". The input is not required, so the "set" is empty.
The result is, that the variable will be filled with "Application Home" (but should be NULL).

The problem is in the "FileInputField.class":

public File getSelectedFile()
{
File result = null;
if (filetxt.getText() != null)

{ result = new File(filetxt.getText()); }

return result;
}

The result of "JTextField.getText()" will never be NULL!
Therefore the "File" fill be created with "", this will default to "Application Home".

JTextField tef = new JTextField();
tef.setText( null );
System.out.println( "JTextField.length() = " + tef.getText().length());
// => "0"

File file = new File( "" );
System.out.println( "FILE = " + file.getAbsolutePath());
// => Application Home

Conclution: Read every "JTextField.getText()" with something "trimToNULL()" (even the userinput of "space" shoult be not a problem).

public static String trimToNull( String stg )
{
if( stg != null )
{
stg = stg.trim();
if( stg.length() == 0 )

{ stg = null; }

}
return stg;
}



 Comments   
Comment by Julien Ponge [ 24/Mar/10 ]

Would you be able to upload a patch?

Thanks

Comment by Tian Schellenberg [ 24/Mar/10 ]

The changed files, based on 4.3.3

Comment by Julien Ponge [ 24/Mar/10 ]

Would you have diff/patch files instead?

Comment by Tian Schellenberg [ 26/Mar/10 ]

Unfortunately, I can't provide more than I did.
Thanks!

Comment by Beverley Ridyard [ 05/Oct/11 ]

Patch seems to have been supplied but Resolution is set to Won't Fix. Could you clarify whether this fix will be in 5.0 please?





[IZPACK-551] Last package in a group is always marked as required (greyed) Created: 22/Mar/10  Updated: 22/Mar/10

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

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

Attachments: PNG File tree_panel.png    
Number of attachments : 1

 Description   

When using the following configuration:

<packs>
  <pack id="ontology" name="" required="yes"><description /></pack>
  <pack id="ontologyFile" name="" parent="ontology" required="no"><description /></pack>
  <pack id="ontologyDb" name="" parent="ontology" required="no"><description /></pack>
  <pack id="core" name="" required="yes"><description /></pack>
  <pack id="normalizer" name="" parent="core" required="no"><description /></pack>
  <pack id="disambiguator" name="" parent="core" required="no"><description /></pack>
  <pack id="tokenizer" name="" parent="core" required="no"><description /></pack>
</packs>

the last package (tokenizer in the example) is always marked as required (greyed). This occurs only for last group in a set. Similar to IZPACK-449, but with opposite effect.






[IZPACK-550] Pack dependency by ID instead of name Created: 19/Mar/10  Updated: 19/Mar/10

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

Type: New Feature Priority: Major
Reporter: Pavel Vlasov 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 complex hierarchical installer. Some of my packs have duplicate names (e.g. Sources) but different ID's (e.g. rules.sources, inspectors.sources). The problem is that the depends tag takes only pack name and not pack id. It'd be very nice if the tag also could take pack ID. Currently I have to give long names to dependent packs to disambiguate (e.g. "Rules sources"), though it is redundant because the pack is in the hierarchy under "Rules").

I think I already reported this problem, but I don't see it in the list of issues.






[IZPACK-549] DTD is too strict for <pack> element Created: 16/Mar/10  Updated: 16/Mar/10

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

Type: Improvement Priority: Major
Reporter: Dmitry Katsubo 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 TreePacksPanel allows to retrieve localized package names and descriptions from language resources. That means "name" attribute and "description" element should become optional in DTD.

For example this looks dummy:

<packs>
  <pack id="service" name="" required="yes"><description /></pack>
</packs>

should be:

<packs>
  <pack id="service" required="yes" />
</packs>





[IZPACK-548] izpack-standalone-compiler 4.3.3 in maven central Created: 16/Mar/10  Updated: 03/Sep/11  Resolved: 03/Sep/11

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

Type: Wish Priority: Major
Reporter: Francis De Brabandere Assignee: Dan Tran
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

izpack-standalone-compiler 4.3.3 does not seem to be available in maven central:

http://mirrors.ibiblio.org/pub/mirrors/maven2/org/codehaus/izpack/izpack-standalone-compiler/



 Comments   
Comment by Katarzyna Czeczot [ 19/Mar/10 ]

Hi,

is there any chance this could be fixed soon please ?

Cheers,
Katarzyna

Comment by Dan Tran [ 03/Sep/11 ]

4.3.4 is up at central





[IZPACK-547] IzPanelLayout does not correctly set panel dimensions Created: 15/Mar/10  Updated: 15/Mar/10

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

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

Attachments: PNG File scr1.png     PNG File scr2.png    
Number of attachments : 2

 Description   

Consider the following code:

JPanel panel = new JPanel(new IzPanelLayout());

panel.setBorder(BorderFactory.createLineBorder(Color.RED, 10));

panel.add(useDefaultSettingsCheckBox = new JCheckBox(), NEXT_LINE);
panel.add(LabelFactory.create(getI18nStringForClass("proxyHost"), LEADING), NEXT_LINE);
panel.add(hostField = new JTextField(10));
panel.add(LabelFactory.create(getI18nStringForClass("proxyPort"), LEADING), NEXT_LINE);

panel.add(portField = new JTextField(10));

add(panel, IzPanelLayout.getDefaultConstraint(XY_VARIABLE_CONSTRAINT));

The result is in attachment scr1.png: The border (and the panel) has a min height set to approx 700 px (and the bottom part of the border is only visible when the window is resized).

When replacing XY_VARIABLE_CONSTRAINT with CONTROL_CONSTRAINT the result is in scr2.png: The layout manager does not correctly calculate the total width/height of the panel.






[IZPACK-546] Help Window is not configurable at all Created: 12/Mar/10  Updated: 07/Apr/10  Resolved: 07/Apr/10

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

Type: Bug Priority: Major
Reporter: mao Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File helpWindow.patch    
Number of attachments : 1

 Description   

We have an HTML help file and it shows in the Help Window correctly. The problem is that the Help Window always open a hyperlink in the same Help Window. What we actually want is to open the link in a browser. There is no an easy way to adjust the help window and open the link in a browser.

We hope you guys can provides some ways to configure the Help Window. e.g. from the XML file, provides a setter or register method to set the event listener so we can set it in our own panels, etc. I hope it can be more flexible, at least in programming.



 Comments   
Comment by mao [ 31/Mar/10 ]

I created a patch to HelpWindow.
It will open a link by the default browser if the link url does not begin with "#". For the url beginning with "#", it will load it to the text component. The patch requires Java 6.
Could anybody test it and have it merge to the source?





[IZPACK-545] HTMLInfoPanel does not reload and parse resource on panelActivate Created: 11/Mar/10  Updated: 12/Mar/10  Resolved: 12/Mar/10

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

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

The HTMLInfoPanel overrides JEditorPane.getStream(URL) in order to perform parsing and variable substitution. The design intent is for this to happen at instantiation and at panel activation. However, it does not happen at panel activation because the URL of the resource has not changed from one JEditorPane.setPage call to the next.

The solution, as documented in the JEditorPane.setPage Javadoc, is to clear the stream description property before setting the URL again.

Here is an updated panelActivate method with the fix:

public void panelActivate()
{
// Clear this property to get the document to reload and perform variable substitution.
// See JEditorPane.setPage javadoc.
final Document doc = textArea.getDocument();
doc.putProperty( Document.StreamDescriptionProperty, null );

try

{ textArea.setPage(loadHTMLInfoContent()); //set caret so beginning of file is displayed: textArea.setCaretPosition(0); }

catch (IOException e)

{ e.printStackTrace(); }

}






[IZPACK-544] ShortcutPanel and ShortcutPanelAutomationHelper refactoring Created: 11/Mar/10  Updated: 03/May/10  Resolved: 03/May/10

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

Type: Improvement Priority: Major
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

At the moment the ShortcutPanelAutomationHelper do not create the Shortcuts as they are described in the spec. It creates the same shortcuts as the ShortcutPanel during installation. There is no check of the conditions.
I think it would be much better to read and create the icons as they are described in the shortcut spec.
This would also mean that we change the format of the xml written by the ShortcutPanel in a way that it holds the information of the panel and not all generated shortcuts.

The xml structure can look like the following:
<ShortcutPanel id="shortcut.panel.id">
<create>true</create> should shortcuts be created?
<programgroup>My Program Group</programgroup> in which program group should the be created?
<ondesktop>false</ondesktop> should we also create desktop icons?
<type>user</type> are the shortcuts for the user only or for all users?
</ShortcutPanel>



 Comments   
Comment by Florian Buehlmann [ 03/May/10 ]

Refactored ShortcutPanel ist active now.





[IZPACK-543] inconsistent way to handle text/html files Created: 11/Mar/10  Updated: 17/Mar/10

Status: In Progress
Project: IzPack
Component/s: Documentation, Panels
Affects Version/s: 4.3.3
Fix Version/s: None

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

Number of attachments : 0

 Description   

IzPack should have an unified way to bind text/html resources to text/html displaying panels.
For example, for a HTMLInfoPanel, we have (from the doc) :

<resources>
  <res id="HTMLInfoPanel.readme" src="readme.html"/>
  <res id="HTMLInfoPanel.disclaimer" src="disclaimer.html"/>
  ...
<resources>
...
<panels>
  <panel classname="HTMLInfoPanel" id="readme" />
  <panel classname="HTMLInfoPanel" id="disclaimer" />
  ...
</panels>

But with InfoPanel we can only display one file (one single InfoPanel or several info panels displaying the same file), and the resource must be id'd "InfoPanel.info".
With (HTML)LicencePanel, we can only choose one file, (HTML)LicencePanel.licence.
HTMLHelloPanel behaves like HTMLInfoPanel (can choose the resource for each panel).

This is quite confusing for the user, and the doc isn't very clear on that point.

The user should be able to choose which file go to which text/html displaying panel. Having those panels behaving like the HTMLInfoPanel would solve this problem and shouldn't break existing installers (they use the default id).



 Comments   
Comment by David Duponchel [ 11/Mar/10 ]

If you are ok with my solution, I can implement it and submit a patch as soon as the git transition is over.

Comment by David Duponchel [ 17/Mar/10 ]

The implementation is done (see http://github.com/dduponchel/IzPack/tree/IZPACK-543) but since the console installation is still unstable, the integration tests can't pass.
I will merge these modifications as soon as the console install works.





[IZPACK-542] Desktop shortcut on Unbuntu fails Created: 10/Mar/10  Updated: 12/Mar/10

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

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

Ubuntu Karmic


Attachments: PNG File Capture.png    
Number of attachments : 1

 Description   

Desktop files is actually placed on desktop but does not produce shortcut (see attached). Something is wrong with the format.



 Comments   
Comment by Bernard Bou [ 12/Mar/10 ]

Actually, clicking on this will validate the desktop. So this may not be a bug but one of Gnome's desktop features. Strange though.





[IZPACK-541] IsPortValidator uses incorrect range and is undocumented Created: 10/Mar/10  Updated: 12/Mar/10  Resolved: 12/Mar/10

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

Type: Bug Priority: Minor
Reporter: Steve Poole 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   

I notice that the IsPortValidator class has this test:

port = Integer.parseInt(client.getFieldContents(0));
if (port > 0 && port < 65535)

{ return true; }

Ports 0 and 65535 are valid and should not be rejected.

Also, this class is not present in the documentation for validators.






[IZPACK-540] Custom lang pack is not loaded Created: 09/Mar/10  Updated: 16/Aug/13  Resolved: 16/Aug/13

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

Type: Bug Priority: Major
Reporter: Dmitry Katsubo Assignee: Rene Krell
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 1.6, izpack-maven-plugin 1.0-alpha-5, izpack-standalone-compiler 4.2.1


Number of attachments : 0

 Description   

Currently loading of custom langpack (e.g. res\packsLang.xml_eng) happens in the constructor of PacksPanelBase/TreePacksPanel. However, some custom installers may not use these panels at all, so for them custom langpack will not be loaded.

The initialisation of custom langpack is not done by GUIInstaller properly: GUIInstaller.addCustomLangpack() should use constant LANG_FILE_NAME = "packsLang.xml" and not LANG_FILE_NAME = "CustomLangpack.xml" and/or the documentation should cover this particular case and explain in more details, how to load/initialize custom langpack.

The following code should be removed from PacksPanelBase/TreePacksPanel (can be used as a temporary workaround for custom panels):

private static final String LANG_FILE_NAME = "packsLang.xml";

InputStream inputStream = ResourceManager.getInstance().getInputStream(LANG_FILE_NAME);
parent.langpack.langpack.add(inputStream);

And finally maven plugin should be updated for the latest version, containing the fix.



 Comments   
Comment by Dmitry Katsubo [ 09/Mar/10 ]

The problem is also described in maillist.

Comment by Rene Krell [ 16/Aug/13 ]

This problem is no longer present in IzPack 5.

The following install.xml loads the resources without a problem:

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

Be aware of changing the case CustomLangpack -> CustomLangPack in the resource ID.





[IZPACK-539] Compilation warning in UserCondition class: actualUsername variable is NULL Created: 08/Mar/10  Updated: 08/Mar/10

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

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

Attachments: PNG File source-shot.png    
Number of attachments : 1

 Description   

See the attached screenshot: Eclipse gives an error, and I agree that the code contains potential NPE at a given location:

Null pointer access: The variable actualUsername can only be null at this location com/izforge/izpack/rules/UserCondition line 51





[IZPACK-538] Win7 wrong shortcut creation Created: 08/Mar/10  Updated: 24/May/11  Resolved: 15/Mar/10

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

Type: Bug Priority: Minor
Reporter: Michael Hagedorn Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ShellLink_cxx.patch     File ShellLink.dll     Text File ShellLink_rc.patch     File ShellLink_x64.dll    
Number of attachments : 4

 Description   

If <shortcut> attribute 'target' and 'commandLine' will be used together and setup runs on Win7 all created shortcuts will link to first defined 'target'. 'commandLine' will be replaced by right one.
This is handled by Windows library ShellLink.dll. Within this library 'target' is mapped to IShellLink::Path and 'commandLine' to IShellLink::Arguments. Before saving shortcuts IShellLink::Resolve() is called. This Method substitutes Path by first used value if it runs on Win7.



 Comments   
Comment by Michael Hagedorn [ 08/Mar/10 ]

patches and deliverables

Comment by Michael Hagedorn [ 08/Mar/10 ]

Please delete following files from svn, this are temp files from MSVC:
RCa01304, ShellLink.aps, ShellLink.ncb, ShellLink.opt, ShellLink.suo

Comment by Julien Ponge [ 15/Mar/10 ]

Thanks Michael!

Comment by timm hörmann [ 24/May/11 ]

I keep getting the bug testing on a win7 32 bit system. Win Xp 32 bit and Win7 64 bit works fine.

Comment by Julien Ponge [ 24/May/11 ]

Any chance you may investigate why the issue persists?

Comment by Michael Hagedorn [ 24/May/11 ]

Timm, please check file version of packaged ShellLink.dll and ShellLink_x64.dll. It has to be 2.0.0.1.
BTW current bug fix is more or less a workaround. I’ve changed resolving functionality of shortcuts exactly for Win 7 and Win 2008 R2 because I hit the bug using these versions (32/64). I wanted to be minimal invasive.
In my opinion there is no need for IShellLink::Resolve() in any Windows.
So the general fix should be removing IShellLink::Resolve(). Are you able to try this? Or should I send you shared libs with generally turned off resolving for testing purpose?





[IZPACK-537] Refresh dynamic variables also at the beginning of the installation to be able to use them for installerrequirement conditions Created: 05/Mar/10  Updated: 20/Sep/10  Resolved: 21/Apr/10

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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by IZPACK-520 Implement basic upgrade handling Resolved
Testcase included: yes
Number of attachments : 0

 Description   

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

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

<dynamicvariables>
<variable name="previous.version" checkonce="true"
file="$

{INSTALL_PATH}

/installation.properties" type="options"
key="version"/>
</dynamicvariables>

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

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

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



 Comments   
Comment by Gregor B. Rosenauer [ 20/Sep/10 ]

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

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

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

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

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

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





[IZPACK-536] UserInputPanel's JScrollPane border is not visually pleasing with title field Created: 26/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Improvement Priority: Trivial
Reporter: Manny Lim Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Attachments: Text File uip_border.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

http://jira.codehaus.org/browse/IZPACK-476 introduces a JScrollPane to add scrollable functionality to UserInputPanel's with lots of controls. The JScrollPane's viewport border is set to an empty border, however the JScrollPane's border is not. As a result, a border is still visible on UserInputPanels. The border is not visually pleasing when a title field is used due to the lack of visual separation between the title text and the border.

Because the viewport border was hidden, I believe it was the intention of the original contributor of this functionality to have no borders at all. I've submitted a patch that simply sets the JScrollPane's border to an empty one. UserInputPanel will look as it did in 4.3.1.



 Comments   
Comment by Julien Ponge [ 15/Mar/10 ]

Thanks!





[IZPACK-535] Avoid logging to System.out in PacksPanelAutiomationHelper Created: 26/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Improvement Priority: Major
Reporter: Jochen Hinrichsen Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File PacksPanelAutomationHelper.logging.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

PacksPanelAutionHelper uses System.out for logging, which interferes with regular installation output. The patch makes use of the regular IzPack Debug.log() functionality.






[IZPACK-534] Parse files within ZIP Files Created: 24/Feb/10  Updated: 07/Sep/11

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

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

Attachments: File parseinzip.diff    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

We stumbled across the need to configure WAR-Files during the installation process with properties which are entered in an UserInputPanel.
To do this we had to call an Ant-Task after the installation which would change the respective files in the WAR file.

I refactored the parse system to achieve this with IzPack alone. Syntax in install.xml is as follows:
targetfile="<PATH_TO_ZIP>@@<PATH_WITHIN_ZIP_1>:<PATH_WITHIN_ZIP_2>:..."

Example:
<pack name="TEST" required="yes">
<description>Test</description>
<singlefile target="$INSTALL_PATH/test.zip" src="test/test.zip"></singlefile>
<parsable targetfile="$INSTALL_PATH/test.zip@@test/a/sys.props:test/b/sys.props"></parsable>
</pack>

Doku patch will follow

Comments are welcome!



 Comments   
Comment by Brett Bergquist [ 24/Feb/10 ]

That would be really useful. I have a similar requirement, but it is even a little more complex. I need to substitute variables in WAR module within an EAR module. Basically a zip/jar file within a zip/jar file. Any chance to extend the feature to support that?

Right now, I have ant scripts as well that unpack, edit, and then repack the EAR to do what I need.

In any case, this is a nice feature to have no matter what.

Comment by Julien Ponge [ 07/Sep/11 ]

This somehow dropped in my todo list; sorry about that.

The functionality is useful but the code removes lots of logger call. It has no copyright attached, and it worked on a previous codebase.

Unless somebody refreshes it to 4.3.4 and master I'm afraid we won't merge it anytime soon.





[IZPACK-533] Panel conditions not working on first panel Created: 22/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Bug Priority: Critical
Reporter: Jochen Hinrichsen Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File InstallerFrame.layout.patch     Text File InstallerFrame.patch     Text File UninstallData.patch    
Number of attachments : 3

 Description   

InstallerFrame.java starts the installation process by executing

// We show the frame
showFrame();
switchPanel(0);

It seems as if switchPanel() does not care about panel conditions, because my first panel gets activated no matter what condition i specify.

In addition, what about a condition -DskipAll that skips all configured panels? In this case, showFrame() should not be called at all.

Conditions for any other than the first (#0) panel are evaluated correctly.



 Comments   
Comment by Jochen Hinrichsen [ 23/Feb/10 ]

The attached patch is more a workaround than a solution. After applying the patch, the layout splits into a left and a right half, and only the right half is used for interaction. The left half stays empty.

I find this acceptable for my current problem.

Comment by Jochen Hinrichsen [ 26/Feb/10 ]

Had some time to dig into the layout issue, the attache patch InstallerFrame.layout.patch contains patches in InstallerFrame.patch plus the layout fix.

Comment by Julien Ponge [ 27/Feb/10 ]

Ok thanks.

We are currently restructuring the code base, so there may be some small lag before we apply pending patches.





[IZPACK-532] CheckedHelloPanel does not handle HKCU Created: 18/Feb/10  Updated: 18/Oct/13  Resolved: 19/Sep/13

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

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

Windows XP


Testcase included: yes
Number of attachments : 0

 Description   

When users on Windows XP run our installer AND already did an install earlier, they get this message:

This product is already installed on this computer under the path <not found>. Are you sure you want to install another entity?

We would like to see the <not found> part of the message fixed.

I did not succeed in running the debugger but I found the following by source code inspection.

This message comes from the standard CheckedHelloPanel in izPack

We use the CheckedHelloPanel with the RegistrySpec.xml file attached below. Note that we use HKCU instead of the more common HKLM because our users are working on a network account and have no admin rights.

Now I found in the CheckedHelloPanel the following code

rh.setRoot(HKEY_LOCAL_MACHINE);
if (!rh.valueExist(keyName, "UninstallString"))
{
//.....
break;
}

So the checkedhellopanel seems to be unaware that the UninstallString may be located in the HKCU instead of HKLM.
I suppose this is incorrect because the RegistryHandler DOES support HKCU.

So I suspect that fixing this is simple: just check the HKCU as well before bailing out.

-----RegistrySpec.xml-------
<registry>
<pack name="UninstallStuff">
<!-- Special "pack", if not defined an uninstall key will be generated automatically -->
<!-- Wouter: and that key will be in LOCAL_MACHINE which is unwritable by normal users -->
<!-- The variable $UNINSTALL_NAME can be only used if CheckedHelloPanel will be used
because there the variable will be declared. With that variable it is possible
to install more than one instances of the product on one machine each with an
unique uninstall key. -->
<value name="DisplayName"
keypath="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$UNINSTALL_NAME"
root="HKCU"
string="$UNINSTALL_NAME"/>
<value name="UninstallString"
keypath="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$UNINSTALL_NAME"
root="HKCU"
string=""$JAVA_HOME\bin\javaw.exe" -jar "$INSTALL_PATH\uninstaller\uninstaller.jar""/>
<value name="DisplayIcon"
keypath="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$UNINSTALL_NAME"
root="HKCU"
string="$INSTALL_PATH\bin\icons\izpack.ico"/>
<value name="HelpLink"
keypath="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$UNINSTALL_NAME"
root="HKCU"
string="$APP_URL"/>
</pack>
<pack name="Documentation-HTML">
<key keypath="SOFTWARE\IzForge\IzPack\$UNINSTALL_NAME\Documentation\HTML" root="HKCU"/>
</pack>
</registry>
------------------



 Comments   
Comment by Julien Ponge [ 18/Feb/10 ]

Would you be able to provide us a patch?

Thanks a lot

Comment by w.pasman [ 02/Mar/10 ]

Thanks for the quick response and for the confidence in my analysis.

I am definitely not an expert on registry issues, in fact I am normally using Mac OSX.

Also I did not figure out how to build the izpack system. I did run ant inside the src/ directory and it build quite some files but in new directories that seemed not to have any effect. It seems that I am missing information and knowledge to do this. In short, even if I made a patch I could not compile or test it.

What I can offer is to suggest a new piece of code, but someone else will have to review and compile it.

BTW Sorry for the late reply. I replied on your mail but I just received a bounce

"Hi. This is the qmail-send program at mail.codehaus.org.
I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out.

<jira@codehaus.org>: user is over quota"

Comment by Julien Ponge [ 03/Mar/10 ]

If you run 'ant quickdist+run' you will be able to build and launch the IzPack own installer from the modified source code.

Cheers

Comment by Daniel Abson [ 18/Sep/13 ]

This seems to have been fixed ages ago, before the big panels refactoring. Suggest it be resolved/closed.

Comment by Rene Krell [ 19/Sep/13 ]

In fact this is fixed in IzPack 5.0, check out 5.0.0-beta11, for example.
I have not checked whether there is a fix in the IzPack 4.X branch.

Comment by Rene Krell [ 19/Sep/13 ]

Solved in 5.0. If someone gets in trouble with this issue for instance with the latest IzPack 4 please reopen.

Comment by w.pasman [ 19/Sep/13 ]

Thanks for the update. Good to hear that this was fixed

We're still on izPack4 but will check later if we can upgrade to 5 to have the fix work for us





[IZPACK-531] izpack2app comes with JavaApplicationStub that fails on newer Macs/Java Libraries Created: 17/Feb/10  Updated: 15/Mar/10  Resolved: 15/Mar/10

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

Type: Bug Priority: Minor
Reporter: Nils Meier Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac Leopard w/latest Java Update

Java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-9M3125)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)


Attachments: HTML File JavaApplicationStub    
Number of attachments : 1

 Description   

I've experimented with izpack2app and have found newer Mac
configurations with Java6/64Bit where the currently provided
JavaApplicationStub fails to start on Mac with "unable to find a
version of Java to launch".

Log:

15/02/10 16:14:26 [0x0-0x10a10a].GenealogyJ[45202] [JavaAppLauncher
Warning] Java application launched from PPC or bad stub. Relaunching
in 32-bit, and tagging sub-processes to prefer 32-bit with
$JAVA_ARCH=i386.
15/02/10 16:14:26 [0x0-0x10a10a].GenealogyJ[45202] [JavaAppLauncher
Error] This process is [i386] and was re-exec'd from [i386], but for
some reason we are trying re-exec to [].
15/02/10 16:14:26 [0x0-0x10a10a].GenealogyJ[45202] [JavaAppLauncher
Error] unable to find a version of Java to launch

I've resolved this issue by replacing JavaApplicationStub with a newer
version from a Mac (attached).

Obviously this should be tested on various Macs - in my case it keeps working on an older 32bit Mac as well as 64bit Leopard.



 Comments   
Comment by Nils Meier [ 17/Feb/10 ]

see also

http://osdir.com/ml/java-dev/2009-06/msg01006.html

and

http://kb.flexerasoftware.com/selfservice/viewContent.do?externalID=Q205207





[IZPACK-530] Dependency by pack id, not by pack name Created: 16/Feb/10  Updated: 16/Feb/10

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

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

Windows XP, Java 6.


Number of attachments : 0

 Description   

In my installers I have a hierarchical structure of packages and duplicate pack names.
E.g.
Component 1
Core
Extensions
Component 2
Core
Extensions

Pack id's are unique.

As of version 4.3.3, <depends> element supports only packname attribute. It'd be really nice if it also supported packid attribute.






[IZPACK-529] Web installer fails without explanation (blank dialog box) Created: 16/Feb/10  Updated: 16/Feb/10

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

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

Windows XP


Number of attachments : 0

 Description   

If a web installer can't access packs, it show a blank dialog box with a caption "Installation failed". It'd be nice if it'd give a description of the problem. And it'd be extremely nice if it'd ask for a proxy configuration if web packs couldn't be accessed directly.






[IZPACK-528] The value of the encoding attribute of <res> element is still ignored Created: 15/Feb/10  Updated: 03/Oct/11  Resolved: 29/Mar/11

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.0.1, 4.3.0
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Major
Reporter: Tuomo Soinio Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File CompilerConfig_4.3.4v2.java     Java Source File CompilerConfig_5.0.0beta5v2.java    
Number of attachments : 2

 Description   

The value of the encoding attribute of <res> element is ignored in install.xml.

For instance, when the file of the EUC-JP encoding is specified with Windows, the display of LicencePanel is garbled.

<resources>
<res id="LicencePanel.licence" src="legal/License.txt" encoding="EUC-JP"/>
</resources>



 Comments   
Comment by Tuomo Soinio [ 15/Feb/10 ]

As I cannot figure out a way to re-open IZPACK-165 I created this clone issue. Sorry if that is wrong thing to do.

Anyways, all encoding attributes of res elements are ignored still on 4.3.3 as they have been for a long time. My comment on the original bug report 165 has also been ignored, so if nothing else, could somebody comment on this? Is the bug going to be fixed in 4.4.0, or ever? Thank you.

Comment by Tuomo Soinio [ 15/Feb/10 ]

I just noticed (looking at IzPack sources) that some conversion is done during installer building. So the issues may be partially runtime-platform-default-encoding (i.e., which language version of Windows one is using) dependent. For example I can get InfoPanel to work by having res element to specify correct ISO-8859-1 encoding for the text file, and then by specifying "java -Dfile.encoding=UTF-8 -jar installer.jar" during the installation time. Various other combinations fail, e.g., if I just have UTF-8 text file with UTF-8 res element encoding attribute, and no runtime -Dfile.encoding spec.

Comment by Tuomo Soinio [ 15/Feb/10 ]

Ok, one more spam today. I think I figured out the problem. The following is for IzPack 4.3.3, and infopanel with the resource defined like the following:

<res id="InfoPanel.info" src="resources/readme.txt" parse="yes" encoding="ISO-8859-1"/>

What happens here, is that during the installer building (compiling) time the CompilerConfig class notices the correctly specified encoding attribute, and re-encodes the file to an UTF-8 temporary file.

The parsing (substitution) is then performed correctly. If there is no encoding (or wrong encoding) specified on the <res/>-line then the parsing probably uses platform default encoding, and likely breaks the file when it encounters, e.g., scandinavian characters.

Then on the installation run-time, the installer tries to open the re-encoded and parsed file using the platform default encoding, which is not UTF-8 for me. So that is why the absurd "-Dfile.encoding=UTF-8" makes it work.

So the bug fix would be either of the following:

  • Really convert everything to UTF-8 during compiling AND forcing that character set also when actually using the resources during installation.
  • Use the user-specified encoding also on the output of parsing process during compiling, and then later when using the resources during installation.

At least I think so.

Comment by Julien Ponge [ 17/Feb/10 ]

Would you be able to provide a patch?

Thanks a lot!

Comment by Timothy Fridey [ 22/Mar/11 ]

Tuomo was half right, the files are converted to UTF-8 however the problem does not seem to be that UTF-8 is not used during installation. The problem apears to be that there is errors in the re-encoding.

1. The uri to the new encoded file is set to a variable thats never read, and therefor never added to the JAR
2. The code that sets resource files to empty (some kind of saftey feature I guess) is accutally called after the re-encoding is done, therefor even if the above code was set to the right variable it would be overwritten with the address to the blank file, hence why if you use the encoding attribute your text will be empty.

I have attaced a fix for both 5.0.0beta5 and 4.3.4RC1, sorry no GIT patch as I still can't work out how to create one with Eclipse (EGit)

Update: My mistake Tuomo was correct after all, the bug I have fixed is to do with blank text when no parse attribute is set. The two errors I described above will happen with the following entry: <res id="InfoPanel.info" src="resources/readme.txt" encoding="ISO-8859-1"/>

I will attach a new fix that also works with the parse attribute set as my first fix didn't. Whoops.

As for the acctual bug this post is about, I can't seem to repoduce the error on my machine but I would assume it would just involve using:

resourceManager.getTextResource(resNamePrifix, "UTF-8")

instead of

resourceManager.getTextResource(resNamePrifix);

When calling loadInfo() in the info panel, etc for the other panels.

Comment by Timothy Fridey [ 22/Mar/11 ]

No parse attribute fix version2

Comment by Julien Ponge [ 29/Mar/11 ]

It's in, thanks Timothy.

Comment by Julien HENRY [ 03/Oct/11 ]

Still not fixed in 5.0.0beta8.

I have a ReadMe.txt encoded in UTF-8. I have declared:
<resources>
<res id="InfoPanel.info" src="Readme.txt" encoding="UTF-8"/>
</resources>

But it is wrongly displayed on Windows where default platform encoding is not UTF-8. Looking at the code the bug seems to come from InfoPanel#loadInfo() that use the ResourceManager#getTextResource(String resource) that does not specify encoding (so default platform encoding is used...

Please reopen.





[IZPACK-527] Bad escaping in parsable property files Created: 12/Feb/10  Updated: 18/Feb/10  Resolved: 18/Feb/10

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

Type: Bug Priority: Minor
Reporter: Jochen Hinrichsen Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all


Attachments: File izpack-527.diff     HTML File VariableSubstitutor-escape-patch     Java Source File VariableSubstitutor.java    
Patch Submitted:
Yes
Number of attachments : 3

 Description   

When replacing parsable properties/ values/ variables in Java .property files, VariableSubstitor.escapeSpecialChars(String, int) escapes spaces in property values. A sample of a generated property:

key=Hello\ world

Taken from the spec (http://java.sun.com/javase/6/docs/api/java/util/Properties.html):

'For the element, leading space characters, but not embedded or trailing space characters, are written with a preceding \ character.'

The patch attached makes space escaping for java property types spec compliant, i.e.

key=Hello world
key2=\ \ Look mom, indented



 Comments   
Comment by Julien Ponge [ 17/Feb/10 ]

I could not apply the patch (both with patch and git).

Comment by Jochen Hinrichsen [ 18/Feb/10 ]

I attached a Subversion patch (izpack-527.diff) and the complete file based on the existing rev 2827.

Comment by Julien Ponge [ 18/Feb/10 ]

Fantastic. Thanks a lot!





[IZPACK-526] Add merging and patching of configuration files and registry entries Created: 12/Feb/10  Updated: 21/Apr/10  Resolved: 21/Apr/10

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

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

Issue Links:
Supercedes
is superceded by IZPACK-520 Implement basic upgrade handling Resolved
Number of attachments : 0

 Description   

For integrating upgrade handling there is a need to pre-configure an installed application.
Therefore, I'd like to introduce a native possibility to handle configure files.

Requirements:

  • supported file formats: option/properties, INI, XML
  • registry support on Windows
  • explicitely set values
  • explicitely delete values
  • merge configuration parameters from a previous installation (or a local template).

Example:

<packs>
  <pack name="My Program Core" required="yes">
    <description>The core files of my program</description>
    <file src="plainfiles" targetdir="${INSTALL_PATH}" override="true"/>

    <configurable keepOldKeys="false" keepOldValues="true"
     fromfile="${INSTALL_PATH_OLD}/conf/myapp.properties" type="properties"
     targetfile=${INSTALL_PATH}/conf/myapp.properties" type="properties"
     condition="previousversion.is.1.0.0">
      <set key="propkey1" value="propvalue" create="true"/>
      <delete key="propkey2"/>
    </configurable>

    <configurable keepOldKeys="false" keepOldValues="true"
     fromfile="${INSTALL_PATH_OLD}/conf/myapp.xml" type="xml"
     targetfile=${INSTALL_PATH}/conf/myapp.xml" type="xml"
     condition="previousversion.is.1.0.0">
      <set key="/root/autostart" value="true" create="true"/>
    </configurable>

    <configurableset type="properties" keepOldKeys="false" keepOldValues="true" create="false"
     fromdir="${OLD_INSTALL_PATH}/conf"
     targetdir="${OLD_INSTALL_PATH}/conf"
     condition="mergeconfigallowed">
       <include="*.properties"/>
       <exclude="*.conf"/>
    </configurableset>

    <configurableset keepOldKeys="false" keepOldValues="true" create="false"
     fromregkey="HKLM\oldkey"
     targetregkey="HKLM\newkey"
     condition="changeregistryallowed"/>

    ...
  </pack>
</packs>}}


 Comments   
Comment by Rene Krell [ 18/Feb/10 ]

I will probably implement this as configuration installer listener, because this issue will require some additional frameworks to add optionally for being able to handle XML merging and XPath patching of XML files. This might look like this:

install.xml

<!-- Configuration listener class -->
<listeners>
  <listener installer="ConfigurationInstallerListener"/>
</listeners>

<!-- Resource to process -->
<resources>
  <res id="ConfigurationActionsSpec.xml" src="@BUILD_DIR@/config-actions-spec.xml" />
</resources>

config-actions-spec.xml:

<configurationactions>

  <pack name="Test Core">

    <configurationaction order="beforepacks">
      <variable name="INSTALL_PATH_OLD" value="${INSTALL_PATH}"/>
    </configurationaction>

    <configurationaction order="afterpacks">
    <configurable keepOldKeys="false" keepOldValues="true"
     fromfile="${INSTALL_PATH_OLD}/conf/myapp.properties" type="properties"
     targetfile=${INSTALL_PATH}/conf/myapp.properties" type="properties"
     condition="previousversion.is.1.0.0">
      <set key="propkey1" value="propvalue" create="true"/>
      <delete key="propkey2"/>
    </configurable>

    <configurable keepOldKeys="false" keepOldValues="true"
     fromfile="${INSTALL_PATH_OLD}/conf/myapp.xml" type="xml"
     targetfile=${INSTALL_PATH}/conf/myapp.xml" type="xml"
     condition="previousversion.is.1.0.0">
      <set key="/root/autostart" value="true" create="true"/>
    </configurable>

    <configurableset type="properties" keepOldKeys="false" keepOldValues="true" create="false"
     fromdir="${OLD_INSTALL_PATH}/conf"
     targetdir="${OLD_INSTALL_PATH}/conf"
     condition="mergeconfigallowed">
       <include="*.properties"/>
       <exclude="*.conf"/>
    </configurableset>

    <configurableset keepOldKeys="false" keepOldValues="true" create="false"
     fromregkey="HKLM\oldkey"
     targetregkey="HKLM\newkey"
     condition="changeregistryallowed"/>
                        ...
    </configurationaction>
    ...
  </pack>

</configurationactions>
Comment by Julien Ponge [ 18/Feb/10 ]

Since you are on GitHub, what if you experimented on a branch there?

Comment by Rene Krell [ 18/Feb/10 - Visible by: Developers ]

Ok, I initiated GIT to work behind our proxy.
From what repository do you recommend to fork a branch for that specific task here? Your's or Anthonin's one?

Comment by Rene Krell [ 21/Apr/10 ]

Resolved as ConfigurationInstallerListener, still to be documented in the Wiki





[IZPACK-525] Enhance conditions to be creatable from dynamic variables to get more dynamic conditions Created: 12/Feb/10  Updated: 12/Feb/10  Resolved: 12/Feb/10

Status: Closed
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: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Supercedes
is superceded by IZPACK-520 Implement basic upgrade handling Resolved
Number of attachments : 0

 Description   

I'd like to enhance conditions to be built from dynamic variables to get dynamic conditions.

At the moment, there can be used only static variables:

<variables>
<variable name="myvar" value="myval"/>
</variables>

<condition type="variable">
<name>myvar</name>
<value>myval</value>
</condition>

This should be possible also for dynamic variables:

<dynamicvariables>
<variable name="mydynvar" value="mydynval"/>
</dynamicvariables>

<condition type="dynamicvariable">
<name>mydynvar</name>
<value>mydynval</value>
</condition>

There must be a check for cycles of conditions, of course, to not allow the following constellation (this should result maybe already in a compiler error):

<dynamicvariables>
<variable name="mydynvar" value="mydynval" condition="condfromdynvar"/>
</dynamicvariables>

<condition type="dynamicvariable" id="condfromdynvar">
<name>mydynvar</name>
<value>mydynval</value>
</condition>



 Comments   
Comment by Rene Krell [ 12/Feb/10 ]

Dynamic variables are mapped to normal variables in the installer as soon as they are refreshed. Therefore there is no need to evaluate dynamic variables separately in conditions, because they can be treated like variables. Sorry for misunderstanding.

Comment by Rene Krell [ 12/Feb/10 ]

Rather than having variables separately from dynamic variables I vote for having them united in one definition <variable> to not confuse users. Special behavior like refreshing on each panel change can be also done by the attribute checkonce="false" as I suggested in another patch.
From the user view, at the installer side there will be always variables while we are defining now <dynamicvariable> and <variable> in the installer description separately.





[IZPACK-524] UserInputPanelConsoleHelper will always show radio button with 0 index as checked. Created: 11/Feb/10  Updated: 18/Dec/10  Resolved: 17/Feb/10

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

Type: Bug Priority: Major
Reporter: Dustin Hawkins Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested in Linux Console, would assume it applies to any console install


Attachments: Java Source File UserInputPanelConsoleHelper.java     Text File UserInputPanelConsoleHelper.java.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

When a set of radio buttons are displayed, the option with the 0 index is always checked.

For instance, if you select option 2 below, it will display both 0 and 2.

Proxy Connection Information

If you use a proxy server, please specify that information below.
0 [x] No Proxy Server
1 [ ] Automatic Proxy Detection
2 [x] User Defined Proxy Server
input selection:



 Comments   
Comment by Julien Ponge [ 17/Feb/10 ]

Thanks!

Comment by Mark Miller [ 17/Dec/10 ]

cherry picked for 4.3.4: https://github.com/lucidimagination/izpack/commit/f3c3656ed2fbbe473142ed49ae26bba0ca0f4e15





[IZPACK-523] Console Installer does not check panelconditions before displaying a panel Created: 11/Feb/10  Updated: 17/Feb/10  Resolved: 17/Feb/10

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

Type: Bug Priority: Major
Reporter: Dustin Hawkins Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested on Linux Console, should effect all platforms


Attachments: Java Source File ConsoleInstaller.java     Text File ConsoleInstaller.java.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

A console installation will iterate though all the panels, ignoring and panelcondition tags

Pulled in and slightly modified canShow from InstallerFrame so ConsoleInstaller now has the same behavior as GUI



 Comments   
Comment by Julien Ponge [ 17/Feb/10 ]

Many thanks for the patch!





[IZPACK-522] Console installer doesn't show a message defined in <installerrequirement> Created: 11/Feb/10  Updated: 12/Feb/10  Resolved: 12/Feb/10

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   

In the installer description it is possible to define an installer requirement. Example:

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

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

Using the GUI Installer this message is shown as a messagebox as expected, if the condition isn't fulfilled, and the installer exits after that -> so far so good.

If I launch the same setup as console installation the installer silently quits if the condition is not true. I would expect the given message on the console to inform the user what happened.



 Comments   
Comment by Rene Krell [ 12/Feb/10 ]

Fixed in SVN r2939

Automated installer was also affected





[IZPACK-521] 32-bit binaries are sometimes installed on Linux amd64 Created: 11/Feb/10  Updated: 22/Feb/10

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

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

Linux amd64


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

 Description   

I am developer for a software project that uses JOGL. We use izpack for our installer. When the installer is run on Linux amd64, 32-bit versions of some of the JOGL binaries are installed instead of the 64-bit binaries.

It seems that if I try to install a given release and, say, the 32-bit version of libjogl.so is installed, then that release will always install the 32-bit version of libjogl.so. But the next release might install the 64-bit version, even though the install.xml file and the JOGL binaries haven't changed.



 Comments   
Comment by Daniel Gulotta [ 22/Feb/10 ]

I guess the problem was that if there are multiple os conditions, izpack requires only one of them to be true, and I expected it to require all conditions to be true. "All conditions" seems like the more intuitive behavior but I suppose "any condition" is more useful.





[IZPACK-520] Implement basic upgrade handling Created: 09/Feb/10  Updated: 03/Aug/10  Resolved: 03/Aug/10

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-295 Installer support of Win Setup API - ... Resolved
supercedes IZPACK-519 Dynamic variable enhancements Resolved
supercedes IZPACK-526 Add merging and patching of configura... Resolved
supercedes IZPACK-525 Enhance conditions to be creatable fr... Closed
supercedes IZPACK-537 Refresh dynamic variables also at the... Resolved
Number of attachments : 0

 Description   

I intend to introduce upgrade handling in IzPack into discussion.

Major requirements that might be provided:

  • get the installation path of a previous installation of the same component
  • get the version of the same component installed before
  • check the compatibility of the previous component version with the one coming with the upgrade setup and deny installation in case of incompatbilities
  • decide which settings of a previous installation should overwrite the default settings in the new installation (including property+INI+XML files, registry), optionally depending on the source and target version, and patch the default settings coming from the new installation accordingly (comments should be saved).
  • delete obsolete files from an old installation, even if they had been installed in a different root path.

Note:
To not get lost in e-mail discussions I rather create a task here that refers to single sub-issues, that might be done for this purpose. This should not replace the developer discussion, but should be the central point for tracing the progress of this abstract issue.



 Comments   
Comment by Rene Krell [ 03/Aug/10 ]

Implemented and documented so far - see IzPack User Documentation





[IZPACK-519] Dynamic variable enhancements Created: 08/Feb/10  Updated: 21/Apr/10  Resolved: 21/Apr/10

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

Attachments: XML File install.xml     Text File izpack_issue_519.patch    
Issue Links:
Supercedes
is superceded by IZPACK-520 Implement basic upgrade handling Resolved
Testcase included: yes
Number of attachments : 2

 Description   

I prepared an enhanced and more flexible dynamic variable assignment system. This includes:

  • reading values from property files
  • reading values from INI files
  • reading values from XML files (XPath queries)
  • reading values from the Windows registry
  • being able to pre-process values using Java regular expressions.

I include a first testcase as an example.

To be discussed, of course. This is still work in progress.



 Comments   
Comment by Rene Krell [ 09/Feb/10 ]

Further plan:

  • reading property, INI and XML files from URLs - first step: 'file:' + 'jar:'
Comment by Rene Krell [ 09/Feb/10 ]

Added a patch that shows the current implementation state for discussion.
Please note that there is a lightweight, 3rd-party framework used for accessing property files, INI files and registry without JNI (ini4j).

Comment by Julien Ponge [ 09/Feb/10 ]

Is the inclusion of the ini4j library optional? How big is it?

You should also ping the people on izpack-dev to get useful feedback

BTW pay attention to the file headers, they have improper copyrigh t assignments. Look at the the templates in src/.

Cheers

Comment by Rene Krell [ 09/Feb/10 ]

INI4J's size is 91.5 KB (stripped, only the classes and MANIFEST, no Maven info) and it handles reading and writing (patching) property and INI files registry entries, while saving comments and ordering in them (not confusing the files as Ant's propertyfile task). The usage of ini4j could have another implication - Windows registry access can be done in future without JNI (COIOSHelper dll), because it uses the reg system command in a compatible manner with all known Windows versions.

In that case as shown in the patch I would say ini4j would not be optional. At the moment, I have no idea how to make it optional and using it at the same time in the IzPack description (dynamic variables).

The above patch still doesn't use the possibilities of ini4j 100%, but I'm thinking about another issue of merging and parametrized patching of configuration files directly from the install.xml. In that case the config file handling that ini4j offers will be a necessarity.

I will have a look at the copyright stuff, thanks.
Furthermore I'll post a hint to the mailinglist.

Comment by Rene Krell [ 11/Feb/10 ]

Replaced files:

  • more complete patch with fixed exception handling and working XPath queries
  • install.xml sample with added xpath queries. A runnable example is in the patch above including the Eclipse run configurations
Comment by Rene Krell [ 21/Apr/10 ]

Resolved according to http://docs.codehaus.org/display/IZPACK/Dynamic+Variables





[IZPACK-518] Problems with run-privileged on Linux Created: 08/Feb/10  Updated: 21/Jul/12  Resolved: 21/Jul/12

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

Type: Bug Priority: Major
Reporter: Julien Ponge Assignee: Tim Anderson
Resolution: Fixed Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

From an email on the dev list:

I have some issues with the run-privileged option.

When specifying <run-privileged
condition="izpack.windowsinstall.vista|izpack.windowsinstall.7"/> the
uninstaller doesn't behave as expected in Linux (Ubuntu.)

While the installer works (the GUI Frame is shown and files are
installed), the uninstaller doesn't work. A terminal is displayed,
asking for password, but no GUI is shown, and the files are untouched
it seems.
When not specifying run-privileged at all, the uninstaller works in
the expected manner, showing GUI and removing files.

When not specifying run-privileged on Linux (Ubuntu), the
isPrivilegedExecutionRequired in Info.java returns false, but when
using the following:, it returns true.
isPrivilegedExecutionRequiredUninstaller behaves the same way.

So there seems to be two issues:
1) Uninstaller asks for permisions on Linux when only Vista and Win7
is specified.
2) It won't remove the files after asking the permissions.

Shouldn't isPrivilegedExecutionRequired and
isPrivilegedExecutionRequiredUninstaller return true only for Vista
and Win7 when using
"izpack.windowsinstall.vista|izpack.windowsinstall.7" ?



 Comments   
Comment by Julien Ponge [ 08/Feb/10 ]

Follow-up on the list:

After checking it out a bit further I find that CompilerConfig calls
info.setRequirePrivilegedExecution(privileged != null);
This is done, not at install time, but when the installer is created.

So isPrivilegedExecutionRequired actually returns if run-privileged is
specified at all, not if it's specified for this platform.
The same thing applies for the uninstaller.

Comment by Julien Legrand [ 25/Nov/10 ]

Same behaviour in 4.3.2

Comment by Julien Ponge [ 07/Dec/10 ]

It's still on my todo list.

Comment by Tim Anderson [ 18/Jul/12 ]

Fix for this is now available at https://github.com/izpack/izpack/pull/26

For installation, the installer will now only elevate permissions if Info.isRequirePrivilegedExecution() is true and:

  • Info.getPrivilegedExecutionConditionID() is null; or
  • the condition referred to by Info.getPrivilegedExecutionConditionID() evaluates true

For uninstallation, the exec-admin file is written by UninstallDataWriter to indicate that the uninstaller should elevate privileges.
This will now only be written if Info.isRequirePrivilegedExecutionUninstaller() is true and:

  • Info.getPrivilegedExecutionConditionID() is null; or
  • the condition referred to by Info.getPrivilegedExecutionConditionID() evaluates true
Comment by Tim Anderson [ 21/Jul/12 ]

Pull request merged





[IZPACK-517] Add nested variable definitions to IzPack compiler Ant task Created: 03/Feb/10  Updated: 21/Sep/12  Resolved: 21/Sep/12

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

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

IzPack Ant task specification


Number of attachments : 0

 Description   

It would be a nice feature to be able to overgive certain values from an Ant build script to the IzPack compiler task. Example:

<izpack input="install.xml"
output="installer.jar"
installerType="standard"
basedir="$

{basedir}"
izPackDir="${basedir}

">
<variable name="VERSION" value="$

{my.version}

" override="true"/>
<variable name="SUBDIR" value="$

{my.subdir}

"/>
</izpack>

Those should be handled as if they would have been defined by the <variable> element in install.xml.
In case of conflicts with existing variables in install.xml there should be used the optional override attribute to handle overriding.



 Comments   
Comment by Rene Krell [ 03/Feb/10 ]

A co-worker told me right now, that it is possible to inherit properties from Ant using <izpack ... inheritAll="true"/> and resolving those properties in install.xml using @

{property_name}

. So at least there is already a way, even though very badly documented.

Nevertheless, inherit particular properties as variables would be a nice feature.

Comment by Rene Krell [ 21/Sep/12 ]

This is no longer relevant for IzPack 5.0





[IZPACK-516] Installer OOMing exits without any notice Created: 01/Feb/10  Updated: 01/Feb/10

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

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

Some of my custom actions require loads of memory. In case the memory is exhausted, an OOM occurs when AutomatedInstaller calls executePostValidateActions(). There is a catch() clause, but only on Exception, not on Error/Throwable, and a finally block, that starts with the comments

// Bye
// FIXME !!! Reboot handling

Some reboot vodoo takes place that makes any unix admin shiver (never ever let an installer reboot a unix system, but this is another story), and then HouseKeeper.shutDown() executes System.exit() without any notice.

No single line has been logged between executePostValidateActions() and System.exit() to indicate that we have a massive problem (that causes the JVM to abort) instead of a smooth installation.






[IZPACK-515] Help Window close button text is not configurable Created: 26/Jan/10  Updated: 17/Feb/10  Resolved: 17/Feb/10

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

Type: Bug Priority: Major
Reporter: Marty Garcia Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


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

 Description   

The help window close button text is not configurable and shares the same ui resource with the installer.prev button.



 Comments   
Comment by Marty Garcia [ 26/Jan/10 ]

I scoured the web on how to submit a patch to izpack but couldn't find one. I'm attaching the patch here, please let me know if this is not the correct process.

Comment by Julien Ponge [ 17/Feb/10 ]

Thanks!





[IZPACK-514] Provide hook for uninstaller to check if any of the installed applications are currently running Created: 19/Jan/10  Updated: 19/Jan/10

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

Type: Improvement Priority: Major
Reporter: Mike Youngstrom 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   

Don't know how possible this is but many isntaller frameworks have some way to check if an application is running and won't uninstall if it is. It would be nice if izpack had some way to do the same.






[IZPACK-513] PasswordKeystoreValidator does not support PKCS12 keystores Created: 07/Jan/10  Updated: 25/Jan/10  Resolved: 25/Jan/10

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

Type: Bug Priority: Major
Reporter: Gabriel Guernik Assignee: Julien Ponge
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   

The PasswordKeystoreValidator has some bugs that cause it to always use "JKS" as the keystore type. Specifically, the following code

keystoreType = params.get("keystoreType");
                if (keystoreFile == null)
                {
                    keystoreType = "JKS";
                    System.out.println("keystoreType parameter null, using default of JKS");
                }
                else if (keystorePassword.equalsIgnoreCase(""))
                {
                    keystoreType = "JKS";
                    System.out.println("keystoreType parameter empty, using default of JKS");
                }

should be changed to

keystoreType = params.get("keystoreType");
                if (keystoreType == null)
                {
                    keystoreType = "JKS";
                    System.out.println("keystoreType parameter null, using default of JKS");
                }
                else if (keystoreType.equalsIgnoreCase(""))
                {
                    keystoreType = "JKS";
                    System.out.println("keystoreType parameter empty, using default of JKS");
                }


 Comments   
Comment by Julien Ponge [ 25/Jan/10 ]

Thanks for the fix.





[IZPACK-512] Avoid using sun.* packages Created: 07/Jan/10  Updated: 04/Aug/10  Resolved: 04/Aug/10

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

Type: Improvement Priority: Major
Reporter: Jochen Hinrichsen Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows, SUN JDK 1.6.16


Attachments: Java Source File Base64.java    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

http://java.sun.com/products/jdk/faq/faq-sun-packages.html



 Comments   
Comment by Julien Ponge [ 08/Jan/10 ]

Ok, so can you confirm that this class works as a drop-in replacement, and that there is no legal issue in including it in our code base?

Comment by Jochen Hinrichsen [ 26/Feb/10 ]

Yes.

Comment by Julien Ponge [ 04/Aug/10 ]

Thanks.





[IZPACK-511] German translations are missing Created: 04/Jan/10  Updated: 25/Jan/10  Resolved: 25/Jan/10

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

Type: Bug Priority: Major
Reporter: Sebastian Pappert Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File deu.xml.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Some translations in bin/langpacks/installer/deu.xml are missing.

Attached is a patch with the missing translations.



 Comments   
Comment by Julien Ponge [ 25/Jan/10 ]

Thanks!





[IZPACK-510] Misspelling in documentation that can be quite confusing Created: 29/Dec/09  Updated: 25/Jan/10  Resolved: 25/Jan/10

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

Type: Task Priority: Minor
Reporter: Zachary Groff Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Website Documentation


Number of attachments : 0

 Description   

Documentation has a misspelling at:
https://izpack.github.io/documentation/installation-files.html#the-installer-requirements-element-installerrequirements

Condition attribute of <installerrequirement> element is misspelled and as such, copy-paste, will result in wierd null pointer exception message in a gui dialog when attempting to run installer. Does not stop installer from building (via ant build task).

Wanted to report this in hopes that others do not have confusion on how to use installer requirements.

Thanks



 Comments   
Comment by Julien Ponge [ 25/Jan/10 ]

Thanks





[IZPACK-509] com.izforge.izpack.util.Console does not close the process when JFrame is closed. Created: 23/Dec/09  Updated: 25/Jan/10  Resolved: 25/Jan/10

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

Type: Bug Priority: Minor
Reporter: Manny Lim Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Attachments: Text File Console.patch.txt    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

When using the com.izforge.izpack.util.Console as a console GUI for a process, closing the console GUI (JFrame) does not stop the process. Any components awaiting the exit status code for the process will wait until the process is stopped, however, the typical user is unable to stop to process as there is no longer a GUI for it.

In our installer, we make use of the ProcessPanel to execute 3rd party executables and scripts. Some scripts require user input, and rather than trying to find a suitable terminal (cmd, xterm, etc) to run the script in, we make use of the ProcessPanel executeclass feature to execute a wrapper class which essentially is a modified version of the com.izforge.izpack.util.Console#main(String[] args) method. During installation, if the console GUI is closed, the process remains running, and the user is stuck on the ProcessPanel unless the user finds another way to stop the process.

I've written a patch that adds a WindowListener to the Console JFrame which kills the process upon window closing event. The patch is sufficient for my requirements, however, I believe the Console class should be re-designed to give developers access to it's swing components to improve it's flexibility.



 Comments   
Comment by Julien Ponge [ 25/Jan/10 ]

Thanks!





[IZPACK-508] execution of executable that contains "(" character fails Created: 21/Dec/09  Updated: 21/Dec/09

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

Type: Bug Priority: Major
Reporter: Laurian Vostinar Assignee: Unassigned
Resolution: Unresolved 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 install path contains "(" character, then I try to execute a bat file (executable) the installation will give an error (that it cannot find the path)






[IZPACK-507] 'compile' crashes with NullPointer (install.xml worked with 4.3.2, but not with 4.3.3) Created: 14/Dec/09  Updated: 15/Dec/09  Resolved: 15/Dec/09

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

Type: Bug Priority: Blocker
Reporter: Raoul S da Silva Curiel Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OpenSuse 11.2 x686


Number of attachments : 0

 Description   

/usr/local/IzPack/bin/compile install.xml -b .

.:: IzPack - Version 4.3.3 ::.

< compiler specifications version: 1.0 >

  • Copyright (c) 2001-2008 Julien Ponge
  • 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 : /home/g4l4xy/installer
-> Kind : standard
-> Compression : default
-> Compr. level: -1
-> IzPack home : /usr/local/IzPack

-> Fatal error :
null
java.lang.NullPointerException
at com.izforge.izpack.adaptator.impl.XMLParser.parseLineNrFromInputSource(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.compiler.CompilerConfig.getXMLTree(Unknown Source)
at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(Unknown Source)
at com.izforge.izpack.compiler.CompilerConfig.main(Unknown Source)
at com.izforge.izpack.compiler.Compiler.main(Unknown Source)



 Comments   
Comment by Julien Ponge [ 14/Dec/09 ]

This one's for you David

Comment by Raoul S da Silva Curiel [ 14/Dec/09 ]

I should add that I didn't change the install.xml script at all that had worked with 4.3.2. I just re-ran the compilation to see if my 'unix shortcut' problem had been fixed, but now it doesn't even generate anything. Can post my install files if necessary, but should be possible to compare the code with the previous version, see what changed, and what could be null...

Comment by David Duponchel [ 15/Dec/09 ]

Julien resolved this issue (a missing xsl file) and updated the online jar. I've just added a meaningful message just in case (the "null" message from the NPE is quite useless...).

Comment by Raoul S da Silva Curiel [ 15/Dec/09 ]

I can confirm this problem no longer exists. Do I close the issue or do you guys control that? I'm happy IZPACK-392 also seems closed. I can now create shortcuts on Linux even if other users exist on the system, which previously (4.3.2) wasn't possible as the system would hang. Great job! We'll forget about uploading over a released version! I also have a day job and a night job and gave up waiting for the fixed version well after midnight as I had to get some sleep before my day job!





[IZPACK-506] IZPack throws exception while creating Windows 7 shortcuts Created: 14/Dec/09  Updated: 24/Jan/10  Resolved: 24/Jan/10

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

Type: Bug Priority: Critical
Reporter: Frank Cohen Assignee: Julien Ponge
Resolution: Not A Bug Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Number of attachments : 0

 Description   

PushToTest TestMaker (http://www.pushtotest.com/products/download) uses IZPack 4.3.2.

The installer throws an exception when it tries to execute the panel to create desktop and Start menu shortcuts. The installer will not continue and users have to manually quit. This only happens when running on Windows 7.

Another user reported this at http://tinyurl.com/y9u7xq9

-Frank



 Comments   
Comment by Attila Magyar [ 24/Jan/10 ]

This happened to me as well. But it seems to me it come forward only on x64, with x64 JVM.

Comment by Attila Magyar [ 24/Jan/10 ]

Use <native type="izpack" name="ShellLink_x64.dll"/> explicitly in the install.xml to make it works.





[IZPACK-505] Installer is showing english with Simplified Chinese and Japanese Created: 14/Dec/09  Updated: 03/Feb/10

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

Type: Bug Priority: Minor
Reporter: JoAnne Applegate Assignee: Kjell Braden
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File 1.jpg     JPEG File 2.jpg    
Number of attachments : 2

 Description   

progress is in english, see attachments.



 Comments   
Comment by JoAnne Applegate [ 14/Dec/09 ]

Here is what we have in the installer.

<locale>
<langpack iso3="eng"/>
<langpack iso3="fra"/>
<langpack iso3="jpn"/>
<langpack iso3="deu"/>
<langpack iso3="kor"/>
<langpack iso3="chn"/>
</locale>

Note: All other languages seem to be working fine. Did we miss a langpack?

Comment by Kjell Braden [ 28/Jan/10 ]

We don't have a translation for the Chinese string. Feel free to provide one if you can.

I can't seem to reproduce the problem with the Japanese language pack. What version of IzPack are you using?

Comment by JoAnne Applegate [ 03/Feb/10 ]

I don't see version any place how can I determine version?

Comment by JoAnne Applegate [ 03/Feb/10 ]

How can I create my own translation? I've just been using product OOTB.

Comment by Kjell Braden [ 03/Feb/10 ]

When compiling your installer, IzPack starts up with a message like

.::  IzPack - Version 4.3.3 ::.

You should be able to add a "CustomLangpack.xml_chn" resource and add your translations in that referenced file. See the IzPack documentation for more details.

Comment by JoAnne Applegate [ 03/Feb/10 ]

I'm using .:: IzPack - Version 4.2.0 ::.

I found that the string in the jpn.xml file doesn't exist so is defauting and the string in chn.xml is not translated;

<str id="InstallPanel.finished" txt="[Íê³É]"/>
<str id="InstallPanel.progress" txt="Overall installation progress :"/>
<str id="InstallPanel.overwrite.title" txt="ÎÄŒþÒÑŸ­ŽæÔÚ"/>

Comment by Kjell Braden [ 03/Feb/10 ]

Yes, that is what I said in comment #1. Can you please try and see if the Japanese works with a recent IzPack version (4.3.3)? Also, can you provide a translation to chinese so we can actually put it in the installer?

Comment by JoAnne Applegate [ 03/Feb/10 ]

downloaded 4.3.3, same results. I've contacted my localization team to see if I can't get them to translate. If I do I will post.





[IZPACK-504] Add a "ShowExistingDirectoryMessage" variable Created: 11/Dec/09  Updated: 11/Dec/09

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

Type: New Feature Priority: Major
Reporter: Patrick Talbot Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Number of attachments : 0

 Description   

There is a "ShowCreateDirectoryMessage" variable which allows to show or not an alert when the target directory chosen in the TargetPanel is not existing.

Similarly, I propose to add a "ShowExistingDirectoryMessage", to allow to show or hide the alert "The directory already exists! Are you sure you want to install here and possibly overwrite existing files?" that might confuse and frighten users when using an IZPack installer to install extensions for an already installed software.

Thanks in advance for adding this variable and behavior.






[IZPACK-503] Add an option to hide or disable the "Force the deletion of ..." checkbox Created: 11/Dec/09  Updated: 11/Dec/09

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

Type: New Feature Priority: Major
Reporter: Patrick Talbot 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   

When using IZPack to install extensions to an existing software, it is problematic to have in the uninstaller the "Force the deletion of ..." checkbox.

An option would be most welcome to hide or at least disable this ckeckbox.

Should be trivial to add but a most important feature for the use of IZPack to install extensions.

Thanks in advance for adding it.






[IZPACK-502] UserPathPanel should support multiple paths Created: 10/Dec/09  Updated: 14/Dec/09  Resolved: 10/Dec/09

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.2
Fix Version/s: 4.3.3

Type: Improvement Priority: Major
Reporter: Gregor B. Rosenauer 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   

From what I've gathered so far, the UserPathPanel only supports a single path entry box, which is imho a waste of screen space and user's time if multiple paths are needed.

E.g. most applications have a home directory, a data directory, a temp directory, etc.
So closely related paths should be gathered in one place from the user.

I am aware that I could create a custom panel for this or (mis)use the UserInputPanel, but for such a common use case there should be a standard panel provided by izPack, also considering the fact that there already is a UserPathPanel, albeit a bit limited.

The UserPathPanelVariable should consequently be transformed into an array, referenced by Path names.

What do you think? I'd really love to see this in izPack, but maybe I'm the only one or missing something,-)



 Comments   
Comment by Julien Ponge [ 10/Dec/09 ]

This is already possible using UserInputPanel, see https://izpack.github.io/documentation/user-input.html#directory-field

Please see on the user list for potential complements.

Cheers

Comment by Gregor B. Rosenauer [ 11/Dec/09 ]

Oh thanks, I mentioned the UserInputPanel as a workaround I wanted to avoid, but I was not aware of the directory-field feature, so you are right, not necessary to add this feature to the UserPathPanel, which is however a bit under-featured in comparison...,-)





[IZPACK-501] On unix corporate install (with 30000 users), izpack hangs forever Created: 09/Dec/09  Updated: 14/Dec/09  Resolved: 14/Dec/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.2
Fix Version/s: 4.3.3, 5.0

Type: Bug Priority: Blocker
Reporter: ludovic Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

opensolaris 2009.06 connected to the Sun internal network with a Sun regular user login, not a local user


Attachments: Text File IZPACK-501.patch    
Issue Links:
Related
is related to IZPACK-392 installer hangs when ShortcutPanel is... Resolved
Number of attachments : 1

 Description   

On unix corporate install (with 30000 users), izpack hangs forever.

Doing a dump of the threads, we see:

"AWT-EventQueue-0" prio=3 tid=0x08b7b400 nid=0x12 runnable [0xb138d000..0xb138eb60]
java.lang.Thread.State: RUNNABLE
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)
at java.io.File.exists(File.java:733)
at
com.izforge.izpack.util.os.unix.UnixUsers.getUsersWithValidShellsAndExistingHomes(Unknown
Source)
at
com.izforge.izpack.util.os.unix.UnixUsers._getUsersWithValidShellsExistingHomesAndDesktops(Unknown
Source)
at
com.izforge.izpack.util.os.unix.UnixUsers.getUsersWithValidShellsExistingHomesAndDesktops(Unknown
Source)
at com.izforge.izpack.util.os.Unix_Shortcut.<clinit>(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at com.izforge.izpack.util.TargetFactory.makeObject(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.panelActivate(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(Unknown Source)
...

which is on the AWT thread and is taking forever.

Not sure why we need to get this list of all users to do a local installation of a product using ispack. It definitely does not scale and block AWT UI.
See https://glassfishplugins.dev.java.net/issues/show_bug.cgi?id=282



 Comments   
Comment by Julien Ponge [ 10/Dec/09 ]

Thanks for reporting it, we are investigating this.

One small note of the GF bug report: yes the code is ugly there, but please keep in mind that nobody's paid for developing IzPack... we are not funded.

Comment by Julien Ponge [ 10/Dec/09 ]

This is a first patch to solve the issue, thanks for reviews.

Unfortunately, I do not have a machine with 30000 accounts to test...

Here is what the change does:

  • The Unix users lookup is made lazily (previously in the constructor).
  • Navigation between panels is now made asynchronously in a separate thread which:
    • blocks the GUI on the EDT
    • performs the work on the created thread
    • releases the GUI on the EDT.

The outcome is that the Swing/AWT thread should not be freezed anymore when swiching panels. It should be "blocked" through the glass pane and the mouse icon showing heavy work in progress.

Comment by ludovic [ 10/Dec/09 ]

Sorry for my bad comment: we selected izpack for a good reason: simple and we like it! over the competition.
It was more about the logic than the code in this corner case.
We'll try the patch, but I would like to understand if this query will still happen. Not sure we need to list all the users of a system in order to install a product for 1 single user. In our case, (Sun, the time to finally get this list can be close to infinity (i.e hours possbly

And thanks also for jumping on a fix. We do have a temp workaround (deliver a tarball as well), and if a fix is available before next monday, we may integrate it for a release on Dec 17 of the tools bundle.

Comment by Julien Ponge [ 10/Dec/09 ]

The fix is in progress on our side.

The GUI should not be blocked anymore, and the mouse cursor indicates that work is in progress.

The lookup happens when you want to create Freedesktop.Org (Gnome/KDE/XFCE) shortcuts on Unix for all users, which I suspect is checked by default in your case when the panel shows up. The code needs to actually look up the accounts and see which ones are legit user accounts.

In short: the first patch that we have will make the application look busy instead of locked, but at some point you will have a 30000 accounts lookup.

Given that your case is actually an extreme one, you may also:

BTW do you need shortcuts at all for deploying the GF Eclipse bundles?

Cheers

Comment by Julien Ponge [ 10/Dec/09 ]

Ok, so we can have a release next monday (French timezone).

Is that ok with you Ludovic?

Otherwise I can give you a patched version, say, sunday.

Cheers

Comment by ludovic [ 10/Dec/09 ]

Great!!

send me the patched version as soon as you want, and we'll test (possibly on monday morning PST).

Comment by ludovic [ 10/Dec/09 ]

Currently, even if we add <defaultCurrentUser/> in the shorcut xml def, the call to get all users is done.
Can you confirm that your patch will never do this call if we add <defaultCurrentUser/>

?

Comment by Julien Ponge [ 11/Dec/09 ]

I could not test it on a Unix box, but it should not be called.

Can you please test with a snapshot build of IzPack? http://snapshots.dist.codehaus.org/izpack/izpack-snapshot-IZPACK-501-install.jar

Thanks a lot

Comment by ludovic [ 11/Dec/09 ]

the installer fails on mac with error executing
/bin/chmod a+x ........./utils/wrappers/izpack2app/Mac-App-Template/Content/MacOS/JavaApplicationStub

Comment by Julien Ponge [ 14/Dec/09 ]

The fix does not block the GUI anymore.

Comment by ludovic [ 14/Dec/09 ]

And the izpack installer on mac issue is fixed as well?

Comment by Julien Ponge [ 14/Dec/09 ]

It is not an issue, just that I built from a Git checkout and some files where missing.

I'll post a link to the released installer to https://glassfishplugins.dev.java.net/issues/show_bug.cgi?id=282 as a comment.





[IZPACK-500] Debug class references Installer class, but Installer class is not included in uninstaller.jar Created: 07/Dec/09  Updated: 14/Dec/09  Resolved: 07/Dec/09

Status: Closed
Project: IzPack
Component/s: Uninstaller
Affects Version/s: 4.2.0, 4.2.1, 4.3.0, 4.3.1, 4.3.2
Fix Version/s: 4.3.3, 5.0

Type: Bug Priority: Minor
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Every call to Debug methods can cause ClassNotFound Exceptions because the static init code references the Installer class which is not included in the uninstaller.jar



 Comments   
Comment by Florian Buehlmann [ 07/Dec/09 ]

The Installer class is no longer referenced to avoid ClassNotFound exceptions.





[IZPACK-499] Cannot create shortcuts for all users on RHEL 5.3 Created: 04/Dec/09  Updated: 04/Dec/09  Resolved: 04/Dec/09

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

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

RHEL 5.3


Number of attachments : 0

 Description   

I run the installer as root and I get to the panel for creating shortcuts. I select "all users", but it does not work. The menu entry get created correctly and placed into /etc/xdg/menus/applications-merged, but the desktop file does not get placed into /usr/share/applications. It instead gets placed into /root/.local/share/applications.



 Comments   
Comment by James Chamberlain [ 04/Dec/09 ]

I did not see that createForAll is defaulted to false for the Unix spec file. Adding an entry and setting it to true made it work just fine.





[IZPACK-498] Multi-file validation bug Created: 03/Dec/09  Updated: 14/Dec/09  Resolved: 03/Dec/09

Status: Closed
Project: IzPack
Component/s: None
Affects Version/s: 4.3.2
Fix Version/s: 4.3.3, 5.0

Type: Bug Priority: Major
Reporter: Julien Ponge Assignee: Julien Ponge
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   

Reported by Bram Van Dam on the user list, along with a patch:

Index: lib/com/izforge/izpack/panels/MultipleFileInputField.java
===================================================================
--- lib/com/izforge/izpack/panels/MultipleFileInputField.java   (revision 2876)
+++ lib/com/izforge/izpack/panels/MultipleFileInputField.java   (working copy)
@@ -243,7 +243,11 @@
    public boolean validateField(){
        boolean result = false;
        int fileCount = model.getSize();
-
+
+        if (fileCount == 0 && allowEmpty){
+            result = true;
+        }
+
        for (int i=0; i < fileCount; i++){
            result = validateFile((String) model.getElementAt(i));
            if (!result){


 Comments   
Comment by Julien Ponge [ 03/Dec/09 ]

Fixed.





[IZPACK-497] Installer should switch to console mode automatically when no GUI environment is available Created: 26/Nov/09  Updated: 21/Mar/12  Resolved: 21/Mar/12

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

Type: Improvement Priority: Major
Reporter: Andreas Kohn 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   

Currently it is required to remember that console mode installations need the '-console' switch, and installation attempts in headless environments will fail with a Java exception if that switch is not given.

It would be great if the installer could fall-back to console mode automatically (maybe only if configured in install.xml to not break compatibility with installers that are not intended for console mode), so that users only have to remember 'java -jar installer.jar'.



 Comments   
Comment by Dustin Kut Moy Cheung [ 20/Mar/12 ]

I think this is already fixed in the branch. Should be marked as Resolved.





[IZPACK-496] Confusing Headline "User Data" on UserInputPanels Created: 26/Nov/09  Updated: 30/Nov/09  Resolved: 30/Nov/09

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

Type: Improvement Priority: Major
Reporter: Rolf Watermann Assignee: Julien Ponge
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   

All UserInputPanels show a common headline "User Data" which is quite large compared to the title field. This confuses our users, they associate esp. the German localization "Benutzerdaten" with personal data like name, address, phone.

Maybe you could render "User Data" a little less obtrusive or enhance the <panel> tag with an id attribute to customize the headline.



 Comments   
Comment by Rolf Watermann [ 30/Nov/09 ]

Found the solution in

https://izpack.github.io/documentation/advanced-features.html#using-a-separated-heading-panel

However, please

Comment by Julien Ponge [ 30/Nov/09 ]

Thanks for your feedback.





[IZPACK-495] Annoying popups from file field Created: 18/Nov/09  Updated: 07/Sep/11

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

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

Ubuntu 8.04 / jdk 1.6.0_11


Number of attachments : 0

 Description   

Declare a UserInputPanel with a combobox and a file field:

  <panel order="3">
    <field type="combo" variable="iz.database.name">
      <spec id="database.vendor">
        <choice txt="PostgreSQL" value="postgresql" set="true" />
        <choice txt="MySQL" value="mysql" />
        <choice txt="Oracle" value="oracle" />
      </spec>
    </field>
    <field type="file" align="left" variable="iz.database.driver.jar">
      <spec size="20" id="database.driver.jar" mustExist="false" fileext="jar" fileextdesc="Jar file (*.jar)"/>
    </field>
  </panel>

If you operate the combobox before you have chosen a file, a message pops up twice: "The file you have chosen either does not exist or is not valid."



 Comments   
Comment by Piotr Skowronek [ 24/Feb/10 ]

I can confirm the issue. It seems that changing state of a combo causes panel to be refreshed/repainted, hence the annoying pop up. Someone should clarify what's the idea behind refreshing panel by combos (ie is it by design or not). I can imagine that it can be used to accomplish better dynamism - states of other controls can be changed upon combo's selection (though, I haven't tested that). However, clicking on checkbox doesn't seem to refresh/repaint the panel.

Comment by Piotr Skowronek [ 23/Mar/10 ]

Can anyone confirm whether this behavior regarding refresh is by design?





[IZPACK-494] Console Installer does not create a complete Uninstaller jar Created: 12/Nov/09  Updated: 03/Dec/09  Resolved: 03/Dec/09

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

Type: Bug Priority: Major
Reporter: Dustin Hawkins Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Console Install


Attachments: Java Source File ConsoleInstaller.java    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

When running a Linux based console installer similar to the following:

java -jar install.jar -console

The resulting Uninstaller jar file is not complete.

Added the method writeUninstallData to ConsoleInstaller.java, and it now creates the uninstaller properly.

An additional note for the documentation, if i have line like:
<run-privileged condition="izpack.windowsinstall.vista|izpack.windowsinstall.7"/>
In a linux based installer, running:
java -jar Uninstaller.jar -c
Will result in an error surrounding privilege elevation and a headless install. To solve that issue, i removed the <run-privileged line from my Linux izpack installer XML file.






[IZPACK-493] Installation from template and template generation cannot be run headless Created: 12/Nov/09  Updated: 14/Dec/09  Resolved: 03/Dec/09

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

Type: Bug Priority: Major
Reporter: Andreas Kohn Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File izpack-installer-headless-templates.diff    
Number of attachments : 1

 Description   

IZPACK-368 introduce a refactoring in the Installer class that created a regression for installations using '-options' and '-options-template': with izpack 4.3.1 those could done in headless environments, with 4.3.2 these require a UI.

Attached a fix (against head of git, for 4.3.2 the patch needs minimal adjustments) for this that enforces the console installer for those.



 Comments   
Comment by Julien Ponge [ 03/Dec/09 ]

Fixed, but with a different patch (yours did not apply).





[IZPACK-492] "Condition already registered." messages Created: 12/Nov/09  Updated: 12/Nov/09

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

Type: Bug Priority: Major
Reporter: Rolf Watermann 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 click the "previous" and "next" buttons on a UserInputPanel the installer prints lots of messages

Condition already registered.

to stdout. I think it is one message per widget. The same messages occur when you select something in a combo field.






[IZPACK-491] Optional file selection Created: 12/Nov/09  Updated: 12/Nov/09

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

Type: Wish Priority: Major
Reporter: Rolf Watermann 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 a file field on a UserInputPanel, the user cannot proceed to the next panel w/o choosing a file. Please provide a flag to make this optional and allows the user to leave the field empty.






[IZPACK-490] Created ProcessPanelConsoleHelper.java Created: 11/Nov/09  Updated: 25/Jan/10  Resolved: 25/Jan/10

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

Type: Improvement Priority: Major
Reporter: Dustin Hawkins Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested in Linux


Attachments: Java Source File ProcessPanelConsoleHelper.java    
Number of attachments : 1

 Description   

I was in dire need of a ProcessPanel console helper for a linux headless installer, so I copied another console helper, and ripped out some of the contents of the Automated Helper.

Its by no means pretty, but it works for our Console installs.



 Comments   
Comment by Julien Ponge [ 25/Jan/10 ]

Thanks!





[IZPACK-489] Add setting a variable $INSTALL_DRIVE with the target drive letter for Windows systems Created: 11/Nov/09  Updated: 14/Dec/09  Resolved: 14/Dec/09

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

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

Attachments: Text File izpack_drive_letter_patch.txt    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

I have the requirement to get the driver letter part of a Windows installation path for customization purposes. I added a pre-tested and documented patch for the current IzPack trunk.



 Comments   
Comment by Julien Ponge [ 14/Dec/09 ]

Thanks!





[IZPACK-488] Variables are not resolved nested include and exclude elements of filesets Created: 11/Nov/09  Updated: 07/Dec/10  Resolved: 07/Dec/10

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

There is a fileset in my install.xml with include and exclude clauses with variables.

<variables>
<variable name="INSTALL_SUBPATH" value="deploy"/>
...
</variables>

<fileset dir="plain" targetdir="$

{INSTALL_PATH}

" override="true">
<include name="$

{INSTALL_SUBPATH}/bin/*"/>
<exclude name="${INSTALL_SUBPATH}

/etc/*"/>
...
</fileset>

I wished to resolve IzPack variables in that include and exclude element values, which doesn't work at the moment.






[IZPACK-487] Processor for field should be available for all the field types Created: 11/Nov/09  Updated: 18/Oct/13  Resolved: 09/Jul/13

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

Type: Improvement Priority: Major
Reporter: Shrirang Assignee: Dennis Reil
Resolution: Fixed Votes: 1
Labels: 5.0.0-rc1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ProcessorDirFieldNew.patch     Text File ProcessorDirField.patch    
Number of attachments : 2

 Description   

Processor for field should be available for all the field types.
Using Processor for File field in UserInputPanel
While we are writing a installer for our product, we need to capture a file name and replace the fully qualified file name into one of the properties files. Before that we need to modify the fileName (for windows) and replace single '\' with '
'. We are using userInputPanel with File fields to let the user select the file and processor sounded most logical place to manipulate the fileName.
I feel the processor should be available for all the field types by default.



 Comments   
Comment by Shrirang [ 11/Nov/09 ]

This is a fix for DirInputField. It will also work for FileInputField. System.out has been added at some places since debug is off.

Comment by Shrirang [ 12/Nov/09 ]

This fix is without the System.out.

Comment by Shrirang [ 15/Dec/09 ]

By when can we expect this fix ?

Comment by Tim Anderson [ 18/Jul/12 ]

This JIRA has a Fix Version of 5.0, but unfortunately the codebase has moved on significantly since the JIRA was raised and the patch no longer applies.
If you want to resubmit against the current codebase, see the instructions at https://izpack.github.io/developers/

Comment by Nicholas Albion [ 05/Jul/13 ]

I have the same requirement and am using izpack-maven-plugin 5.0.0-rc1-SNAPSHOT.

I stumbled across the FieldProcessor class and see that Field has a "processor" instance which is provided by the FieldConfig instance in the constructor.

I see that there is a PortProcessor, but will have to experiment with it to get it working because I can't find any documentation or examples on how it would be used.

@Shirang, could you share the source code of your PathProcessor?

Comment by Nicholas Albion [ 09/Jul/13 ]

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

Comment by Rene Krell [ 09/Jul/13 ]

Thank you for the contribution.





[IZPACK-486] Links on HTMLInfoPanel cause NPE Created: 10/Nov/09  Updated: 04/Dec/10

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

Type: Bug Priority: Major
Reporter: Rolf Watermann Assignee: Emmanuel Hugonnet
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 8.04, jdk 1.6.0_11


Number of attachments : 0

 Description   

Clicking a link on a HTMLInfoPanel causes an NPE:

java.lang.NullPointerException
  at com.izforge.izpack.util.HyperlinkHandler.hyperlinkUpdate(Unknown Source)
  at javax.swing.JEditorPane.fireHyperlinkUpdate(JEditorPane.java:327)
  at javax.swing.text.html.HTMLEditorKit$LinkController.activateLink(HTMLEditorKit.java:828)
  at javax.swing.text.html.HTMLEditorKit$LinkController.mouseClicked(HTMLEditorKit.java:638)
  at java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:253)


 Comments   
Comment by Emmanuel Hugonnet [ 04/Dec/10 ]

Could not reproduce the problem in izpack 5.0-beta4 on Ubuntu 10.10 Java6.0_22 64 bits. The link is correctly displayed and clicking on it opens my default browser.





[IZPACK-485] Variable substitution in HTMLInfoPanel broken Created: 10/Nov/09  Updated: 10/Nov/09

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

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

Ubuntu 8.04, jdk 1.6.0_11


Number of attachments : 0

 Description   

Variables in the HTMLInfoPanel are substituted with their initial values instead of considering user input. Using dynamic variables makes things even worse: some are not substituted at all.

How to reproduce:

install.xml:

<dynamicvariables>
  <variable name="iz.install.host" value="localhost"/>
  <variable name="iz.preview.http.port" value="8001"/>
</dynamicvariables>

Panel resource:

<html>
...
<a href="http://${iz.install.host}:${iz.preview.http.port}/dashboard">http://${iz.install.host}:${iz.preview.http.port}/dashboard</a>
...
</html>

User interaction:
iz.install.host is set to "myserver"
iz.preview.http.port is set to "9001"

Panel:

http://localhost:${iz.preview.http.port}/dashboard





[IZPACK-484] Regression: Process Panel jobs not executing with installers generated via IzPack release 4.3.2 Created: 10/Nov/09  Updated: 25/Jan/10

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

Type: Bug Priority: Major
Reporter: Charles Leu Assignee: David Duponchel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP w/SP2 and CentOS 5.2 with kernel 2.6.18-128.4.1.el5


Attachments: XML File AgentConfigProcesses.xml     File changes-4.3.1-to-4.3.2.diff.bz2     Text File install-trace-4.3.1.log     Text File install-trace-4.3.2.log     XML File izpack-installer-definition.xml    
Number of attachments : 5

 Description   

Notes:
1) Upgraded from IzPack 4.3.1 to IzPack 4.3.2 and newly generated installers (via IzPack 4.3.2) for Linux and Windows now don't execute their Process Panel jobs (as they did without ado using IzPack 4.3.1 build installers).
2) Attached are trace logs for 4.3.1 and 4.3.2 installations; they're virtually identical, hence probably worthless for diagnostic purposes. Also attached is the base installer definition file.
3) Please advise as to what additional information is desired, as well as the means by which such information should be



 Comments   
Comment by Charles Leu [ 10/Nov/09 ]

Additional Notes/Corrections:
1) Windows XP Professional version 2002 Service Pack 3 (Version 5.1.2600)
2) Please advise as to what additional information is desired to aid diagnostics and the means by which such information should be obtained.

Comment by Charles Leu [ 10/Nov/09 ]

XML for Process Panel included (Skeleton/Test version) that yields the problem.

Comment by Julien Ponge [ 10/Nov/09 ]

Strange as the process execution classes haven't changed since last february:

I will try to look at the whole differences between 4.3.1 and 4.3.2 and see wether I see something obvious.

BTW in your installer definition, you should bump the required Java version to 1.5, as IzPack does not run on 1.3 (for a long long time). Also, there are now pre-built OS identification conditions which you could use instead of the ones you declare (see the docs).

More to follow soon.

Comment by Julien Ponge [ 10/Nov/09 ]

Allright so these are the complete changes between the 2 versions.

I carefully went through the changes and could not spot anything that would cause the process panels job to fail (and I tested on a project that uses ProcessPanel).

You can maybe:

  1. look at potential changes on your own project between the previous installer you had and now, and
  2. look at the changes and see if you can see anything wrong there too.
Comment by Charles Leu [ 11/Nov/09 ]
  • OK, I'll review the delta between 4.3.1 and 4.3.2
  • Will also re-install 4.3.2 in a 'jailed' location and re-build/test in that location.
Comment by Charles Leu [ 19/Nov/09 ]

Notes:

  • OK, I finally had cycles to reinstall and perform some additional quick tests. The problem appears related to conditions.
  • This particular problem is related to the
    <os family="windows"> ... </os>

    restriction within the Process panel XML; when present the executefile target doesn't get executed; when

    <os family="windows"> ... </os>

    is removed the executefile target does get executed (note that the target system is windows as described per Environment above).

  • Still have yet to review the delta between 4.3.1 and 4.3.2; perhaps I can do so tonight. That's all for now.
Comment by Charles Leu [ 19/Nov/09 ]
  • The issue is one of XML parsing; this issue is easily resolved by adjusting the process panel XML.
  • Previously the process panel contained:
    <os family="windows"> ... </os>

    and with 4.3.1 it parsed OK and worked. When changed to:

    <os family="windows"/>

    it parses OK and works with 4.3.2.

  • The IzPack ant task was used to generate the installer. With the -v (i.e. verbose) ant option nothing was emitted from the build task. Shouldn't there have been a message emitted by the build process indicating that the process panel XML was considered invalid?
Comment by Julien Ponge [ 25/Jan/10 ]

I think David is the right person for handling this.

Comment by David Duponchel [ 25/Jan/10 ]

This issue comes from IZPACK-364. In the 4.3.1 version, a job used all its children named "executefile" (including those in an <os> tag). With the corrections from IZPACK-364, only the direct children are used (those in <os> are ignored). As a result, the AgentConfigProcesses.xml file of Charles defined empty jobs for IzPack 4.3.2. I've commited a debug statement when a job is considered empty (commit 2932), but I think the real solution would be to force a validation against a DTD.





[IZPACK-483] The packs should be able to delete certain files after installation is over. Created: 07/Nov/09  Updated: 19/Jul/10  Resolved: 23/Jun/10

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

Type: Improvement Priority: Major
Reporter: Shrirang Assignee: Julien Ponge
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File temp-dir-4.3.3.diff     Text File temp-directory-IZPACK-483.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

The packs should be able to delete certain files after installation is over. These are normally files that are parsed and copied to certain locations.
For e.g.
1. I need to execute a sql script in the process panel.
2. I copy the file to install directory through packs panel
3. I execute the sql script file through the process panel
4. Now i do not need the sql script any more lying in my install directory.



 Comments   
Comment by Sean O'Loughlin [ 07/Jun/10 ]

temp-dir-4.3.3.diff is a patch against the 4.3.3 git source to add support for a temp directory which is deleted after install.

Comment by Sean O'Loughlin [ 07/Jun/10 ]

temp-directory-IZPACK-483.patch is an improved version of the same code against more current code, but hasn't been tested due to issues building the latest source from git.

Comment by Julien Ponge [ 23/Jun/10 ]

The patches do not apply.

Comment by Sean O'Loughlin [ 05/Jul/10 ]

The patches add a temp directory, this solves the problem described in the description because it would allow the following steps:

1. Copy the file to the temp directory through packs panel
2. Execute the sql script file through the process panel (or any other mechanism)
3. The script is deleted when the installer exits.

It doesn't enable the deletion of, for example, some of the files installed by a third party installer so it doesn't solve all potential file deletion problems. It should solve the problem outlined in the description of this issue though.

Comment by Julien Ponge [ 19/Jul/10 ]

Sorry, but I have to close the issue as the patches don't apply.





[IZPACK-482] Shortcuts for directories containing spaces ("Simple Program") dont work on Ubuntu Created: 07/Nov/09  Updated: 25/Jan/10  Resolved: 25/Jan/10

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

Type: Bug Priority: Minor
Reporter: Miron Sadziak Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux


Attachments: Java Source File Unix_Shortcut.java     Text File unix_shortcut_svn_patch.txt    
Number of attachments : 2

 Description   

When use some installer created with IzPack on Ubuntu, specify the installation directory containing spaces (i.e. /home/user/Simple Program) and let the installer create a shortcut for any program in that directory, the created shortcut won't work.
Trying to lunch it will result in "Could not move to directory ...." error.
See for example isse https://sourceforge.net/tracker/?func=detail&aid=2862145&group_id=28383&atid=393414 of SQuirreL SQL.
Problem is the .desktop file being created. Name of the directory containing spaces gets surrounded there with apostrophes, which is probably wrong behavior.



 Comments   
Comment by Miron Sadziak [ 07/Nov/09 ]

As far as I understand format of .desktop files ( http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html ), the Exec= element needs to be surrounded by double quotes because it is passed to the terminal where it would cause an error if it contained spaces (/home/user/Simple Program/run.sh would result in running only /home/user/Simple). But Path= element does not need double quotes because it is just a property describing a directory.

Hence, here is a patch that solves the issue. It basically comments out lines 1213 to 1219 in file Unix_Shortcut.java leaving a small comment. Im attaching the file itself and the patch which should be applied on izpack-src/trunk.

I may be wrong, so check me, but If everybody agrees that Path= element really does not need qoutes, then that code and also a few other places in the fore-mentioned file (using $P_QUOT) should be removed.

Comment by Julien Ponge [ 25/Jan/10 ]

Thanks for the update.





[IZPACK-481] UserInputPanel's Text/Password fields get cut off Created: 06/Nov/09  Updated: 27/Aug/12  Resolved: 27/Aug/12

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

Type: Bug Priority: Major
Reporter: Brian Shim Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Fedora 10 i386
Java 1.5
Resolution 1680x1050


Attachments: XML File install.xml     PNG File UserInputPanel-5.0.png     PNG File UserInputPanel-cutoff.png     XML File userInputSpec.xml    
Number of attachments : 4

 Description   

UserInputPanel has text/password fields can get cut-off depending on the length of their corresponding label string. This is significant when dealing with localization of strings as they can vary in size.

I suggest setting the TwoColumnConstraints stretch value to true for addTextField(...), addPasswordField(...) for the component on the East. This appears to work for the password field, but not the text.



 Comments   
Comment by Tim Anderson [ 27/Aug/12 ]

Corresponding screenshot using IzPack 5.0.0-beta11-SNAPSHOT

Comment by Tim Anderson [ 27/Aug/12 ]

Appears to be fixed in 5.0. See UserInputPanel-5.0.png for its layout in 5.0.0-beta11-SNAPSHOT





[IZPACK-480] Console Install option does not invoke Process Panels Created: 06/Nov/09  Updated: 29/Apr/11  Resolved: 18/Dec/10

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.2
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Major
Reporter: Derek Townsend Assignee: Julien Ponge
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux OS with Java 1.6 build 16


Number of attachments : 0

 Description   

When running the installer in console mode it skips over the Processes defined in the ProcessPanel.
Complex Installers with any custom processing can not be used in console mode.



 Comments   
Comment by Mark Miller [ 15/Dec/10 ]

I have something of a fix for this here: https://github.com/lucidimagination/izpack/commit/f992582039c5a0dfbfaaee27c8b6002c601eb15f

The ProcessPanel needed a ProcessPanelConsoleHelper - very similar to ProcessPanelAutomationHelper.





[IZPACK-479] Missing classes in release 4.3.1 Created: 06/Nov/09  Updated: 26/Jan/10  Resolved: 26/Jan/10

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2, 4.3.3, 5.0

Type: Bug Priority: Blocker
Reporter: Mitchel 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   

Lots of classes are missing in IzPack-install-4.3.1.jar (both in official site: https://izpack.github.io/downloads/ or maven repository: http://repo1.maven.org/maven2/org/codehaus/izpack/izpack-standalone-compiler/4.3.1/).

For axample, if you compare the panels source code (http://svn.codehaus.org/izpack/izpack-src/tags/4.3.1/src/lib/com/izforge/izpack/panels/) and the panels classes inside official jar files, you can see that some classes like com.izforge.izpack.panels.Processor are missing.

This is a blocker issue since we can't use these classes to develop custom components. For example, it's not possible to create custom Processor classes to set default value inside UserInputPanel (userInputSpec.xml):
<userInput>
<panel order="0">
<field ...
<spec txt="Enter IP address of $

{application.server.name}

:"
layout="N:3:3 . N:3:3 . N:3:3 . N:3:3"
set="0:defaultVal:ServerIpProcessor 1:defaultVal:ServerIpProcessor 2:defaultVal:ServerIpProcessor 3:defaultVal:ServerIpProcessor"
resultFormat="displayFormat" />
...

This is one of the examples...



 Comments   
Comment by Julien Ponge [ 06/Nov/09 ]

Fixed in IzPack 4.3.2 (to be released today).

infinity:src jponge$ unzip -t ../bin/panels/UserInputPanel.jar
Archive:  ../bin/panels/UserInputPanel.jar
    testing: META-INF/                OK
    testing: META-INF/MANIFEST.MF     OK
    testing: com/                     OK
    testing: com/izforge/             OK
    testing: com/izforge/izpack/      OK
    testing: com/izforge/izpack/panels/   OK
    testing: com/izforge/izpack/panels/DirInputField.class   OK
    testing: com/izforge/izpack/panels/FileInputField.class   OK
    testing: com/izforge/izpack/panels/MultipleFileInputField.class   OK
    testing: com/izforge/izpack/panels/PasswordGroup.class   OK
    testing: com/izforge/izpack/panels/PasswordUIElement.class   OK
    testing: com/izforge/izpack/panels/ProcessingClient.class   OK
    testing: com/izforge/izpack/panels/Processor.class   OK
    testing: com/izforge/izpack/panels/RadioButtonUIElement.class   OK
    testing: com/izforge/izpack/panels/RuleInputField$FieldSpec.class   OK
    testing: com/izforge/izpack/panels/RuleInputField.class   OK
    testing: com/izforge/izpack/panels/RuleTextField$Rule.class   OK
    testing: com/izforge/izpack/panels/RuleTextField.class   OK
    testing: com/izforge/izpack/panels/StringInputProcessingClient.class   OK
    testing: com/izforge/izpack/panels/TextInputField.class   OK
    testing: com/izforge/izpack/panels/UIElement.class   OK
    testing: com/izforge/izpack/panels/UIElementType.class   OK
    testing: com/izforge/izpack/panels/UserInputFileFilter.class   OK
    testing: com/izforge/izpack/panels/UserInputPanel$SearchField$1.class   OK
    testing: com/izforge/izpack/panels/UserInputPanel$SearchField.class   OK
    testing: com/izforge/izpack/panels/UserInputPanel$TextValuePair.class   OK
    testing: com/izforge/izpack/panels/UserInputPanel.class   OK
    testing: com/izforge/izpack/panels/UserInputPanelAutomationHelper.class   OK
    testing: com/izforge/izpack/panels/UserInputPanelConsoleHelper$Choice.class   OK
    testing: com/izforge/izpack/panels/UserInputPanelConsoleHelper$Input.class   OK
    testing: com/izforge/izpack/panels/UserInputPanelConsoleHelper$Password.class   OK
    testing: com/izforge/izpack/panels/UserInputPanelConsoleHelper.class   OK
    testing: com/izforge/izpack/panels/Validator.class   OK
    testing: com/izforge/izpack/panels/ValidatorContainer.class   OK
No errors detected in compressed data of ../bin/panels/UserInputPanel.jar.
Comment by Julien Ponge [ 14/Nov/09 ]

The classes need to be added to the standalone compiler JAR.

Comment by Julien Ponge [ 16/Nov/09 ]

The standalone compiler will now have all IzPack classes.

The fix will appear soon in another maintenance release (4.3.3).

Comment by Mitchel [ 11/Jan/10 ]

Same issue appears with 4.3.3 release

Comment by Julien Ponge [ 25/Jan/10 ]

I checked 4.3.3 and the processor / validator classes are in:

infinity:src jponge$ unzip -t ../_dist/IzPack-install-4.3.3.jar  | grep Validator
    testing: com/izforge/izpack/installer/DataValidator$Status.class   OK
    testing: com/izforge/izpack/installer/DataValidator.class   OK
    testing: com/izforge/izpack/installer/DataValidatorFactory.class   OK
    testing: com/izforge/izpack/installer/PackValidator.class   OK
    testing: com/izforge/izpack/panels/Validator.class   OK
    testing: com/izforge/izpack/panels/ValidatorContainer.class   OK
    testing: com/izforge/izpack/util/HostAddressValidator.class   OK
    testing: com/izforge/izpack/util/IsPortValidator.class   OK
    testing: com/izforge/izpack/util/NotEmptyValidator.class   OK
    testing: com/izforge/izpack/util/PasswordEncryptionValidator.class   OK
    testing: com/izforge/izpack/util/PasswordEqualityValidator.class   OK
    testing: com/izforge/izpack/util/PasswordKeystoreValidator.class   OK
    testing: com/izforge/izpack/util/PortValidator.class   OK
    testing: com/izforge/izpack/util/RegularExpressionValidator.class   OK
infinity:src jponge$ unzip -t ../_dist/IzPack-install-4.3.3.jar  | grep Processor
    testing: com/izforge/izpack/util/PortProcessor.class   OK
    testing: com/izforge/izpack/util/SummaryProcessor.class   OK
    testing: com/izforge/izpack/util/UnixGroupProcessor.class   OK
    testing: com/izforge/izpack/util/UnixUserProcessor.class   OK

Unless you mention which classes are missing, I will close the issue again.

Comment by Mitchel [ 25/Jan/10 ]

As mentionned at the beginning, Processor interface IS in the source repository (http://svn.codehaus.org/izpack/izpack-src/tags/4.3.3/src/lib/com/izforge/izpack/panels/) but NOT in the jar file, as you can see from your unzip command.

Also, as Dan mentionned before in this thread, I'm using izpack-maven-plugin which requires every thing in the standalone compiler. For the last 4.3.3 release, I can't find the good repository (http://repo1.maven.org/maven2/org/codehaus/izpack/izpack-standalone-compiler/ is not updated).

Comment by Julien Ponge [ 25/Jan/10 ]

My bad. I see now.

Comment by Julien Ponge [ 25/Jan/10 ]

Fixed.

Comment by Mitchel [ 26/Jan/10 ]

Processor interface still not in the jar:

unzip -t IzPack-install-4.3.3.jar | grep Processor
    testing: com/izforge/izpack/util/PortProcessor.class   OK
    testing: com/izforge/izpack/util/SummaryProcessor.class   OK
    testing: com/izforge/izpack/util/UnixGroupProcessor.class   OK
    testing: com/izforge/izpack/util/UnixUserProcessor.class   OK
Comment by Julien Ponge [ 26/Jan/10 ]

Of course, this will appear only in the next release.

You can still grab the SVN trunk and build an installer as an emergency fix.





[IZPACK-478] com.izforge.izpack.util.Log custom messages are not formatted correctly. Created: 04/Nov/09  Updated: 06/Nov/09  Resolved: 06/Nov/09

Status: Closed
Project: IzPack
Component/s: Utilities
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2

Type: Bug Priority: Minor
Reporter: Manny Lim Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any


Attachments: Text File patch.txt    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

In the buildMessage/Warning/Error/Debug(int index) methods, the variables array is incorrectly passed to the MessageFormat.format(String pattern, Object... arguments) method as an element of an Object[] array. It should be passed directly to the method instead.

I was using this class to log debugging messages and stack traces to file for failed installations and noticed the variables in my custom messages were not being substituted properly. Instead of the variable(s) it was inserting the Object.toString() representation of the variable array. For example:

Log.getInstance().addCustomMessage("Incorrect password for user

{0}

", new String[]

{userName}

);

Would print: "Incorrect password for user [Ljava.lang.String;@10b62c9"



 Comments   
Comment by Julien Ponge [ 06/Nov/09 ]

Great, thanks!





[IZPACK-477] multiFile allowEmptyValue does not function properly Created: 04/Nov/09  Updated: 06/Nov/09

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

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

Any


Attachments: Text File eng.patch     Text File multifile.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

multiFile input field ignores the allowEmptyValue property. Validation does not succeed when no files are selected. Attached patch fixes this.

Second patch fixes the lack of English button text on multiFile.



 Comments   
Comment by Julien Ponge [ 06/Nov/09 ]

The patch does not apply (eng.patch gets rejected).





[IZPACK-476] Make the UserInputPanel contents scrollable Created: 02/Nov/09  Updated: 01/Mar/10  Resolved: 06/Nov/09

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2

Type: Improvement Priority: Minor
Reporter: Lukasz Karnasiewicz Assignee: Julien Ponge
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File UserInputPanel.patch    
Issue Links:
Related
relates to IZPACK-363 Improve layout possibility on UserInp... Resolved
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Sometimes it is required to have lots of controls on one UserInputPanel (e.g. in our product we have a long summary list of configuration variables displayed at the end of the installation process). Unfortunately UserInputPanel does not display all of these controls.
My proposed improvement is to change the implementation of the UserInputPanel so that it contains a vertical scroll. To be exact I propose adding a JPanel that will hold all user input controls and will have the TwoColumnLayout. This JPanel will be put inside a JScrollPane which will be added as a direct and only child of the UserInputPanel.

I've attached a patch of my changes.



 Comments   
Comment by Julien Ponge [ 06/Nov/09 ]

Great job, thanks!

Comment by Florian Buehlmann [ 01/Mar/10 ]

The border can be enabled or disabled by a panel attribute.





[IZPACK-475] ProcessPanel is ignored in console mode Created: 29/Oct/09  Updated: 20/Dec/10  Resolved: 20/Dec/10

Status: Closed
Project: IzPack
Component/s: None
Affects Version/s: 4.3.1
Fix Version/s: 4.3.4, 5.0

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

An installation, which contains ProcessPanel are ignored if it is started in console mode.
Starting the installation in GUI mode works properly.



 Comments   
Comment by Mark Miller [ 20/Dec/10 ]

see IZPACK-480





[IZPACK-474] Wrong behaviour on PacksPanel if pack is required Created: 28/Oct/09  Updated: 17/Feb/10  Resolved: 17/Feb/10

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

Type: Bug Priority: Major
Reporter: Tiziano Furlan Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

XP with Java5


Number of attachments : 0

 Description   

When you click on the checkbox of a pack that has required="true" attribute set, the mouse event handler doesn't check if the pack is required (checked value = -1). So the sub packs gets deselected even if they shouldn't.

A patch could be (this is not tested):

public void mouseClicked(MouseEvent event)
{
int row = packsTable.rowAtPoint(event.getPoint());
int col = packsTable.columnAtPoint(event.getPoint());
if (col == 0)

{ Integer checked = (Integer) packsModel.getValueAt(row, 0); checked = (checked <= 0) ? 1 : 0; packsModel.setValueAt(checked, row, 0); packsTable.repaint(); }

}

Notice the "checked = (checked <= 0) ? 1 : 0" line



 Comments   
Comment by Julien Ponge [ 25/Jan/10 ]

DId you have a chance to test this?

Comment by Julien Ponge [ 17/Feb/10 ]

The proposed change makes sense; thanks.





[IZPACK-473] UserInputPanel field type dir doesn't work properly Created: 28/Oct/09  Updated: 16/Dec/10  Resolved: 16/Dec/10

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

Type: Bug Priority: Major
Reporter: Robert Lieb Assignee: Julien Ponge
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows, JRE 1.6.0_16


Number of attachments : 0

 Description   

I'm using the following code snippet in userInputSpec.xml

<field type="dir" variable="DATA_DIR">
<spec txt="Data directory" size="20"
set="$

{INSTALL_PATH}

$

{FILE_SEPARATOR}${MOD_PATH}${FILE_SEPARATOR}

data"
mustExists="true" create="true"/>
</field>

The documentation says that this will create the directory if not exists, but I get always an error messages:
The directory you have choosen either does not exists or is not valid.



 Comments   
Comment by juliano antunes guimarães leite [ 13/Dec/10 ]

try: mustExists="false" create="true"





[IZPACK-472] Handling of elements and their attributes is not fully implemented in UserInputPanelConsoleHelper Created: 28/Oct/09  Updated: 24/Feb/13

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

Type: Bug Priority: Major
Reporter: Dennis Reil Assignee: Tim Anderson
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Number of attachments : 0

 Description   

The UserInputPanelConsoleHelper does currently not support all fields and options available in the standard UserInputPanel. Furthermore, it implements a second analysis of the xml structure.

This has to be refactored to only use one analysis and to support the same elements, attributes, ...



 Comments   
Comment by martin krueger [ 30/Apr/12 ]

Hi Dennis,
are you already working on this? I started about a week ago but unfortunatly I cannot assign anything to my name.
Greetings,
Martin

Comment by Tim Anderson [ 27/Sep/12 ]

Started work on this at https://github.com/unb/izpack/tree/IZPACK-472

Comment by Rene Krell [ 12/Dec/12 ]

Is there any news here?

I made recently some changes to the UserInputPanelConsoleHelper eliminating the duplicate static String definitions and importing them from UserInputPanel, instead.

From my point of view there are two different problems here:

  • missing support for some field types -> Is this still present from your point of view, can you review this with the latest snapshot? This should be done in IzPack 5.0
  • implementation cleanup -> This is still present as far as I can see, but can be moved to IzPack 5.0.x or 5.1.

Let's move a bit with this issue, if you can

Comment by Rene Krell [ 12/Dec/12 ]

@Martin: Do you have a proposal for this? Can I help you somehow to get involved?
@Tim: Is this branch ready to merge or is there some open work from your point of view?

Comment by Tim Anderson [ 12/Dec/12 ]

I've been refactoring UserInputPanel and friends at https://github.com/unb/izpack/tree/IZPACK-472 but I've been sidetracked with other projects.
I probably won't get back to it until the new year. I'd say release 5.0.0-beta-11 without it.

Comment by Rene Krell [ 12/Dec/12 ]

@Tim: Alright, thank you. You might need to merge the changes I made to not get in deeper conflicts as soon as you'll return to it. Your solution will be the more complete one I guess.

Comment by Tim Anderson [ 24/Feb/13 ]

I've refactored UserInputPanel and UserInputPanelConsoleHelper and merged the corresponding pull request: https://github.com/izpack/izpack/pull/87 to master.
The following field types are yet to be implemented:

  • multifile
  • search




[IZPACK-471] TestLangPacks will throw NullPointerException when there aren't any unknown elements Created: 22/Oct/09  Updated: 22/Oct/09  Resolved: 22/Oct/09

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

Type: Bug Priority: Minor
Reporter: Ari Voutilainen Assignee: Ari Voutilainen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP#1, TestLangPacks 2.0


Number of attachments : 0

 Description   

When there aren't any unknown elements exception will be thrown. In case of one or more unknown elements all will work.






[IZPACK-470] console installion mode - invalid installer and incorrect 'Add/Remove Programs' entry Created: 22/Oct/09  Updated: 24/Mar/12  Resolved: 24/Mar/12

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

Type: Bug Priority: Blocker
Reporter: Scott Hostovich Assignee: Julien Ponge
Resolution: Fixed Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP 32-bit


Number of attachments : 0

 Description   

When you install IzPack 4.3.1 using the '-console' option:

  • The uninstaller does not not work.
    1. Installing using command: java -jar IzPack-install-4.3.1.jar -console
    2. Try uninstall using command (with and without '-console' option): java -jar Uninstaller\uninstaller.jar
    3. Error given: "Invalid or corrupt jarfile Uninstaller\uninstaller.jar"
  • Entry into 'Add or Remove Programs' is wrong and broken:
    1. Entry added is labeled: $UNINSTALL_NAME
    2. Change/Remove operation does nothing
    3. Using same installer in graphical mode installs/uninstalls without issue.


 Comments   
Comment by Patrick Talbot [ 14/Jul/10 ]

This is true for all platforms, the uninstaller jar is corrupted when using -console mode

Comment by Mark Miller [ 15/Sep/10 ]

Should this be fix version 5.0? This issue is a problem for me as well.

Comment by Chris [ 17/Sep/10 ]

Ubuntu 9.10 "Karmic Koala"

I installed without the -console option and am experiencing this issue... I don't suppose there's a valid uninstaller available for separate download? What I thought required IzPack actually does not and now I want it off my computer... safely (not a simple rm -rf ~/IzPack).

Comment by Dustin Kut Moy Cheung [ 15/Mar/12 ]

This bug occurs because in com.izforge.izpack.Installer.ConsoleInstaller.java, there is no outJar.flush(); and outJar.close(); [ In InstallerFrame, they close the zip stream ]. Hence the uninstaller.jar is never flushed and contents are not written. Not closing it makes the jar broken [ You can't even unzip the jar! ]

I just added those 2 statements at the place where [Console Installation complete] is printed and after that, I could unzip the jar [ but could not run it since a lot of files were missing inside ]

I'll try to port all the stuff from InstallerFrame [concerning the uninstaller] to ConsoleInstaller and see if that resolves the issue.

Comment by Dustin Kut Moy Cheung [ 15/Mar/12 ]

https://github.com/jponge/izpack/pull/14

Could someone please verify if this fix works?

[It works for me but I have a midly modified ConsoleInstaller.java and hence would like other people to try it first]

Comment by Stefan Engel [ 20/Mar/12 ]

I tried your fix and it works in our (unmodified) console installer as well!

Comment by Dustin Kut Moy Cheung [ 20/Mar/12 ]

Glad I was helpful! Let's wait and see if that get merged.





[IZPACK-469] Update for Finnish langpack Created: 19/Oct/09  Updated: 19/Oct/09  Resolved: 19/Oct/09

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

Type: Task Priority: Trivial
Reporter: Ari Voutilainen Assignee: Ari Voutilainen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0




[IZPACK-468] Language pack for Basque (EUS) Created: 12/Oct/09  Updated: 06/Nov/09  Resolved: 15/Oct/09

Status: Closed
Project: IzPack
Component/s: Translations
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2, 5.0

Type: Improvement Priority: Major
Reporter: Jon Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive eus.zip    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Translation made for the basque language, both the flag gif and the internationalization xml for the language.



 Comments   
Comment by Julien Ponge [ 15/Oct/09 ]

Thanks!





[IZPACK-467] Load Variable Values from a Properties File Specified at Install Time Created: 11/Oct/09  Updated: 14/Dec/09  Resolved: 14/Dec/09

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

Type: New Feature Priority: Major
Reporter: Dasapich Thongnopnua Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File izpack_load_properties_panel.diff    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

We have quite a few configuration fields on several UserInputPanels and need a way to allow the default values for the fields to be set to different values at install time by loading the values from a properties file. The user can then inspect the values in the UserInputPanel and modify them, if needed.

Basically, the installer is intended to be run several times to install the software in different environments (such as UAT, then Production, etc.) that have different configurations (for example, web service URL, database host, port, user, etc.). We use UserInputPanels to allow entering different values but do not know appropriate default values at packaging/build time. Our approach is to have the client prepare a properties file for each environment. During the installation, the client can specify the location of the properties file (i.e. through a file field on the UserInputPanel). The installer then loads values from the properties file and sets them to their respective variables which can be used as default values for fields on a successive UserInputPanel(s). Without having to manually enter all the values, this allows the client to inspect and modify the values before proceeding the with installation.

I am proposing to add a panel that loads and set variable values from a specified properties file specified through a variable "load.properties.file". The variable can be specified at install-time (e.g. through a field on the UserInputPanel). A patch is attached.

I have seen the ability to set variable values from a specified properties file in ConsoleInstaller.doInstallFromPropertiesFile() but only for automated installation.

This is my first time contributing so any comments, suggestions are welcome.



 Comments   
Comment by Julien Ponge [ 14/Dec/09 ]

Thanks for the new feature!





RulesEngine compound conditions logic. (IZPACK-334)

[IZPACK-466] Document restrictions resp. workaround in rules compound conditions logic Created: 08/Oct/09  Updated: 08/Oct/09

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

Type: Sub-task Priority: Major
Reporter: Dennis Reil Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0




[IZPACK-465] UserInputPanel does not create dir in debian lenny Created: 04/Oct/09  Updated: 06/Oct/09  Resolved: 06/Oct/09

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

Type: Bug Priority: Major
Reporter: Claudius Teodorescu Assignee: Kjell Braden
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian Lenny, java 1.6


Number of attachments : 0

 Description   

Dev note (Kjell Braden): FileInputField.verifyCreateOK() tells the user the non-existing directory would be created, but does not contain any code for actually creating it.



 Comments   
Comment by Julien Ponge [ 04/Oct/09 ]

Kjell, this looks like this issue is for you

Comment by Kjell Braden [ 06/Oct/09 ]

From version 4.4.0 onwards you can specify create="true" along with mustExist="false".





[IZPACK-464] Registry information is not rolled back after unsuccessful installation Created: 02/Oct/09  Updated: 02/Oct/09  Resolved: 02/Oct/09

Status: Resolved
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.0, 4.2.1, 4.3.0, 4.3.1
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Even if an installation fails the registry modification done by the RegistryInstallerListener are not rolled back.

If an installation is not successful (AutomatedInstallData.getInstance().successful == false) the registry modification should be rolled back.



 Comments   
Comment by Florian Buehlmann [ 02/Oct/09 ]

All registry modifications are now rolled back if the installation is not successful.





[IZPACK-463] Either support variable substitution in variable value attribute, or make it clear that you don't Created: 02/Oct/09  Updated: 18/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Malcolm McMahon 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   

How about allowing $

{variable}

substitution in the value assigned to variables? This would, presumably, have to happen at install time when the variables were loaded from the jar.

My case:

I want some database files stored in the application data directory on Windows, and a configuration modified to point to it. So I did:

<variable name="DATABASE_DIR" value="$

{ENV[APPDATA}

\Csales"/>

(Also picking up the variable in an installation listener to configure the config file). The documentation is rather uninformative about what kind of substitution is allowed where. I assumed since variables are an install time thing substitution should be allowed.

The only technical obstacle, it seems to me, is that variable storage doesn't seem to preserve declaration order. I think it would need a flag to indicate which variable have already been substituted so that you could have a controlled recursion on substituting variables which, themselves, require substitution.



 Comments   
Comment by Malcolm McMahon [ 02/Oct/09 ]

Oops, missed the right bracket from the example, but not from the real script.

Comment by Gregor B. Rosenauer [ 07/Dec/09 ]

I ran into the same issue - please support nested variables, in this case variables on the RHS of the declaration, it's a commonly needed usecase (at least here.
The documentation does not mention this and I wondered why the path used during installation was wrong (using something similar to the reporter)...

Comment by Tom Helpstone [ 18/Nov/14 ]

You do not mention, whether you are using <variables> or <dynamicvariables>.
(Maybe <dynamicvariables were not available at all, when this issue was created?)

The following should work in version 5.0 (do not forget to export the variable!):

<dynamicvariables>
   <variable name="DATABASE_DIR" value="${ENV[APPDATA]}" />
</dynamicvariables>

-> This issue can be closed?!?





[IZPACK-462] Launching application after installation Created: 30/Sep/09  Updated: 14/Nov/12

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

Type: Improvement Priority: Minor
Reporter: Dmitry Demidenko 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   

We need in a panel where user can select a checkbox "Launch app after installation". If user selects this option, installed application will be launched after pressing "done" button.



 Comments   
Comment by Andrei Costache [ 14/Nov/12 ]

Hi,

Any progress/news on this? Is there a schedule as to when this might get in?
If not, could someone please post a good workaround suggestion (or more)?

Regards,
Andrei





[IZPACK-461] ArrayIndexOutOfBoundsException in TreePacksPanel Created: 29/Sep/09  Updated: 29/Apr/11  Resolved: 21/Mar/11

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

Type: Bug Priority: Major
Reporter: Massimiliano Ziccardi Assignee: Julien Ponge
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The TreePacksPanel panel raises an ArrayIndexOutOfBoundsException if any of its children is marked as hidden.

The following works:

<pack name="Inculder" id="includer" required="no">
<description>Including pack</description>
</pack>
<pack name="Inculded1" id="included1" parent="includer" required="no">
<description>Including pack</description>
</pack>
<pack name="Inculded2" id="included2" parent="includer" required="no">
<description>Including pack</description>
</pack>

The following gives the exception

<pack name="Inculder" id="includer" required="no">
<description>Including pack</description>
</pack>
<pack name="Inculded1" id="included1" parent="includer" required="no">
<description>Including pack</description>
</pack>
<pack name="Inculded2" id="included2" parent="includer" required="no" hidden="true">
<description>Including pack</description>
</pack>

The exception is :
java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at com.izforge.izpack.panels.PacksModel.getValueAt(PacksModel.java:437)
at com.izforge.izpack.panels.TreePacksPanel.updateModel(TreePacksPanel.java:588)
at com.izforge.izpack.panels.TreePacksPanel.updateModel(TreePacksPanel.java:593)
at com.izforge.izpack.panels.TreePacksPanel.fromModel(TreePacksPanel.java:526)
at com.izforge.izpack.panels.CheckBoxNodeRenderer.getTreeCellRendererComponent(TreePacksPanel.java:996)
at javax.swing.plaf.basic.BasicTreeUI$NodeDimensionsHandler.getNodeDimensions(BasicTreeUI.java:2717)
at javax.swing.tree.AbstractLayoutCache.getNodeDimensions(AbstractLayoutCache.java:475)
at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.updatePreferredSize(VariableHeightLayoutCache.java:1342)
at javax.swing.tree.VariableHeightLayoutCache.updateNodeSizes(VariableHeightLayoutCache.java:900)
at javax.swing.tree.VariableHeightLayoutCache.invalidateSizes(VariableHeightLayoutCache.java:354)
at javax.swing.plaf.basic.BasicTreeUI.setCellRenderer(BasicTreeUI.java:372)
at javax.swing.plaf.basic.BasicTreeUI$Handler.propertyChange(BasicTreeUI.java:3326)
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
at java.awt.Component.firePropertyChange(Component.java:8128)
at javax.swing.JTree.setCellRenderer(JTree.java:749)
at com.izforge.izpack.panels.TreePacksPanel.createPacksTree(TreePacksPanel.java:473)
at com.izforge.izpack.panels.TreePacksPanel.createNormalLayout(TreePacksPanel.java:186)
at com.izforge.izpack.panels.TreePacksPanel.panelActivate(TreePacksPanel.java:861)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(InstallerFrame.java:839)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(InstallerFrame.java:1451)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(InstallerFrame.java:1419)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.actionPerformed(InstallerFrame.java:1561)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
...



 Comments   
Comment by Katarzyna Czeczot [ 17/Aug/10 ]

duplicate with: http://jira.codehaus.org/browse/IZPACK-391

Comment by Timothy Fridey [ 18/Mar/11 ]

This should be marked as Fixed see: IZPACK-391





[IZPACK-460] run-privileged process does not log debug/console output with -DTRACE=true Created: 28/Sep/09  Updated: 23/Jul/12

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

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

Mac OS X 10.6.1,
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)


Number of attachments : 0

 Description   

I don't get any debug or console output when I have run-privileged turned on and -DTRACE=true enabled. I poked around a little in the code and it looks like the relaunched process should redirect it's output in PrivilegedRunner.java.

The following method looked suspicious.

public int relaunchWithElevatedRights() throws IOException, InterruptedException

{ String javaCommand = getJavaCommand(); String installer = getInstallerJar(); ProcessBuilder builder = new ProcessBuilder(getElevator(javaCommand, installer)); builder.environment().put("izpack.mode", "privileged"); return builder.start().waitFor(); }

 Comments   
Comment by Demiurg [ 21/Feb/10 ]

I can confirmed this issue on Windows Vista. Not only the relaunched installer does not have the tracing enabled, but additionally when I run it in the following way:
java -DTRACE=TRUE -Dizpack.mode=privileged -jar install.jar
It looks like it is not running in privileged mode, as it cannot write to Program files.

Comment by Gustavo Hexsel [ 23/Jul/12 ]

The issue seems to be that system properties (anything -Dx=y) are not propagated at all, including TRACE=true. I have an unrelated system property and it works on all systems except for Windows.





[IZPACK-459] Allow compile-time variable substitution in build.xml Created: 28/Sep/09  Updated: 28/Sep/09

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

Type: Improvement Priority: Minor
Reporter: Gregor B. Rosenauer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64, Eclipse 3.4.1 Ganymede, Ant 1.7.1


Number of attachments : 0

 Description   

Currently, it is not possible to use variables at compile time, e.g. for specifying resource paths etc. in the install.xml file.
Ant variables are only substituted when the install.xml is included inside a <configuration> element, which is cumbersome to edit and maintain.

I'd like to be able to use environment variables and ant variables for dynamically specifying resource paths etc. to avoid hard coded absolute paths, e.g. for shortut-specs, like so:

<resources>
<res id="InfoPanel.info" src="$

{ENV[my.dir]}

/Readme.txt" />
<res id="shortcutSpec.xml" src="@

{base.dir}

/shortcutSpec.xml" />

Related Issues: issue IZPACK-327, IZPACK-169






[IZPACK-458] Galician language updated. Created: 13/Sep/09  Updated: 06/Nov/09  Resolved: 02/Oct/09

Status: Closed
Project: IzPack
Component/s: Translations
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2, 5.0

Type: Improvement Priority: Major
Reporter: Xabier Cancela Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

 Description   

Here is the updated file of Galician language, translation of galician language file was made from the english language file which is in the SVN (revision 2850). Galician language file is in the attachment.



 Comments   
Comment by Julien Ponge [ 30/Sep/09 ]

There is no attachment

Comment by Xabier Cancela [ 01/Oct/09 ]

sorry, it was a mistake, here is the file.

Comment by Julien Ponge [ 02/Oct/09 ]

Thanks!





[IZPACK-457] Update the look and feel libraries Created: 09/Sep/09  Updated: 09/Sep/09  Resolved: 09/Sep/09

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

Type: Improvement Priority: Minor
Reporter: Julien Ponge Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 10 minutes
Time Spent: Not Specified
Original Estimate: 10 minutes

Number of attachments : 0

 Description   

The substance, nimbus and jgoodies looks libraries need an update w.r.t. the upstream versions.



 Comments   
Comment by Julien Ponge [ 09/Sep/09 ]

Done.





[IZPACK-456] Allow changing the default install path using conditions Created: 05/Sep/09  Updated: 08/Jun/11

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

Type: Improvement Priority: Major
Reporter: Carlos Valenzuela Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Patch Submitted:
Yes
Number of attachments : 0

 Description   

For some of my projects i need to have a different defaultinstallation path depending on conditions so I ca use something like
<variables>
<variable name="ST_PROFILE" value="PRO"/>
<variable name="DesktopShortcutCheckboxEnabled" value="true"/>

<variable name="INSTALL_PATH" value="$

{APPLICATIONS_DEFAULT_ROOT}${FILE_SEPARATOR}ST_MEXICO_PRO" condition="C_PROF_PRO"/>

<variable name="INSTALL_PATH" value="${APPLICATIONS_DEFAULT_ROOT}

$

{FILE_SEPARATOR}

ST_MEXICO_CAP" condition="C_PROF_CAP"/>
</variables>

The following code that must replace the method TargetPanel.panelActivate
implements this requirement:

/**

  • Called when the panel becomes active.
    */
    public void panelActivate() { String defaultInstallDir; super.panelActivate(); com.izforge.izpack.util.VariableSubstitutor vs = new com.izforge.izpack.util.VariableSubstitutor(idata.getVariables()); defaultInstallDir = vs.substitute(getDefaultInstallDir(), null); setDefaultDir(defaultInstallDir); idata.setInstallPath(defaultInstallDir); // Set the default or old value to the path selection panel. pathSelectionPanel.setPath(idata.getInstallPath()); }


 Comments   
Comment by Mario Morneau [ 08/Jun/11 ]

I need about the same feature but with a list of choice.

What we want to do is to have a costum list field (a list of environnment ex: DEV, TEST, PRE_PROD, PRODUCTION with default value=DEV)
this value is then put in a variable ex name="ENV_CHOICE"
And when this fields is selected force the default installation path to include a suffix or prefix to the path

<variable name="INSTALL_PATH" value="$

{APPLICATIONS_DEFAULT_ROOT}${FILE_SEPARATOR}${ENV_CHOICE}" />

or
<variable name="INSTALL_PATH" value="${ENV_CHOICE}${FILE_SEPARATOR}${APPLICATIONS_DEFAULT_ROOT}

" />

Or add a feature that let us overide the default install path at any time in the configuration process.

thank





[IZPACK-455] Missing entry for FinishPanel.auto.dialog.filterdesc in deu.xml (German) Created: 04/Sep/09  Updated: 06/Nov/09  Resolved: 30/Sep/09

Status: Closed
Project: IzPack
Component/s: Translations
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Major
Reporter: Sebastian Pappert Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File deu.xml.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The translation entry for FinishPanel.auto.dialog.filterdesc is missing for the German language file. A translation for "XML Files" is "XML-Dateien", see attached patch.



 Comments   
Comment by Julien Ponge [ 30/Sep/09 ]

Thanks!





[IZPACK-454] Lost input data in password fields when navigating forward/backward in installer Created: 04/Sep/09  Updated: 08/Oct/09  Resolved: 08/Oct/09

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

Type: Bug Priority: Major
Reporter: Jochen Hinrichsen Assignee: Dennis Reil
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   

When entering data in input fields of the GUI-driven installer this data is lost after going "next" and "back".

The field is defined as a RuleInputField
<field type="rule"> ...



 Comments   
Comment by Jochen Hinrichsen [ 04/Sep/09 ]

Input of type="password" is los when navigating panels. type="text" works. Sample snippet from user input spec:

<field type="text" variable="db_server_name">
<spec set="127.0.0.1" size="25" txt="Server:"/>
<validator class="com.izforge.izpack.util.NotEmptyValidator" txt="Please enter IP"/>
</field>
<field type="password" variable="db_user_password">
<spec>
<pwd set="secret" size="25" txt="Passwort:"/>
</spec>
<validator class="com.izforge.izpack.util.NotEmptyValidator" txt="Please enter password."/>
</field>

(1) When entering the panel for the first time, the defaults '127.0.0.1' and 'secret' (scrambled using *) are shown
(2) Enter '0' as db_server_name
(3) Enter '1' as db_user_password
(4) Hit 'next'
(5) Hit 'previous'
(6) db_server_name is '0' (user input)
(7) BAD: db_user_password is 'secret' (scrambled) instead of '1'

Same problem: http://www.nabble.com/Password-fields-td18322987.html#a18322987

http://www.nabble.com/Retaining-values-on-the-panel-td8406351.html#a13604509 is not an option because no default value can be specified.

Comment by Dennis Reil [ 08/Oct/09 ]

This is as designed because you configured set="secret" which means, fill the field with secret. So what you'll have to do is:
1. Define a variable, e.g. THE_PASSWORD
2. set it to the default, i.e. secret
3. define the password field with set="$

{THE_PASSWORD}

"

and everything will be as expected. So this is actually no bug.





[IZPACK-453] Considering conditions in resources Created: 04/Sep/09  Updated: 13/Dec/12  Resolved: 18/Feb/10

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

Type: New Feature Priority: Major
Reporter: Patrick Zbinden Assignee: Julien Ponge
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File IZPACK-453-jponge.diff     Text File IzPack_ResourceBundle_DokuPatch.txt     Text File IzPack_ResourceBundle_Patch.txt     Text File IzPack_ResourceBundle_Patch.txt    
Number of attachments : 4

 Description   

Hello

I want to built an installer for two different brands. Therefore I need different images on the panels, i.e "Heading.image" or "Installer.image"
I managed to do this on the panels by registering a GUIListener at installerFrame and adjusting the images when switching panel.
But now I have two problems:
a) The explained way is not really nice
b) This is the point: I cannot use different images on LanguageDialog!

Wouldn't it be nice to have the possibility of using conditions for resources? This would solve both of my problems.

i.e.:
...
<res id="installer.langsel.img" src="langsel_Brand1.png" condition="is.Brand1"/>
<res id="installer.langsel.img" src="langsel_Brand2.png" condition="is.Brand2"/>

<res id="Heading.image" src="heading_Brand1.png" condition="is.Brand1"/>
<res id="Heading.image" src="heading_Brand2.png" condition="is.Brand2"/>
...

Thank you in advance for your answer.



 Comments   
Comment by Patrick Zbinden [ 06/Jan/10 ]

Hello again

I have a different suggestion to solve my wish.
How about introducing a "resource bundle"?
We should have the possibility to define bundles of resources. BundleName should be set by SystemProperty and in defining a default in install.xml.

ResourceManager should then look for the asked resource in the following order:
/res/<bundleName>/<resourceName>_<iso3>
/res/<bundleName>/<resourceName>
/res/<resourceName>_<iso3>
/res/<resourceName>
ResourceManager should then already be used for the LanguageDialog and also for JFrameIcon in InstallerFrame.

i.e.
<resources>
<!-- bundle 1 -->
<bundle id="bundle1" default="yes">
<res id="Heading.image" src="path1/HeadingImage.png" />
<res id="installer.langsel.img" src="path1/langselImage.png" />
</bundle>
<!-- bundle 2 -->
<bundle id="bundle2">
<res id="Heading.image" src="path2/HeadingImage.png" />
<res id="installer.langsel.img" src="path2/langselImage.png" />
</bundle>
<!-- common resources -->
<res id="resource.id" src="path.to.resource" />
...
</resources>

Thank you in advance

Comment by Patrick Zbinden [ 01/Feb/10 ]

Hello

Attached a patch to realize the "resource bundle".
Behaviour as described.

If the patch will be applied, I can also send you the patch for documentation.

Regards
Patrick

Comment by Patrick Zbinden [ 09/Feb/10 ]

Patch for documentation

Comment by Julien Ponge [ 17/Feb/10 ]

Hi Patrick;

I could not apply the patch. Could you please update it?

Thanks a lot

Comment by Patrick Zbinden [ 18/Feb/10 ]

Hi Julien

Here's the patch including documentation. Replaces all patches before.
Hope it works now.

Patrick

Comment by Julien Ponge [ 18/Feb/10 ]

I have adapted from your patch. Here is my proposal. Can you please confirm that it functionally matches yours?

Thanks Patrick

Comment by Patrick Zbinden [ 18/Feb/10 ]

Looks ok to me.

Regards
Patrick

Comment by Julien Ponge [ 18/Feb/10 ]

My adaptations had issues, so I went back to your patch.

Thanks!

Comment by Rene Krell [ 18/Feb/10 - Visible by: Developers ]

In the SVN checkin, there is something wrong in CompilerConfig.java:

The following part of the patch doesn't compile for me:

@@ -1774,6 +1852,10 @@
}
}

+ if (bundleName != null && !bundleName.isEmpty())
+

{ + id = bundleName + "/" + id; + }

It should rather be:

@@ -1774,6 +1852,10 @@
}
}

+ if (bundleName != null && bundleName.length()>0)
+ { + id = bundleName + "/" + id; + }

Am I right?

Comment by Julien Ponge [ 18/Feb/10 ]

Yes, see my last commit (this is a Java6-only method).





[IZPACK-452] Run-privileged forces GUI installation even if automated install is requested Created: 04/Sep/09  Updated: 14/Mar/11  Resolved: 03/Dec/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.1
Fix Version/s: 4.3.3, 5.0

Type: Bug Priority: Major
Reporter: Manuel Padilha Assignee: Julien Ponge
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OSX


Attachments: Text File izpack_installer.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

If:
1. an installer is created with the run-privileged tag
2. and the installer is launched with an administrative user that is currently unprivileged
3. the installer is launched with an XML passed as parameter in order to perform an automatic install

Then:
1. the installer launches sees it needs privilege escalation
2. the installer prepares a ProcessBuilder that will invoke the native executable run-with-privileges-on-osx
3. the ProcessBuilder is constructed BUT the parameter that was passed with the XML file is ignored
4. the run-with-privileges-on-osx launches the installer again, with the correct privileges BUT without the XML argument
5. the installer runs in full GUI mode

I solved the problem by doing the following:
1. In the Installer class, before creating the AutomatedInstaller object, I store the argument in a system property => System.setProperty("izpack.cmdline_argument", args[0]);
2. In the PrivilegedRunner class, in the method relaunchWithElevatedRights() I read the system property and use it to complete the command line that is used in the ProcessBuilder.

Attached you can find the patch.
However I don't recommend using it... It's a quick hack and things should probably be done in a different way.



 Comments   
Comment by Julien Ponge [ 30/Sep/09 ]

The patch does not apply cleanly.

Comment by Manuel Padilha [ 30/Sep/09 ]

The patch is trivial, you'll understand what it does just by opening it in a text editor.
And, as stated above, it's a quick hack with possible caveats. A better solution should be provided by someone with insight on the architecture of izpack installer.

However, I'm willing to try and generate another patch if you tell me why it's failing to apply.

Comment by Maksim Sorokin [ 04/Mar/11 ]

Is this issue fixed? I can still reproduce this issue in IzPack 4.3.3 on Windows 7.

Comment by Julien Ponge [ 07/Mar/11 ]

No, the patch was incomplete...

Comment by Maksim Sorokin [ 07/Mar/11 ]

Can we reopen this issue?

Comment by Julien Ponge [ 07/Mar/11 ]

Only if you come up with a patch that I can apply

Comment by Maksim Sorokin [ 07/Mar/11 ]

Can you elaborate more on why Manuel's patch is incomplete? Is there another, cleaner way to do that?

I am asking because I am not sure, if I should try it out out and test on different operating systems.

Comment by Julien Ponge [ 07/Mar/11 ]

I simply could not apply it to either master of 4.3 Git branches.

It's probably not complicated to edit the files according to what the patch says, but like most projects do, we tend to classify as 'incomplete' an issue where the patch simply does not apply on top of the SCM that we have.

This is not to be pedantic.

Comment by Manuel Padilha [ 07/Mar/11 ]

sorry about that.
i wont be able to rebuild the patch for at least a few more days, so if anyone wishes to do so, please do
the changes introduced are trivial albeit ugly.

Comment by Maksim Sorokin [ 07/Mar/11 ]

Ok, now I understand.

Preliminary testing shows, that this patch works. I am going to test that tomorrow in different scenarios (we have pretty complicated chains of installers) to verify that it is truly working correctly.

As far as I see you have a lot of changes in code in IzPack 5. So I think, I will not look at the code until it is released. But I could provide you with a patch for 4.3.4 version. Just tell me in what format you want to get it.

Comment by Julien Ponge [ 14/Mar/11 ]

A Git-friendly patch would be just fine!





[IZPACK-451] customize size of pack in the install.xml Created: 24/Aug/09  Updated: 06/Aug/12  Resolved: 06/Aug/12

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

Type: New Feature Priority: Major
Reporter: Wang Linchuan 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 is a database in my install package,and the database need some more space to build data(sometimes it is very large).But the size shows in the GroupPanel and PacksPanel is not include that. So I want to set the disk space's size in the GroupPanel and PacksPanel by myself.
Would you add an attribute in the <pack> element in install.xml.
thanks!



 Comments   
Comment by Tim Anderson [ 04/Aug/12 ]

Pull request is at: https://github.com/izpack/izpack/pull/45

The pack size can now be specified in install.xml
E.g.

<pack name="Core" required="yes" size="10000000"/>

Given:

  • size = the specified pack size; and
  • fileSize = the total size of all files in the pack

After compilation, the Pack.getSize() method will return:

  • size if size > fileSize
  • fileSize if size < fileSize

A new method, Pack.getFileSize() returns the total size of the files in the pack.





[IZPACK-450] <pack> invalid attribute 'preselected': Expected (yes|no) if present Created: 11/Aug/09  Updated: 11/Aug/09

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

Type: Improvement Priority: Minor
Reporter: Jochen Hinrichsen 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 allowed values for installer element pack/@preselected is [no|yes]. For the sake of usability, this should rather be the standard, default [false|true] as used in most other values (e.g. fileset/@override)

When using true or false as values, the warning message

<pack> invalid attribute 'preselected': Expected (yes|no) if present

is shown and preselection fails.






[IZPACK-449] First pack in TreePacksPanel always grey Created: 11/Aug/09  Updated: 24/Mar/10  Resolved: 24/Mar/10

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

Type: Bug Priority: Major
Reporter: Sebastian Pappert Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Vista with Java6


Attachments: Text File 0001-fix-for-tree-pack-viewer-first-one-always-greyed-out.patch     Text File 0002-same.patch     XML File install.xml     JPEG File izpack-treepackspanel.jpg    
Number of attachments : 4

 Description   

The first element in the TreePacksPanel is always grey. Besides of that there seems to be no other difference to the rest of the elements. I attached the install.xml from the sample directory where I only changed the PacksPanel to TreePacksPanel and set the required attribute of the Base pack to "no". You can see the result in the attached image.



 Comments   
Comment by Katarzyna Czeczot [ 23/Mar/10 ]

sorry that in two patches

Comment by Julien Ponge [ 24/Mar/10 ]

Thanks for the patch!





[IZPACK-448] TargetPanel directory chooser dialog does not allow creation of new directory on Mac OS X Created: 09/Aug/09  Updated: 06/Nov/09  Resolved: 26/Aug/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Minor
Reporter: Christian d'Heureuse Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS X


Number of attachments : 0

 Description   

On Mac OS X, it's not possible to create a new directory from within the directory chooser dialog of the TargetPanel. The user has to create the directory outside of IzPack, or type the path of the new directory into the input box.



 Comments   
Comment by Julien Ponge [ 22/Aug/09 ]

Good point Christian, however that's an issue with Swing on Mac OS X.

The non-intuitive workaround is to type the name of the directory to be created in the field...

Comment by Christian d'Heureuse [ 24/Aug/09 ]

When JFileChooser.showSaveDialog() is used instead of showOpenDialog(), the button to create a new directory is shown.

Comment by Julien Ponge [ 26/Aug/09 ]

...good point!





[IZPACK-447] Uninistaller does not uninstall correctly under windows 7 Created: 04/Aug/09  Updated: 15/Mar/12  Resolved: 15/Mar/12

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

Type: Bug Priority: Major
Reporter: Mathew Joseph Assignee: Tim Anderson
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Number of attachments : 0

 Description   

he windows installer / uninstaller does not uninstall correctly under windows,

it removes the start menu entries, along with most of the program files,
however it doesn't remove the registry entries,

this means that ghost installations remain in the registry, that windows things
is still there, and using the control panel uninstallation is not feasible as
the requisite jar has been removed by the installer, uninstall process.

error:

"Java Virtual Machine Launcher"
"Unable to access jarfile"
"c:\path\to\jar"



 Comments   
Comment by Tim Anderson [ 15/Mar/12 ]

Added integration test com.izforge.izpack.integration.windows.WindowsInstallationTest to verify this works in 5.0





[IZPACK-446] Schema (.xsd) for userInputSpec Created: 03/Aug/09  Updated: 05/Aug/12  Resolved: 05/Aug/12

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

Type: Improvement Priority: Trivial
Reporter: Jochen Hinrichsen Assignee: Tim Anderson
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

n/a


Attachments: XML File userInput.xsd    
Number of attachments : 1

 Description   

A first version of a re-engineered xml schema for the user input specification. Several dtd's are already existing, but not for the userInputSpec.xml.

It will successfully validate the sample-userInputSpec.xml from IzPack and the glassfish installer v3.



 Comments   
Comment by Tim Anderson [ 02/Aug/12 ]

Thanks for the patch. The .xsd is included in the schema directory of the distribution.

Pull request is at: https://github.com/izpack/izpack/pull/43





[IZPACK-445] console mode NullPointerException Created: 29/Jul/09  Updated: 06/Nov/09  Resolved: 05/Aug/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Minor
Reporter: Sebastian Held Assignee: Kjell Braden
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode)


Attachments: File bug.tgz    
Number of attachments : 1

 Description   

The gui-installer runs fine, but the console mode does not.



 Comments   
Comment by Kjell Braden [ 05/Aug/09 ]

That's because the console installer currently requires the english language pack. As a workaround you can add <langpack iso3="eng"/> to your <locale/> definition.

Comment by Kjell Braden [ 05/Aug/09 ]

The language for the console installer can now be specified by e.g. "-language deu", by default the first element of the <locale/> definition will be used.





[IZPACK-444] defaultInstallDir should be setable by conditional variable Created: 28/Jul/09  Updated: 28/Jul/09

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

Type: Improvement Priority: Major
Reporter: Sebastian Held 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   

To modify the default installation path, a resource entry needs to be created, the file needs to have
$varName
in it and a variable needs to be defined. With it it's possible to define the install dir at runtime (important for update installations).

Better way:
The default install folder should be specifiable by a conditional variable. Then it would be possible to take the default value at initial installation and a specific folder (e.g. from environment variable) at subsequent (update) installations.






[IZPACK-443] Invalid Unexpected end of stream(installer coorupted) Created: 25/Jul/09  Updated: 03/Mar/10

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

Type: Bug Priority: Critical
Reporter: zosrothko Assignee: Kjell Braden
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WXP JRE 1.5


Attachments: GIF File bug1.gif     GIF File bug2.gif     Java Archive File ISO-ITU-OSI-100-install(2).jar     Text File traces first run.txt     Text File traces second run.txt     Text File traces third run.txt    
Number of attachments : 6

 Description   

Hi

For the same installer ISO-ITU-OSI-100-install.jar, run 3 successives times, I got

1/ on first run, the bug1.gif attached

2/ on the second run, the bug2.gif attached

3/ on the third run, a complete working installation.

What is going wrong the first 2 times????

Rgds

zosrothko



 Comments   
Comment by zosrothko [ 25/Jul/09 ]

I tried to join the installer jar but that's not possible since it is about 12Mb and the upper allowed limit for attachment is 10Mb.

Comment by zosrothko [ 25/Jul/09 ]

Hi

This issue is BLOCKING my installation since the final user should retry 3 times to run the install.jar before getting the product installed...
(I do not find how to increase the priority)

Please help...

zosrothko

Comment by zosrothko [ 25/Jul/09 ]

Reduced install.jar with which the problem can be reproduced.

Comment by Kjell Braden [ 05/Aug/09 ]

Can you reproduce the issue by running the installer from the console with "java -DTRACE=TRUE -DSTACKTRACE=TRUE -jar ISO-ITU-OSI-100-install(2).jar" and attach the resulting output here?

Comment by zosrothko [ 12/Aug/09 ]

Hi Kiell

Here the three traces for each runs for:
java -DTRACE=TRUE -DSTACKTRACE=TRUE -jar ISO-ITU-OSI-100-install(3).jar

zos

Comment by Aftab Vhora [ 03/Mar/10 ]

Hi zosrothko,

In this installer are you copying same file to two diff. places

i.e. abc.txt to $INSTALL_PATH/abc and $INSTALL_PATH/xyz

This problem might be because of that...Because of IzPack's feature of back referencing it might be causing problem.

-Aftab

Comment by zosrothko [ 03/Mar/10 ]

Hi Aftab

Yes, the installer copies a same file to 2 different places.

zosrothko

Comment by Aftab Vhora [ 03/Mar/10 ]

Screenshot provides very little information about where exactly its causing problem in the Unpacker.

I have resolved similar issues in the past in the IzPack code.

What you may want to try is :

1. Remove copying same file to diff. location, remove copying from one location.
2. Write an execuatble which copies that file from one location to other.

i.e. <file src="abc.txt" todir="$INSTALL_PATH/abc" />
<file src="abc.txt" todir="$INSTALL_PATH/xyz" /> <!-- REMOVE THIS LINE -->

Write a script sh/bat file something like this
copy.sh
=======
cp $INSTALL_PATH/abc/abc.txt $INSTALL_PATH/xyz/

and put this copy.sh in execuatble as well as parsable tag.

This might resolve your problem.

-Aftab





[IZPACK-440] $myVar] is not being replaced with variable value Created: 21/Jul/09  Updated: 06/Nov/09  Resolved: 22/Jul/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Major
Reporter: Laurian Vostinar Assignee: Kjell Braden
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all


Attachments: Text File VariableSubstitutor_Patch.txt    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

If I have a parsable where a variable is immediately followed by "]" the value won't be replaced with its value. Example: $myVar]



 Comments   
Comment by Kjell Braden [ 22/Jul/09 ]

Thanks for your report and patch.





[IZPACK-439] Installer issues on Linux Created: 19/Jul/09  Updated: 17/Nov/09

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

Type: Bug Priority: Major
Reporter: Christoph Kutzinski Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 9.04, Sun JDK 1.6.0_14


Number of attachments : 0

 Description   

These are various issues I've encountered while testing an IzPack installer on Linux (specifically Ubuntu/Gnome). I installed this as a non-root user.

a) creation of 'main menu' subgroups doesn't work

If I e.g. specify the $APP_NAME as the program group, no shortcut is created at all. If I however install again, a shortcut in the group "Other" is created

After that I specified the programGroup Accessories. I.e.
<programGroup defaultName="Accessories"
location="applications"/>
This works on 1st installation. However:

b) On repeated installation an (additional) shortcut in the program group "Other" is created
For every following installation an additional shortcut is created in this group

c) Consequently these additional shortcuts are not removed, when I run the uninstaller

d) Categories don't have any effect?
I didn't quite understand from the documentation what categories are good for. However, they don't seem to have any effect. I've specified the category
Categories="Utility"
but he 'Categories' key in the .desktop file (of which BTW a new one is created for each installation) under ~/.local/share/applications is empty

e) Desktop icons on Gnome don't work
Okay, that one is already mentioned in the documentation



 Comments   
Comment by Joris [ 17/Nov/09 ]

In my case (openSUSE 11.2, Sun JDK 1.6.0_15 or Sun JDK 1.6.0_16) the IzPack installer itself, let alone installers created using IzPack, does not even get to the scortcut creation step (Step 8/9), if I don't run as root. When I do run as root everything works jsut fine. As it is the whole installer just freezes at the end of the 7th step, when you click 'next'. I'm not sure what in the world the IzPack installer is trying to do that requires root permission but to me it seems a bit scary. I hope it can be fixed soon!





[IZPACK-438] Uninstaller does not delete all folders Created: 16/Jul/09  Updated: 06/Nov/09  Resolved: 30/Sep/09

Status: Closed
Project: IzPack
Component/s: Uninstaller
Affects Version/s: 4.3.0
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Major
Reporter: Andreas Vef Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Issue Links:
Duplicate
duplicates IZPACK-387 Uninstaller does not elevate when ins... Closed
Number of attachments : 0

 Description   

The Uninstaller does not delete all folders. The installation folder and the uninstaller folder are not deleted.
Maybe this could be done via File.deleteOnExit()



 Comments   
Comment by Julien Ponge [ 30/Sep/09 ]

Fixed by IZPACK-387





[IZPACK-437] Shortcut attribute subgroup is not documented. Created: 16/Jul/09  Updated: 16/Jul/09

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

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

Windows


Number of attachments : 0

 Description   

The attribute "subgroup" of the shortcut element is not documented.

Currently you have to prefix the value with a backslash because it is appended directly to the program group name.
Example: If your program group is "MyApp" and you want to create your documentation links in "MyApp\Documentation", you must specify subgroup="\Documentation".
Is this intended?






[IZPACK-436] Documentation: izpack2exe requires .net framework 3.5 (?) Created: 16/Jul/09  Updated: 16/Jul/09

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

Type: Improvement Priority: Major
Reporter: Andreas Vef Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP2


Number of attachments : 0

 Description   

izpack2exe fails to start on Windows XP SP2 without .net framework 3.5.
The error message is just "Application failed to initialize, reinstallation may solve the problem".
The documentation should mention this requirement. Maybe .net 3.0 is sufficient too, at least 2.0 is not.






[IZPACK-435] NullPointerException in PacksPanelBase.getSummaryBody() if PacksPanel has not been visible Created: 16/Jul/09  Updated: 16/Jul/09

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

Type: Bug Priority: Minor
Reporter: Andreas Vef 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 our installer we skip the PacksPanel via a condition unless the group "Custom installation" is selected in the InstallationGroupPanel.
This causes a NullPointerException in PacksPanelBase.getSummaryBody(), and the SummaryPanel is empty.
Reason: packsModel is null when packsModel.isModifyinstallation() is called.






[IZPACK-434] Danish language translation is missing values Created: 16/Jul/09  Updated: 06/Nov/09  Resolved: 30/Sep/09

Status: Closed
Project: IzPack
Component/s: Translations
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Trivial
Reporter: Kasper Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

I used Windows 7


Attachments: JPEG File Bug.jpg    
Number of attachments : 1

 Description   

When using the danish language pack some values are missing.
These are
PackPanel.freespace
FinishPanel.done

I can't figure out how to fix this, since editing the dan.xml file does nothing at me. But I know what the translations should be in there:
<str id="PacksPanel.freespace" txt="Fri plads: "/>
<str id="FinishPanel.done" txt="Færdig"/>

Greetings
foens



 Comments   
Comment by Julien Ponge [ 30/Sep/09 ]

Thanks for the missing strings!





[IZPACK-433] ShortcutPanel fails to load if shortcutSpec.xml is UTF-8 encoded and contains non-ascii characters Created: 16/Jul/09  Updated: 29/Apr/11  Resolved: 21/Mar/11

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.0
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Major
Reporter: Andreas Vef Assignee: Julien Ponge
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

German Windows, Java default encoding Windows-1252


Number of attachments : 0

 Description   

The ShortcutPanel fails to load if shortcutSpec.xml is UTF-8 encoded and contains non-ascii characters that are correctly encoded in the XML file.
Error message: FEHLER: 'Invalid byte 1 of 1-byte UTF-8 sequence.'
The problem is caused by com.izforge.izpack.adaptator.impl.XMLParser:
public IXMLElement parse( String inputString )

{ return parse(new ByteArrayInputStream(inputString.getBytes())); }

getBytes() uses the current codepage, but the XML is UTF-8 by default.
I suggest this implementation:
public IXMLElement parse( String inputString )

{ InputSource inputSource = new InputSource( new CharArrayReader( inputString.toCharArray())); DOMResult result = parseLineNrFromInputSource( inputSource ); return searchFirstElement( result ); }

 Comments   
Comment by Roman Platonov [ 05/Aug/09 ]

Hi!
Is it any workaround for this problem?
My project in Russian language, and izpack installer fails to load if shortcutSpec.xml in UTF-8 encoding, but I need for Russian words in it.

Comment by Lauri Korpela [ 07/Aug/09 ]

This sounds like a duplicate of IZPACK-422

Comment by Timothy Fridey [ 18/Mar/11 ]

Looks like this should be marked as fixed.

Fixed since 4.3.2 see: IZPACK-422





[IZPACK-432] Portugues European Language Pack Created: 16/Jul/09  Updated: 06/Nov/09  Resolved: 15/Oct/09

Status: Closed
Project: IzPack
Component/s: Translations
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2, 5.0

Type: New Feature Priority: Major
Reporter: Miguel Guilherme Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All OS


Attachments: Zip Archive prt_languagepack.zip    
Number of attachments : 1

 Description   

Language Pack for Portuguese European, I've choose "prt" because "por" is already taken by "brasilian portuguese" and there is a few mistakes and problems. Could you release put this in the next release.
How do I use this pack I've created with the actual version without changing the original jar?

Language and flag included.



 Comments   
Comment by Miguel Guilherme [ 16/Jul/09 ]

I've forget to tell, the default name on the language selection panel would be: "Português"

Thanks

Comment by Miguel Guilherme [ 17/Jul/09 ]

Could be great to integrate in the next stand-alone version to.

Thanks

Comment by Julien Ponge [ 15/Oct/09 ]

Thanks!





[IZPACK-431] Package names with blank cause web installer to fail Created: 15/Jul/09  Updated: 15/Jul/09

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

Type: Bug Priority: Major
Reporter: Gregor B. Rosenauer Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Vista SP2


Number of attachments : 0

 Description   

When creating a web installer with package names that contain a blank " ", the installer and associated package-JARs are created without warnings but the installer fails when trying to download the packages.
Problem is, the installer just exits with a general "installation failed" message and does not provide any further help.
In the log, I see:

java.lang.NullPointerException while trying to download http://www-intra.sozvers
.at/seucc/auslief/download/TA%203.0/Referenzinstallation/webinstaller_test/3.4.2
_1.1.0/ta30j-ri-3.4.2_1.1.0_web-installer.pack-JBoss 4.2.3.GA-cxf.jar
Current focus owner: null.glassPane
com.izforge.izpack.installer.InstallerException: Installation failed

The web installer should catch such errors and report correctly which package failed to download and why.
Also, it should correctly deal with blanks by replacing them with "%20" as by the URL notation.

This fact should also be noted in the docs along with a recommendation to not use blanks in the package name or better provide a package id which is then taken for the package filename (only found that out by trying, it's not mentioned in the docs afaik).

Besides this minor gripe, the web installer is a fantastic feature of izPack and works very well, thanks a lot!






[IZPACK-430] uninstaller elevation configurable Created: 14/Jul/09  Updated: 06/Nov/09  Resolved: 14/Jul/09

Status: Closed
Project: IzPack
Component/s: Compiler, Uninstaller
Affects Version/s: 4.3.2
Fix Version/s: 4.3.2

Type: Bug Priority: Minor
Reporter: Kjell Braden Assignee: Kjell Braden
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 20 minutes
Original Estimate: 20 minutes

Attachments: Text File izpack-430.patch    
Number of attachments : 1

 Description   

Should be possible to configure the elevation of the uninstaller as for the installer. Currently it depends on the installer being elevated at runtime, which leads to problems in some use cases.



 Comments   
Comment by Kjell Braden [ 14/Jul/09 ]

Compiles fine, didn't test the installer/uninstaller though.





[IZPACK-429] Issues executing scripts files on different operating systems Created: 10/Jul/09  Updated: 27/Jan/10  Resolved: 27/Jan/10

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

Type: Bug Priority: Major
Reporter: thirumaran thura rajah Assignee: Kjell Braden
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MacOs and XP


Attachments: JPEG File screenshot.JPG    
Number of attachments : 1

 Description   

Hi Guys,

I just completed an installer using IzPack 4.2.1. The issue I am having is if I were to do the compilation on a Mac it runs well on Macs but tends to throw an error on Windows platform and vice verse. The error as per below

java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readInt(Unknown Source
)
at java.io.ObjectInputStream.readInt(Unknown Source)
at com.izforge.izpack.installer.Unpacker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

I manage to narrow down the problems to the executable scripts that I introduce using the <executable>. It tends to throws an error with an error box popping up I assume when the executable scripts need to executed. If I comment out the executable section and recompile they seem to work fine.

Can someone help me with this?

Regards,
Thiru



 Comments   
Comment by Kjell Braden [ 05/Aug/09 ]

Can you reproduce the issue by running the installer from the console with "java -DTRACE=TRUE -DSTACKTRACE=TRUE -jar install.jar" and attach the resulting output here? Please also provide your install.xml containing the <pack/> definitions.

Comment by Kjell Braden [ 27/Jan/10 ]

I'm closing this issue as incomplete. When you provide the requested information, I'll reopen the bug.





[IZPACK-428] InstallerPanel: Installer panel fails in case <executable> element has <os> element inside Created: 09/Jul/09  Updated: 27/Jan/10

Status: Reopened
Project: IzPack
Component/s: Installer, Panels
Affects Version/s: 4.3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Kshitiz Saxena Assignee: Kjell Braden
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Number of attachments : 0

 Description   

If you define <execuatable> with <os> under <pack>, then installer does not perform any task on windows.
For example :
<executable targetfile="$INSTALL_PATH/uninstall.sh" stage="never">
<os family="unix"/>
</executable>

However it works fine if "os" is provided as attribute.
<executable targetfile="$

{LBPLUGIN_INSTALL_PATH}

/uninstall.sh" stage="never" os="unix"/>



 Comments   
Comment by Kjell Braden [ 05/Aug/09 ]

I can't reproduce your issue, using <os family="unix"/> results in the same behavior as os="unix" for me. Can you please clarify what you meant by "then installer does not perform any task on windows"? Setting os="unix" should never perform any task on windows. Also note that setting stage="never" should only mark files as executable, which has no effect on windows.

Comment by Kshitiz Saxena [ 03/Nov/09 ]

I meant if
<executable targetfile="$

{LBPLUGIN_INSTALL_PATH}/uninstall.sh" stage="never"><os="unix"/> </executable>
is used instead of
<executable targetfile="${LBPLUGIN_INSTALL_PATH}

/uninstall.sh" stage="never" os="unix"/>
then not even other tasks defined as pack name "Base" are executed on windows.

Comment by Kjell Braden [ 03/Nov/09 ]

You wrote <os="unix"/> - that's no valid XML. Try again with <os family="unix" /> and report back please.

Comment by Kshitiz Saxena [ 04/Nov/09 ]

Well I meant
<executable targetfile="$

{LBPLUGIN_INSTALL_PATH}

/uninstall.sh" stage="never">
<os family="unix"/>
</executable>

Comment by Kjell Braden [ 27/Jan/10 ]

Hi! Sorry for leaving you alone for so long. I just found IZPACK-364, which could be the issue you described. Can you please check with IzPack version 4.3.3 and see if the issue persists?





[IZPACK-427] UserInputPanel: inputs should not be validated when panel is reloaded due to checkbox/radiobutton having revalidate="yes" in their spec Created: 09/Jul/09  Updated: 29/Apr/11  Resolved: 27/Apr/11

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.1
Fix Version/s: 4.3.4

Type: Bug Priority: Major
Reporter: Kshitiz Saxena Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Generic


Issue Links:
Duplicate
is duplicated by IZPACK-603 UserInputPanel: inputs should not be ... Closed
Patch Submitted:
Yes
Number of attachments : 0

 Description   

Reload of panel calls all validator added to panel. Validator are executed even on reload, which should not be the case. Validator should only be executed when "next" button is clicked.

Following changes in izpack-src-trunk/src/lib/com/izforge/izpack/panels/UserInputPanel.java helps avoid validation in case of panel reload.
Variable "validating" already exists in code, however its usage has been commented out . I used it in few more places

Index: UserInputPanel.java
===================================================================
— UserInputPanel.java (revision 2817)
+++ UserInputPanel.java (working copy)
@@ -1196,7 +1196,7 @@
try
{
FileInputField panel = (FileInputField) field.getComponent();

  • result = panel.validateField();
    + result = !validating || panel.validateField();
    if (result)
    {
    idata.setVariable(field.getAssociatedVariable(), panel.getSelectedFile()
    @@ -1221,7 +1221,7 @@
    try
    {
    FileInputField input = (FileInputField) field.getComponent();
  • result = input.validateField();
    + result = !validating || input.validateField();
    if (result)
    {
    idata.setVariable(field.getAssociatedVariable(), input.getSelectedFile()
    @@ -1246,7 +1246,7 @@
    try
    {
    MultipleFileInputField input = (MultipleFileInputField) field.getComponent();
  • result = input.validateField();
    + result = !validating || input.validateField();
    if (result)
    {
    List<String> files = input.getSelectedFiles();
    @@ -1834,7 +1834,7 @@

// validate the input
Debug.trace("Validating text field");

  • boolean success = textField.validateContents();
    + boolean success = !validating || textField.validateContents();
    if (!success) { Debug.trace("Validation did not pass, message: " + message); @@ -3909,7 +3909,11 @@ // readInput(); // panelActivate(); // validating = true; + Debug.trace("Setting validating to false"); + validating=false; updateDialog(); + Debug.trace("Setting validating back to true"); + validating=true; }


 Comments   
Comment by Julien Ponge [ 30/Aug/10 ]

Formatting broke your patch. Could you please upload it as an attachment?

Comment by Sergiy Shyrkov [ 19/Apr/11 ]

I guess, the pasted patch is the same Kshitiz has posted in the mailing list: http://markmail.org/message/jbupthhx3zopfvrw

We are also interested in that patch.
Thank you in advance!

Kind regards
Sergiy

Comment by Julien Ponge [ 22/Apr/11 ]

Even so, I would prefer a fresh patch. The one is the mailing-list does not apply on the master branch.

Thanks

Comment by Sergiy Shyrkov [ 27/Apr/11 ]

By the way, this one is a duplicate of IZPACK-603

Julien, you've posted a comment in that ticket that no further releases are planned for 4.3 code branch.
Could you please confirm that 4.3.3 was the last release on that branch?
I guess, you can close this ticket as "Won't fix". A new ticket should be opened for the 5.x code base if the issue is still present.

Thank you in advance!

Kind regards
Sergiy

Comment by Julien Ponge [ 27/Apr/11 ]

We are releasing a 4.3.4 this week thanks to the work of a contributor called Mark Miller.

I am going to include that patch from IZPACK-603





[IZPACK-426] UserInputPanel: File/directory is filled will value even if provided empty value, even with allowEmptyValue="true" added to file/directory spec Created: 09/Jul/09  Updated: 30/Aug/10

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

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

Generic


Patch Submitted:
Yes
Number of attachments : 0

 Description   

Even if I add allowEmptyValue="true" to file/directory spec, there is a value provided for file/directory. The value provided is directory from where izpack jar is executed.

Below code changes in UserInputPanel.java is needed to fix this issue:
Index: UserInputPanel.java
===================================================================
— UserInputPanel.java (revision 2817)
+++ UserInputPanel.java (working copy)
@@ -1195,14 +1195,17 @@
boolean result = false;
try
{
FileInputField panel = (FileInputField) field.getComponent();
result = panel.validateField();
if (result)
{

  • idata.setVariable(field.getAssociatedVariable(), panel.getSelectedFile()
  • .getAbsolutePath());
  • entries.add(new TextValuePair(field.getAssociatedVariable(), panel
  • .getSelectedFile().getAbsolutePath()));
    + String value = "";
    + File inputFile = input.getSelectedFile();
    + if(inputFile != null && !inputFile.getName().equals("")) { + value = input.getSelectedFile().getAbsolutePath(); + }
    + idata.setVariable(field.getAssociatedVariable(), value);
    + entries.add(new TextValuePair(field.getAssociatedVariable(), value));
    }
    }
    catch (Exception e)
    @@ -1221,13 +1224,16 @@
    try
    {
    FileInputField input = (FileInputField) field.getComponent();
    result = input.validateField();
    if (result)
    {
    - idata.setVariable(field.getAssociatedVariable(), input.getSelectedFile()
    - .getAbsolutePath());
    - entries.add(new TextValuePair(field.getAssociatedVariable(), input
    - .getSelectedFile().getAbsolutePath()));
    + String value = "";
    + File inputFile = input.getSelectedFile();
    + if(inputFile != null && !inputFile.getName().equals("")){+ value = input.getSelectedFile().getAbsolutePath();+ }

    + idata.setVariable(field.getAssociatedVariable(), value);
    + entries.add(new TextValuePair(field.getAssociatedVariable(), value));
    }
    }
    catch (Exception e)



 Comments   
Comment by Julien Ponge [ 30/Aug/10 ]

Formatting broke your patch. Could you please upload it as an attachment?





[IZPACK-425] Installer does not create shortcuts under Solaris 10 JDS Created: 08/Jul/09  Updated: 08/Jul/09

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

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

Solaris 10
Java Desktop System


Number of attachments : 0

 Description   

The installer does not create shortcuts. I tried installing IzPack 4.3.0 as the test and tried both installing as root and as a normal user. In either case, no shortcuts or desktop items are created.






[IZPACK-424] unistaller should look more like the installer Created: 07/Jul/09  Updated: 30/Apr/13

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

Type: Improvement Priority: Minor
Reporter: Kjell Braden Assignee: Kjell Braden
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File IZPACK-424.patch    
Number of attachments : 1

 Description   

The uninstaller currently looks very simple, but does not match the installer's design. It would be great to have a way to

  1. Make the uninstaller look like the installer
  2. Configure the panels shown in the uninstaller


 Comments   
Comment by Kjell Braden [ 03/Feb/10 ]

I've attached a larger set of changes. I've tried to keep the them as non-intrusive as possible. It probably supersedes more or less large parts of the code for the old uninstaller, but I don't have the overview of the code to decide what can be stripped.
I don't dare to commit this yet, therefore I'd like to hear other opinions first.

 bin/langpacks/installer/deu.xml                               |   10
 bin/langpacks/installer/eng.xml                               |    9
 src/build.xml                                                 |   74 +++-
 src/dist-files/IzPack-install.xml                             |    8
 src/lib/com/izforge/izpack/compiler/Compiler.java             |    8
 src/lib/com/izforge/izpack/compiler/CompilerConfig.java       |   32 +
 src/lib/com/izforge/izpack/compiler/IPackager.java            |    5
 src/lib/com/izforge/izpack/compiler/MultiVolumePackager.java  |   63 +--
 src/lib/com/izforge/izpack/compiler/Packager.java             |   42 +-
 src/lib/com/izforge/izpack/compiler/PackagerBase.java         |   52 ++
 src/lib/com/izforge/izpack/compiler/PackagerHelper.java       |   56 ---
 src/lib/com/izforge/izpack/installer/UnpackerBase.java        |   74 +++-
 src/lib/com/izforge/izpack/panels/UninstallPanel.java         |  139 +++++++
 src/lib/com/izforge/izpack/panels/UninstallerFinishPanel.java |   92 ++++
 src/lib/com/izforge/izpack/panels/UninstallerHelloPanel.java  |  185 ++++++++++
 src/lib/com/izforge/izpack/rules/RulesEngine.java             |   13
 src/lib/com/izforge/izpack/rules/StaticCondition.java         |   61 +++
 src/lib/com/izforge/izpack/uninstaller/Uninstaller.java       |   58 +--
 src/lib/com/izforge/izpack/util/IoHelper.java                 |   21 +
 19 files changed, 822 insertions(+), 180 deletions(-)
Comment by Tim Anderson [ 27/Jun/12 ]

Appologies, but this patch is now too far out of date to apply to 5.0.
Do you want to resubmit it for the current 5.0 codebase?

Comment by Daniel Abson [ 19/Jul/12 ]

Is anybody currently working on this?

Comment by Tim Anderson [ 19/Jul/12 ]

Not that I know of.

Comment by Rene Krell [ 30/Apr/13 ]

Please send a pull request at Github against the current 5.0 head with these changes.
Thank you





[IZPACK-423] possibility to check for $ENV variable existance Created: 07/Jul/09  Updated: 06/Nov/09  Resolved: 14/Jul/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2

Type: Improvement Priority: Minor
Reporter: Kjell Braden 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   

(citing from mailing list)

currently, we ignore $ENV[] variables, when the key does not appear in
the environment (ie. $ENV[foo] would appear as $ENV[foo] if foo is unset).

In my project I have a UserInputPanel which presents a FileInputField,
defaulting to a path set in the environment. As there's currently no way
to check for existence of these, I suggest one of the following:

1.) make VariableExistanceCondition aware of $ENV[] variables
(probably better)
2.) let $ENV[] variables default to an empty path, if they don't exist
(probably easier)



 Comments   
Comment by Kjell Braden [ 07/Jul/09 ]

I've a two-lines patch ready for solution number 2.

Waiting for Juliens opinion until he returns.





[IZPACK-422] Opening shortcutPanel fails, if scandinavian characters (ÅÖÄ) in shortcut name and definition xml is in UTF-8 format Created: 07/Jul/09  Updated: 27/Jan/10  Resolved: 27/Jan/10

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2, 4.3.3, 5.0

Type: Bug Priority: Major
Reporter: Lauri Korpela Assignee: Kjell Braden
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WinXP
Java SE 6 update 14
Ant 1.7.1


Attachments: XML File install.xml     Java Archive File test_install.jar     XML File win_shortcuts.xml    
Number of attachments : 3

 Description   

The shortcut specification XML is saved with UTF-8 encoding and encoding element in the XML says it is UTF-8. When installer comes to ShortcutPanel, the following stack trace is printed (if run from the command prompt) and the ShortCutPanel is skipped. Please see the attachments.

ERROR: 'Invalid byte 2 of 3-byte UTF-8 sequence.'
ERROR: 'com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Invalid byte 2 of 3-byte UTF-8 sequence.'
javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Invalid byte 2 of 3-byte UTF-8 sequence.
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parseLineNrFromInputSource(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.readShortcutSpec(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.panelActivate(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(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: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Invalid byte 2 of 3-byte UTF-8 sequence.
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source)
... 36 more
Caused by: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Invalid byte 2 of 3-byte UTF-8 sequence.
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
... 37 more
---------
javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Invalid byte 2 of 3-byte UTF-8 sequence.
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parseLineNrFromInputSource(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.readShortcutSpec(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.panelActivate(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(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: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Invalid byte 2 of 3-byte UTF-8 sequence.
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
... 37 more
---------
com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Invalid byte 2 of 3-byte UTF-8 sequence.
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parseLineNrFromInputSource(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.readShortcutSpec(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.panelActivate(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(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)
---------
com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 2 of 3-byte UTF-8 sequence.
at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanLiteral(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLScanner.scanAttributeValue(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanAttribute(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.xml.sax.helpers.XMLFilterImpl.parse(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parseLineNrFromInputSource(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.readShortcutSpec(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.panelActivate(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(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)
---------
com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Invalid byte 2 of 3-byte UTF-8 sequence.
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parseLineNrFromInputSource(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.readShortcutSpec(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.panelActivate(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(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)
---------
com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 2 of 3-byte UTF-8 sequence.
at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanLiteral(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLScanner.scanAttributeValue(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanAttribute(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.xml.sax.helpers.XMLFilterImpl.parse(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parseLineNrFromInputSource(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.readShortcutSpec(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.panelActivate(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(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)
could not read shortcut spec!
java.lang.NullPointerException
at com.izforge.izpack.adaptator.impl.XMLParser.searchFirstElement(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.adaptator.impl.XMLParser.parse(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.readShortcutSpec(Unknown Source)
at com.izforge.izpack.panels.ShortcutPanel.panelActivate(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(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 Kjell Braden [ 05/Aug/09 ]

This is because we read the file in with UTF-8 encoding and then send it to the parser with the system's default encoding. I'll make it use UTF-8 again.

Comment by Lauri Korpela [ 18/Jan/10 ]

Any progress with this issue? This is holding me back for updating IzPack version in our project. So, it would be really nice if this would get fixed.

Cheers,
Lauri

Comment by Kjell Braden [ 27/Jan/10 ]

Sorry Lauri, this should be fixed since 4.3.2. Looks like I forgot to update the bug's status. Can you please test 4.3.3 as it is the latest version and see if the issue still exists?





[IZPACK-421] Text Fueld too small for UserPathPanel Created: 07/Jul/09  Updated: 21/Mar/12  Resolved: 21/Mar/12

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

Type: Bug Priority: Major
Reporter: Tonny Kohar Assignee: Julien Ponge
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File izpack-userpathpanel.png    
Number of attachments : 1

 Description   

The text field for UserPathPanel is to small. Please see the attached screenshoot.

It is tested on both MS Windows and Ubuntu Linux



 Comments   
Comment by Dustin Kut Moy Cheung [ 20/Mar/12 ]

Identical JIRA to IZPACK-337 and patch on IZPACK-337 applied to 4.3 branch
https://github.com/jponge/izpack/pull/13
[Should be closed as Duplicate]





[IZPACK-420] Update for Finnish langpack Created: 05/Jul/09  Updated: 05/Jul/09  Resolved: 05/Jul/09

Status: Closed
Project: IzPack
Component/s: Translations
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2

Type: Task Priority: Trivial
Reporter: Ari Voutilainen Assignee: Ari Voutilainen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0




[IZPACK-419] On Windows, to avoid the blank-in-path problem in parsable file, $INSTALL_PATH should be replaced by its 8.3 name, not by the full declared name Created: 04/Jul/09  Updated: 30/Mar/12  Resolved: 30/Mar/12

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

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

WXP SP2, Java 1.5


Number of attachments : 0

 Description   

Hi

I have a parsable file that contains a JVM property expressed as:

<config location="-Dlog4j.properties=file:///$INSTALL_PATH/cfg/log4j.xml">

When installing the product into C:\Program Files, the substittued value is

<config location="-Dlog4j.properties=file:///C:\Program Files/cfg/log4j.xml">

which leads to an exception or a misuse of the configuration file.

Thus, IsPack on WXP, should use the short standard 8.3 name instead of the full path name to avoid this blank-in-path problem.



 Comments   
Comment by Rene Krell [ 08/Feb/10 ]

I understand the problem, but I'm not sure about the solution you suggested.

The right solution here would be to make whitespaces simply work (with a fix or workaround), but not to fall back using 8.3 names, in case the operating system and Java normally fully supports whitespaces in file names.

Comment by Rene Krell [ 29/Mar/12 ]

Does this problem still exist for you in the latest IzPack 4 branch and 5 versions?
If yes, can you please send a stacktrace of the exception you mentioned. What is the problem, one with parsing the resulting XML?

Comment by Rene Krell [ 30/Mar/12 ]

In order to convert $INSTALL_PATH to an URL, use an own approach, or try using path names directly, without the URL notation.
For IzPack 5.0, one new approach could be a dynamic variable assignment with regular expression filtering/replacements, where you can replace the space by an %20.
The suggested solution is furthermore OS-dependent, if there are really more people which want an on-the-fly convertion of path names to an URL, I'd rather like an explicit expression to do this instead of using the Microsoft/vFat-specific 8.3 notation.





[IZPACK-418] Allow Automated Installer to parse variables in the 'value' field for UserInputPanel Created: 03/Jul/09  Updated: 30/Sep/09  Resolved: 30/Sep/09

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

Type: Improvement Priority: Minor
Reporter: Stuart Wallis Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

IzPack 4.0.0


Attachments: Text File UserInputPanelAutomationHelper.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

I have a requirement to allow variables to be parsed in the UserInputPanel of an Automated Installer to match the functionality in the GUI installer. For example here is a snippet from the XML response file.

<com.izforge.izpack.panels.UserInputPanel>
<userInput>
<entry key="key_host" value="$HOST_NAME"/>
</userInput>
</com.izforge.izpack.panels.UserInputPanel>

I have attached a patch file to allow this behavior.



 Comments   
Comment by Julien Ponge [ 30/Sep/09 ]

Thanks!





[IZPACK-417] HeadingPanel is not added to XInfoPanel when setting useHeadingPanel=yes Created: 03/Jul/09  Updated: 05/Feb/10  Resolved: 05/Feb/10

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

Type: Bug Priority: Minor
Reporter: Stuart Wallis Assignee: Unassigned
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Using IzPack 4.0.0 GA


Number of attachments : 0

 Description   

I am trying to modify a pre-existing installer to make use of the HeadingPanel feature using the following in my install.xml:

<modifier key="useHeadingPanel" value="yes"/>
<modifier key="headingImageOnLeft" value="yes"/>
<modifier key="headingLineCount" value="1"/>
<modifier key="headingFontSize" value="1.5"/>
<modifier key="headingBackgroundColor" value="0x00ffffff"/>
<modifier key="headingForegroundColor" value="0x00ffffff"/>
<modifier key="headingPanelCounter" value="progressbar"/>
<modifier key="headingPanelCounterPos" value="inNavigationPanel"/>

All panels display the Heading.image correctly with the exception of the XInfoPanel. For this panel the HeadingPanel is missing and XInfoPanel textArea fills the entire panel. I noted that the InfoPanel does show the HeadingPanel as expected however I already use an InfoPanel elsewhere in the installer so cannot switch to this panel type.



 Comments   
Comment by Stuart Wallis [ 05/Feb/10 ]

This issue was caused by the default langpack not having a headline defined for the XInfoPanel. For example.

<str id="XInfoPanel.headline" txt="Information"/>





[IZPACK-416] Maven plugin - copy *shortcut.xml as well as install.xml (or use in place without copying/filtering) Created: 03/Jul/09  Updated: 03/Jul/09

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

Type: Improvement Priority: Major
Reporter: Gwyn Evans Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

izpack maven plugin 1.0-alpha-5


Number of attachments : 0

 Description   

The plugin copies the IzPack descriptor file to the base folder, but not any shortcut files, which means that there needs to be some sort of fiddling around in order to either get them copied or to have (fragile) relative paths back from the build dir set in the descriptor file.

If the plugin could also copy "*shortcut.xml", (and/or just use the file without copying it) it would be a lot simpler to use the plugin.






[IZPACK-415] Pack name is used as reference Created: 03/Jul/09  Updated: 15/Dec/09

Status: Open
Project: IzPack
Component/s: Panels
Affects Version/s: 4.2.1, 4.3.0, 4.3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Laurian Vostinar Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all


Number of attachments : 0

 Description   

Pack name is used as reference when pack id should be used:

  • variable UserPathPanelDependsName
  • createForPack tag for defining shortcuts


 Comments   
Comment by Gregor B. Rosenauer [ 15/Dec/09 ]

Fully agree here - names which are used for the GUI and therefore are tuned to be user readable should not be used for internal references (conflicting goals!).
This makes installer.xml's unnecessarily brittle to change.

See also registrySpec.xml-format which also references packs by name:

<registry>
<pack name="">





[IZPACK-414] Keep same file order in pack Created: 03/Jul/09  Updated: 28/Jan/10  Resolved: 28/Jan/10

Status: Closed
Project: IzPack
Component/s: None
Affects Version/s: 4.2.1, 4.3.0, 4.3.1
Fix Version/s: 5.0

Type: Improvement Priority: Major
Reporter: Laurian Vostinar Assignee: Kjell Braden
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all


Attachments: Text File SameFileOrderInPack.txt    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The list of files for a pack is stored in a HashMap which leads to unknown order of files; LinkedHashMap should be used instead.



 Comments   
Comment by Kjell Braden [ 05/Aug/09 ]

Could you explain why this is a problem for you?

Comment by Laurian Vostinar [ 06/Aug/09 ]

This is related to http://jira.codehaus.org/browse/IZPACK-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ; the error didn't occur every time because the order of files was not the same making it difficult to figure out what was happenning.

Comment by Kjell Braden [ 28/Jan/10 ]

Pushed fix to trunk and 4.3 branch. Thanks.





[IZPACK-413] Mergeable Packs (a la Merge Modules) Created: 02/Jul/09  Updated: 02/Jul/09

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

Type: New Feature Priority: Major
Reporter: David Hoyt 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 think it'd be a great idea to have something similar to merge modules like in Windows installers. With merge modules, I can build a self-contained pack for my development work and then hand that to the installer guy who builds it into the installer. It's like creating a little installer module that is merged into the actual installer at a later time. You can't install the merge module by itself. You could, in theory, componetize the entire install and have it made up entirely of multiple merge modules.

This is primarily useful in environments where development is split between multiple groups, each contributing part of the whole product.

I hope this is making sense. In IzPack terms, it would be the equivalent of being able to compile an external pack. e.g.:

<installation version="2.0">
    ...
    <packs>
        <pack id="Core" name="Core" required="yes" module="my_jar_file_containing_a_pack.jar" />
        <pack id="ModuleA" name="Module A" required="no" module="my_jar_file_from_group_A.jar" />
        <pack id="ModuleB" name="Module B" required="no" module="my_jar_file_from_group_B.jar" />
    </packs>
    ...
</installation>

You can see how easy it would be to mix and match and create different installers.

The only difference between a typical, full installer and this being that each module would be able to define its own registry entries, shortcuts, variables, etc. IOW, it would be allowed to do only a subset of the total functionality.






[IZPACK-412] Password fields require at least one validator Created: 19/Jun/09  Updated: 06/Nov/09  Resolved: 21/Jun/09

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2

Type: Bug Priority: Minor
Reporter: Brian Krebs Assignee: Kjell Braden
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 20 minutes
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When you put a password field on a UserInputPanel, you must declare at least one validator or when you run the built installer, you can't advance past the UserInputPanel. The Next button isn't disabled, it just doesn't advance to the next panel properly.






[IZPACK-411] enable call of (Simple-)FinishPanel after antscript failed Created: 19/Jun/09  Updated: 19/Jun/09

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

Type: Improvement Priority: Minor
Reporter: Christoph Burmeister Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

izpacks AntActionInstallerListener


Number of attachments : 0

 Description   

We are using izpack's AntActionInstallerListener to call a database deployment tool called dbdeploy from inside the installer. All right, we install a pack "sql-scripts" and afterpack we let izpack do the antcall to dbdeploy. If ant is finished with succes, there is no problem, the next panel follows and the installation goes on. But if ant failed, for whatever-reasons, we only see an error frame with the detailled ant error-output and the "OK"-button. After pushing the button the installer ends unexpected. That means, the installer ends without a finishPanel which definitely says "Sorry, Installation Failed!"
Would be nice to get this issue fixed.






[IZPACK-410] TargetPanel.dir.windows_vista doesn't work Created: 19/Jun/09  Updated: 06/Nov/09  Resolved: 22/Aug/09

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.1
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Major
Reporter: Laurian Vostinar Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows vista


Attachments: Text File TargetPanelDirPatch.txt    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

specifying TargetPanel.dir.windows_vista has no effect in TargetPanel



 Comments   
Comment by Julien Ponge [ 22/Aug/09 ]

Thanks a lot for your patch!





[IZPACK-409] Release izpack-standalone-compiler to maven repository Created: 19/Jun/09  Updated: 23/Jun/09  Resolved: 23/Jun/09

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

Type: Task Priority: Major
Reporter: Thomas Diesler Assignee: Dan Tran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Please make the standalone compiler available here

http://repository.codehaus.org/org/codehaus/izpack/izpack-standalone-compiler/

Perhaps this can be added to the list of required release steps

This is an recurring issue that is related to IZPACK-374 and IZPACK-171



 Comments   
Comment by Julien Ponge [ 23/Jun/09 ]

Dan made the release





[IZPACK-408] Occasionally builds installer that throws EOFException when Unpacker attempts to read the number of parsable objects available. Created: 19/Jun/09  Updated: 06/Nov/09  Resolved: 06/Aug/09

Status: Closed
Project: IzPack
Component/s: Compiler
Affects Version/s: 4.2.1, 4.3.0, 4.3.1
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Minor
Reporter: Manny Lim Assignee: Kjell Braden
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 8.10, Windows XP


Attachments: Zip Archive EOFExceptionInstaller.zip    
Number of attachments : 1

 Description   

Occasionally, my build will create an installer that will throw EOFException in the InstallPanel. Heres the stack trace:

java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:375)
at java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:2776)
at java.io.ObjectInputStream.readInt(ObjectInputStream.java:950)
at com.izforge.izpack.installer.Unpacker.run(Unpacker.java:377)
at java.lang.Thread.run(Thread.java:619)

Without changing anything, subsequently building the installer again will produce an installer that may work correctly or may exhibit the same problem. I placed some debugging statements in the Packager and Unpacker to verify that the number of parsables, executables, and updatechecks is correct for each pack. The numbers are correct every time. However, in a broken installer, once the Unpacker has installed the files in the pack, the EOFException is thrown when the Unpacker attempts to read the next integer to determine the number of parsable file objects there are for the current pack.

After extracting the packs from working and broken installers and examining them, I've found they differ. I am able to de-serialize packs (using code adapted from the Unpacker) from the working installers, but fail to de-serialize packs from the broken installers (EOFException when I attempt to read the number of parsables).

I've managed to break down my install.xml into a simple example that exhibits this problem. Heres how the packs section of the example install.xml looks:

<packs>
<pack name="Application" id="application" required="no">
<description>
This may cause an EOFException.
</description>
<singlefile src="install.xml" target="$INSTALL_PATH/install.xml" />
<fileset dir="folder" targetdir="$INSTALL_PATH">
<os family="unix" arch="x64" />
<os family="unix" arch="x86_64" />
<os family="unix" arch="amd64" />
<os family="unix" arch="ia64" />
</fileset>
<executable targetfile="$INSTALL_PATH/install.xml"
stage="never">
<os family="unix" />
</executable>
</pack>
</packs>

Changing this around seems to fix the problem, however it does not explain why sometimes a working installer is created and sometimes a broken installer is created. Can someone explain to me why this may cause the pack to be serialized incorrectly?

To repeat:
I've included the install.xml and ant build.xml file I used to recreate this problem.
1) Substitute the location of your IzPack directory for the $

{izpack.dir}

property in the build file.
2) Create a directory called "folder" in the same directory as the install.xml file.
3) If you are on Windows, replace all instances of "unix" with "windows" in the install.xml file.
4) Run the exec.installer target to build the installer and run it. (You may have to do this several times to get an installer that throws EOFException).



 Comments   
Comment by Manny Lim [ 22/Jun/09 ]

Occurs on 32 bit systems.

Comment by Manny Lim [ 23/Jun/09 ]

The EOFException is caused by a bug in the Unpacker. The following conditions will re-create the EOFException problem:

1) The pack passes conditions for installation.
2) The last pack file is a directory.
3) The OS constraints for the last pack file (directory) does not match the current system.

What happens:
The Unpacker will iterate through all files in the pack. If the file's OS constraints match the current system, then it is unpacked, and everything is handled nicely. However, if the file's OS constraints do not match the current system, the Unpacker will try to discard that file's bytes from the InputStream, unless that file is a back reference. This means that the Unpacker will attempt to discard the bytes associated with directory type files, of which there are none since directories themselves are not serialized by the Packager. For most cases this logic has seemed to be working OK, when I examine the number of bytes discarded, it is 0.

However, if a directory ends up being the last file in the pack, and it's OS constraints do not match the current system, the Unpacker ends up discarding more than 0 bytes. This causes EOFException when an attempt is made to read the next integer to determine the number of parsables.

Comment by Manny Lim [ 25/Jun/09 ]

This also explains why the EOFException problem affects some installers but not others (of the same build). The order in which the pack files are serialized is determined by the iteration order of the HashMap data structure used to stored the PackFile objects, which is not guaranteed to be the same every time. So occasionally, the pack files are ordered such that the last file is a directory.

Comment by Laurian Vostinar [ 02/Jul/09 ]

It seems that Unpacker should ignore the folder's length when os constraint is not fulfilled. I have a patch for this, it works for me with this change:

### Eclipse Workspace Patch 1.0
#P IzPack
Index: src/lib/com/izforge/izpack/installer/Unpacker.java
===================================================================
--- src/lib/com/izforge/izpack/installer/Unpacker.java  (revision 2811)
+++ src/lib/com/izforge/izpack/installer/Unpacker.java  (working copy)
@@ -366,7 +366,7 @@
                     }
                     else
                     {
-                        if (!pf.isBackReference())
+                        if (!pf.isBackReference() && !pf.isDirectory())
                         {
                             objIn.skip(pf.length());
                         }
Comment by Manny Lim [ 02/Jul/09 ]

I believe this is the proper fix, thank you Laurian.

Comment by Laurian Vostinar [ 03/Jul/09 ]

I also added an improvement: https://svn.cargo.codehaus.org/browse/IZPACK-414 - Keep same file order in pack

Comment by Kjell Braden [ 06/Aug/09 ]

Thanks for your investigation and proposals, this should be fixed with revisions 2837/2838.





[IZPACK-407] No meaningful xml exception Created: 16/Jun/09  Updated: 06/Nov/09  Resolved: 17/Jun/09

Status: Closed
Project: IzPack
Component/s: None
Affects Version/s: 4.3.0, 4.3.1
Fix Version/s: 4.3.2

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

Number of attachments : 0

 Description   

The actual xml adaptator thows a NPE (for a parse error, for example) and "eat" other xml related exceptions. A possible improvement is to throw a meaningful exception.



 Comments   
Comment by David Duponchel [ 17/Jun/09 ]

XMLException added, and TransformerException thrown by the xml writer changed (svn rev 2810).





[IZPACK-406] Set a system property izpack.io.tmpdir and/or an automatic variable IZPACK_TMPDIR with a unique temporary directory for the current install session Created: 12/Jun/09  Updated: 19/Sep/12

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

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

From experience with my IzPack setups I use at the moment I suffer from the lack of a writable temporary directory, which is available in install.xml and which should be unique for one single installation session.

This could be achieved by setting a system property izpack.io.tmpdir and/or an automatic variable $

{IZPACK_TMPDIR}

initialized by File.createTempDir() in each installer session, which doesn't even have to be created automatically, but which can be used in install.xml as the target directory for temporary files. This directory should be writable for the current user. In each case it should be deleted at the end of the installer session, if it doesn't contain any more files (combined with the attribute keep="false").



 Comments   
Comment by Sérgio Michels [ 19/Sep/12 ]

I think this feature exists in 5 beta 11. In the info tag you can define to IzPack create a temporary directory:

<info>
  <tempdir />
</info>

And you can use the dir value with the variable $TEMP_DIRECTORY





[IZPACK-405] Add -console-auto option to read options from system properties Created: 10/Jun/09  Updated: 26/Aug/09  Resolved: 26/Aug/09

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

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

Attachments: GZip Archive izpack_enhance_unattended_installs_patch_r2796.txt.gz     GZip Archive izpack-issues_295_405_against_r2844.patch.gz    
Issue Links:
Related
is related to IZPACK-295 Installer support of Win Setup API - ... Resolved
Number of attachments : 2

 Description   

For better controlling an IzPack installation on the command line I would like to add a command line option "-console-auto" (or something similar) which does simply the same as "-options <property_file>" except that the installation properties will be read only from the system properties. This way it will be possible to have an unattended installation without preparing an external settings file in automated installation environment.

Example of usage:
java -DINSTALL_PATH=/opt -jar install.jar -console-auto

I have already prepared an implementation in my local SVN copy of the trunk which would handle this.
I don't know if you like this idea, but I need this requirement at my work, since we have use cases where we call the same installation on one computer more times installing into different mounted directories.



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

Maybe even better the option should be named "-options-system". If one option is missing there will be an error thrown, as during installing with "-options propfile.properties".

Comment by Rene Krell [ 11/Jun/09 ]

A the moment I have implemented and pre-tested the following implementation (in my SVN copy of the trunk):

Additional options:

  • -options-system
    Runs an unattended installation exclusively using system properties given on the command
    line.
  • -options-auto <propsfile>
    Runs an unattended installation while reading the properties from the
    properties file specified in <propsfile> and overwriting them with particular
    system properties given on the command line.

This meets all requirements for unattended installations for me at this time.
I don't know whether you might want this in the official version.

Comment by Julien Ponge [ 11/Jun/09 ]

You can always submit a patch

Comment by Rene Krell [ 11/Jun/09 ]

Here is the patch. Hopefully it works with your state of source code.

Comment by Rene Krell [ 11/Jun/09 ]

Another patch against the latest revision from trunk, otherwise there will be conflicts.

Comment by Julien Ponge [ 22/Aug/09 ]

Hi René, I just went into the code, but first I need to check your other patch for reboots, as this one seems to have it as a prerequisite.

Comment by Rene Krell [ 24/Aug/09 ]

Hi Julien,
this is a common patch for both issues, 295 and 405.

Those issues are absolutely independent concerning the implementation. There are only some particular files affected by both and I'm not able to separate them now so quickly, because I enqueued those changes over half a year in trunk. I hope this will not be a big deal.

A a hint, I give you a list of classes:

Issue 405:
com.izforge.izpack.installer.Installer
com.izforge.izpack.installer.PanelConsole
... and all classes implementing PanelConsole.java:
com.izforge.izpack.panels.FinishPanelConsoleHelper
com.izforge.izpack.panels.HelloPanelConsoleHelper
com.izforge.izpack.panels.HTMLLicencePanelConsoleHelper
com.izforge.izpack.panels.InstallPanelConsoleHelper
com.izforge.izpack.panels.JDKPathPanelConsoleHelper
com.izforge.izpack.panels.LicencePanelConsoleHelper
com.izforge.izpack.panels.TargetPanelConsoleHelper
com.izforge.izpack.panels.UserInputPanelConsoleHelper

Issue 295 + 405:
src/doc-reST/advanced-features.txt
#405: Section "Unattended installations" (merged with previous issues)
#295: the rest
com.izforge.izpack.installer.ConsoleInstaller
#295: method checkedReboot(),
#405: the rest

Just ask if you get into trouble with this.

BTW: There are many formatting issues due to trailing white spaces in the source code. I would appreciate to use an automatic tool for eliminating them for better patches and formatting, such as the AnyEdit plugin for Eclipse.

Thanks, René

Comment by Julien Ponge [ 26/Aug/09 ]

Thanks René.





[IZPACK-404] Pack200 Created: 07/Jun/09  Updated: 30/Sep/09

Status: Open
Project: IzPack
Component/s: Build, Documentation
Affects Version/s: 4.3.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Bruce Martin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 6 (build) Java 5 install


Number of attachments : 0

 Description   

One issue with Pack200 is when jar's are packed with Java 6, the unpack with java 5 may fail (one case is Netbeans RCP 6.0). This is a not a problem with all (or even most) jars but it is better to use java 5 when

1) I would suggest putting a warning in the documentation
2) There may be an option to force pack200 to build pack files that are compatible with prior version ???
3) Also I would suggest having the option of using pre-packed jars on disk. This has the advantage of
a) Speeding up install build
b) Can use jars packed on a different system (my jars do unpack with java 5 when packed with java 6) so
provided the other jars have been packed with Java 5, I can build with Java 6.

Note: I use pack200 files on disk then have ProcessPanel step to do the unpack once installed. On the whole this works well except the uninstaller does not delete the files.

Error you may get is:
Error: java.io.IOException: Corrupted pack file: magic/ver = CAFED00D/160.1 should be CAFED00D/150.7
Unpacking /home/knoppix/FFReport/iReport/ide8/modules/locale/org-netbeans-spi-palette_pl.jar
unpack: /home/knoppix/FFReport/iReport/ide8/modules/locale/org-netbeans-modules-lexer-editorbridge_ja.jar.pack to /home/knoppix/FFReport/iReport/ide8/modules/locale/org-netbeans-modules-lexer-editorbridge_ja.jar






[IZPACK-403] licence panel, the "Quit" button isn't displayed Created: 28/May/09  Updated: 16/Jun/09  Resolved: 11/Jun/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.0
Fix Version/s: 4.3.1

Type: Bug Priority: Minor
Reporter: Amélie Pellaprat Assignee: Julien Ponge
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

sunOs 5.10 Generic sun4u sparc SUNW,Ultre-250
java 1.6.0_06-b02


Attachments: PNG File bug_quit_button.png    
Number of attachments : 1

 Description   

When I tried run the installer, in licence panel, the "Quit" button isn't displayed.



 Comments   
Comment by Julien Ponge [ 29/May/09 ]

Looks like a problem of the underlying Java look and feel.

What if you use another look and feel? (e.g., JGoodies, Substance, ...)

Comment by Amélie Pellaprat [ 11/Jun/09 ]

Thank you, it works with an another look and feel.

Comment by Julien Ponge [ 11/Jun/09 ]

Thanks Amélie!





[IZPACK-402] In the UserInput Panel, a validator is being triggered on a password field, due to a dropdown selection change, before a value has been entered Created: 28/May/09  Updated: 28/May/09

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

Type: Bug Priority: Major
Reporter: Van Halbert 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 DBConnectionValidator is being triggered when the driver in the combo is being selected, and before the password had been entered (and therefore the database connection fails because of no password). This was working in 4.1

Here's the userInputSpec snippit:

<field type="combo" variable="driver">
<description align="left" txt="Select the JDBC Driver Class:"
id="combo.1.description.driver"/>
<spec>
<choice processor="com.izforge.izpack.processor.LoadJDBCDriverCombo" />
</spec>
<validator class="com.izforge.izpack.util.NotEmptyValidator" id="val.1.database.texterror" txt="Please select database driver"></validator>
</field>

<field type="text" variable="username">
<spec txt="User Name:" id="text.1.username" size="30" set="sa"/>
</field>
<field type="space"/>
<field type="password" variable="password">
<spec>
<pwd txt="Password" id="pwd.1.password" size="30" />
</spec>
<validator class="com.izforge.izpack.validator.DBConnectionValidator" txt="The database connection cannot be made, please check the connection properties" id="val.1.dsRepository.error"/>
</field>

Here is the stacktrace:

at com.izforge.izpack.validator.DBConnectionValidator.validate(DBConnectionValidator.java:122)
at com.izforge.izpack.panels.PasswordGroup.validateContents(PasswordGroup.java:170)
at com.izforge.izpack.panels.UserInputPanel.readPasswordField(UserInputPanel.java:2404)
at com.izforge.izpack.panels.UserInputPanel.readInput(UserInputPanel.java:1139)
at com.izforge.izpack.panels.UserInputPanel.isValidated(UserInputPanel.java:1018)
at com.izforge.izpack.panels.UserInputPanel.updateDialog(UserInputPanel.java:3950)
at com.izforge.izpack.panels.UserInputPanel.itemStateChanged(UserInputPanel.java:3942)
at javax.swing.JComboBox.fireItemStateChanged(JComboBox.java:1207)
at javax.swing.JComboBox.selectedItemChanged(JComboBox.java:1255)
at javax.swing.JComboBox.contentsChanged(JComboBox.java:1311)
at javax.swing.AbstractListModel.fireContentsChanged(AbstractListModel.java:100)
at javax.swing.DefaultComboBoxModel.setSelectedItem(DefaultComboBoxModel.java:88)
at javax.swing.JComboBox.setSelectedItem(JComboBox.java:559)

My thought for fixing this would be to change the itemstatechanegd method to only trigger the read/validation for the field that was entered. Currently it tries to process all fields when it calls readInput().






[IZPACK-401] add visible attribute to field element in User Input Panel Created: 25/May/09  Updated: 25/May/09

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

Type: Improvement Priority: Major
Reporter: Wang Linchuan 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   

Sometimes,people want to define a input text field with a default value(with attribute "set " ) but don't display it.
I tryed the attribute "conditionid" in field element. But it does not put the variable to the InstallData even if there is a default value (with attribute "set " ).



 Comments   
Comment by Wang Linchuan [ 25/May/09 ]

But I need the variable put into the InstallData whether the field display or not.





[IZPACK-400] Variable substitution result in relative path, although starting with / Created: 23/May/09  Updated: 22/Jul/09

Status: In Progress
Project: IzPack
Component/s: Compiler
Affects Version/s: 4.3.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sebastian Held Assignee: Kjell Braden
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

gentoo linux


Number of attachments : 0

 Description   

<variable name="t" value="/home/test"/>
<file src="$t/testfile" targetdir="$INSTALL_PATH/lib" override="update"/>

will generate the concatenation of "$t" "/." "<current directory>/testfile", which is wrong. It should result in /home/test/testfile






[IZPACK-399] Variable substitution does not work for fileset and res elements Created: 23/May/09  Updated: 07/Sep/11

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

Type: Bug Priority: Major
Reporter: Sebastian Held Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

gentoo linux


Number of attachments : 0

 Description   

<fileset dir="$qtdir/plugins/imageformats" [...] />
does not work, but <file src="$qtdir/lib/libQtCore.so.4" [...] /> does.

<res id="LicencePanel.licence" src="$trunk/LICENSE" [...] />
does not work either.



 Comments   
Comment by Christoph Panwinkler [ 26/Jan/10 ]

also on Windows 7 with variables declared in install.xml

e.g.
<variables>
...
<variable name="JAVA_VERSION" value="1.6.0_17" />
...
</variables>

<pack name="Java Runtime" parent="Core" required="yes">
<fileset dir="jdk-$

{JAVA_VERSION}

" targetdir="$

{INSTALL_PATH}

\jdk">
....
</fileset>
</pack>

Comment by Russell Bolles [ 10/Feb/11 ]

I found the problem in the source code. Not sure if I'm ready to become a contributor so I'm hoping someone who has their development environment set up will commit this change.

com.izforge.izpack.compiler.CompilerConfig.java
private void addPacksSingle(IXMLElement data) throws CompilerException

Add the marked lines (sorry about the formatting loss):

// We get the fileset list
iter = el.getChildrenNamed("fileset").iterator();
while (iter.hasNext())
{
IXMLElement f = iter.next();
String dir_attr = requireAttribute(f, "dir");

File dir = new File(dir_attr);

if (!dir.isAbsolute())

{ dir = new File(basedir, dir_attr); }

//ADDITION*****************************************************
if (!dir.exists())

{ dir = new File(varsubst.substitute(dir.getAbsolutePath(), null)); // next existance checking appears in pack.addFile }

//ADDITION*****************************************************

if (!dir.isDirectory()) // also tests '.exists()'

{ parseError(f, "Invalid directory 'dir': " + dir_attr); }




[IZPACK-398] Add a validator for whitespace in the TargetPanel Created: 22/May/09  Updated: 03/Feb/10  Resolved: 25/Jan/10

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

Type: Improvement Priority: Major
Reporter: Wang Linchuan Assignee: Julien Ponge
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File patch.txt    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Sometimes, the program will make an issue when there is any whitespace in the target directory.
Would you add a variable to check that.
When the pepole click the "next step" button, If there is any whitespace ,show some message and don't go to the next step;



 Comments   
Comment by Wang Linchuan [ 22/May/09 ]

I have add a variable "TargetPanel.allowWhitespaceInTargetPath".And there should be a id "TargetPanel.allowWhitespaceInTargetPath" in the i18n file.

Index: E:/ToolProjects/IzPack/src/lib/com/izforge/izpack/panels/TargetPanel.java
===================================================================
— E:/ToolProjects/IzPack/src/lib/com/izforge/izpack/panels/TargetPanel.java (revision 2776)
+++ E:/ToolProjects/IzPack/src/lib/com/izforge/izpack/panels/TargetPanel.java (working copy)
@@ -89,10 +89,31 @@

{ return (false); }

+ final String vAllow =
+ idata.getVariable("TargetPanel.allowWhitespaceInTargetPath");
+
+ if (vAllow == null || !Boolean.getBoolean(vAllow))
+ {
+ if(isThereIsAnyWhitespace(pathSelectionPanel.getPath()))

{ + emitError(parent.langpack.getString("installer.error"),getI18nStringForClass( + "allowWhitespaceInTargetPath", "TargetPanel")); + return (false); + }

+ }
idata.setInstallPath(pathSelectionPanel.getPath());
return (true);
}

+ private boolean isThereIsAnyWhitespace(String path)
+ {
+ for (int i = 0; i < path.length(); i++){
+ if(Character.isWhitespace(path.charAt))

{ + return true; + }

+ }
+ return false;
+ }
+
/**

  • Returns the default install directory. This is equal to
  • <code>PathInputPanel.getDefaultInstallDir</code>
Comment by Julien Ponge [ 23/May/09 ]

Thanks, I will have a look.

Comment by Julien Ponge [ 26/May/09 ]

Could you please attach the patch tp the issue rather have it inside your comment? Thanks!

Comment by Wang Linchuan [ 24/Aug/09 ]

I'm sorry for attach the patch so late.

Comment by Mike Youngstrom [ 04/Nov/09 ]

I hope this makes it into 4.3.2. This is just what my project needs.

Thanks.

Comment by Julien Ponge [ 06/Nov/09 ]

The proposed solution has 2 drawbacks, hence I am postponing it for 4.4.0 instead:

  1. there is no documentation update in the patch, and
  2. by default (i.e., if the configuration variable is not set) it does not allow whitespaces.
Comment by Niambh Scullion [ 03/Feb/10 ]

Hi Julien, I am just wondering if this is a candidate for the next release of IZPack? If so when is the release expected??

Many thanks in advance.
Niambh

Comment by Julien Ponge [ 03/Feb/10 ]

Hi,

See the previous comment + white spaces are normal in paths under all major operating systems, hence the default must be to accept them.

Cheers





[IZPACK-397] -console option does not display license file Created: 20/May/09  Updated: 16/Jun/09  Resolved: 11/Jun/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.0
Fix Version/s: 4.3.1

Type: Bug Priority: Minor
Reporter: Brian Santarelli Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File build_xml_for_LicensePanelConsoleHelpers_20090608_patch.txt     Text File src_lib_com_izforge_izpack_panels_LicensePanelConsoleHelpers_20090608_patch.txt    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

Invoking the installer in -console mode does not show the license file



 Comments   
Comment by Van Halbert [ 09/Jun/09 ]

Attached is a patch that adds the PanelConsoleHelpers classes for the License and HTMLLicense panels. The HTMLLicencePanelConsoleHelper uses regex expressions to strip out the html. It handles a lot of different tags, but I'm sure there could be others needed.

Also, included is the build.xml patch that addes the 2 new classes to the panel build process.

Comment by Julien Ponge [ 11/Jun/09 ]

Thanks Van for the patch!





[IZPACK-396] -console option does not use i18n langpack Created: 20/May/09  Updated: 27/Jan/10  Resolved: 27/Jan/10

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.0
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Minor
Reporter: Brian Santarelli Assignee: Kjell Braden
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


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

 Description   

When invoking an installer, there is no way to specify an i18n locale/langpack therefore the installer is always English language



 Comments   
Comment by Van Halbert [ 09/Jun/09 ]

Just a heads up. I'll soon (hope to) be submitting a patch to support langpacks running in console mode. I've got an existing patch awaiting acceptance before these changes can be submitted.

Comment by Van Halbert [ 11/Jun/09 ]

This adds lang support for the license and the userinput console helper panels.

Comment by Kjell Braden [ 06/Aug/09 ]

I lowered the priority because I added support for specifying a language pack via -language fra in revision 2830 (for IZPACK-445).

Is that ok for you?

Comment by Julien Ponge [ 30/Sep/09 ]

Kjell, any news on this issue?

Thanks!

Comment by Kjell Braden [ 27/Jan/10 ]

Closing as the reporter didn't object.





[IZPACK-395] EOFException in installer created with pack200 Created: 18/May/09  Updated: 06/Nov/09  Resolved: 22/Aug/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.0
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Minor
Reporter: Christoph Kutzinski Assignee: Julien Ponge
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, Sun JRE 1.6.0_13


Attachments: Text File izdiff.txt     Java Archive File Wremja-Installer-1.0-SNAPSHOT.jar    
Number of attachments : 2

 Description   

I've got an installer created with IzPack and the <pack200/> option enabled.
I.e.

<info>
...
<javaversion>1.6</javaversion>
<requiresjdk>no</requiresjdk>
<pack200/>
</info>

I can execute install with this installer only ONCE into the same target directory. If I try to install again into the same directory in get an exception whenthe wizard enters the InstallPanel:

java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readInt(Unknown Source)
at java.io.ObjectInputStream.readInt(Unknown Source)
at com.izforge.izpack.installer.Unpacker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

If I install into a different target directory, it works once. Installing again into that directory results in the same exception.



 Comments   
Comment by Christoph Kutzinski [ 18/May/09 ]

This is an installer which exhibits the described problem

Comment by Christoph Kutzinski [ 18/May/09 ]

BTW: the installer was created with the izpack-maven-plugin 1.0-alpha-5

Comment by Attila Magyar [ 21/Aug/09 ]

Imho this problem occurs if the target file is already exists and the installer tries to miss it by calling the skip method on the stream. I'm not sure if I understand the src correctly but, I think you should only skip 4 bytes if the current package is a Pack200 package, since the data itself is stored into a separated stream.

Comment by Attila Magyar [ 22/Aug/09 ]

I've attached a patch which appears to be working. Please check if this is correct.

Comment by Julien Ponge [ 22/Aug/09 ]

Thanks for your patch, it has been applied!





[IZPACK-394] Make parsable works on a embedded fileset element instead of on a single file Created: 18/May/09  Updated: 25/Jan/10  Resolved: 25/Jan/10

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

Type: Improvement Priority: Major
Reporter: zosrothko Assignee: Julien Ponge
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WXP Pro SP2, Java 1.5


Attachments: File IZPACK-394.diff    
Number of attachments : 1

 Description   

Hi

the element <parsable> is working on a single file while it would be adviseable to make it running over a set of files defined for example by an embedded <fileset> element. A usage of this extension would be to allow cross references of separate javadocs by updating the "href" URL in each javadoc.html of the referee.

Rgds



 Comments   
Comment by Laurian Vostinar [ 21/Jul/09 ]

I have a patch for this, as a result targetfile attribute will be no longer mandatory (you can just have a fileset inside a parsable tag). If targetfile is present file will be added, also will look for all filesets inside parsable; all existing files from fileset(s) will be added as parsables.

"patch.txt"
### Eclipse Workspace Patch 1.0
#P IzPack
Index: src/lib/com/izforge/izpack/compiler/CompilerConfig.java
===================================================================
--- src/lib/com/izforge/izpack/compiler/CompilerConfig.java (revision 2826)
+++ src/lib/com/izforge/izpack/compiler/CompilerConfig.java (working copy)
@@ -710,14 +710,48 @@
             while (iter.hasNext())
             {
                 IXMLElement p = iter.next();
-                String target = requireAttribute(p, "targetfile");
+                String target = p.getAttribute("targetfile", null);
                 String type = p.getAttribute("type", "plain");
                 String encoding = p.getAttribute("encoding", null);
                 List<OsConstraint> osList = OsConstraint.getOsList(p); // TODO: unverified
                 String condition = p.getAttribute("condition");
-                ParsableFile parsable = new ParsableFile(target, type, encoding, osList);
-                parsable.setCondition(condition);
-                pack.addParsable(parsable);
+                if (target != null)
+                {
+                    ParsableFile parsable = new ParsableFile(target, type, encoding, osList);
+                    parsable.setCondition(condition);
+                    pack.addParsable(parsable);
+                }
+                Iterator<IXMLElement> iterSet = p.getChildrenNamed("fileset").iterator();
+                while (iterSet.hasNext())
+                {
+                    IXMLElement f = iterSet.next();
+                    String targetdir = requireAttribute(f, "targetdir");
+                    String dir_attr = requireAttribute(f, "dir");
+                    File dir = new File(dir_attr);
+                    if (!dir.isAbsolute())
+                    {
+                        dir = new File(basedir, dir_attr);
+                    }
+                    if (!dir.isDirectory()) // also tests '.exists()'
+                    {
+                        parseError(f, "Invalid directory 'dir': " + dir_attr);
+                    }
+                    String []includedFiles = getFilesetIncludedFiles(f);
+                    if (includedFiles != null)
+                    {
+                        for (String filePath:includedFiles)
+                        {
+                            File file = new File(dir,filePath);
+                            if (file.exists() && file.isFile())
+                            {
+                                String targetFile = new File(targetdir, filePath).getPath();
+                                ParsableFile parsable = new ParsableFile(targetFile, type, encoding, osList);
+                                parsable.setCondition(condition);
+                                pack.addParsable(parsable);
+                            }
+                        }
+                    }
+                }
             }

             // We get the executables list
@@ -872,8 +906,8 @@
             while (iter.hasNext())
             {
                 IXMLElement f = iter.next();
+                String targetdir = requireAttribute(f, "targetdir");
                 String dir_attr = requireAttribute(f, "dir");
-
                 File dir = new File(dir_attr);
                 if (!dir.isAbsolute())
                 {
@@ -883,127 +917,28 @@
                 {
                     parseError(f, "Invalid directory 'dir': " + dir_attr);
                 }
-
-                boolean casesensitive = validateYesNoAttribute(f, "casesensitive", YES);
-                boolean defexcludes = validateYesNoAttribute(f, "defaultexcludes", YES);
-                String targetdir = requireAttribute(f, "targetdir");
+                String []includedFiles = getFilesetIncludedFiles(f);
                 List<OsConstraint> osList = OsConstraint.getOsList(f); // TODO: unverified
                 int override = getOverrideValue(f);
                 Map additionals = getAdditionals(f);
                 String condition = f.getAttribute("condition");
-
-                // get includes and excludes
-                Vector<IXMLElement> xcludesList = null;
-                String[] includes = null;
-                xcludesList = f.getChildrenNamed("include");
-                if (!xcludesList.isEmpty())
+                if (includedFiles != null)
                 {
-                    includes = new String[xcludesList.size()];
-                    for (int j = 0; j < xcludesList.size(); j++)
+                    for (String filePath:includedFiles)
                     {
-                        IXMLElement xclude = xcludesList.get(j);
-                        includes[j] = requireAttribute(xclude, "name");
-                    }
-                }
-                String[] excludes = null;
-                xcludesList = f.getChildrenNamed("exclude");
-                if (!xcludesList.isEmpty())
-                {
-                    excludes = new String[xcludesList.size()];
-                    for (int j = 0; j < xcludesList.size(); j++)
-                    {
-                        IXMLElement xclude = xcludesList.get(j);
-                        excludes[j] = requireAttribute(xclude, "name");
-                    }
-                }
-
-                // parse additional fileset attributes "includes" and "excludes"
-                String[] toDo = new String[]{"includes", "excludes"};
-                // use the existing containers filled from include and exclude
-                // and add the includes and excludes to it
-                String[][] containers = new String[][]{includes, excludes};
-                for (int j = 0; j < toDo.length; ++j)
-                {
-                    String inex = f.getAttribute(toDo[j]);
-                    if (inex != null && inex.length() > 0)
-                    { // This is the same "splitting" as ant PatternSet do ...
-                        StringTokenizer tok = new StringTokenizer(inex, ", ", false);
-                        int newSize = tok.countTokens();
-                        int k = 0;
-                        String[] nCont = null;
-                        if (containers[j] != null && containers[j].length > 0)
-                        { // old container exist; create a new which can hold
-                            // all values
-                            // and copy the old stuff to the front
-                            newSize += containers[j].length;
-                            nCont = new String[newSize];
-                            for (; k < containers[j].length; ++k)
-                            {
-                                nCont[k] = containers[j][k];
-                            }
-                        }
-                        if (nCont == null) // No container for old values
-                        // created,
-                        // create a new one.
+                        try
                         {
-                            nCont = new String[newSize];
+                            File file = new File(dir,filePath);
+                            String target = new File(targetdir, filePath).getPath();
+                            pack.addFile(baseDir, file, target, osList, override,
+                                    additionals, condition);
                         }
-                        for (; k < newSize; ++k)
-                        // Fill the new one or expand the existent container
+                        catch (FileNotFoundException x)
                         {
-                            nCont[k] = tok.nextToken();
+                            parseError(f, x.getMessage(), x);
                         }
-                        containers[j] = nCont;
                     }
                 }
-                includes = containers[0]; // push the new includes to the
-                // local var
-                excludes = containers[1]; // push the new excludes to the
-                // local var
-
-                // scan and add fileset
-                DirectoryScanner ds = new DirectoryScanner();
-                ds.setIncludes(includes);
-                ds.setExcludes(excludes);
-                if (defexcludes)
-                {
-                    ds.addDefaultExcludes();
-                }
-                ds.setBasedir(dir);
-                ds.setCaseSensitive(casesensitive);
-                ds.scan();
-
-                String[] files = ds.getIncludedFiles();
-                String[] dirs = ds.getIncludedDirectories();
-
-                // Directory scanner has done recursion, add files and
-                // directories
-                for (String file : files)
-                {
-                    try
-                    {
-                        String target = new File(targetdir, file).getPath();
-                        pack.addFile(baseDir, new File(dir, file), target, osList, override,
-                                additionals, condition);
-                    }
-                    catch (FileNotFoundException x)
-                    {
-                        parseError(f, x.getMessage(), x);
-                    }
-                }
-                for (String dir1 : dirs)
-                {
-                    try
-                    {
-                        String target = new File(targetdir, dir1).getPath();
-                        pack.addFile(baseDir, new File(dir, dir1), target, osList, override,
-                                additionals, condition);
-                    }
-                    catch (FileNotFoundException x)
-                    {
-                        parseError(f, x.getMessage(), x);
-                    }
-                }
             }

             // get the updatechecks list
@@ -1119,7 +1054,120 @@

         notifyCompilerListener("addPacksSingle", CompilerListener.END, data);
     }
+    private String[] getFilesetIncludedFiles(IXMLElement f) throws CompilerException
+    {
+        List<String> includedFiles = new ArrayList<String>();
+        String dir_attr = requireAttribute(f, "dir");

+        File dir = new File(dir_attr);
+        if (!dir.isAbsolute())
+        {
+            dir = new File(basedir, dir_attr);
+        }
+        if (!dir.isDirectory()) // also tests '.exists()'
+        {
+            parseError(f, "Invalid directory 'dir': " + dir_attr);
+        }
+
+        boolean casesensitive = validateYesNoAttribute(f, "casesensitive", YES);
+        boolean defexcludes = validateYesNoAttribute(f, "defaultexcludes", YES);
+
+        // get includes and excludes
+        Vector<IXMLElement> xcludesList = null;
+        String[] includes = null;
+        xcludesList = f.getChildrenNamed("include");
+        if (!xcludesList.isEmpty())
+        {
+            includes = new String[xcludesList.size()];
+            for (int j = 0; j < xcludesList.size(); j++)
+            {
+                IXMLElement xclude = xcludesList.get(j);
+                includes[j] = requireAttribute(xclude, "name");
+            }
+        }
+        String[] excludes = null;
+        xcludesList = f.getChildrenNamed("exclude");
+        if (!xcludesList.isEmpty())
+        {
+            excludes = new String[xcludesList.size()];
+            for (int j = 0; j < xcludesList.size(); j++)
+            {
+                IXMLElement xclude = xcludesList.get(j);
+                excludes[j] = requireAttribute(xclude, "name");
+            }
+        }
+
+        // parse additional fileset attributes "includes" and "excludes"
+        String[] toDo = new String[]{"includes", "excludes"};
+        // use the existing containers filled from include and exclude
+        // and add the includes and excludes to it
+        String[][] containers = new String[][]{includes, excludes};
+        for (int j = 0; j < toDo.length; ++j)
+        {
+            String inex = f.getAttribute(toDo[j]);
+            if (inex != null && inex.length() > 0)
+            { // This is the same "splitting" as ant PatternSet do ...
+                StringTokenizer tok = new StringTokenizer(inex, ", ", false);
+                int newSize = tok.countTokens();
+                int k = 0;
+                String[] nCont = null;
+                if (containers[j] != null && containers[j].length > 0)
+                { // old container exist; create a new which can hold
+                    // all values
+                    // and copy the old stuff to the front
+                    newSize += containers[j].length;
+                    nCont = new String[newSize];
+                    for (; k < containers[j].length; ++k)
+                    {
+                        nCont[k] = containers[j][k];
+                    }
+                }
+                if (nCont == null) // No container for old values
+                // created,
+                // create a new one.
+                {
+                    nCont = new String[newSize];
+                }
+                for (; k < newSize; ++k)
+                // Fill the new one or expand the existent container
+                {
+                    nCont[k] = tok.nextToken();
+                }
+                containers[j] = nCont;
+            }
+        }
+        includes = containers[0]; // push the new includes to the
+        // local var
+        excludes = containers[1]; // push the new excludes to the
+        // local var
+
+        // scan and add fileset
+        DirectoryScanner ds = new DirectoryScanner();
+        ds.setIncludes(includes);
+        ds.setExcludes(excludes);
+        if (defexcludes)
+        {
+            ds.addDefaultExcludes();
+        }
+        ds.setBasedir(dir);
+        ds.setCaseSensitive(casesensitive);
+        ds.scan();
+
+        String[] files = ds.getIncludedFiles();
+        String[] dirs = ds.getIncludedDirectories();
+
+        // Directory scanner has done recursion, add files and
+        // directories
+        for (String file : files)
+        {
+            includedFiles.add( file);
+        }
+        for (String dir1 : dirs)
+        {
+            includedFiles.add( dir1);
+        }
+        return includedFiles.toArray(new String[]{});
+    }
     private IXMLElement readRefPackData(String refFileName, boolean isselfcontained)
             throws CompilerException {
         File refXMLFile = new File(refFileName);
Index: src/lib/com/izforge/izpack/installer/WebRepositoryAccessor.java
===================================================================
--- src/lib/com/izforge/izpack/installer/WebRepositoryAccessor.java (revision 2811)
+++ src/lib/com/izforge/izpack/installer/WebRepositoryAccessor.java (working copy)
@@ -357,12 +357,14 @@
             while (iter.hasNext())
             {
                 IXMLElement p = iter.next();
-                String target = requireAttribute(p, "targetfile");
+                String target = p.getAttribute("targetfile", null);
                 String type = p.getAttribute("type", "plain");
                 String encoding = p.getAttribute("encoding", null);
                 List<OsConstraint> osList = OsConstraint.getOsList(p); // TODO: unverified
-
-                pack.addParsable(new ParsableFile(target, type, encoding, osList));
+                if (target != null)
+                {
+                    pack.addParsable(new ParsableFile(target, type, encoding, osList));
+                }
             }

             // We get the executables list 
Comment by Laurian Vostinar [ 30/Jul/09 ]

I improved the patch a bit:

"patch.txt"
### Eclipse Workspace Patch 1.0
#P IzPack
Index: src/lib/com/izforge/izpack/compiler/CompilerConfig.java
===================================================================
--- src/lib/com/izforge/izpack/compiler/CompilerConfig.java (revision 2826)
+++ src/lib/com/izforge/izpack/compiler/CompilerConfig.java (working copy)
@@ -710,14 +710,48 @@
             while (iter.hasNext())
             {
                 IXMLElement p = iter.next();
-                String target = requireAttribute(p, "targetfile");
+                String target = p.getAttribute("targetfile", null);
                 String type = p.getAttribute("type", "plain");
                 String encoding = p.getAttribute("encoding", null);
                 List<OsConstraint> osList = OsConstraint.getOsList(p); // TODO: unverified
                 String condition = p.getAttribute("condition");
-                ParsableFile parsable = new ParsableFile(target, type, encoding, osList);
-                parsable.setCondition(condition);
-                pack.addParsable(parsable);
+                if (target != null)
+                {
+                    ParsableFile parsable = new ParsableFile(target, type, encoding, osList);
+                    parsable.setCondition(condition);
+                    pack.addParsable(parsable);
+                }
+                Iterator<IXMLElement> iterSet = p.getChildrenNamed("fileset").iterator();
+                while (iterSet.hasNext())
+                {
+                    IXMLElement f = iterSet.next();
+                    String targetdir = requireAttribute(f, "targetdir");
+                    String dir_attr = requireAttribute(f, "dir");
+                    File dir = new File(dir_attr);
+                    if (!dir.isAbsolute())
+                    {
+                        dir = new File(basedir, dir_attr);
+                    }
+                    if (!dir.isDirectory()) // also tests '.exists()'
+                    {
+                        parseError(f, "Invalid directory 'dir': " + dir_attr);
+                    }
+                    String []includedFiles = getFilesetIncludedFiles(f);
+                    if (includedFiles != null)
+                    {
+                        for (String filePath:includedFiles)
+                        {
+                            File file = new File(dir,filePath);
+                            if (file.exists() && file.isFile())
+                            {
+                                String targetFile = new File(targetdir, filePath).getPath().replace(File.separatorChar, '/');
+                                ParsableFile parsable = new ParsableFile(targetFile, type, encoding, osList);
+                                parsable.setCondition(condition);
+                                pack.addParsable(parsable);
+                            }
+                        }
+                    }
+                }
             }

             // We get the executables list
@@ -872,8 +906,8 @@
             while (iter.hasNext())
             {
                 IXMLElement f = iter.next();
+                String targetdir = requireAttribute(f, "targetdir");
                 String dir_attr = requireAttribute(f, "dir");
-
                 File dir = new File(dir_attr);
                 if (!dir.isAbsolute())
                 {
@@ -883,127 +917,28 @@
                 {
                     parseError(f, "Invalid directory 'dir': " + dir_attr);
                 }
-
-                boolean casesensitive = validateYesNoAttribute(f, "casesensitive", YES);
-                boolean defexcludes = validateYesNoAttribute(f, "defaultexcludes", YES);
-                String targetdir = requireAttribute(f, "targetdir");
+                String []includedFiles = getFilesetIncludedFiles(f);
                 List<OsConstraint> osList = OsConstraint.getOsList(f); // TODO: unverified
                 int override = getOverrideValue(f);
                 Map additionals = getAdditionals(f);
                 String condition = f.getAttribute("condition");
-
-                // get includes and excludes
-                Vector<IXMLElement> xcludesList = null;
-                String[] includes = null;
-                xcludesList = f.getChildrenNamed("include");
-                if (!xcludesList.isEmpty())
+                if (includedFiles != null)
                 {
-                    includes = new String[xcludesList.size()];
-                    for (int j = 0; j < xcludesList.size(); j++)
+                    for (String filePath:includedFiles)
                     {
-                        IXMLElement xclude = xcludesList.get(j);
-                        includes[j] = requireAttribute(xclude, "name");
-                    }
-                }
-                String[] excludes = null;
-                xcludesList = f.getChildrenNamed("exclude");
-                if (!xcludesList.isEmpty())
-                {
-                    excludes = new String[xcludesList.size()];
-                    for (int j = 0; j < xcludesList.size(); j++)
-                    {
-                        IXMLElement xclude = xcludesList.get(j);
-                        excludes[j] = requireAttribute(xclude, "name");
-                    }
-                }
-
-                // parse additional fileset attributes "includes" and "excludes"
-                String[] toDo = new String[]{"includes", "excludes"};
-                // use the existing containers filled from include and exclude
-                // and add the includes and excludes to it
-                String[][] containers = new String[][]{includes, excludes};
-                for (int j = 0; j < toDo.length; ++j)
-                {
-                    String inex = f.getAttribute(toDo[j]);
-                    if (inex != null && inex.length() > 0)
-                    { // This is the same "splitting" as ant PatternSet do ...
-                        StringTokenizer tok = new StringTokenizer(inex, ", ", false);
-                        int newSize = tok.countTokens();
-                        int k = 0;
-                        String[] nCont = null;
-                        if (containers[j] != null && containers[j].length > 0)
-                        { // old container exist; create a new which can hold
-                            // all values
-                            // and copy the old stuff to the front
-                            newSize += containers[j].length;
-                            nCont = new String[newSize];
-                            for (; k < containers[j].length; ++k)
-                            {
-                                nCont[k] = containers[j][k];
-                            }
-                        }
-                        if (nCont == null) // No container for old values
-                        // created,
-                        // create a new one.
+                        try
                         {
-                            nCont = new String[newSize];
+                            File file = new File(dir,filePath);
+                            String target = new File(targetdir, filePath).getPath();
+                            pack.addFile(baseDir, file, target, osList, override,
+                                    additionals, condition);
                         }
-                        for (; k < newSize; ++k)
-                        // Fill the new one or expand the existent container
+                        catch (FileNotFoundException x)
                         {
-                            nCont[k] = tok.nextToken();
+                            parseError(f, x.getMessage(), x);
                         }
-                        containers[j] = nCont;
                     }
                 }
-                includes = containers[0]; // push the new includes to the
-                // local var
-                excludes = containers[1]; // push the new excludes to the
-                // local var
-
-                // scan and add fileset
-                DirectoryScanner ds = new DirectoryScanner();
-                ds.setIncludes(includes);
-                ds.setExcludes(excludes);
-                if (defexcludes)
-                {
-                    ds.addDefaultExcludes();
-                }
-                ds.setBasedir(dir);
-                ds.setCaseSensitive(casesensitive);
-                ds.scan();
-
-                String[] files = ds.getIncludedFiles();
-                String[] dirs = ds.getIncludedDirectories();
-
-                // Directory scanner has done recursion, add files and
-                // directories
-                for (String file : files)
-                {
-                    try
-                    {
-                        String target = new File(targetdir, file).getPath();
-                        pack.addFile(baseDir, new File(dir, file), target, osList, override,
-                                additionals, condition);
-                    }
-                    catch (FileNotFoundException x)
-                    {
-                        parseError(f, x.getMessage(), x);
-                    }
-                }
-                for (String dir1 : dirs)
-                {
-                    try
-                    {
-                        String target = new File(targetdir, dir1).getPath();
-                        pack.addFile(baseDir, new File(dir, dir1), target, osList, override,
-                                additionals, condition);
-                    }
-                    catch (FileNotFoundException x)
-                    {
-                        parseError(f, x.getMessage(), x);
-                    }
-                }
             }

             // get the updatechecks list
@@ -1119,7 +1054,120 @@

         notifyCompilerListener("addPacksSingle", CompilerListener.END, data);
     }
+    private String[] getFilesetIncludedFiles(IXMLElement f) throws CompilerException
+    {
+        List<String> includedFiles = new ArrayList<String>();
+        String dir_attr = requireAttribute(f, "dir");

+        File dir = new File(dir_attr);
+        if (!dir.isAbsolute())
+        {
+            dir = new File(basedir, dir_attr);
+        }
+        if (!dir.isDirectory()) // also tests '.exists()'
+        {
+            parseError(f, "Invalid directory 'dir': " + dir_attr);
+        }
+
+        boolean casesensitive = validateYesNoAttribute(f, "casesensitive", YES);
+        boolean defexcludes = validateYesNoAttribute(f, "defaultexcludes", YES);
+
+        // get includes and excludes
+        Vector<IXMLElement> xcludesList = null;
+        String[] includes = null;
+        xcludesList = f.getChildrenNamed("include");
+        if (!xcludesList.isEmpty())
+        {
+            includes = new String[xcludesList.size()];
+            for (int j = 0; j < xcludesList.size(); j++)
+            {
+                IXMLElement xclude = xcludesList.get(j);
+                includes[j] = requireAttribute(xclude, "name");
+            }
+        }
+        String[] excludes = null;
+        xcludesList = f.getChildrenNamed("exclude");
+        if (!xcludesList.isEmpty())
+        {
+            excludes = new String[xcludesList.size()];
+            for (int j = 0; j < xcludesList.size(); j++)
+            {
+                IXMLElement xclude = xcludesList.get(j);
+                excludes[j] = requireAttribute(xclude, "name");
+            }
+        }
+
+        // parse additional fileset attributes "includes" and "excludes"
+        String[] toDo = new String[]{"includes", "excludes"};
+        // use the existing containers filled from include and exclude
+        // and add the includes and excludes to it
+        String[][] containers = new String[][]{includes, excludes};
+        for (int j = 0; j < toDo.length; ++j)
+        {
+            String inex = f.getAttribute(toDo[j]);
+            if (inex != null && inex.length() > 0)
+            { // This is the same "splitting" as ant PatternSet do ...
+                StringTokenizer tok = new StringTokenizer(inex, ", ", false);
+                int newSize = tok.countTokens();
+                int k = 0;
+                String[] nCont = null;
+                if (containers[j] != null && containers[j].length > 0)
+                { // old container exist; create a new which can hold
+                    // all values
+                    // and copy the old stuff to the front
+                    newSize += containers[j].length;
+                    nCont = new String[newSize];
+                    for (; k < containers[j].length; ++k)
+                    {
+                        nCont[k] = containers[j][k];
+                    }
+                }
+                if (nCont == null) // No container for old values
+                // created,
+                // create a new one.
+                {
+                    nCont = new String[newSize];
+                }
+                for (; k < newSize; ++k)
+                // Fill the new one or expand the existent container
+                {
+                    nCont[k] = tok.nextToken();
+                }
+                containers[j] = nCont;
+            }
+        }
+        includes = containers[0]; // push the new includes to the
+        // local var
+        excludes = containers[1]; // push the new excludes to the
+        // local var
+
+        // scan and add fileset
+        DirectoryScanner ds = new DirectoryScanner();
+        ds.setIncludes(includes);
+        ds.setExcludes(excludes);
+        if (defexcludes)
+        {
+            ds.addDefaultExcludes();
+        }
+        ds.setBasedir(dir);
+        ds.setCaseSensitive(casesensitive);
+        ds.scan();
+
+        String[] files = ds.getIncludedFiles();
+        String[] dirs = ds.getIncludedDirectories();
+
+        // Directory scanner has done recursion, add files and
+        // directories
+        for (String file : files)
+        {
+            includedFiles.add( file);
+        }
+        for (String dir1 : dirs)
+        {
+            includedFiles.add( dir1);
+        }
+        return includedFiles.toArray(new String[]{});
+    }
     private IXMLElement readRefPackData(String refFileName, boolean isselfcontained)
             throws CompilerException {
         File refXMLFile = new File(refFileName);
Index: src/lib/com/izforge/izpack/installer/WebRepositoryAccessor.java
===================================================================
--- src/lib/com/izforge/izpack/installer/WebRepositoryAccessor.java (revision 2811)
+++ src/lib/com/izforge/izpack/installer/WebRepositoryAccessor.java (working copy)
@@ -357,12 +357,14 @@
             while (iter.hasNext())
             {
                 IXMLElement p = iter.next();
-                String target = requireAttribute(p, "targetfile");
+                String target = p.getAttribute("targetfile", null);
                 String type = p.getAttribute("type", "plain");
                 String encoding = p.getAttribute("encoding", null);
                 List<OsConstraint> osList = OsConstraint.getOsList(p); // TODO: unverified
-
-                pack.addParsable(new ParsableFile(target, type, encoding, osList));
+                if (target != null)
+                {
+                    pack.addParsable(new ParsableFile(target, type, encoding, osList));
+                }
             }

             // We get the executables list 
Comment by Julien Ponge [ 30/Sep/09 ]

The patch does not apply.

Comment by Laurian Vostinar [ 29/Oct/09 ]

There were some changes to CompilerConfig.java, I merged it. Here is the updated patch:

patch.txt
### Eclipse Workspace Patch 1.0
#P IzPack
Index: src/lib/com/izforge/izpack/compiler/CompilerConfig.java
===================================================================
--- src/lib/com/izforge/izpack/compiler/CompilerConfig.java (revision 2875)
+++ src/lib/com/izforge/izpack/compiler/CompilerConfig.java (working copy)
@@ -710,14 +710,48 @@
             while (iter.hasNext())
             {
                 IXMLElement p = iter.next();
-                String target = requireAttribute(p, "targetfile");
+                String target = p.getAttribute("targetfile", null);
                 String type = p.getAttribute("type", "plain");
                 String encoding = p.getAttribute("encoding", null);
                 List<OsConstraint> osList = OsConstraint.getOsList(p); // TODO: unverified
                 String condition = p.getAttribute("condition");
-                ParsableFile parsable = new ParsableFile(target, type, encoding, osList);
-                parsable.setCondition(condition);
-                pack.addParsable(parsable);
+                if (target != null)
+                {
+                    ParsableFile parsable = new ParsableFile(target, type, encoding, osList);
+                    parsable.setCondition(condition);
+                    pack.addParsable(parsable);
+                }
+                Iterator<IXMLElement> iterSet = p.getChildrenNamed("fileset").iterator();
+                while (iterSet.hasNext())
+                {
+                    IXMLElement f = iterSet.next();
+                    String targetdir = requireAttribute(f, "targetdir");
+                    String dir_attr = requireAttribute(f, "dir");
+                    File dir = new File(dir_attr);
+                    if (!dir.isAbsolute())
+                    {
+                        dir = new File(basedir, dir_attr);
+                    }
+                    if (!dir.isDirectory()) // also tests '.exists()'
+                    {
+                        parseError(f, "Invalid directory 'dir': " + dir_attr);
+                    }
+                    String []includedFiles = getFilesetIncludedFiles(f);
+                    if (includedFiles != null)
+                    {
+                        for (String filePath:includedFiles)
+                        {
+                            File file = new File(dir,filePath);
+                            if (file.exists() && file.isFile())
+                            {
+                                String targetFile = new File(targetdir, filePath).getPath().replace(File.separatorChar, '/');
+                                ParsableFile parsable = new ParsableFile(targetFile, type, encoding, osList);
+                                parsable.setCondition(condition);
+                                pack.addParsable(parsable);
+                            }
+                        }
+                    }
+                }
             }

             // We get the executables list
@@ -876,7 +910,8 @@
             {
                 IXMLElement f = iter.next();
                 String dir_attr = requireAttribute(f, "dir");
-
+                String targetdir = requireAttribute(f, "targetdir");
+
                 File dir = new File(dir_attr);
                 if (!dir.isAbsolute())
                 {
@@ -887,127 +922,30 @@
                     parseError(f, "Invalid directory 'dir': " + dir_attr);
                 }

-                boolean casesensitive = validateYesNoAttribute(f, "casesensitive", YES);
-                boolean defexcludes = validateYesNoAttribute(f, "defaultexcludes", YES);
-                String targetdir = requireAttribute(f, "targetdir");
+                String []includedFiles = getFilesetIncludedFiles(f);
                 List<OsConstraint> osList = OsConstraint.getOsList(f); // TODO: unverified
                 int override = getOverrideValue(f);
                 int blockable = getBlockableValue(f, osList);
                 Map additionals = getAdditionals(f);
                 String condition = f.getAttribute("condition");

-                // get includes and excludes
-                Vector<IXMLElement> xcludesList = null;
-                String[] includes = null;
-                xcludesList = f.getChildrenNamed("include");
-                if (!xcludesList.isEmpty())
+                if (includedFiles != null)
                 {
-                    includes = new String[xcludesList.size()];
-                    for (int j = 0; j < xcludesList.size(); j++)
+                    for (String filePath:includedFiles)
                     {
-                        IXMLElement xclude = xcludesList.get(j);
-                        includes[j] = requireAttribute(xclude, "name");
-                    }
-                }
-                String[] excludes = null;
-                xcludesList = f.getChildrenNamed("exclude");
-                if (!xcludesList.isEmpty())
-                {
-                    excludes = new String[xcludesList.size()];
-                    for (int j = 0; j < xcludesList.size(); j++)
-                    {
-                        IXMLElement xclude = xcludesList.get(j);
-                        excludes[j] = requireAttribute(xclude, "name");
-                    }
-                }
-
-                // parse additional fileset attributes "includes" and "excludes"
-                String[] toDo = new String[]{"includes", "excludes"};
-                // use the existing containers filled from include and exclude
-                // and add the includes and excludes to it
-                String[][] containers = new String[][]{includes, excludes};
-                for (int j = 0; j < toDo.length; ++j)
-                {
-                    String inex = f.getAttribute(toDo[j]);
-                    if (inex != null && inex.length() > 0)
-                    { // This is the same "splitting" as ant PatternSet do ...
-                        StringTokenizer tok = new StringTokenizer(inex, ", ", false);
-                        int newSize = tok.countTokens();
-                        int k = 0;
-                        String[] nCont = null;
-                        if (containers[j] != null && containers[j].length > 0)
-                        { // old container exist; create a new which can hold
-                            // all values
-                            // and copy the old stuff to the front
-                            newSize += containers[j].length;
-                            nCont = new String[newSize];
-                            for (; k < containers[j].length; ++k)
-                            {
-                                nCont[k] = containers[j][k];
-                            }
-                        }
-                        if (nCont == null) // No container for old values
-                        // created,
-                        // create a new one.
+                        try
                         {
-                            nCont = new String[newSize];
+                            File file = new File(dir,filePath);
+                            String target = new File(targetdir, filePath).getPath();
+                            pack.addFile(baseDir, file, target, osList, override,blockable,
+                                    additionals, condition);
                         }
-                        for (; k < newSize; ++k)
-                        // Fill the new one or expand the existent container
+                        catch (FileNotFoundException x)
                         {
-                            nCont[k] = tok.nextToken();
+                            parseError(f, x.getMessage(), x);
                         }
-                        containers[j] = nCont;
                     }
                 }
-                includes = containers[0]; // push the new includes to the
-                // local var
-                excludes = containers[1]; // push the new excludes to the
-                // local var
-
-                // scan and add fileset
-                DirectoryScanner ds = new DirectoryScanner();
-                ds.setIncludes(includes);
-                ds.setExcludes(excludes);
-                if (defexcludes)
-                {
-                    ds.addDefaultExcludes();
-                }
-                ds.setBasedir(dir);
-                ds.setCaseSensitive(casesensitive);
-                ds.scan();
-
-                String[] files = ds.getIncludedFiles();
-                String[] dirs = ds.getIncludedDirectories();
-
-                // Directory scanner has done recursion, add files and
-                // directories
-                for (String file : files)
-                {
-                    try
-                    {
-                        String target = new File(targetdir, file).getPath();
-                        pack.addFile(baseDir, new File(dir, file), target, osList, override,
-                                blockable, additionals, condition);
-                    }
-                    catch (FileNotFoundException x)
-                    {
-                        parseError(f, x.getMessage(), x);
-                    }
-                }
-                for (String dir1 : dirs)
-                {
-                    try
-                    {
-                        String target = new File(targetdir, dir1).getPath();
-                        pack.addFile(baseDir, new File(dir, dir1), target, osList, override,
-                                blockable, additionals, condition);
-                    }
-                    catch (FileNotFoundException x)
-                    {
-                        parseError(f, x.getMessage(), x);
-                    }
-                }
             }

             // get the updatechecks list
@@ -1124,6 +1062,121 @@
         notifyCompilerListener("addPacksSingle", CompilerListener.END, data);
     }

+    private String[] getFilesetIncludedFiles(IXMLElement f) throws CompilerException
+    {
+        List<String> includedFiles = new ArrayList<String>();
+        String dir_attr = requireAttribute(f, "dir");
+
+        File dir = new File(dir_attr);
+        if (!dir.isAbsolute())
+        {
+            dir = new File(basedir, dir_attr);
+        }
+        if (!dir.isDirectory()) // also tests '.exists()'
+        {
+            parseError(f, "Invalid directory 'dir': " + dir_attr);
+        }
+
+        boolean casesensitive = validateYesNoAttribute(f, "casesensitive", YES);
+        boolean defexcludes = validateYesNoAttribute(f, "defaultexcludes", YES);
+
+        // get includes and excludes
+        Vector<IXMLElement> xcludesList = null;
+        String[] includes = null;
+        xcludesList = f.getChildrenNamed("include");
+        if (!xcludesList.isEmpty())
+        {
+            includes = new String[xcludesList.size()];
+            for (int j = 0; j < xcludesList.size(); j++)
+            {
+                IXMLElement xclude = xcludesList.get(j);
+                includes[j] = requireAttribute(xclude, "name");
+            }
+        }
+        String[] excludes = null;
+        xcludesList = f.getChildrenNamed("exclude");
+        if (!xcludesList.isEmpty())
+        {
+            excludes = new String[xcludesList.size()];
+            for (int j = 0; j < xcludesList.size(); j++)
+            {
+                IXMLElement xclude = xcludesList.get(j);
+                excludes[j] = requireAttribute(xclude, "name");
+            }
+        }
+
+        // parse additional fileset attributes "includes" and "excludes"
+        String[] toDo = new String[]{"includes", "excludes"};
+        // use the existing containers filled from include and exclude
+        // and add the includes and excludes to it
+        String[][] containers = new String[][]{includes, excludes};
+        for (int j = 0; j < toDo.length; ++j)
+        {
+            String inex = f.getAttribute(toDo[j]);
+            if (inex != null && inex.length() > 0)
+            { // This is the same "splitting" as ant PatternSet do ...
+                StringTokenizer tok = new StringTokenizer(inex, ", ", false);
+                int newSize = tok.countTokens();
+                int k = 0;
+                String[] nCont = null;
+                if (containers[j] != null && containers[j].length > 0)
+                { // old container exist; create a new which can hold
+                    // all values
+                    // and copy the old stuff to the front
+                    newSize += containers[j].length;
+                    nCont = new String[newSize];
+                    for (; k < containers[j].length; ++k)
+                    {
+                        nCont[k] = containers[j][k];
+                    }
+                }
+                if (nCont == null) // No container for old values
+                    // created,
+                    // create a new one.
+                {
+                    nCont = new String[newSize];
+                }
+                for (; k < newSize; ++k)
+                    // Fill the new one or expand the existent container
+                {
+                    nCont[k] = tok.nextToken();
+                }
+                containers[j] = nCont;
+            }
+        }
+        includes = containers[0]; // push the new includes to the
+        // local var
+        excludes = containers[1]; // push the new excludes to the
+        // local var
+
+        // scan and add fileset
+        DirectoryScanner ds = new DirectoryScanner();
+        ds.setIncludes(includes);
+        ds.setExcludes(excludes);
+        if (defexcludes)
+        {
+            ds.addDefaultExcludes();
+        }
+        ds.setBasedir(dir);
+        ds.setCaseSensitive(casesensitive);
+        ds.scan();
+
+        String[] files = ds.getIncludedFiles();
+        String[] dirs = ds.getIncludedDirectories();
+
+        // Directory scanner has done recursion, add files and
+        // directories
+        for (String file : files)
+        {
+            includedFiles.add( file);
+        }
+        for (String dir1 : dirs)
+        {
+            includedFiles.add( dir1);
+        }
+        return includedFiles.toArray(new String[]{});
+    }
+
     private IXMLElement readRefPackData(String refFileName, boolean isselfcontained)
             throws CompilerException {
         File refXMLFile = new File(refFileName);
Index: src/lib/com/izforge/izpack/installer/WebRepositoryAccessor.java
===================================================================
--- src/lib/com/izforge/izpack/installer/WebRepositoryAccessor.java (revision 2811)
+++ src/lib/com/izforge/izpack/installer/WebRepositoryAccessor.java (working copy)
@@ -357,12 +357,14 @@
             while (iter.hasNext())
             {
                 IXMLElement p = iter.next();
-                String target = requireAttribute(p, "targetfile");
+                String target = p.getAttribute("targetfile", null);
                 String type = p.getAttribute("type", "plain");
                 String encoding = p.getAttribute("encoding", null);
                 List<OsConstraint> osList = OsConstraint.getOsList(p); // TODO: unverified
-
-                pack.addParsable(new ParsableFile(target, type, encoding, osList));
+                if (target != null)
+                {
+                    pack.addParsable(new ParsableFile(target, type, encoding, osList));
+                }
             }

             // We get the executables list 
Comment by Julien Ponge [ 01/Nov/09 ]

The patch applies, and the feature makes sense.

Would you be able to provide a documentation update/patch as well?

Thanks

Comment by Laurian Vostinar [ 17/Dec/09 ]

Here is the documentation patch:

Doc Patch
### Eclipse Workspace Patch 1.0
#P IzPack
Index: src/doc-reST/installation-files.txt
===================================================================
--- src/doc-reST/installation-files.txt (revision 2923)
+++ src/doc-reST/installation-files.txt (working copy)
@@ -1219,7 +1219,7 @@
 A ``<additionaldata>`` tag can also be specified for customizing.


-``<parsable>`` - parse a file after installation
+``<parsable>`` - parse file(s) after installation
 ''''''''''''''''''''''''''''''''''''''''''''''''''

 Files specified by ``<parsable>`` are parsed after installation and may have
@@ -1228,13 +1228,14 @@
 -   ``targetfile`` : the file to parse, could be something like
     ``$INSTALL_PATH/bin/launch-script.sh``
     A slash will be changed to the system dependant path separator (e.g. to a
-    backslash on Windows) only if no backslash masks the slash.
+    backslash on Windows) only if no backslash masks the slash. No longer mandatory as a fileset of files can be used.
 -   ``type`` : specifies the type (same as for the resources) - the
     default is ``plain``
 -   ``encoding`` : specifies the file encoding
 -   ``os``: specifies the operating system, works like for ``<file>``
 -  ``condition``: an id of a condition which has to be fullfilled to parse this file

+One or more fileset tags can be used inside parsable to specify multiple files at once.

 ``<executable>`` - mark file executable or execute it
 '''''''''''''''''''''''''''''''''''''''''''''''''''''''
Comment by Julien Ponge [ 22/Dec/09 ]

Thanks, I will handle this soon.

Comment by Julien Ponge [ 25/Jan/10 ]

Thanks for the patches.





[IZPACK-392] installer hangs when ShortcutPanel is opened Created: 14/May/09  Updated: 15/Dec/09  Resolved: 15/Dec/09

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

Type: Bug Priority: Major
Reporter: Sascha Hunold Assignee: Julien Ponge
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, Java


Issue Links:
Related
relates to IZPACK-501 On unix corporate install (with 30000... Closed
Number of attachments : 0

 Description   

When I try to install IzPack (4.3.0) the installer hangs after I clicked the "next" button, and the ShortcutPanel is supposed to pop up.

The UI completely freezes. (One could handle the event in a separate thread.)

I checked the stack trace of the hanging IzPack.

Here it is (a snippet):

java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0x00007f4f972c5f68> (a java.lang.UNIXProcess)
    at java.lang.Object.wait(Object.java:485)
    at java.lang.UNIXProcess.waitFor(UNIXProcess.java:165)
  • locked <0x00007f4f972c5f68> (a java.lang.UNIXProcess)
    at com.izforge.izpack.util.FileExecutor.executeCommand(Unknown Source)
    at com.izforge.izpack.util.FileExecutor.getExecOutput(Unknown Source)
    at com.izforge.izpack.util.os.unix.UnixUser.getXdgDesktopfolder(Unknown Source)
    at com.izforge.izpack.util.os.unix.UnixUsers._getUsersWithValidShellsExistingHomesAndDesktops(Unknown Source)
    at com.izforge.izpack.util.os.unix.UnixUsers.getUsersWithValidShellsExistingHomesAndDesktops(Unknown Source)
    at com.izforge.izpack.util.os.Unix_Shortcut.<clinit>(Unknown Source)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:169)

So, it seems that the process does not return.
I dived into the code of UnixUser.getXdgDesktopfolder().
When I rename the file .config/user-dirs.dirs the installer works correctly, i.e., the ShortcutPanel is shown.

The script with the pseudo unique name is correctly written (and returns the correct path when called externally). But the call to
String xdgDesktopfolder = FileExecutor.getExecOutput( new String[]

{ UnixHelper.getSuCommand(), itsName, "-c", XDGDesktopFolderNameScriptFilename }

, true ).trim();
causes my system to ask for the password, and so we hang at this point.

Could anyone look into this please!

Cheers

Sascha



 Comments   
Comment by Sascha Hunold [ 15/May/09 ]

Well, it works when one starts the installer as root user.
But I want to install programs packed with IzPack as regular user.

Comment by Raoul S da Silva Curiel [ 14/Dec/09 ]

It also works if you remove all the other users on the system apart from the user under which you want to install! Seriously, I'm also running up against this and it is rather frustrating. I'm surprised this issue isn't being dealt with because for me this is stopping me using IzPack for Linux users. If only I hadn't convinced my wife to start using Linux instead of Windows (using her own account), then I wouldn't have this problem!

Comment by Raoul S da Silva Curiel [ 15/Dec/09 ]

In 4.3.3 this bug seems closed to me! Good job guys!





[IZPACK-391] hidden="true" for Packs does not work for TreePacksPanel Created: 12/May/09  Updated: 29/Apr/11  Resolved: 17/Feb/11

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.0
Fix Version/s: 4.3.4, 5.0

Type: Bug Priority: Major
Reporter: Vikash Kumar Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Attachments: Text File 0002-fixed-tree-packs-panel.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

I am trying to use hidden="true" attribute for pack definitions. It works fine if I display the packs in regular Packs Panel, but it throws exception if I use TreePacksPanel.



 Comments   
Comment by Katarzyna Czeczot [ 17/Aug/10 ]

this fixes it for me, I haven't tested it a lot though

Comment by Katarzyna Czeczot [ 17/Aug/10 ]

duplicate with http://jira.codehaus.org/browse/IZPACK-461

Comment by Julien Ponge [ 30/Aug/10 ]

This does not apply on master.

Comment by Julien Ponge [ 17/Feb/11 ]

I am closing the issue. It does not do what is advertised, as it introduces a new attribute doNotShowPackSize as a side-effect.

Comment by Katarzyna Czeczot [ 17/Feb/11 ]

It does what is advertised

doNotShowPackSize is not new attribute, it was used in table view already so it's merely unifing the interfaces

I added it here because I didn't want to fix the size bug in the tree packs panel as I didn't need it

I attached the patch only as a way of helping people who have the same problem as I did.

Comment by Julien Ponge [ 17/Feb/11 ]

Let me check then...

Comment by Julien Ponge [ 17/Feb/11 ]

Ok, my bad

It's in, thanks.





[IZPACK-390] ProgressBarInstallerListener.jar not available in IzPack out of the box build Created: 12/May/09  Updated: 06/Nov/09  Resolved: 22/Aug/09

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

Type: Improvement Priority: Major
Reporter: Vikash Kumar Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Number of attachments : 0

 Description   

I am able to get the ant messages displayed in the Install Panel as part of the Progress bar, however there is one issue that I am facing.
The ProgressBarInstallerListener.jar file is not present in the out of the box IzPack. I was able to create this myself but then I have to maintain a local build for IzPack and will have to do this everytime I need to upgrade Izpack to a newer version.

It would be really nice if this jar file can also be made available (just like AntActionInstallerListener.jar etc.) in the out of the box IzPack build.



 Comments   
Comment by Eric Rose [ 19/Jun/09 ]

this doesn't appear to be fixed. Adding the listener to my project descriptor led to a ClassNotFoundException. I had to add the following to src/build.xml before I could make it work:

<build-installer-listener name="ProgressBarInstallerListener">
<include name="com/izforge/izpack/event/ProgressBarInstallerListener.java"/>
</build-installer-listener>

Comment by Julien Ponge [ 22/Aug/09 ]

Thanks for pointing out that!





[IZPACK-389] Autoinstaller doesn't create appropriate AbstractUIHandler for PanelActions Created: 07/May/09  Updated: 07/May/09  Resolved: 07/May/09

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

Type: Bug Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The autoinstaller just passes null to the panel action. This leads to null pointer exceptions as panel action can only communicate through this handler.



 Comments   
Comment by Dennis Reil [ 07/May/09 ]

created ConsolePanelAutomationHelper.





[IZPACK-388] Two installers can overwrite each other if they share the same programGroup Created: 05/May/09  Updated: 05/May/09

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

Type: Bug Priority: Major
Reporter: Nicola Di Nisio Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days
Environment:

Ubuntu 8.04


Number of attachments : 0

 Description   

I am creating two installers for two distinct products A and B. They are both to be launched with dedicated shortcuts placed under the same program group P.
If I install A and then B I will only see the Program Group P containing the shortcut for B. The shortcut for A is lost.
If I install B and then A I will only see the Program Group P containing the shortcut for A. The shortcut for B is lost.
Basically the second installer overwrites the program group P created by the first one, instead of merging in its shortcuts.



 Comments   
Comment by Julien Ponge [ 05/May/09 ]

Thanks for your report Nicola. Would you be able to investigate a patch?





[IZPACK-387] Uninstaller does not elevate when installer has been elevated by OS Created: 02/May/09  Updated: 06/Nov/09  Resolved: 30/Sep/09

Status: Closed
Project: IzPack
Component/s: Uninstaller
Affects Version/s: 4.3.0
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Major
Reporter: Christian d'Heureuse Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP


Issue Links:
Duplicate
is duplicated by IZPACK-438 Uninstaller does not delete all folders Closed
Number of attachments : 0

 Description   

When the installer is started via an EXE file named Install.exe, the Windows XP operating system automatically prompts the user to run the program as an admin. In this case, the installer does not create the ZIP file entry "exec-admin" within the uninstaller JAR. So the uninstaller does not elevate by itself.

When the uninstaller is started via an EXE file named Uninstall.exe, the Windows XP operating system does not prompt the user, because the file name "Uninstall.exe" is not recognized as one of the programs that need admin privileges. On Windows Vista the user would be prompted for elevation, but not on Windows XP. Because the "exec-admin" dummy file is not in the JAR file, the uninstaller does not elevate and the program cannot be uninstalled. (No error message is displayed, because Destroyer.run() just ignores errors during deletion of files and directories... This should also be improved)

I suggest to extend Uninstaller.checkForPrivilegedExecution() to do something similar as in PrivilegedRunner.isElevationNeeded(), e.g. test whether it is possible to write into the $INSTALL_PATH directory.



 Comments   
Comment by Julien Ponge [ 30/Sep/09 ]

Hi Christian,

I have added a new check from the uninstaller:

private static boolean elevationShouldBeInvestigated()
{
    return (Uninstaller.class.getResource("/exec-admin") != null) ||
               (OsVersion.IS_WINDOWS && !(new PrivilegedRunner().canWriteToProgramFiles()));
}

which is called from checkForPrivilegedExecution()

Comment by Julien Ponge [ 30/Sep/09 ]

Fixed.

Comment by Christian d'Heureuse [ 02/Oct/09 ]

Julien, thanks for fixing this bug. I have tested it and it works.





[IZPACK-386] Uninstaller does not elevate on Windows Created: 01/May/09  Updated: 16/Jun/09  Resolved: 10/May/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.0
Fix Version/s: 4.3.1

Type: Bug Priority: Major
Reporter: Christian d'Heureuse Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Attachments: Text File IZPACK-386-Uninstaller.patch     Text File UninstallerElevation.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

The fix for IZPACK-353 has the effect that the uninstaller does never elevate on Windows.

The reason is, that the environment variable "izpack.mode" is not passed through Shell.ShellExecute() in elevate.js. This has the effect that the ZIP file entry "exec-admin" is not created within the uninstaller JAR and therefore the uninstaller does not elevate.

The attached patch solves the problem by changing the following:

  • PrivilegedRunner.getElevator() passes the java command parameter -Dizpack.mode=privileged to elevate.js in order to set the system property "izpack.mode".
  • The new function PrivilegedRunner.isPrivilegedMode() checks for an environment variable or a system property with the name "izpack.mode". This function is now used to check the privileging mode instead of testing the environment variable directly.

Note that the patch for PrivilegedRunner.java is intended to be applied after the patch of IZPACK-384.



 Comments   
Comment by Christian d'Heureuse [ 02/May/09 ]

Added a missing patch for Uninstaller.java.

Note that his patch is intended to be applied after IZPACK-331.patch.
(Alternatively the patch could be done manually, it's only a single line)

Comment by Julien Ponge [ 10/May/09 ]

Great job!





[IZPACK-385] PacksPanelAutomationHelper do not add optional packs even if they are selected in the autoinstall.xml Created: 30/Apr/09  Updated: 16/Jun/09  Resolved: 30/Apr/09

Status: Closed
Project: IzPack
Component/s: None
Affects Version/s: 4.3.0
Fix Version/s: 4.3.1, 5.0

Type: Bug Priority: Critical
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

During automated installation optional packs that are not pre selected are not installed even if the are are selected in the autoinstall.xml file.






[IZPACK-384] Installer does not work when JAR is loaded by custom class loader Created: 29/Apr/09  Updated: 16/Jun/09  Resolved: 10/May/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.0
Fix Version/s: 4.3.1

Type: Bug Priority: Major
Reporter: Christian d'Heureuse Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ClassLoaderError.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The following two errors occur when the installer JAR is loaded by a custom class loader:

  • Condition values are not found, because JavaCondition uses ClassLoader.getSystemClassLoader().loadClass().
  • Privilege elevation does not work, because PrivilegedRunner uses ClassLoader.getSystemResource().

The attached patch solves the problem.



 Comments   
Comment by Julien Ponge [ 05/May/09 ]

Interesting. BTW in which context do you use custome classloaders?

Comment by Christian d'Heureuse [ 05/May/09 ]

> BTW in which context do you use custom classloaders?

I use a small starter JAR that constructs the classpath and launches the main application using java.net.URLClassLoader. The classpath has to be constructed at run-time, because it depends on the operating system (the correct SWT JAR library has to be included, etc.).

The application starts directly from DVD. The user may choose to install the application on disk, in which case the IzPack installer is called.

I plan to publish the launcher class. A preliminary version is at http://www.source-code.biz/snippets/java/JavaApplLauncher.java.txt

Comment by Julien Ponge [ 10/May/09 ]

Thanks Christian.





[IZPACK-383] com.izforge.izpack.panels.DefaultTargetPanel.summaryCaption property undefined Created: 29/Apr/09  Updated: 16/Jun/09  Resolved: 26/May/09

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

Type: Bug Priority: Minor
Reporter: Christophe Bram Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 2000


Attachments: XML File install.xml     JPEG File IZPACK-383.jpg    
Number of attachments : 2

 Description   

When using a DefaultTargetPanel, there is no value for property "com.izforge.izpack.panels.DefaultTargetPanel.summaryCaption", and therefore it is displayed as the key in a SummaryPanel.
The problem is very easy to understand when looking at the included screenshot.

I have included the "install.xml" IzPack file, in case the problem comes from an error I've done using IzPack.



 Comments   
Comment by Julien Ponge [ 05/May/09 ]

That's a missing translation in bin/langpacks/installer/fra.xml.

You can fix it by yourself meanwhile (just add a string with the displayed id).

Comment by Christophe Bram [ 05/May/09 ]

I'm not writing this comment asking for a workaround, but just to say that the workaround you've just written doesn't work:
1) I've added the string to both "fra.xml" and "eng.xml"
2) Executed compilation in order to create the "installer.jar"
3) Launched the installer in both English and French languages, in both cases it's still the key which is displayed instead of the value specified in the language file

Comment by Christophe Bram [ 05/May/09 ]

The added string was << <str id="DefaultTargetPanel.summaryCaption" txt="Installation Path"/> >>

Comment by Julien Ponge [ 26/May/09 ]

Fixed





[IZPACK-382] install.xml: Attribute condition in <variable> tag is ignored Created: 29/Apr/09  Updated: 29/Apr/09

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

Type: Bug Priority: Major
Reporter: Ralph Jacobs 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 installation.dtd defines the attribute "condition" for <variable> definitions.

While interpreting the file install.xml, this attribute is ignored: CompilerConfig.addVariables
All variables will be written to the installer.

I would expect evaluation of the condition at install-time.
To archieve this, the conditions of the variables have to be stored in the installer to be interpreted at install-time in InstallerBase.loadInstallData






[IZPACK-381] Extended JDK download description with a clickable hyperlink Created: 27/Apr/09  Updated: 13/Aug/12  Resolved: 13/Aug/12

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

Type: New Feature Priority: Minor
Reporter: Mateusz Fiolka Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File JDKPanel.patch     PNG File screenshot.png    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

This patch adds a text field to the JDKPathPanel panel. It contains short instruction to the user - where can he find JDK and that he needs to install it. You can see on the screenshot how does the final panel look in action, used by Tigase server installer. This screenshot contains some custom and has hardcoded the Tigase label in it. Hovewer patch contains a generic string which can be applied to any installed application.
Patch is generated for the version 2759 of IzPack svn trunk.



 Comments   
Comment by Danesh Mondegarian [ 12/Jul/12 ]

Wouldn't it be easier to make avail the Desktop class's browse method rather than hard-coding all these browsers ?

Comment by Tim Anderson [ 19/Jul/12 ]

If you can resubmit using Desktop and using the latest codebase, I will apply the changes.
See https://izpack.github.io/developers/ for instructions.

Comment by Danesh Mondegarian [ 20/Jul/12 ]

Here is the pull request : https://github.com/jponge/izpack/pull/19

Comment by Tim Anderson [ 13/Aug/12 ]

Thanks. Changes applied, with some modifications.





[IZPACK-380] izpack2exe: abillity to specify more then one file, file to launch defined can be set separately. Created: 27/Apr/09  Updated: 16/Jun/09  Resolved: 26/May/09

Status: Closed
Project: IzPack
Component/s: Utilities
Affects Version/s: 4.3.0
Fix Version/s: 4.3.1

Type: Improvement Priority: Minor
Reporter: Krzysztof Piech Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File izpack2exe.py     Text File izpack2exe.py    
Patch Submitted:
Yes
Number of attachments : 2

 Comments   
Comment by Krzysztof Piech [ 27/Apr/09 ]

While reading history on svn I recall about os.path.basename. Sorry for my oversight.

Comment by Julien Ponge [ 26/May/09 ]

Thanks!





[IZPACK-379] Uninstaller: missing styleSheet.xsl Created: 23/Apr/09  Updated: 23/Apr/09  Resolved: 23/Apr/09

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

Type: Bug Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
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   

The styleSheet.xsl is missing in uninstaller. So uninstallation is not working as a ParseException is thrown when reading the langpack.xml.



 Comments   
Comment by Dennis Reil [ 23/Apr/09 ]

I didn't have the correct version of build.xml





[IZPACK-378] Wrong namespace for xi:include Created: 22/Apr/09  Updated: 06/Nov/09  Resolved: 27/Jun/09

Status: Closed
Project: IzPack
Component/s: Documentation
Affects Version/s: 4.3.0
Fix Version/s: 4.3.2

Type: Bug Priority: Minor
Reporter: Sebastian Pappert Assignee: Anthonin Bonnefoy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The documentation says in the section about the fallback element (https://izpack.github.io/documentation/installation-files.html#the-fallback-element) in the examples to use the namespace xmlns:xi="http://www.izforge.com/izpack/include. It is correct in the section above where the xi:include element is introduced but the example is very prominent and made me look for other possible errors for a while.






[IZPACK-377] Cannot find named Resource: '/res/userInputLang.xml_eng' Created: 22/Apr/09  Updated: 16/Jun/09  Resolved: 04/Jun/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.0
Fix Version/s: 4.3.1

Type: Bug Priority: Major
Reporter: Thomas Diesler Assignee: Julien Ponge
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   

After an upgrade from 4.2.1 to 4.3.0 I see

com.izforge.izpack.installer.ResourceNotFoundException: Cannot find named Resource: '/res/userInputLang.xml_eng' AND '/res/userInputLang.xml_eng_eng'
at com.izforge.izpack.installer.ResourceManager.getLanguageResourceString(Unknown Source)
at com.izforge.izpack.installer.ResourceManager.getInputStream(Unknown Source)
at com.izforge.izpack.panels.UserInputPanel.init(Unknown Source)
at com.izforge.izpack.panels.UserInputPanel.panelActivate(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.switchPanel(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.navigateNext(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame$NavigationHandler.actionPerformed(Unknown Source

I have a resources section like this

<resources>
<res id="userInputSpec.xml" src="@

{filtered.resources.dir}/user-input-spec.xml" />
<res id="TargetPanel.dir" src="@{filtered.resources.dir}

/target-panel-dir.txt" />
</resources>



 Comments   
Comment by Thomas Diesler [ 22/Apr/09 ]

Related to https://jira.jboss.org/jira/browse/JBOSGI-71

Comment by Thomas Diesler [ 04/Jun/09 ]

In UserInputPanel.init() I see


    protected void init()
    {
        eventsActivated = false;
        TwoColumnLayout layout;
        super.removeAll();
        elements.clear();

        // ----------------------------------------------------
        // get a locale database
        // ----------------------------------------------------
        try
        {
            this.langpack = (LocaleDatabase) parent.langpack.clone();

            String resource = LANG_FILE_NAME + "_" + idata.localeISO3;
            this.langpack.add(ResourceManager.getInstance().getInputStream(resource));
        }
        catch (Throwable exception)
        {
            exception.printStackTrace();
        }

    /**
     * This method is used to get the language dependent path of the given resource. If there is a
     * resource for the current language the path of the language dependen resource is returnd. If
     * there's no resource for the current lanuage the default path is returned.
     *
     * @param resource Resource to load language dependen
     * @return the language dependent path of the given resource
     * @throws ResourceNotFoundException If the resource is not found
     */
    private String getLanguageResourceString(String resource) throws ResourceNotFoundException
    {
        InputStream in;
        String resourcePath = this.resourceBasePath + resource + "_" + this.locale;

        in = ResourceManager.class.getResourceAsStream(resourcePath);
        if (in != null)
        {

            return resourcePath;
        }

        else
        {
            // if there's no language dependent resource found
            resourcePath = this.resourceBasePath + resource;
            in = ResourceManager.class.getResourceAsStream(resourcePath);
            if (in != null)
            {
                return resourcePath;
            }
            else
            {
                throw new ResourceNotFoundException( "Cannot find named Resource: '" + this.resourceBasePath + resource + "' AND '" + this.resourceBasePath + resource + "_" + this.locale + "'"  );
            }
        }

    }

From what I can tell, the ResourceManager throws the ResourceNotFoundException , which is then logged to the console.

Perhaps exception.printStackTrace() should be made conditional on some debug switch.

Comment by Julien Ponge [ 04/Jun/09 ]

Thanks for pointing out where the issue was, Thomas.





[IZPACK-376] NullPointerException occours in Unpacker.cleanup() Created: 22/Apr/09  Updated: 16/Jun/09  Resolved: 27/Apr/09

Status: Closed
Project: IzPack
Component/s: Uninstaller
Affects Version/s: 4.2.1
Fix Version/s: 4.3.1, 5.0

Type: Bug Priority: Major
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

A NPE is rised during uninstallation after all Listeners are called.






[IZPACK-375] New langpack for language Polish Created: 22/Apr/09  Updated: 16/Jun/09  Resolved: 26/May/09

Status: Closed
Project: IzPack
Component/s: Translations
Affects Version/s: 4.3.0
Fix Version/s: 4.3.1

Type: Improvement Priority: Major
Reporter: Kamil Dybicz Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GIF File pol.gif     XML File pol.xml    
Number of attachments : 2

 Description   

I have updated langpack for language Polish using as base English langpack. File is added as attachment.



 Comments   
Comment by Kamil Dybicz [ 22/Apr/09 ]

One more issue. There is:

<str id="InfoPanel.info" txt="Prosz&#281; przeczyta&#263; poni&#380;sze informacj&#281;: "/>

but should be:

<str id="InfoPanel.info" txt="Prosz&#281; przeczyta&#263; poni&#380;sze informacje: "/>
Comment by Julien Ponge [ 10/May/09 ]

Thanks Kamil, but would it be possible for you to provide a flag image?

Comment by Kamil Dybicz [ 10/May/09 ]

This is the same flag image like the one in langpacks/flags directrory. Isn't good?

Comment by Julien Ponge [ 26/May/09 ]

Thanks for the update!





[IZPACK-374] Release izpack-standalone-compiler to maven repository Created: 21/Apr/09  Updated: 22/Apr/09  Resolved: 22/Apr/09

Status: Closed
Project: IzPack
Component/s: Maven plugin
Affects Version/s: 4.1.0
Fix Version/s: 4.3.0

Type: Task Priority: Major
Reporter: Thomas Diesler Assignee: Dan Tran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Comments   
Comment by Thomas Diesler [ 21/Apr/09 ]

Please edit this issue such that it effects 4.3.0

The standalone compiler should be available here

http://repository.codehaus.org/org/codehaus/izpack/izpack-standalone-compiler/

Comment by Thomas Diesler [ 21/Apr/09 ]

Related to IZPACK-171

Comment by Thomas Diesler [ 21/Apr/09 ]

Perhaps this can be added to the list of required release steps

Comment by Dan Tran [ 22/Apr/09 ]

izpack standalone 4.3.0 has been deployed to codehaus maven2 repo, should be synced with maven central within 24 hour

Comment by Julien Ponge [ 22/Apr/09 ]

Thanks Dan!





[IZPACK-373] SelfModifier not respecting whitespaces in paths Created: 21/Apr/09  Updated: 22/Aug/09  Resolved: 22/Aug/09

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

Type: Bug Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The Selfmodifier is not respection whitespaces in paths, e.g. the classpath or the path to the java executable.



 Comments   
Comment by Christian d'Heureuse [ 30/Apr/09 ]

The current SVN version of SelfModifier does not work on Windows.

The Java command in SelfModifier.spawn() does not run, because quotes are used for the value of -Dself.mod.jar.

Comment by Christian d'Heureuse [ 30/Apr/09 ]

Dennis, I have seen that you have been improving SelfModifier. Would it be possible to display a GUI error message when the Java command fails in SelfModifier.spawn()? The current situation is that on Windows the uninstaller just terminates without a visible error message.

Additionally it would be good if there was a fallback mechanism when SelfModifier fails. After a warning message, the uninstaller should continue without SelfModifier. Locked files and directories could not be removed in this case, but most parts of the application would be uninstalled, including start menu entries and desktop links.





[IZPACK-372] Uninstaller not working Created: 21/Apr/09  Updated: 21/Apr/09  Resolved: 21/Apr/09

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

Type: Bug Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The uninstaller is not working and throws an exeception. Seems that this is caused by refactoring of SelfModifier.






[IZPACK-371] Memory options not transferred to sub process Created: 20/Apr/09  Updated: 08/Aug/12  Resolved: 08/Aug/12

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

Type: Bug Priority: Critical
Reporter: Dennis Reil 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   

If I specify -Xmx512m on the command line while starting a multi volume installer, the restarted process (with SelfModifier) doesn't have the extended memory.



 Comments   
Comment by Julien Ponge [ 20/Apr/09 ]

Hi Dennis,

Your commit fixes the issue, right?

Cheers

Comment by Dennis Reil [ 21/Apr/09 ]

Jepp, I think the issue should now be fixed, but I have to validate

Comment by Julien Ponge [ 21/Apr/09 ]

Thanks Dennis!

Comment by Dennis Reil [ 21/Apr/09 ]

it's not working the easy way

Comment by Julien Ponge [ 24/Apr/09 ]

I'm moving the fix for version BTW.

Comment by Tim Anderson [ 24/Jul/12 ]

The pull request at https://github.com/izpack/izpack/pull/36 fixes this issue.
It uses:

ManagementFactory.getRuntimeMXBean().getInputArguments()

to determine what argumnents were passed to the JVM, and passes these to spawned processes.
To avoid conflicts, the following arguments are excluded:

  • -Xdebug
  • -Xrunjdwp
  • -Dself.mod.*
  • -Dizpack.mode
  • -agentlib
  • -javaagent

Any -DDEBUG and -DTRACE argument will be passed to spawned processes.
Note that on Windows, console output won't be displayed even if -DDEBUG=true as the wscript command used by PrivilegeRunner to relaunch the installer with elevated permissions doesn't propagate the output.

Comment by Tim Anderson [ 05/Aug/12 ]

Turns out that RuntimeMXBean.getInputArguments() doesn't handle spaces in arguments, so path names get mangled.
This causes the uninstaller to fail if it is located in a directory containing spaces e.g.:

2012-08-05T21:55:04.006 Phase 1: JarFile: C:\Program Files\IzPack\Uninstaller\uninstaller.jar
2012-08-05T21:55:07.637 Phase 1: Extracted 861 files into C:\cygwin\tmp\izpack1347036817648907491.d
2012-08-05T21:55:07.640 Phase 1: Spawning phase 2:
        C:\Program Files\Java\jdk1.6.0_30\jre\bin\java.exe
        -classpath
        C:\cygwin\tmp\izpack1347036817648907491.d
        -Dself.mod.base=C:\cygwin\tmp\izpack1347036817648907491
        -Dself.mod.jar=C:\Program Files\IzPack\Uninstaller\uninstaller.jar
        -Dself.mod.class=com.izforge.izpack.uninstaller.Uninstaller
        -Dself.mod.method=uninstall
        -Dself.mod.phase=2
        com.izforge.izpack.util.SelfModifier
2012-08-05T21:55:07.643 Phase 1: Exit
2012-08-05T21:55:08.795 Phase 2: Spawning phase 3:
        C:\Program Files\Java\jdk1.6.0_30\jre\bin\java.exe
        Files\IzPack\Uninstaller\uninstaller.jar
        -classpath
        C:\cygwin\tmp\izpack1347036817648907491.d
        -Dself.mod.base=C:\cygwin\tmp\izpack1347036817648907491
        -Dself.mod.jar=C:\Program Files\IzPack\Uninstaller\uninstaller.jar
        -Dself.mod.class=com.izforge.izpack.uninstaller.Uninstaller
        -Dself.mod.method=uninstall
        -Dself.mod.phase=3
        com.izforge.izpack.util.SelfModifier
java.lang.NoClassDefFoundError: Files\IzPack\Uninstaller\uninstaller/jar
Caused by: java.lang.ClassNotFoundException: Files\IzPack\Uninstaller\uninstaller.jar
        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)
Could not find the main class: Files\IzPack\Uninstaller\uninstaller.jar.  Program will exit.

This is caused by the following bug, which is apparently fixed in JDK7: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6459832

Comment by Tim Anderson [ 06/Aug/12 ]

Added workaround for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6459832 by concatenating arguments to the previous argument if they don't start with a '-'. Arguments are concatenated with a space separating them.

New pull request is at https://github.com/izpack/izpack/pull/50

Comment by Julien Ponge [ 08/Aug/12 ]

Pull request merged.





[IZPACK-370] Support localized folder names for Mac OS X Created: 17/Apr/09  Updated: 17/Apr/09

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

Type: Improvement Priority: Major
Reporter: Christian d'Heureuse Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS X


Number of attachments : 0

 Description   

In a non-English Mac OS X, some system folder names are automatically translated when they are displayed to the user.

e.g. in German:
/Applications is displayed as /Programme
/Users is displayed as /Benutzer
...

IzPack currently displays the non-translated folder names, except in the "folder chooser" dialog.






[IZPACK-369] Automated Installer always fails with ArrayIndexOutOfBoundsException since r2722 Created: 17/Apr/09  Updated: 20/Apr/09  Resolved: 19/Apr/09

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.0
Fix Version/s: 4.3.0

Type: Bug Priority: Blocker
Reporter: Kjell Braden 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   

As far as I can see, the for loop line 201 in PacksPanelAutomationHelper.java has an off-by-one error since r2722. (as I don't understand what's it doing there anyways, I'm not going to patch this myself )

$ java -jar IzPack-install-4.3.0-rc2.jar install-izpack.xml
[ Starting automated installation ]
Read pack list from xml definition.
Try to add to selection [Name: Core and Index: 0]
Try to remove from selection [Name: HTML Documentation and Index: 1]
Try to remove from selection [Name: PDF Documentation and Index: 2]
Try to remove from selection [Name: Javadocs Documentation and Index: 3]
Try to remove from selection [Name: Utilities and Index: 4]
Try to remove from selection [Name: Sample and Index: 5]
Try to remove from selection [Name: Sources and Index: 6]
Modify pack selection.
Pack [Name: HTML Documentation and Index: 1] removed from selection.
Pack [Name: PDF Documentation and Index: 2] removed from selection.
Pack [Name: Javadocs Documentation and Index: 3] removed from selection.
Pack [Name: Utilities and Index: 4] removed from selection.
Pack [Name: Sample and Index: 5] removed from selection.
Pack [Name: Sources and Index: 6] removed from selection.
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 7
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 7
        at java.util.Vector.get(Unknown Source)
        at com.izforge.izpack.adaptator.impl.XMLElementImpl.getChildAtIndex(XMLElementImpl.java:182)
        at com.izforge.izpack.panels.PacksPanelAutomationHelper.runAutomated(PacksPanelAutomationHelper.java:201)
        at com.izforge.izpack.installer.AutomatedInstaller.installPanel(AutomatedInstaller.java:429)
        at com.izforge.izpack.installer.AutomatedInstaller.doInstall(AutomatedInstaller.java:385)
        at com.izforge.izpack.installer.Installer.main(Installer.java:65)
[ Automated installation FAILED! ]


 Comments   
Comment by Julien Ponge [ 19/Apr/09 ]

FIxed by rewriting the loop as follows:

for (int counter = panelRoot.getChildrenCount(); counter > 0; counter--)
{
    panelRoot.removeChild(panelRoot.getChildAtIndex(0));
}




[IZPACK-368] Implement functionalities for complex installers in console mode Created: 14/Apr/09  Updated: 18/Oct/13  Resolved: 13/Dec/12

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.0
Fix Version/s: 4.3.2, 5.0

Type: Improvement Priority: Major
Reporter: Peter Heiles Assignee: Julien Ponge
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File patch_20090528.txt     Text File patch-24-8-2009.txt     Text File patch.txt     Text File src_lib_com_izforge_izpack_panels_InstallationGroup_20090601_build_patch.txt     Text File src_lib_com_izforge_izpack_panels_InstallationGroup_20090601_patches.txt     Text File src_lib_com_izforge_izpack_panels_UserInputPanelConsoleHelper_052609_patch.txt     Text File src_lib_com_izforge_izpack_panels_UserInputPanelConsoleHelper_20090529_patch.txt     Text File src_lib_com_izforge_izpack_panels_UserInputPanelConsoleHelper_20090601_patch.txt     Text File src_lib_com_izforge_izpack_panels_UserInputPanelConsoleHelper_20090608_patch.txt    
Number of attachments : 9

 Description   

I used izPack for a quite complex installer. As I think the console mode is a great feature I tried it out with the latest trunk version and encountered diffrent problems listed below. In "worst case" none of the panels/input fields can be displayed and something unwanted (e.g. without parsing files according to user input) will be installed.
Those are the points i found in my installation scenario:

1) Using title field in UserInPutPanel causes Exception and following input fields are skipped
title field collection not implemented
java.lang.NullPointerException
at com.izforge.izpack.panels.UserInputPanelConsoleHelper.runConsole(Unknown Source)
at com.izforge.izpack.installer.ConsoleInstaller.iterateAndPerformAction(Unknown Source)
at com.izforge.izpack.installer.ConsoleInstaller.doInstall(Unknown Source)
at com.izforge.izpack.installer.Installer.main(Unknown Source)

2) Using check field in UserInPutPanel causes Exception and following input fields are skipped
java.lang.NullPointerException
at com.izforge.izpack.panels.UserInputPanelConsoleHelper.runConsole(Unknown Source)
at com.izforge.izpack.installer.ConsoleInstaller.iterateAndPerformAction(Unknown Source)
at com.izforge.izpack.installer.ConsoleInstaller.doInstall(Unknown Source)
at com.izforge.izpack.installer.Installer.main(Unknown Source)

3) Rule field in UserInputPanel is not implemented, those fields are simply skipped

4) Panel validators are not called
e.g. I implemented a simple jdbc connection validator based on user input:
<panel classname="UserInputPanel" id="jdbc">
<validator classname="install.jdbcconval"/>
</panel>
In GUI mode the validator class is called, in console mode it is skipped

5) JDKPathPanel is not implemented



 Comments   
Comment by Mounir el hajj [ 15/Apr/09 ]

currently these features are not implemented. i will have a look and try to submit a patch

Comment by Peter Heiles [ 15/Apr/09 ]

thank you.
Is just saw that the DefaultTargetPanel is also not called in console mode - I guess that should be quite easy to implement. It would be also nice to have some kind of list which features are not implemented yet

Comment by Mounir el hajj [ 17/Apr/09 ]

taken from revision 2735

Comment by Mounir el hajj [ 17/Apr/09 ]

Peter can you please test the patch?
it should fix all the errors in the user input panel. note that the Rule field will be handled like a normal text field, which is logic, since no gui is involved.
Validation should be also performed.
As for JDKPathPanel, and DefaultTargetPanel i haven't had time to do these. all you have to do is create a console helper class for these panels, the same way an automation helper is implemented
one final note. can you set <property name="debug" value="on"/> in the build.xml before compiling your compiler? this will give more meaningful stack traces

Thank you,
M

Comment by Peter Heiles [ 17/Apr/09 ]

I just did a quick test and came to the following result - setting debug=on before compilation did not increase the debug output

@1) Title field is displayed

@2) Check field
Still causes Exception
java.lang.NullPointerException
at com.izforge.izpack.panels.UserInputPanelConsoleHelper.processCheckField(Unknown Source)
at com.izforge.izpack.panels.UserInputPanelConsoleHelper.runConsole(Unknown Source)
at com.izforge.izpack.installer.ConsoleInstaller.iterateAndPerformAction(Unknown Source)
at com.izforge.izpack.installer.ConsoleInstaller.doInstall(Unknown Source)
at com.izforge.izpack.installer.Installer.main(Unknown Source)

Also causes the validator in the panel not being called (as it's the last option in this user panel i guess that all following input fields are also skipped)

@3) Ruled Input fields
It shows the suggestion, e.g. for an IP Address: " Server IP: [0:127 1:0 2:0 3:1]"
Result: If the user just hits "Enter" variable is filled with "0:127 1:0 2:0 3:1"
So the default value is filled with the field number (0:, 1:, ...), which should not be included in the default value and additional chars in the rule (e.g. "." between the fields) is not considered
Suggestion: Fill the default value according to the rule, e.g. "127.0.0.1"

@4) Validators are called, but failed validation does not force the user to validate the entered Parameters. Causes the installation to start without having valid user input (with validation I would expect that user input has to be valid before installation process is executed):
com.izforge.izpack.installer.InstallerException: Validating data for panel jdbc was not successfull
at com.izforge.izpack.installer.ConsoleInstaller.validatePanel(Unknown Source)
at com.izforge.izpack.installer.ConsoleInstaller.iterateAndPerformAction(Unknown Source)
at com.izforge.izpack.installer.ConsoleInstaller.doInstall(Unknown Source)
at com.izforge.izpack.installer.Installer.main(Unknown Source)
Configure [NEXTPANEL]

@5) JDKPathPanel, DefaultTargetPane not Implemented, therefore no change expected

Additional finding:
When choosing "redisplay" after a UserInputPanel is finished I would expect that the values entered before are shown, but default values are displayed

Comment by Mounir el hajj [ 17/Apr/09 ]

please try this new patch
@2) check that debug is not set to false in a previous place. in all cases attach the user input spec that is causing the exception for this panel, it is difficult to debug this exception without an accurate trace or scenario
@3) test
@4) test

M

Comment by Peter Heiles [ 17/Apr/09 ]

I will try out the newer patch, for now my Test Case for 2:
<field type="check" variable="BINDIP">
<spec txt="Bind Application to specified IP" true="true" false="false"/>
<validator class="com.izforge.izpack.util.NotEmptyValidator" />
</field>

Comment by Peter Heiles [ 17/Apr/09 ]

Just tested the changes:
@3: seems like there is no change in my installation after recompiling with new patch
Test Case:
<field type="rule" variable="SERVERIP">
<spec txt="Server IP:" layout="N:3:3 . N:3:3 . N:3:3 . N:3:3" set="0:127 1:0 2:0 3:1"/>
<validator class="com.izforge.izpack.util.NotEmptyValidator" />
</field>

display: " Server IP: [0:127 1:0 2:0 3:1]"
variable contains: 0:127 1:0 2:0 3:1

@4 Works as expected, if no exception occurs before validator should be called (e.g. in case 2).
Improvement suggestion : Output Text like "Validation failed, please verify your input" before redisplaying the input fields for the panel

Comment by Mounir el hajj [ 20/Apr/09 ]

please test this latest patch

Comment by Peter Heiles [ 20/Apr/09 ]

thanks! almost working good for me:

@2) Check box works fine, but now I figured out that dynamic variables are not updated on panel switch
Test Case:
Condition ipBindingWanted depends on user input in check field BINDAPPAPPTOIP and causes variable to change its value
— UserInput---
<field type="check" variable="BINDIP">
<spec txt="Bind Application to specified IP" true="true" false="false"/>
<validator class="com.izforge.izpack.util.NotEmptyValidator" />
</field>
--install.xml---
<conditions>
<condition type="variable" id="ipBindingWanted">
<name>BINDIP</name>
<value>true</value>
</condition>
<conditions>
<dynamicvariables>
<variable name="APPBINDHOST" value="$SERVERIP" condition="ipBindingWanted" />
<variable name="APPBINDHOST" value="0.0.0.0" condition="!ipBindingWanted" />
</dynamicvariables>

@3) works fine. In contrast to the check box the entered value is not redisplayed for ruled input fields (did not check for "simple fields)(if selected by user or validation fails)

Comment by Peter Heiles [ 20/Apr/09 ]

Patch for dynamic variable refreshs:

Index: ConsoleInstaller.java
===================================================================
— ConsoleInstaller.java (revision 2736)
+++ ConsoleInstaller.java (working copy)
@@ -1,263 +1,300 @@
-/*

  • * IzPack - Copyright 2001-2008 Julien Ponge, All Rights Reserved.
  • *
  • * https://izpack.github.io/
  • * http://izpack.codehaus.org/
  • *
  • * Copyright 2007 Dennis Reil
  • *
  • * Licensed under the Apache License, Version 2.0 (the "License");
  • * you may not use this file except in compliance with the License.
  • * You may obtain a copy of the License at
  • *
  • * http://www.apache.org/licenses/LICENSE-2.0
  • *
  • * Unless required by applicable law or agreed to in writing, software
  • * distributed under the License is distributed on an "AS IS" BASIS,
  • * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  • * See the License for the specific language governing permissions and
  • * limitations under the License.
  • */
    -package com.izforge.izpack.installer;
    -
    -import java.io.FileReader;
    -import java.io.InputStream;
    -import java.io.PrintWriter;
    -import java.io.FileInputStream;
    -import java.util.Iterator;
    -import java.util.Properties;
    -
    -import com.izforge.izpack.LocaleDatabase;
    -import com.izforge.izpack.Panel;
    -import com.izforge.izpack.util.Debug;
    -import com.izforge.izpack.util.Housekeeper;
    -import com.izforge.izpack.util.OsConstraint;
    -import com.izforge.izpack.util.VariableSubstitutor;
    -
    -/**
  • * Runs the console installer
  • *
  • * @author Mounir el hajj
  • */
    -public class ConsoleInstaller extends InstallerBase
    -{
    -
  • private AutomatedInstallData installdata = new AutomatedInstallData();
    -
  • private boolean result = false;
    -
  • private Properties properties;
    -
  • private PrintWriter printWriter;
    -
  • public ConsoleInstaller() throws Exception
  • {
  • super();
  • loadInstallData(this.installdata);
  • this.installdata.localeISO3 = "eng";
  • InputStream in = getClass().getResourceAsStream(
  • "/langpacks/" + this.installdata.localeISO3 + ".xml");
  • this.installdata.langpack = new LocaleDatabase(in);
  • this.installdata.setVariable(ScriptParser.ISO3_LANG, this.installdata.localeISO3);
  • ResourceManager.create(this.installdata);
  • loadConditions(installdata);
  • loadInstallerRequirements();
  • loadDynamicVariables();
  • if (!checkInstallerRequirements(installdata))
  • { - Debug.log("not all installerconditions are fulfilled."); - return; - }
    - addCustomLangpack(installdata);
    - }
    -
    - protected void iterateAndPerformAction(String strAction) throws Exception
    - {
    - if (!checkInstallerRequirements(this.installdata))
    - { - Debug.log("not all installerconditions are fulfilled."); - return; - }
  • Debug.log("[ Starting console installation ] " + strAction);
    -
  • try
  • {
  • this.result = true;
  • Iterator<Panel> panelsIterator = this.installdata.panelsOrder.iterator();
  • this.installdata.curPanelNumber = -1;
  • while (panelsIterator.hasNext())
  • {
  • Panel p = (Panel) panelsIterator.next();
  • this.installdata.curPanelNumber++;
  • String praefix = "com.izforge.izpack.panels.";
  • if (p.className.compareTo(".") > -1)
  • { - praefix = ""; - }
  • if (!OsConstraint.oneMatchesCurrentSystem(p.osConstraints))
  • { - continue; - }
  • String panelClassName = p.className;
  • String consoleHelperClassName = praefix + panelClassName + "ConsoleHelper";
  • Class<PanelConsole> consoleHelperClass = null;
    -
  • Debug.log("ConsoleHelper:" + consoleHelperClassName);
  • try
  • { - - consoleHelperClass = (Class<PanelConsole>) Class - .forName(consoleHelperClassName); - - }
  • catch (ClassNotFoundException e)
  • { - Debug.log("ClassNotFoundException-skip :" + consoleHelperClassName); - continue; - }
  • PanelConsole consoleHelperInstance = null;
  • if (consoleHelperClass != null)
  • {
  • try
  • { - Debug.log("Instantiate :" + consoleHelperClassName); - refreshDynamicVariables( - new VariableSubstitutor(installdata.getVariables()), installdata); - consoleHelperInstance = consoleHelperClass.newInstance(); - }
  • catch (Exception e)
  • { - Debug.log("ERROR: no default constructor for " + consoleHelperClassName - + ", skipping..."); - continue; - }
  • }
    -
  • if (consoleHelperInstance != null)
  • {
  • try
  • {
  • Debug.log("consoleHelperInstance." + strAction + ":"
  • + consoleHelperClassName + " entered.");
  • boolean bActionResult = true;
  • boolean bIsConditionFulfilled = true;
  • String strCondition = p.getCondition();
  • if (strCondition != null)
  • { - bIsConditionFulfilled = installdata.getRules().isConditionTrue( - strCondition); - }

    -

  • if (strAction.equals("doInstall") &&bIsConditionFulfilled)
  • { - bActionResult = consoleHelperInstance.runConsole(this.installdata); - }
  • else if (strAction.equals("doGeneratePropertiesFile"))
  • { - bActionResult = consoleHelperInstance.runGeneratePropertiesFile( - this.installdata, this.printWriter); - }
  • else if (strAction.equals("doInstallFromPropertiesFile") &&bIsConditionFulfilled)
  • { - bActionResult = consoleHelperInstance.runConsoleFromPropertiesFile( - this.installdata, this.properties); - }
  • if (!bActionResult)
  • { - this.result = false; - return; - }
  • else
  • { - Debug.log("consoleHelperInstance." + strAction + ":" - + consoleHelperClassName + " successfully done."); - }
  • }
  • catch (Exception e)
  • { - Debug.log("ERROR: console installation failed for panel " + panelClassName); - e.printStackTrace(); - this.result = false; - }

    -

  • }
    -
  • }
    -
  • if (this.result)
  • { - System.out.println("[ Console installation done ]"); - }
  • else
  • { - System.out.println("[ Console installation FAILED! ]"); - }
  • }
  • catch (Exception e)
  • { - this.result = false; - System.err.println(e.toString()); - e.printStackTrace(); - System.out.println("[ Console installation FAILED! ]"); - }

    -

  • }
    -
  • protected void doInstall() throws Exception
  • {
  • try
  • { - iterateAndPerformAction("doInstall"); - }
  • catch (Exception e)
  • { - throw e; - }
    -
    - finally
    - { - Housekeeper.getInstance().shutDown(this.result ? 0 : 1); - }
    - }
    -
    - protected void doGeneratePropertiesFile(String strFile) throws Exception
    - {
    - try
    - { - this.printWriter = new PrintWriter(strFile); - iterateAndPerformAction("doGeneratePropertiesFile"); - this.printWriter.flush(); - }
    - catch (Exception e)
    - { - throw e; - }

    -

  • finally
  • { - this.printWriter.close(); - Housekeeper.getInstance().shutDown(this.result ? 0 : 1); - }

    -

  • }
    -
  • protected void doInstallFromPropertiesFile(String strFile) throws Exception
  • {
  • FileInputStream in = new FileInputStream(strFile);
  • try
  • { - properties = new Properties(); - properties.load(in); - iterateAndPerformAction("doInstallFromPropertiesFile"); - }
  • catch (Exception e)
  • { - throw e; - }
  • finally
  • { - in.close(); - Housekeeper.getInstance().shutDown(this.result ? 0 : 1); - }
  • }
    -}
    +/*
    + * IzPack - Copyright 2001-2008 Julien Ponge, All Rights Reserved.
    + *
    + * https://izpack.github.io/
    + * http://izpack.codehaus.org/
    + *
    + * Copyright 2007 Dennis Reil
    + *
    + * Licensed under the Apache License, Version 2.0 (the "License");
    + * you may not use this file except in compliance with the License.
    + * You may obtain a copy of the License at
    + *
    + * http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing, software
    + * distributed under the License is distributed on an "AS IS" BASIS,
    + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    + * See the License for the specific language governing permissions and
    + * limitations under the License.
    + */
    +package com.izforge.izpack.installer;
    +
    +import java.io.FileReader;
    +import java.io.InputStream;
    +import java.io.PrintWriter;
    +import java.io.FileInputStream;
    +import java.util.Iterator;
    +import java.util.Properties;
    +
    +import com.izforge.izpack.LocaleDatabase;
    +import com.izforge.izpack.Panel;
    +import com.izforge.izpack.installer.DataValidator.Status;
    +import com.izforge.izpack.util.Debug;
    +import com.izforge.izpack.util.Housekeeper;
    +import com.izforge.izpack.util.OsConstraint;
    +import com.izforge.izpack.util.VariableSubstitutor;
    +
    +/**
    + * Runs the console installer
    + *
    + * @author Mounir el hajj
    + */
    +public class ConsoleInstaller extends InstallerBase
    +{
    +
    + private AutomatedInstallData installdata = new AutomatedInstallData();
    +
    + private boolean result = false;
    +
    + private Properties properties;
    +
    + private PrintWriter printWriter;
    +
    + public ConsoleInstaller() throws Exception
    + {
    + super();
    + loadInstallData(this.installdata);
    + this.installdata.localeISO3 = "eng";
    + InputStream in = getClass().getResourceAsStream(
    + "/langpacks/" + this.installdata.localeISO3 + ".xml");
    + this.installdata.langpack = new LocaleDatabase(in);
    + this.installdata.setVariable(ScriptParser.ISO3_LANG, this.installdata.localeISO3);
    + ResourceManager.create(this.installdata);
    + loadConditions(installdata);
    + loadInstallerRequirements();
    + loadDynamicVariables();
    + if (!checkInstallerRequirements(installdata))
    + { + Debug.log("not all installerconditions are fulfilled."); + return; + }
    + addCustomLangpack(installdata);
    + }
    +
    + protected void iterateAndPerformAction(String strAction) throws Exception
    + {
    + if (!checkInstallerRequirements(this.installdata))
    + { + Debug.log("not all installerconditions are fulfilled."); + return; + }

    + Debug.log("[ Starting console installation ] " + strAction);
    +
    + try
    + {
    + this.result = true;
    + Iterator<Panel> panelsIterator = this.installdata.panelsOrder.iterator();
    + this.installdata.curPanelNumber = -1;
    + VariableSubstitutor substitutor = new VariableSubstitutor(this.installdata.getVariables());
    + while (panelsIterator.hasNext())
    + {
    + Panel p = (Panel) panelsIterator.next();
    + this.installdata.curPanelNumber++;
    + String praefix = "com.izforge.izpack.panels.";
    + if (p.className.compareTo(".") > -1)
    +

    { + praefix = ""; + }

    + if (!OsConstraint.oneMatchesCurrentSystem(p.osConstraints))
    +

    { + continue; + }

    + String panelClassName = p.className;
    + String consoleHelperClassName = praefix + panelClassName + "ConsoleHelper";
    + Class<PanelConsole> consoleHelperClass = null;
    +
    + Debug.log("ConsoleHelper:" + consoleHelperClassName);
    + try
    +

    { + + consoleHelperClass = (Class<PanelConsole>) Class + .forName(consoleHelperClassName); + + }

    + catch (ClassNotFoundException e)
    +

    { + Debug.log("ClassNotFoundException-skip :" + consoleHelperClassName); + continue; + }

    + PanelConsole consoleHelperInstance = null;
    + if (consoleHelperClass != null)
    +

    Unknown macro: {+ try+ { + Debug.log("Instantiate :" + consoleHelperClassName); + refreshDynamicVariables(substitutor, installdata); + consoleHelperInstance = consoleHelperClass.newInstance(); + }+ catch (Exception e)+ { + Debug.log("ERROR: no default constructor for " + consoleHelperClassName + + ", skipping..."); + continue; + }+ }

    +
    + if (consoleHelperInstance != null)
    + {
    + try
    + {
    + Debug.log("consoleHelperInstance." + strAction + ":"
    + + consoleHelperClassName + " entered.");
    + boolean bActionResult = true;
    + boolean bIsConditionFulfilled = true;
    + String strCondition = p.getCondition();
    + if (strCondition != null)
    +

    { + bIsConditionFulfilled = installdata.getRules().isConditionTrue( + strCondition); + }

    +
    + if (strAction.equals("doInstall") && bIsConditionFulfilled)
    +

    Unknown macro: {+ do+ { + bActionResult = consoleHelperInstance.runConsole(this.installdata); + }+ while (!validatePanel(p));+ }

    + else if (strAction.equals("doGeneratePropertiesFile"))
    +

    { + bActionResult = consoleHelperInstance.runGeneratePropertiesFile( + this.installdata, this.printWriter); + }

    + else if (strAction.equals("doInstallFromPropertiesFile")
    + && bIsConditionFulfilled)
    +

    { + bActionResult = consoleHelperInstance.runConsoleFromPropertiesFile( + this.installdata, this.properties); + }

    + if (!bActionResult)
    +

    { + this.result = false; + return; + }

    + else
    +

    { + Debug.log("consoleHelperInstance." + strAction + ":" + + consoleHelperClassName + " successfully done."); + }

    + }
    + catch (Exception e)
    +

    { + Debug.log("ERROR: console installation failed for panel " + panelClassName); + e.printStackTrace(); + this.result = false; + }

    +
    + }
    +
    + }
    +
    + if (this.result)
    +

    { + System.out.println("[ Console installation done ]"); + }

    + else
    +

    { + System.out.println("[ Console installation FAILED! ]"); + }

    + }
    + catch (Exception e)
    +

    { + this.result = false; + System.err.println(e.toString()); + e.printStackTrace(); + System.out.println("[ Console installation FAILED! ]"); + }

    +
    + }
    +
    + protected void doInstall() throws Exception
    +

    Unknown macro: {+ try+ { + iterateAndPerformAction("doInstall"); + }+ catch (Exception e)+ { + throw e; + }
    +
    + finally
    + { + Housekeeper.getInstance().shutDown(this.result ? 0 : 1); + }
    + }
    +
    + protected void doGeneratePropertiesFile(String strFile) throws Exception
    + {
    + try
    + { + this.printWriter = new PrintWriter(strFile); + iterateAndPerformAction("doGeneratePropertiesFile"); + this.printWriter.flush(); + }
    + catch (Exception e)
    + { + throw e; + }++ finally+ { + this.printWriter.close(); + Housekeeper.getInstance().shutDown(this.result ? 0 : 1); + }++ }

    +
    + protected void doInstallFromPropertiesFile(String strFile) throws Exception
    +

    Unknown macro: {+ FileInputStream in = new FileInputStream(strFile);+ try+ { + properties = new Properties(); + properties.load(in); + iterateAndPerformAction("doInstallFromPropertiesFile"); + }+ catch (Exception e)+ { + throw e; + }+ finally+ { + in.close(); + Housekeeper.getInstance().shutDown(this.result ? 0 : 1); + }+ }

    +
    + /**
    + * Validate a panel.
    + *
    + * @param p The panel to validate
    + * @throws InstallerException thrown if the validation fails.
    + */
    + private boolean validatePanel(final Panel p) throws InstallerException
    + {
    + boolean bValidity = true;
    + String dataValidator = p.getValidator();
    + if (dataValidator != null)
    + {
    + DataValidator validator = DataValidatorFactory.createDataValidator(dataValidator);
    + Status validationResult = validator.validateData(installdata);
    + if (validationResult != DataValidator.Status.OK)
    +

    Unknown macro: {+ // if defaultAnswer is true, result is ok+ if (validationResult == Status.WARNING && validator.getDefaultAnswer())+ { + System.out + .println("Configuration said, it's ok to go on, if validation is not successfull"); + + }+ // make installation fail instantly+ bValidity = false;+ System.out.println("Validation failed, please verify your input");+ }

    + }
    + return bValidity;
    + }
    +}

Comment by Peter Heiles [ 20/Apr/09 ]

Added patches to fix described problems:
a) dynamic variables are now refreshed after panel switch
b) default "text values" are replaced with previous user input if panel is redisplayed

Comment by Van Halbert [ 21/May/09 ]

Is anyone adding the logic to support field types "file" and "password"? Also, what about supporting the langpacks, because it didn't appear to be substituting the language for the id.

Why I'm asking about these is because I would be glad to work on this and provide a patch, if no one is currently adding these options.

Comment by Peter Heiles [ 22/May/09 ]

Attached my latest version of the patch.
I'm currently not adding more functionality to the console mode

Comment by Julien Ponge [ 23/May/09 ]

Thanks I will have a look Peter.

@Van: sure, feel free to contribute a patch!

Comment by Van Halbert [ 26/May/09 ]

This patch adds the following:

  • supports Processor for obtaining choices in the combo or radio field types
  • support for Password field type
  • fixed bug on return from calling getInputFromField(...), needed to handle null.
  • added Space and Divider field types for visual appearance

Next capabilities to add are:

  • support Validators and DataValidators
  • support more complex installation options based on pack selection
Comment by Julien Ponge [ 26/May/09 ]

@Peter: I tried to apply your patch (Index_ src_lib_com_izforge_izpack_installer_ConsoleInstaller.java.txt) but it did not work. Since there are some patch bits in the issue comments, I guess you had a problem to properly upload it. Could you please re-submit one single patch?

@Van: your patch applies fine, but just to make sure: you applied the one from Mounir (patch.txt) first right?

Comment by Van Halbert [ 26/May/09 ]

yes, that patch added the support for rules and check boxes (and others). I added additional logic for check boxes to support processors.

Comment by Van Halbert [ 26/May/09 ]

I said added logic to check boxes, but I meant for combo boxes.

Comment by Peter Heiles [ 27/May/09 ]

2nd try to upload patch. it includes the changes from Mounir + some fixes

Comment by Mounir el hajj [ 27/May/09 ]

I also have a small correction, for generating properties file, and playback form that file, when an input has no variable attached to it like for example a statictext input. i will post the patch once the available patches are submitted. it is very simple

107,113c107,111
< if(strVariableName!=null){
< String strVariableValue = p.getProperty(strVariableName);
< if (strVariableValue != null)
<

{ < installData.setVariable(strVariableName, strVariableValue); < }

< }

> String strVariableValue = p.getProperty(strVariableName);
> if (strVariableValue != null)
>

{ > installData.setVariable(strVariableName, strVariableValue); > }

125,128c123
< Input input=(Input) inputIterator.next();
< if (input.strVariableName!=null)

{ < printWriter.println(input.strVariableName + "="); < }


> printWriter.println(((Input) inputIterator.next()).strVariableName + "=");

Comment by Julien Ponge [ 28/May/09 ]

Van's patch applies fine. I am applying it to the IzPack source tree, in branches/4.3 under SVN.

Peter, your patch does not apply after Van's one:

julien@jponge ~/C/i/s/lib> patch --dry-run -p0 < ../../patch_20090527.txt
(Stripping trailing CRs from patch.)
patching file com/izforge/izpack/installer/ConsoleInstaller.java
(Stripping trailing CRs from patch.)
patching file com/izforge/izpack/panels/JDKPathPanel.java
(Stripping trailing CRs from patch.)
patching file com/izforge/izpack/panels/JDKPathPanelConsoleHelper.java
(Stripping trailing CRs from patch.)
patching file com/izforge/izpack/panels/UserInputPanelConsoleHelper.java
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file com/izforge/izpack/panels/UserInputPanelConsoleHelper.java.rej

@Mounir: ok to get your patch after the ones from Van and Peter

Comment by Peter Heiles [ 28/May/09 ]

Julien, this is the patch based on revision 2783 - you should be able to apply it now

Comment by Julien Ponge [ 29/May/09 ]

Thanks Peter, it has been applied.

I am now waiting on an update from Mounir before I can close the issue.

Comment by Van Halbert [ 29/May/09 ]

This patch applies to rev 2785.

It does the following:

  • adds the display of the description (header) for the combo or radio boxes
  • fixes the setting of the selected default for combo / radio boxes (including when only one exist in the combo, therefore setting that as the default)
Comment by Julien Ponge [ 31/May/09 ]

Thanks Van, it's been applied.

Comment by Van Halbert [ 01/Jun/09 ]

This is a patch to rev 2787. It provides the following:

  • the default value for a text field wasn't being substituted for
  • adds logic to support installation groups and OS specific panels/fields (see patch src_lib_com_izforge_izpack_panels_InstallationGroup_20090601_patches.txt that adds installationgroup console helper for presenting installation group options)
Comment by Van Halbert [ 01/Jun/09 ]

The attached patch adds the ability in console mode to support selecting an installation group.

After working on the console mode for userinputpanel, realized there was alot of code duplication when dealing with the xml elements and properties. Therefore, in this patch, i've tried to consolidate the code for use by the UI and console mode logic. I'm not sure if this is how you would have preferred to break out the code, so please direct me if you would like to handle it differently.

Comment by Van Halbert [ 01/Jun/09 ]

This is the patch to the build.xml file to support the InstallationGroup patches.

Comment by Peter Heiles [ 03/Jun/09 ]

Van, with revision 2785 I found the following behaviour with radio boxes:
in userinputpanel definition for this panel option 0 has the option set="true", others have no set defined

1.: Initial display
Select Installation Type
0 [x] Single Node Installation
1 [ ] Cluster Installation
2 [ ] DemoInstallation

2. select "1"

3. Redisplay:
0 [x] Single Node Installation
1 [x] Cluster Installation
2 [ ] DemoInstallation
Both Options are marked (which should not happen with a radio box)

after removing the "set="true"" Parameter from the radio box definition display was as expected

Comment by Julien Ponge [ 03/Jun/09 ]

Thanks Van, but the first patch in the queue fails to apply:

patch --dry-run -p0 < src_lib_com_izforge_izpack_panels_UserInputPanelConsoleHelper_20090601_patch.txt
patching file src/lib/com/izforge/izpack/panels/UserInputPanelConsoleHelper.java
Hunk #3 FAILED at 172.
Hunk #4 succeeded at 247 (offset -1 lines).
Hunk #5 succeeded at 259 (offset -1 lines).
Hunk #6 succeeded at 341 (offset -1 lines).
Hunk #7 succeeded at 851 (offset -1 lines).
1 out of 7 hunks FAILED -- saving rejects to file src/lib/com/izforge/izpack/panels/UserInputPanelConsoleHelper.java.rej

Could you please have a look and consolidate with the other ones?

Thanks!

Comment by Peter Heiles [ 03/Jun/09 ]

Julien, I figured out that variables in staticText fields are not replaced.
Here is my code snippet for UserInputPanelConsoleHelper (too many open patches at the moment - think it's not good to add another one right now).
Could you please put it in there "manually"?

boolean processSimpleField(Input input, AutomatedInstallData idata)

{ VariableSubstitutor vs = new VariableSubstitutor(idata.getVariables()); System.out.println(vs.substitute(input.strText, null)); return true; }
Comment by Julien Ponge [ 04/Jun/09 ]

Ok Peter, it has been manually applied

Comment by Van Halbert [ 08/Jun/09 ]

Sorry for the unacceptable patch.

Here's a new patch that's run thru the patch process:

src_lib_com_izforge_izpack_panels_UserInputPanelConsoleHelper_20090608_patch.txt was created against rev 2792.

Comment by Julien Ponge [ 11/Jun/09 ]

Just merged, thanks!

Comment by Mounir el hajj [ 26/Jun/09 ]

sorry for the late notice, but i think the small correction posted by me on 27/May/09 09:11 AM was not merged. Julien how to proceed?

Comment by Julien Ponge [ 22/Aug/09 ]

Hi Mounir,

Sorry for the delay. I guess the best would be that you have a look, and upload a fresh patch.

Cheers

Comment by Mounir el hajj [ 24/Aug/09 ]

Hi Julien. patch-24-8-2009.txt attached

Comment by Julien Ponge [ 26/Aug/09 ]

Great.

Shall I now consider the issue as resolved?

If you guys have further fixes, new issues should be created. What do you think?

Comment by Mounir el hajj [ 27/Aug/09 ]

Thanks Julien

you can consider everything is resolved from my side

Thank You





[IZPACK-367] Installdata is null in condition Created: 07/Apr/09  Updated: 06/Nov/09  Resolved: 08/Oct/09

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

Type: Bug Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The installdata is sometimes not initialized in conditions.



 Comments   
Comment by Julien Ponge [ 13/Apr/09 ]

As we are 1 week away from the release of 4.3.0, do you think that you can resolve the issue on time?

It is absolutly not a problem if you can't, just let me know as we can move the issue to 4.3.1.

Thanks a lot!





[IZPACK-366] Minor fixes for Italian langpack Created: 07/Apr/09  Updated: 20/Apr/09  Resolved: 08/Apr/09

Status: Closed
Project: IzPack
Component/s: Translations
Affects Version/s: 4.2.1, 4.3.0
Fix Version/s: 4.3.0

Type: Improvement Priority: Trivial
Reporter: Andrea Gualano Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ita.xml.diff    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Standardized translation of "progress" to "progresso".
Both "progresso" and "progressione" are valid translations, but mixing the two is a bit ugly.



 Comments   
Comment by Julien Ponge [ 08/Apr/09 ]

Thanks!





[IZPACK-365] Allow compile-time variable substitution for <file> elements Created: 06/Apr/09  Updated: 08/Apr/09  Resolved: 08/Apr/09

Status: Closed
Project: IzPack
Component/s: Compiler
Affects Version/s: 3.11.0, 4.0.0, 4.0.1, 4.1.0, 4.1.1, 4.2.0, 4.2.1, 4.3.0, 4.3.1, 5.0
Fix Version/s: 4.3.0

Type: Improvement Priority: Minor
Reporter: Kjell Braden Assignee: Kjell Braden
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 20 minutes
Original Estimate: 30 minutes

Attachments: Text File izpack-365.patch    
Number of attachments : 1

 Description   

Another feature I'd like to see in IzPack is being able to use variables for adding files.

Example use case:

My project ships in multiple flavors, they all have a very similar design but each flavor need to include a, say, different database dump. Now I would not like to maintain multiple configuration files, but rather have a install-base.xml containing basicly everything (and a {{<singlefile src="$

{FLAVOR}

.dump" ...>}}) and a install.xml which looks something like this:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<installation version="1.0" xmlns:xi="http://www.w3.org/2001/XInclude">
  <xi:include href="install-base.xml" />

  <variables>
    <variable name="FLAVOR" value="foo" />
  </variables>
</installation>

Now I could create one of these small files for each flavor and adjust the variable, and every flavor would use the same configuration, but a different dump file.






[IZPACK-364] OsConstraints in only one parsable leads to skipping the whole pack Created: 06/Apr/09  Updated: 06/Nov/09  Resolved: 30/Sep/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1, 4.3.0
Fix Version/s: 4.3.2, 5.0

Type: Bug Priority: Critical
Reporter: Dennis Reil Assignee: Julien Ponge
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

OsConstraints are not handled correctly. If I define a pack with a whole bunch of files, specifying e.g. four parsables and marking only one of it with <os family="unix" />, because this only should be parsed on unix, then the installer will not show the whole pack if I'm running on windows or any other non unix system.

Especially if I'm using conditions to select which file has to be parsed or executed, this is a big problem.



 Comments   
Comment by Julien Ponge [ 13/Apr/09 ]

As we are 1 week away from the release of 4.3.0, do you think that you can resolve the issue on time?

It is absolutly not a problem if you can't, just let me know as we can move the issue to 4.3.1.

Thanks a lot!

Comment by Laurian Vostinar [ 23/Jun/09 ]

This is not just for parsables, I have an executable and get the same issue. Problem seems to be function public Vector<IXMLElement> getChildrenNamed(String name) from XmlElementImpl which has changed functionality: with nanoxml it only returned children with that name now it returns all descendants with that name. So, compiler thinks the os contrainst that is defined for parsable/executable... is a os constraint for the whole pack.

Comment by Laurian Vostinar [ 21/Jul/09 ]

a patch for this issue:

"patch.txt"
### Eclipse Workspace Patch 1.0
#P IzPack
Index: src/lib/com/izforge/izpack/adaptator/impl/XMLElementImpl.java
===================================================================
--- src/lib/com/izforge/izpack/adaptator/impl/XMLElementImpl.java (revision 2811)
+++ src/lib/com/izforge/izpack/adaptator/impl/XMLElementImpl.java (working copy)
@@ -196,12 +196,14 @@
     public Vector<IXMLElement> getChildrenNamed(String name)
     {
         Vector<IXMLElement> res = new Vector<IXMLElement>();
-        NodeList nodeList = element.getElementsByTagName(name);
-        Element child;
-        for (int i = 0; i < nodeList.getLength(); i++)
+        Vector<IXMLElement> children = getChildren();
+        for (int i = 0; i < children.size(); i++)
         {
-            child = (Element) nodeList.item(i);
-            res.add(new XMLElementImpl(child));
+            IXMLElement child = children.elementAt(i);
+            if (child.getName()!= null && child.getName().equals(name))
+            {
+                res.add(new XMLElementImpl(child.getElement()));
+            }
         }
         return res;
     }
Comment by Julien Ponge [ 30/Sep/09 ]

Thanks for the patch!





[IZPACK-363] Improve layout possibility on UserInputPanel Created: 06/Apr/09  Updated: 01/Mar/10  Resolved: 01/Mar/10

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

Type: Improvement Priority: Major
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
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-176 Alignment in UserInputPanel Resolved
is related to IZPACK-476 Make the UserInputPanel contents scro... Closed
Number of attachments : 0

 Description   

For the moment it is not possible to change the alignment or position of controls or text.

It would be nice if the user could change the position and alignment of each label and control to fit the needs of the designed GUI.

Add the following attributes to all field types:

  • label_position (westonly / west / east / eastonly)
  • label_align (left / right)
  • label_indent (true / false)
  • control_position (westonly / west / east / eastonly)
  • control_align (left / right)
  • control_indent (true / false)


 Comments   
Comment by Florian Buehlmann [ 26/Feb/10 ]

In addition to the label and control positioning and alignment features, it will be possible to avoid the border of the UserInputPanel.
This can be done with the panel attribute border.
It is now also possible to set the column width with the panel attribute column_width.

Comment by Florian Buehlmann [ 01/Mar/10 ]

There are several new layout possibilities for UserInputPanel. See documentation for more information.





[IZPACK-362] Allow override of InstallDir from Java property Created: 04/Apr/09  Updated: 02/Jun/14

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

Type: Improvement Priority: Minor
Reporter: Tom Rodriguez 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   

During an unattended install, the only way to specify a non-standard Install Directory is to create a file where the new directory is defined, and provide that on the command line. Rather than having to create this file, it would be much more convenient if I could just set a property, such as "izpack.InstallDir" or something similar, that would override any defaults for the installation directory.

In my case, I have a very simple installer that takes no input, but simply installs the component. Specifically, the "panels" section of the install.xml file looks like so:

<panels>
<panel classname="InstallPanel"/>
</panels>

So there is now no opportunity for the default install directory to be overriden.



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

In IZPack 5.0 it is possible to set -DINSTALL_PATH=/some/path on the command line. I've tested this just with TargetPanel present in the panel list, but there are known unsolved issues for installers not using TargetPanel at all.





[IZPACK-361] Updatecheck should only check the included files of the installation path Created: 03/Apr/09  Updated: 20/Apr/09  Resolved: 09/Apr/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Jens Mühlenhoff Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Number of attachments : 0

 Description   

The uptodatecheck check all files in the installation directory. This will take a long time, if the installation contains a lot of files.

The Unpacker should eval the next directory, if it matches any of the given include. This will reduce the number of files which must be checked.

One think could be like this:

if (newf.isDirectory() && !fileMatchesOnePattern(newfname, exclude_patterns) )
{
    scanstack.push(newf);
}

in this case the deeper directories will only be scanned if they are not explicitly excluded. This will not break the current implementation, but will speed up the installation, if hugh directories could be exclude for scanning.



 Comments   
Comment by Julien Ponge [ 09/Apr/09 ]

Thanks!





[IZPACK-360] language select TWN Created: 03/Apr/09  Updated: 16/Jun/09  Resolved: 16/Jun/09

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

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

Attachments: PNG File Screenshot-Izpack-lan.png    
Number of attachments : 1

 Description   

Hi,

I forgot to tell you that,
the select language with twn.xml don't have the real reading word that display on the selecting panel.
If you could add for us, the twn display word is same as chn "中文"

So if the chn display "中文", the twn is the same too.
The flag will notice us, which is sample chinese or traditional chinese.

thanks you.



 Comments   
Comment by Edward Chiang [ 03/Apr/09 ]

Or can add for this display, if the developer don't chose the use flags:
sample chinese = 簡體中文
traditional chinese = 繁體中文

Comment by Julien Ponge [ 03/Apr/09 ]

I don't get it

Comment by Edward Chiang [ 03/Apr/09 ]

I upload a picture for you. The word it display is "twn",
could you put it as "繁體中文" for us.

Thanks.

Comment by Edward Chiang [ 16/Jun/09 ]

It seem that the iso3 doesn't add the Taiwan here for us. We add the reference by country, and determain with zh_CN and zh_TW, then we get the different display item at the language page.

Thanks.





[IZPACK-359] Make <parsable> able to replace ant properties defined as @{x} when inheritAll="true" is specified Created: 03/Apr/09  Updated: 03/Apr/09

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

Type: Wish Priority: Major
Reporter: Boris Capitanu 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 discovered that when invoking the <IzPack> task via ant with inheritAll="true", then <parsable> files that contain references to ant properties (such as @

{ant.project.name}

) do not get replaced. Apparently the ant properties are only available for reference inside the install.xml definition file. It would be great if those inherited ant properties would be made available for <parsable> files as well.

Scenario: One of the files I need to deploy is a BAT file that contains a command to execute a particular jar. The jar name is dependent on the version number. There is an ant task that figures out what the proper JAR name is, and that value is stored in a property. I don't currently have a direct way of referencing that JAR name via that property in the BAT file. I have to create the BAT file from ant.






[IZPACK-358] PacksPanelAutomationHelper deselect packs that are marked as required for the installation Created: 02/Apr/09  Updated: 20/Apr/09  Resolved: 06/Apr/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Critical
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If a user modifies an autoinstall.xml and change the value of a pack "selected=true" to false the pack is not installed. This make sense for optional packs. If the pack is required for an installation this value should be ignored.
As I have seen in the automation helper for the PacksPanel we clear the selected packs list and build them fresh from autoinstall.xml. I think we should only allow to change the selection for optional packs and not rebuild the selected pack list from autinstall.xml. In my opinion the installer should be the master that defines the packs to install. It should only be possible to make changes to optional values with the autoinstall.xml.



 Comments   
Comment by Florian Buehlmann [ 06/Apr/09 ]

The installer now defines the package set. Only optional packages can now be selected deselected by the automated installer (autoinstall.xml)





[IZPACK-357] Loose pack do not work on linux if installer is created on windows Created: 01/Apr/09  Updated: 20/Apr/09  Resolved: 02/Apr/09

Status: Closed
Project: IzPack
Component/s: Compiler, Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Blocker
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If a installer that is built on a windows system runs on linux the loose pack files can not be copied because of wrong file separator chars in relative file path.
These characters are set during compilation. If the installer is built on a linux system it works fine for windows and linux.



 Comments   
Comment by Florian Buehlmann [ 02/Apr/09 ]

Loose packs now work on linux even if the installer is built on windows.





[IZPACK-356] Show progress while MultiVolumeInstaller is using SelfModifier to extract and restart Created: 01/Apr/09  Updated: 20/Apr/09  Resolved: 01/Apr/09

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

Type: Improvement Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The MultiVolumeInstaller should show a progress window while it is extracting the installer to the temporary directory and restarting itself from there. With big installers this could take a while and can maybe mislead customer if no ui is shown.



 Comments   
Comment by Dennis Reil [ 01/Apr/09 ]

MultiVolumeInstaller now shows a progress dialog if ui is available.





[IZPACK-355] Null Pointer Exception at RulesEngine.getCondition Created: 01/Apr/09  Updated: 06/May/09  Resolved: 03/Apr/09

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

Type: Bug Priority: Major
Reporter: Abhishek Sharma Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Number of attachments : 0

 Description   

I need to validate the CATALINA_HOME property in environment. For this I've written a condition which evaluates the CATALINA_HOME from a java file.

This condition works fine with the Panel but when I tries to use <installerrequirements> nothing happens and a nullpointer is thrown by Izpack.

Code:

<panels>

<panel classname="InfoPanel"/>

<panel classname="TargetPanel" condition="setcatalina"/>

<panel classname="LicencePanel"/>

<panel classname="PacksPanel" />

<panel classname="UserInputPanel" id="UserInputPanel.0" />

<panel classname="UserInputPanel" id="UserInputPanel.0" />

<panel classname="InstallPanel" />

<panel classname="ShortcutPanel"/>

<panel classname="ProcessPanel"/>

<panel classname="SimpleFinishPanel" />

</panels>

<condition type="java" id="setcatalina">

<java>

<class>PropertyReplace</class>

<field>IS_CATALINA_HOME_SET</field>

</java>

<returnvalue type="boolean">true</returnvalue>

</condition>

</conditions>

<installerrequirements>

<installerrequirement conditon="setcatalina" message="CATALINA HOME NOT FOUND !" /></installerrequirements>

Exception

F:\EMS28March\Code\EMS\installer>call java -jar ems-installer.jar

  • ERROR -

java.lang.NullPointerException

java.lang.NullPointerException

at java.lang.StringBuffer.<init>(Unknown Source)

at com.izforge.izpack.rules.RulesEngine.getCondition(Unknown Source)

at com.izforge.izpack.installer.InstallerBase.checkInstallerRequirements

(Unknown Source)

at com.izforge.izpack.installer.GUIInstaller.<init>(Unknown Source)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Sou

rce)

at java.lang.reflect.Constructor.newInstance(Unknown Source)

at java.lang.Class.newInstance0(Unknown Source)

at java.lang.Class.newInstance(Unknown Source)

at com.izforge.izpack.installer.Installer.main(Unknown Source)

PLEASE HELP I ALREADY INVESTED ENOUGH TIME ON THIS.



 Comments   
Comment by Dennis Reil [ 01/Apr/09 ]

Seems to be a classloading problem. I fixed that for 4.3.0.

Comment by Abhishek Sharma [ 02/Apr/09 ]

Let me know if i am not using the installer requirements correctly. This is the code i used in install.xml

<conditions>
<condition type="variable" id="start_ems_server">
<name>start_ems_server</name>
<value>true</value>
</condition>

<condition type="java" id="setCatalina">
<java>
<class>PropertyReplace</class>
<field>IS_CATALINA_HOME_SET</field>
</java>
<returnvalue type="boolean">true</returnvalue>
</condition>
</conditions>

<installerrequirements>
<installerrequirement conditionid="setCatalina" message="This installer could not run"/></installerrequirements>

I tried with Izpack4.3 test release and below is the error log:

Total time: 10 seconds

  • ERROR -
    java.lang.NullPointerException
    java.lang.NullPointerException
    at java.lang.StringBuffer.<init>(Unknown Source)
    at com.izforge.izpack.rules.RulesEngine.getCondition(Unknown Source)
    at com.izforge.izpack.installer.InstallerBase.checkInstallerRequirements
    (Unknown Source)
    at com.izforge.izpack.installer.GUIInstaller.init(Unknown Source)
    at com.izforge.izpack.installer.GUIInstaller.<init>(Unknown Source)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Sou
rce)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at com.izforge.izpack.installer.Installer.main(Unknown Source)

Comment by Dennis Reil [ 03/Apr/09 ]

This is my sample code, to test this. Maybe your custom class is doing something wrong?

<?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>Sample Installation</appname>
<appversion>1.4 beta 666</appversion>
<authors>
<author name="JPz" email="jpz@superman.org"/>
<author name="Hidden Man" email="hidden@hisdomain.com"/>
</authors>
<url>http://www.anotherworld-inspace-website.net/</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="no">
<modifier value="true" key="showDebugWindow" />
</guiprefs>

<!--
The locale section.
Asks here to include the English and French langpacks.
-->
<locale>
<langpack iso3="eng"/>
<langpack iso3="fra"/>
</locale>

<!--
The resources section.
The ids must be these ones if you want to use the LicencePanel and/or the InfoPanel.
-->
<resources>
<res id="LicencePanel.licence" src="Licence.txt"/>
<res id="InfoPanel.info" src="Readme.txt"/>
</resources>

<variables>
<variable name="do.test" value="1" />
<variable name="radioSelection" value="New" />
</variables>

<dynamicvariables>
<variable name="test" value="0" condition="!do.test" />
<variable name="test" value="1" condition="do.test" />
</dynamicvariables>

<conditions>
<condition type="variable" id="do_test">
<name>do.test</name>
<value>1</value>
</condition>
<condition type="variable" id="newinstallation">
<name>radioSelection</name>
<value>New</value>
</condition>
<condition type="variable" id="upgradeinstallation">
<name>radioSelection</name>
<value>Upgrade</value>
</condition>
</conditions>

<installerrequirements>
<installerrequirement condition="!do_test" message="Requirement not fulfilled." />
</installerrequirements>

<!--
The panels section.
We indicate here which panels we want to use. The order will be respected.
-->
<panels>
<panel classname="HelloPanel"/>
<panel classname="InfoPanel"/>
<panel classname="LicencePanel"/>
<panel classname="TargetPanel"/>
<panel classname="PacksPanel"/>
<panel classname="InstallPanel"/>
<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="script.bat" targetdir="$INSTALL_PATH"/>
<file src="Licence.txt" targetdir="$

{INSTALL_PATH}/${test}"/>
<parsable targetfile="$INSTALL_PATH/script.bat"/>
<!-- The file will be parsed -->
</pack>
<pack name="HiddenSelector" id="hideme" required="no" preselected="yes" hidden="false">
<description>Test of a hidden pack</description>
<file src="HiddenDocument.txt" targetdir="${INSTALL_PATH}

/hidden" />
</pack>

<pack name="HiddenTest" required="no" preselected="yes" hidden="true" condition="izpack.selected.hideme">
<description>Test of a hidden pack</description>
<file src="HiddenDocument.txt" targetdir="$

{INSTALL_PATH}/hidden" />
</pack>
<pack name="Docs" required="no" preselected="no">
<description>The documentation</description>
<file src="doc" targetdir="$INSTALL_PATH"/>
<file src="doc" targetdir="${INSTALL_PATH}

/conditiondoc" condition="do_test" />
<!-- Reccursive adding -->
</pack>
<pack name="Sources" required="no" preselected="no" id="sources">
<description>The sources</description>
<file src="src" targetdir="$INSTALL_PATH"/>
</pack>
<pack name="Database Configuration" required="no" condition="do_test" id="database.pack">
<description>The database configuration</description>
<file src="dbconfig" targetdir="$INSTALL_PATH" />
</pack>
<pack name="Database" required="yes" condition="newinstallation" id="dbpack">
<description>HSQL database files - you'll need these unless you are upgrading</description>
</pack>
<pack name="Upgrade" required="yes" condition="upgradeinstallation" id="upgradepack">
<description>Files needed to upgrade</description>
</pack>
</packs>

</installation>

Comment by Vikash Kumar [ 17/Apr/09 ]

Could you please let me know if this is fixed for TreePacksPanel too? I am using TreePacksPanel and have a hidden pack.

<pack name="Start Weblogic" id="StartWL" required="no" hidden="true" condition="always_true">
<description>This will start weblogic server.</description>
<file src="configure-appserver-temp.xml" targetdir="$INSTALL_PATH/ant-scripts"/>
</pack>

It throws the following error while loading the TreePacksPanel and shows and empty panel.
Exception in thread "AWT-EventQueue-0" java.lang.IndexOutOfBoundsException: Inde
x: 8, Size: 8
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at com.izforge.izpack.panels.PacksModel.getValueAt(Unknown Source)
at com.izforge.izpack.panels.TreePacksPanel.updateModel(Unknown Source)
at com.izforge.izpack.panels.TreePacksPanel.updateModel(Unknown Source)
at com.izforge.izpack.panels.TreePacksPanel.updateModel(Unknown Source)
at com.izforge.izpack.panels.TreePacksPanel.fromModel(Unknown Source)
at com.izforge.izpack.panels.CheckBoxNodeRenderer.getTreeCellRendererCom
ponent(Unknown Source)

If it is not fixed for TreePacksPanel, Can it be?
Thanks and Regards
Vikash

Comment by Marco Tessari [ 06/May/09 ]

I think there is some confusion on the condition attribute in installerrequirement element.

In doc you have conditon:

<installerrequirement conditon="installonwindows" message="This installer could only be run on Windows operating systems."/>

In Abhishek exemple there is conditionid (may be from a previous version):

<installerrequirement conditionid="setCatalina" message="This installer could not run"/>

and the one which works condition:

<installerrequirement condition="installonwindows" message="This installer could only be run on Windows operating systems."/>

I think a simple documentation update should fix the problem
A better error message (a DTD or any XML validation) should be even better





[IZPACK-354] default path in Windows was program files Created: 28/Mar/09  Updated: 28/Mar/09  Resolved: 28/Mar/09

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

Type: New Feature Priority: Major
Reporter: Edward Chiang Assignee: Unassigned
Resolution: Not A Bug Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows xp, jdk 1.5, tomcat 6


Number of attachments : 0

 Description   

Hi,

I use the Izpack to wrapped our project for installer.
And the panel of install path in windows will default given us
C:
Program Files
$

{app.name}

Our project will use this given path to build the project.
But our project could not use the path that include with blank space.

So I wonder how can I get the default install path only the value in "C:
${app.name}

"
instead of "C:
Program Files

{app.name}

" ?

Thank you.

Best regards,
Edward Chiang



 Comments   
Comment by Julien Ponge [ 28/Mar/09 ]

Please ask on the lists instead. Thanks





[IZPACK-353] Uninstaller does not respect condition in run-privileged Created: 26/Mar/09  Updated: 20/Apr/09  Resolved: 02/Apr/09

Status: Closed
Project: IzPack
Component/s: Uninstaller
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Minor
Reporter: Andrea Gualano Assignee: Julien Ponge
Resolution: Fixed 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 have an installer that works correctly under Windows XP; I have added this line to make it work under Windows Vista:
<run-privileged condition="izpack.windowsinstall.vista"/>
The two configurations are otherwise identical.

The installer with "run-privileged" works as expected under Vista. Under XP, the installer works correctly (i.e. without asking for privilege elevation) but the uninstaller opens a privilege escalation dialog.
The uninstaller without "run-privileged" works correctly under XP.

The uninstallers generated on XP by the two installers are the same except for an empty file called "exec-admin" in the one with "run-privileged".
Perhaps the empty file should not be included when the condition is not verified?

Also note that this might be related to IZPACK-217 since I am testing the installer on a localized version of Windows XP.



 Comments   
Comment by Julien Ponge [ 02/Apr/09 ]

Fixed: the uninstaller is told to make an elevation only if if the installer did a successful one.





[IZPACK-352] Enhance conditions to save configuration of conditions to xml. Created: 24/Mar/09  Updated: 20/Apr/09  Resolved: 24/Mar/09

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

Type: Improvement Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

For postinstallation or update/upgrade issues, it would be good to be able to save the set of conditions used during the installation in a xml file. Thus, a postinstallation or update process can read it in and use it for its work.



 Comments   
Comment by Dennis Reil [ 24/Mar/09 ]

integrated a new abstract method (makeXML) which works similar to PanelAutomation.makeXMLData. Each condition will get a root element containing the id and class. The condition then has to serialize their configuration to xml and add it as child elements to the root element.





Improve user documentation (IZPACK-327)

[IZPACK-351] Document automatic Windows privilege elevation Created: 23/Mar/09  Updated: 20/Apr/09  Resolved: 02/Apr/09

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

Type: Sub-task Priority: Minor
Reporter: Christian d'Heureuse Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Number of attachments : 0

 Description   

I propose to extend the documentation with some notes about Windows Vista and XP privilege elevation. It could be added as a note to the description of the <run-privileged> element, or as a separate chapter in "Advanced Features".

As an alternative to using the <run-privileged> element, a Java launcher EXE with the name "setup.exe" or "install.exe" can be used.

Background info: http://msdn.microsoft.com/en-us/library/bb530410.aspx

Windows Vista has a feature called "installer detection". When an EXE file name contains one of the words "install", "setup" or "update", the operating system automatically prompts the user for UAC privilege elevation when the program is started. This automatic privilege elevation can be overridden using a manifest file for the EXE and setting the requestedExecutionLevel in the manifest.

In Windows XP, when the following conditions are met, the operating system prompts the user to run the program with the administrator account:

  • The user is not part of the administrators group.
  • The name of the EXE file is "setup.exe" or "install.exe".
  • The EXE is started via Windows Explorer, e.g. by double-clicking on the icon of the EXE file.





[IZPACK-350] If emitError is called during a panel validator / panel action it should not be possible to call the next panel Created: 23/Mar/09  Updated: 25/Mar/09  Resolved: 25/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Wish Priority: Major
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If a user calls the emitError method on a handler the installer brings up a message but it is possible to continue the installation even if an error has accoured.

Would'nt be better to disable the next button in this case?
This would mean that a user only can go back or quit.



 Comments   
Comment by Florian Buehlmann [ 23/Mar/09 ]

Possible solution:
Add a emitErrorAndBlockNext method on the AbstractUIHandler interface.

Normally this method calls the regular emitError method. If we are on a GUI then we block additionally the next button. On an Automatic installation we additionally call shutdown method of the Housekeeper with exit reason 10.

Comment by Florian Buehlmann [ 25/Mar/09 ]

Implemented method emitErrorAndBlockNext to give the user the ability to block the next button after emitting an error to the handler.





[IZPACK-349] Windows privilege elevation does not work if installation JAR is on a mapped network drive Created: 23/Mar/09  Updated: 20/Apr/09  Resolved: 23/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Major
Reporter: Christian d'Heureuse Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Vista


Attachments: Text File IZPACK-349.patch     File TestConvertToUnc.js    
Number of attachments : 2

 Description   

When the installer JAR file is on a network drive with a mapped drive letter, UAC privilege elevation does not work in Windows Vista, because the drive letter of the network drive is no longer available in administrator mode. To solve this problem, we have to convert the path of the installer JAR file into UNC format, but there seems to be no Java API which can do that. Maybe it could be done within elevate.js?

Link with background info:
http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx



 Comments   
Comment by Christian d'Heureuse [ 23/Mar/09 ]

JavaScript function for converting a file path to UNC.

Comment by Julien Ponge [ 23/Mar/09 ]

So the trick would be to call getUniversalPath on the JAR path in elevate.js?

Comment by Christian d'Heureuse [ 23/Mar/09 ]

Yes, I have uploaded a patch to do that.

Another solution would be to call the Win32 API routine WNetGetUniversalName via JNI in Java.

Comment by Julien Ponge [ 23/Mar/09 ]

Fixed: I have applied your patch and made some reformating. Thanks!





Unpacker should display a warning message when a "loose" file is not found (IZPACK-339)

[IZPACK-348] Error in API comment of AbstractUIHandler.emitWarning() Created: 23/Mar/09  Updated: 20/Apr/09  Resolved: 08/Apr/09

Status: Closed
Project: IzPack
Component/s: Documentation
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Sub-task Priority: Trivial
Reporter: Christian d'Heureuse 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   

As noted with IZPACK-339, the API comment of AbstractUIHandler.emitWarning() is wrong.

emitWarning() returns:
false: when "Cancel" is clicked
true: when "OK" is clicked

The comment is currently:
@return true if the user decided not to continue

It should be:
@return false if the user decided not to continue
or:
@return true if the user decided to continue






[IZPACK-347] Privilege elevation does not work if installation is startet from UNC path Created: 23/Mar/09  Updated: 20/Apr/09  Resolved: 23/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Major
Reporter: Christian d'Heureuse Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Attachments: Text File PrivilegedRunnerUnc.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Privilege elevation on Windows XP or Vista does not work when an UNC path (\\server\share\...) is used for the installer JAR.

The attached patch fixes the problem, but it would be nicer to use a common subroutine within PrivilegedRunner.getInstallerJar() and UnpackerBase.getAbsolutInstallSource() to find the path of the JAR file.

see also IZPACK-308






[IZPACK-346] Japanese messages Created: 22/Mar/09  Updated: 20/Apr/09  Resolved: 23/Mar/09

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

Type: Improvement Priority: Minor
Reporter: Takahashi Eikou Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GZip Archive jpn.xml.patch.gz    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

I attached a patch for japanese messages.



 Comments   
Comment by Julien Ponge [ 23/Mar/09 ]

Thanks!





[IZPACK-345] PanelActions not working in AutomatedInstaller Created: 19/Mar/09  Updated: 20/Apr/09  Resolved: 19/Mar/09

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

Type: Bug Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

PanelActions are not working in AutomatedInstaller, because a list of actions is not filled correctly.



 Comments   
Comment by Dennis Reil [ 19/Mar/09 ]

added the initialized PanelActions to the list which is used later on.





[IZPACK-344] Make conditions usable in RegistryInstallerListener Created: 19/Mar/09  Updated: 20/Apr/09  Resolved: 24/Mar/09

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

Type: Improvement Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Conditions shall be usable in the RegistryInstallerListener to be able to conditionally execute entries in a pack.






[IZPACK-343] Debugger is causing NPE Created: 18/Mar/09  Updated: 20/Apr/09  Resolved: 18/Mar/09

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

Type: Bug Priority: Minor
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The debugger is causing a NullPointerException if the status of the DEBUG-class is changed through a custom action, as it is only initialized if TRACE is true at installer start time.



 Comments   
Comment by Dennis Reil [ 18/Mar/09 ]

initialization is now done regardless of the trace status.





[IZPACK-342] MultiVolumeUnpacker shall be usable in AutoInstaller Created: 17/Mar/09  Updated: 20/Apr/09  Resolved: 24/Mar/09

Status: Closed
Project: IzPack
Component/s: None
Affects Version/s: 3.11.0, 4.0.0, 4.0.1, 4.1.0, 4.1.1, 4.2.0, 4.2.1
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The MultiVolumeUnpacker is currently not really working in AutoInstaller as it will show a dialog for choosing the media files if a switch to the next media file is needed. This shall be corrected with this work item.






[IZPACK-341] Let trace statements optionally be logged Created: 16/Mar/09  Updated: 20/Apr/09  Resolved: 16/Mar/09

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

Type: Improvement Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed 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 optionally let tace statements be logged into the logfile.



 Comments   
Comment by Dennis Reil [ 16/Mar/09 ]

a new option was added to the Debug-class which can be activated through a custom action or some other custom code.





[IZPACK-340] A new language from Taiwan Created: 13/Mar/09  Updated: 20/Apr/09  Resolved: 15/Mar/09

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

Type: Improvement Priority: Minor
Reporter: Edward Chiang Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jdk 5.0


Attachments: GIF File twn.gif     XML File twn.xml    
Number of attachments : 2

 Description   

Hi, I come from Taiwan, and our language is Chinese traditional.
But Izpack doesn't support.

Here is my file in Tradional Chinese and the flag.

Hope you can add for us.



 Comments   
Comment by Julien Ponge [ 15/Mar/09 ]

Thanks!





[IZPACK-339] Unpacker should display a warning message when a "loose" file is not found Created: 12/Mar/09  Updated: 20/Apr/09  Resolved: 16/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Improvement Priority: Minor
Reporter: Christian d'Heureuse Assignee: Florian Buehlmann
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

Attachments: Text File IZPACK-339.patch     Text File UnpackerFileNotFoundWarning.patch    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
IZPACK-348 Error in API comment of AbstractUIHan... Sub-task Closed Julien Ponge  
Patch Submitted:
Yes
Number of attachments : 2

 Description   

When the source file of a "loose" pack is not found, a message is displayed at the console, but nothing is displayed at the GUI. A GUI user cannot see that something went wrong.

The attached patch displays a warning message in this case and asks the user to continue.

Note that the JavaDoc comment of AbstractUIHandler.emitWarning() is wrong: The routine returns:
false: when "Cancel" is clicked
true: when "OK" is clicked



 Comments   
Comment by Julien Ponge [ 15/Mar/09 ]

I have had a look and the patch does not apply on Unpacker.

Did you get it to apply Florian?

Comment by Christian d'Heureuse [ 15/Mar/09 ]

That the patch did no apply is probably because Florian already applied the patch for IZPACK-338, which deleted the line just below this patch.
I have uploaded a new patch for the current trunk version.

Comment by Florian Buehlmann [ 16/Mar/09 ]

I was able to applay the patch, that's ok.
I will fix that this week.





[IZPACK-338] NullPointerException occurs in Unpacker.run() when the first file is a "loose" file and not found Created: 12/Mar/09  Updated: 20/Apr/09  Resolved: 13/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Minor
Reporter: Christian d'Heureuse Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File UnpackerNullPointerException.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

When the first file to be installed is part of a "loose" pack and the source file does not exist, a NullPointerException occurs in Unpacker.run() at the statement out.close(), because "out" is null. There is no need to close "out" here.

The attached patch solves the problem.



 Comments   
Comment by Florian Buehlmann [ 13/Mar/09 ]

I checked the patch und you are right. The close() is not needed at this point.





[IZPACK-337] UserPathPanel layout issue Created: 12/Mar/09  Updated: 16/Nov/12  Resolved: 09/Apr/09

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

Type: Bug Priority: Major
Reporter: Julien Ponge Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File mail.png    
Number of attachments : 1

 Description   

There is a lyaout problem in this panel see:



 Comments   
Comment by Julien Ponge [ 09/Apr/09 ]

I have added a fix.

Comment by Thomas Demande [ 26/May/09 ]

I'm not sure the fix you did fixed the issue.

The 4.2.1 behavior for this panel was creating a JTextField whose size just fit the length of the UserPathPanelVariable (just as shown on this screenshot).

The new behavior seems to create a fixed-size JTextField, will a quite small size.

Looking into the source code, I saw that the code was a sort of mirror of the TargetPanel, especially for this JTextField (stretch value for instance defined in UserPathSelectionPanel), but the result is not the same!

Any idea or workaround possible?

Comment by Julien Ponge [ 28/May/09 ]

I realized that the code was basically the same, which makes it tricky to fix. Does 4.3.0 reproduce the same wrong layout?

Comment by Thomas Demande [ 28/May/09 ]

The only difference between using 4.2.1 and 4.3.0 is that the size of the JTextField is fixed in 4.3.0, which is a logical consequence of the change you made.

In 4.2.1, it is as long as the length of the UserPathPanelVariable.

Tested with a dead simple installer configuration:

<?xml version="1.0" encoding="UTF-8" ?>
<installation version="1.0">
    <info>
        <appname>user-path-panel-test</appname>
        <appversion>1</appversion>
        <javaversion>1.5</javaversion>
        <uninstaller write="no" />
    </info>

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

    <guiprefs width="800" height="600" resizable="yes">
    </guiprefs>

  <packs>
    <pack name="My Application" required="yes">
      <description>My Super Application</description>
      <file src="./resources/brol.xml" override="true" targetdir="$INSTALL_PATH"/>
    </pack>
    </packs>

    <panels>
    <panel classname="HelloPanel" />
    <panel classname="TargetPanel" />
    <panel classname="UserPathPanel" />
    <panel classname="SummaryPanel" />
    <panel classname="InstallPanel" />
    <panel classname="SimpleFinishPanel" />
  </panels>

</installation>

Screenshots

  • No value for{{UserPathPanelVariable}}
    Used 4.2.1
    Used 4.3.0
  • Value for{{UserPathPanelVariable}} set to C:\Program Files\My Application
    Added:
    <variables>
      <variable name="UserPathPanelVariable" value="C:\Program Files\My Application" />
    </variables>
    

    Used 4.2.1
    Used 4.3.0

Comment by Julien Ponge [ 28/May/09 ]

The screenshots are helpful, thanks a lot.

BTW does the text field enlarges when you pad the variable value with lots of trailing spaces?

Comment by Thomas Demande [ 28/May/09 ]

In 4.2.1 yes, not in 4.3.0

Comment by Laurian Vostinar [ 19/Jun/09 ]

A patch for this issue (UserPathPanel to display the same as TargetPanel):

LayoutPatch.txt
### Eclipse Workspace Patch 1.0
#P IzPack
Index: src/lib/com/izforge/izpack/gui/IzPanelLayout.java
===================================================================
--- src/lib/com/izforge/izpack/gui/IzPanelLayout.java (revision 2811)
+++ src/lib/com/izforge/izpack/gui/IzPanelLayout.java (working copy)
@@ -22,6 +22,7 @@
 package com.izforge.izpack.gui;

 import com.izforge.izpack.panels.PathSelectionPanel;
+import com.izforge.izpack.panels.UserPathSelectionPanel;
 import com.izforge.izpack.util.Log;
 import com.izforge.izpack.util.MultiLineLabel;

@@ -224,7 +225,8 @@
             }
             if (PathSelectionPanel.class.isAssignableFrom(clazz)
                     || JCheckBox.class.isAssignableFrom(clazz)
-                    || JRadioButton.class.isAssignableFrom(clazz))
+                    || JRadioButton.class.isAssignableFrom(clazz)
+                    || UserPathSelectionPanel.class.isAssignableFrom(clazz))
             {
                 return (FULL_LINE_CONTROL_CONSTRAINT);
             }
@@ -1151,7 +1153,7 @@
     private boolean needsReEvaluation(Component comp)
     {
         if ((comp instanceof com.izforge.izpack.util.MultiLineLabel)
-                || (comp instanceof com.izforge.izpack.panels.PathSelectionPanel))
+                || (comp instanceof com.izforge.izpack.panels.PathSelectionPanel) || (comp instanceof com.izforge.izpack.panels.UserPathSelectionPanel))
         {
             return (true);
         }
Comment by Thomas Demande [ 19/Jun/09 ]

This patch indeed fixes the issue!

(If possible, please apply it to 4.0+ branches...).

Comment by Laurian Vostinar [ 19/Jun/09 ]

Unfortunately I made a mistake, this patch introduces a dependency of IzPanelLayout to UserPathSelectionPanel; this breaks the installer if no UserPathSelectionPanel is present. Maybe will look for another fix if I have time later.

Comment by Julien Ponge [ 23/Jun/09 ]

Thanks for letting us know, and I'm looking forward to another patch.

Comment by Laurian Vostinar [ 21/Jul/09 ]

I maybe another patch:

LayoutPatch.txt
### Eclipse Workspace Patch 1.0
#P IzPack
Index: src/lib/com/izforge/izpack/gui/IzPanelLayout.java
===================================================================
--- src/lib/com/izforge/izpack/gui/IzPanelLayout.java (revision 2811)
+++ src/lib/com/izforge/izpack/gui/IzPanelLayout.java (working copy)
@@ -38,6 +38,7 @@
 public class IzPanelLayout implements LayoutManager, LayoutManager2, LayoutConstants
 {

+    private static final String USER_PATH_SELECTION_PANEL_CLASS = "com.izforge.izpack.panels.UserPathSelectionPanel";
     /**
      * holds all the components and layout constraints.
      */
@@ -224,7 +225,8 @@
             }
             if (PathSelectionPanel.class.isAssignableFrom(clazz)
                     || JCheckBox.class.isAssignableFrom(clazz)
-                    || JRadioButton.class.isAssignableFrom(clazz))
+                    || JRadioButton.class.isAssignableFrom(clazz)
+                    || USER_PATH_SELECTION_PANEL_CLASS.equals(clazz.getName()))
             {
                 return (FULL_LINE_CONTROL_CONSTRAINT);
             }
@@ -1151,7 +1153,8 @@
     private boolean needsReEvaluation(Component comp)
     {
         if ((comp instanceof com.izforge.izpack.util.MultiLineLabel)
-                || (comp instanceof com.izforge.izpack.panels.PathSelectionPanel))
+                || (comp instanceof com.izforge.izpack.panels.PathSelectionPanel)
+                || USER_PATH_SELECTION_PANEL_CLASS.equals(comp.getClass().getName()))
         {
             return (true);
         }
Comment by Paul Rosen [ 20/Sep/10 ]

Hi,

This one appears to have a good patch suggested by Laurian on 21 July 09 (it works fine for me), but it has not yet been applied to the latest version of Izpack (I have recently downloaded and am using version 4.3.3). Would it be possible for this patch to be applied to the next released version of Izpack?

Thanks
Paul

Comment by Julien Ponge [ 30/Sep/10 ]

Could you please check against v5?

Comment by Andrei Costache [ 16/Nov/12 ]

Please note that indeed the fix is in version controlled code, but in the libraries generated by a fresh install (using http://dist.codehaus.org/izpack/releases/4.3.5/IzPack-install-4.3.5.jar) the install.jar does not contain this fix.

Regards,
Andrei





[IZPACK-336] Librarian#cleanUp method shouldn't support java 1.4 Created: 11/Mar/09  Updated: 11/Mar/09  Resolved: 11/Mar/09

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

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

Number of attachments : 0

 Description   

Since IzPack only support java 5+, a method to handle java 1.4 is useless.






[IZPACK-335] Implement "src" attribute for <native> element Created: 11/Mar/09  Updated: 23/Mar/09  Resolved: 23/Mar/09

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

Type: Improvement Priority: Major
Reporter: Christian d'Heureuse Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File IZPACK-335-DTD.patch     Text File srcAttributeForNativeElement.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

The attached patch implements an "src=" attribute for the <native> element.

This is important, to allow the use of native library files which are stored in other locations than $IZPACK_HOME/bin/native/, outside of the IzPack directory tree.



 Comments   
Comment by Florian Buehlmann [ 16/Mar/09 ]

Sounds like a good enhancement.
I would applay this patch as it is.

Christian is it possible that you can attach a patch for the documentation also?

Comment by Florian Buehlmann [ 23/Mar/09 ]

Patch applayed and updated documentation.

Comment by Christian d'Heureuse [ 23/Mar/09 ]

Florian, thanks for applying the patch and sorry for not providing the documentation patch in time.

The DTD should also be updated. I have uploaded a patch for that.





[IZPACK-334] RulesEngine compound conditions logic. Created: 11/Mar/09  Updated: 08/Oct/09  Resolved: 08/Oct/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.2

Type: Bug Priority: Minor
Reporter: Manny Lim Assignee: Dennis Reil
Resolution: Not A Bug 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
Environment:

Windows XP


Sub-Tasks:
Key
Summary
Type
Status
Assignee
IZPACK-466 Document restrictions resp. workaroun... Sub-task Open  
Number of attachments : 0

 Description   

Hi,

I've had some trouble using compound conditions using the expression language such as "!a+!b", which I assumed should be valid since the documentation states "from IzPack 3.11 on normally, you don't have to define the compound conditions because you can use a simple expression language." In my case, the expression !a+!b evaluated to true in every case except where a=true and b=false. This should reproduce the problem:

<variables>
<variable name="a" value="true" />
<variable name="b" value="true" />
</variables>

<conditions>
<condition type="variable" id="a" >
<name>a</name>
<value>true</value>
</condition>
<condition type="variable" id="b" >
<name>b</name>
<value>true</value>
</condition>
</conditions>

<panels>
<!-- !a+!b => !F+!F should evaluate to F, but instead evaluates to T -->
<panel classname="ThisPanelShouldOnlyShowIfAandBareBothFalse" condition="!a+!b" />
</panels>

Since the panel kept showing up for every case except when a=true and b=false, I took at look at the RulesEngine class. I believe the implementation of getConditionByExpr() is incorrect for use with compound expressions and violates the logical operators order of precedence. In this situation, I believe it does the following for !a+!b:

NotCondition(AndCondition(a, NotCondition(b))) which is essentially !(a+(!b)), and is semantically different from what I meant by !a+!b or (!a)+(!b).

!(T+(!T)) => !(T+F) => !F => T
!(T+(!F)) => !(T+T) => !T => F
!(F+(!T)) => !(F+F) => !F => T
!(F+(!F)) => !(F+T) => !F => T

(!T)+(!T) => F+F => F
(!T)+(!F) => F+T => F
(!F)+(!T) => T+F => F
(!F)+(!F) => T+T => T

I believe many others may be experiencing the same trouble with conditionals that I did because of this.

Thanks,
Manny



 Comments   
Comment by Julien Ponge [ 12/Mar/09 ]

I am assigning the issue to Dennis.

Comment by Dennis Reil [ 12/Mar/09 ]

This is not a bug, but a documentation bug, because the !-operator is currently only allowed at the first position. So if you would start the installer in Debug-mode you would get an error message.
In case of such a syntax error, the parsing is stopped and a null condition is returned.

As it should be stated in the documentation, such complex conditions should be defined with the xml syntax and not with the expressional conditions. These are only intended as convenience for simple conditions.

Comment by Manny Lim [ 13/Mar/09 ]

Thank you Dennis, in addition, I think the documentation should mention that the order of precedence is the reverse order in which the operators appear. By rewriting my expressions with this in mind, I have been able to achieve the behavior I desired. For example, !a+!b can be rewritten as !a|b which is evaluated as !(a|b), the equivalent of (!a)+(!b).

I have only been able to produce the error message you mentioned by placing the Unable to render embedded object: File (-operator to the right of the operand (e.g. "a) not found."). From what I see, as long as the syntax is valid, !-operators can be used anywhere in the expression, for example "!a|!b", which is evaluated as follows:
"!a|!b"
NotCondition( "a|!b" )
NotCondition( OrCondition( a, "!b" ) )
NotCondition( OrCondition( a, NotCondition( b ) ) )
or !(a|(!b))

Since getConditionByExpr() is called recursively, index is reset to the first position each time. Thus, as long as !-operator is to the left of its operand, it will never display the error message.

Thanks,
Manny

Comment by Julien Ponge [ 13/Apr/09 ]

As we are 1 week away from the release of 4.3.0, do you think that you can resolve the issue on time?

It is absolutly not a problem if you can't, just let me know as we can move the issue to 4.3.1.

Thanks a lot!

Comment by Dennis Reil [ 08/Oct/09 ]

This is as designed, but the documentation should be extended to describe this special behaviour better.





Improve user documentation (IZPACK-327)

[IZPACK-333] Document that custom native libraries have to be loaded using com.izforge.izpack.util.Librarian Created: 10/Mar/09  Updated: 20/Apr/09  Resolved: 02/Apr/09

Status: Closed
Project: IzPack
Component/s: Documentation
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Sub-task Priority: Minor
Reporter: Christian d'Heureuse 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   

The documentation at https://izpack.github.io/documentation/installation-files.html#the-native-element-native should contain a note that com.izforge.izpack.util.Librarian.loadLibrary() must be used to load custom native libraries.






[IZPACK-332] Pack ID instead of name is displayed in PacksPanel summary Created: 09/Mar/09  Updated: 20/Apr/09  Resolved: 15/Apr/09

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Major
Reporter: Christian d'Heureuse Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File PacksPanelBase.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

When a pack has an ID and there is no translation in the langpack, the correct name is displayed within the table in the PacksPanel.
But within the summary displayed in the SummaryPanel, the pack ID instead of the pack name is displayed.

The attached patch for PacksPanelBase.java corrects the error.



 Comments   
Comment by Vikash Kumar [ 14/Apr/09 ]

Should this be working on RC1 or RC2 ? I tested on both and it doesn't seem to be fixed.
Thanks in advance
Vikash

Comment by Christian d'Heureuse [ 14/Apr/09 ]

Yes, it should be fixed in RC1 and RC2.

Comment by Vikash Kumar [ 15/Apr/09 ]

I tested for TreePacksPanel and seems like it is not fixed for TreePacksPanel. It would be highly appreciated if it can be fixed for TreePacksPanel too in this release if it is not too much effort!

Thanks and Regards
Vikash

Comment by Julien Ponge [ 15/Apr/09 ]

Investigating a fix for TreePacksPanel.

Comment by Julien Ponge [ 15/Apr/09 ]

Fixed!





Improve user documentation (IZPACK-327)

[IZPACK-331] Document how to debug an uninstaller Created: 09/Mar/09  Updated: 16/Jun/09  Resolved: 05/May/09

Status: Closed
Project: IzPack
Component/s: Documentation
Affects Version/s: 4.2.1
Fix Version/s: 4.3.1

Type: Sub-task Priority: Minor
Reporter: Christian d'Heureuse Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File IZPACK-331.patch     Java Source File IzPackUninstallerStarter.java    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

The FAQ documents how to get console and debug output from an installer (http://docs.codehaus.org/display/IZPACK/FAQ+-+Frequently+asked+questions#FAQ-Frequentlyaskedquestions-DebugOutput ). But it's not so easy to get console output from an uninstaller, at least under Windows.

When the uninstaller is called using

java -jar -DTRACE=TRUE uninstaller.jar

console output is not visible.

The uninstaller uses the SelfModifier class to start a new java VM and the console output of the second VM is not visible.

One possible solution is to write a class that starts the uninstaller code by bypassing SelfModifier:

import com.izforge.izpack.uninstaller.Uninstaller;

public class IzPackUninstallerStarter {

public static void main (String args[])

{ Uninstaller.uninstall (args); }

}



 Comments   
Comment by Julien Ponge [ 02/Apr/09 ]

Would you have a piece of documentation for this?

Comment by Christian d'Heureuse [ 03/Apr/09 ]

Added a sample class that can be used to start an uninstaller so that console output is visible. (Console output is otherwise not visible on Windows). It bypasses the SelfModifier class.

When the class is included in the uninstaller JAR, the following command can be used:

java -cp uninstaller.jar IzPackUninstallerStarter

Comment by Julien Ponge [ 08/Apr/09 ]

I have updated the FAQ with a link to this issue as it fits better here.

Comment by Christian d'Heureuse [ 08/Apr/09 ]

Added a patch to implement a "-d" (direct) option switch for Uninstaller.java.

This would make it easier to get console output from the uninstaller.

With this patch, the uninstaller can be called as:

java -jar uninstaller.jar -d

Comment by Julien Ponge [ 05/May/09 ]

Marked as iixed as Christian has updated the issue.





Improve user documentation (IZPACK-327)

[IZPACK-330] Document compile-time variable subtitution in the installation XML file Created: 09/Mar/09  Updated: 20/Apr/09  Resolved: 02/Apr/09

Status: Closed
Project: IzPack
Component/s: Documentation
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Sub-task Priority: Major
Reporter: Christian d'Heureuse 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   

In the installation XML file, $-Variables (e.g. $INSTALL_PATH) are substituted at installation time.

To use variables that are substituted at compile time, the installation XML file has to be included within an Ant XML file (build.xml). (see https://izpack.github.io/documentation/advanced-features.html#embedding-the-installation-file-using-a-config-element )

But there is an undocumented feature that allows us to use Java system properties as compile time variables in some of the attribute values of the installation XML file.

Examples:

<listener ... jar="@

{user.dir}/lib/myListener.jar"/>

(Here the compile time variable @{user.dir}

is used in <listener> to specify a JAR file that lies outside of the IzPack directory tree, without having to hard-code an absolute path.)

<res id="shortcutSpec.xml" src="@

{user.dir}/build/izPack/myShortcutSpec.xml"/>

(Here @{user.dir}

is used to specify a path for the resource file which lies outside of the base directory ("baseDir" parameter of the IzPack task).)



 Comments   
Comment by Christian d'Heureuse [ 11/Mar/09 ]

Supplement to description of this Jira issue:

The routines substituteProperties() and substituteAllProperties() in ComplerConfig.java substitute properties (in @

{propertyName}

syntax) everywhere in the installation XML file except under <listener> and <packager>. There is no need to explicitly call compiler.replaceProperties() within the other XML elements.

The following built-in properties are set:
basedir
izpack.file
(UNPACKER_CLASS)

There seems to be an undocumented <properties> element, which can be used to define additional properties, that can be used as compile-time variables .





Improve user documentation (IZPACK-327)

[IZPACK-329] Document how to build listeners and custom panels outside of IzPack directory tree Created: 09/Mar/09  Updated: 20/Apr/09  Resolved: 08/Apr/09

Status: Closed
Project: IzPack
Component/s: Documentation
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Sub-task Priority: Major
Reporter: Christian d'Heureuse Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

 Description   

The documentation explains how to build listeners (for custom actions), custom panels, etc. by modifying and adding files within the IzPack installation directory tree. This is no good practice. User-specific extensions should be kept outside the IzPack directory tree and it should be documented how to do that. There should be samples / skeleton files to start developing custom listeners and panels. It should be possible to move the sample files into a separate project and separate directory tree on the disk and compile and test them there. The path of the IzPack home directory could be defined e.g. in an Ant property in the build.xml file for compiling the sample.



 Comments   
Comment by Christian d'Heureuse [ 23/Mar/09 ]

Depends on: IZPACK-312

Comment by Julien Ponge [ 02/Apr/09 ]

Would you have some documentation piece to suggest?

Comment by Christian d'Heureuse [ 03/Apr/09 ]

Added a sample Ant build.xml file.

This Ant build file is intended to be stored in \trunk\sample\src, but it can also be used outside the IzPack directory tree when IZPACK_HOME environment variable is set.

Comment by Christian d'Heureuse [ 03/Apr/09 ]

The "sample" directory needs some cleanup.
I suggest to:

  • Move the following files/directories into a subdirectory, e.g. "sample/sampleInstallation1":
    Files: install.xml, License.txt, Readme.txt, script.bat
    Directory: doc
  • Move sample/src/myCompany to sample/src/com/myCompany
  • Correct ChmodInstallerListener.java:
    Add an "import" statement for com.izforge.izpack.util.OsVersion, because compilation fails otherwise.




Improve user documentation (IZPACK-327)

[IZPACK-328] Correct and clarify documentation of OS attribute and OS element Created: 09/Mar/09  Updated: 20/Apr/09  Resolved: 02/Apr/09

Status: Closed
Project: IzPack
Component/s: Documentation
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Sub-task Priority: Major
Reporter: Christian d'Heureuse 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   

For some of the XML elements in the configuration file, it is possible to use an "os=" attribute or to use a nested <os> element. The documentation is not clear about the difference and there are no good examples.

Some of the examples are wrong:

https://izpack.github.io/documentation/installation-files.html#os-make-a-file-os-dependent
-> no <os> is used in the example

https://izpack.github.io/documentation/installation-files.html#os-make-a-library-os-dependent
-> no <os> in the sample for the <native> tag. No indication that the "os" attribute could also be used...

There is not a single example for the "os=" attribute in the page https://izpack.github.io/documentation/installation-files.html






[IZPACK-327] Improve user documentation Created: 09/Mar/09  Updated: 20/Apr/09  Resolved: 08/Apr/09

Status: Closed
Project: IzPack
Component/s: Documentation
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Christian d'Heureuse Assignee: Julien Ponge
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-328 Correct and clarify documentation of ... Sub-task Closed Julien Ponge  
IZPACK-329 Document how to build listeners and c... Sub-task Closed Julien Ponge  
IZPACK-330 Document compile-time variable subtit... Sub-task Closed Julien Ponge  
IZPACK-331 Document how to debug an uninstaller Sub-task Closed Julien Ponge  
IZPACK-333 Document that custom native libraries... Sub-task Closed Julien Ponge  
IZPACK-351 Document automatic Windows privilege ... Sub-task Closed Julien Ponge  
Number of attachments : 0

 Description   

The user documentation of the IzPack project is in a bad shape. For many of the more complex features, one has to look at the source code to really understand how it works. Some important features are not documented. In contrast to the documentation, the source code is well organized, modular and easy to read.

Maybe it would help if the documentation was moved to a Wiki. Then it would be easier for users to contribute, correct and discuss the documentation. (I would prefer MediaWiki over Confluence).






[IZPACK-326] Wrong Data is read from autoinstall.xml if first panel of same class is disabled by condition Created: 09/Mar/09  Updated: 20/Apr/09  Resolved: 09/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Critical
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I have multiple UserInputPanels. If the first UserInputPanel is disabled by condition then the next UserInputPanel gets the wrong XML-root to parse for input variables.






[IZPACK-325] Implement "jar" attribute for "panel" element Created: 09/Mar/09  Updated: 23/Mar/09  Resolved: 23/Mar/09

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

Type: New Feature Priority: Major
Reporter: Christian d'Heureuse Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File IZPACK-325-DTD.patch     Text File jarAttributeForPanelElement2.patch     Text File jarAttributeForPanelElement3.patch     Text File jarAttributeForPanelElement.patch    
Patch Submitted:
Yes
Number of attachments : 4

 Description   

I don't want to modify the IzPack installation to include JAR files for the custom panels of my projects. This would be bad practice and lead to version conflicts among the different project installations.

So I added a "jar=" attribute to the "panel" element (see attached patch), as it is already there for the listeners.

Usage example:
<panel classname="MyCustomPanel" jar="@

{user.dir}

/lib/containsMyCustomPanel.jar"/>



 Comments   
Comment by Dan Tran [ 09/Mar/09 ]

take a look at http://www.nabble.com/No-more-small-custom-panel-jar-files---IZPACK-226-feedback-requested-td21577984.html#a21577984

to see if you enhancement is still necessary

Comment by Christian d'Heureuse [ 09/Mar/09 ]

Dan, thanks for your comment.

I understand that it can be done with the <jar> element now, but:

  • When the <jar> element is used, a warning message ("Panel jar file not found") is still displayed by the compiler, because the default JAR ("bin/panels/"className".jar") cannot be found. Maybe we could extend my patch to add the possibility to specify jar="-" to suppress the warning?
  • The <listener> element also has a "jar=" attribute. So it would be logical and consistent to also have a "jar" attribute for the "panel" element.
  • The patch is very small and doesn't interfere with anything that has already been built-in or will be improved in the future.
Comment by Christian d'Heureuse [ 09/Mar/09 ]

Extended patch to allow jar="-" (or jar="") to suppress the warning message ("Panel jar file not found") when the <jar> element is used to include the JAR file (see IZPACK-226).

Comment by Christian d'Heureuse [ 11/Mar/09 ]

Added an improved version of the patch.

(Calling compiler.replaceProperties() is not necessary within the <panel> element)

Comment by Florian Buehlmann [ 13/Mar/09 ]

I just had a look at the patch. Looks like a nice feature. I would suggest to not suppress the warning with a jar attribute like jar="-". For me it's confusing to suppress warnings with faked attribute values.

Comment by Florian Buehlmann [ 13/Mar/09 ]

Would it be possible to attach a patch for the documentation also?

Comment by Christian d'Heureuse [ 13/Mar/09 ]

Florian, would you support the syntax jar="" instead of jar="-"?

It's purpose is not only to suppress the warning, although it has that effect, but to specify that for this panel there is no JAR file that has to be automatically included in the installer.

Comment by Dan Tran [ 13/Mar/09 ]

I am +1 for the new attribute, but i think we should not suppress the warning since it is hard to trouble shoot

Comment by Christian d'Heureuse [ 13/Mar/09 ]

Dan, the warning would only be suppressed when the user explicitly writes jar="" in the XML file. If the new jar= attribute is not used, everything would be as before and the warning message occurs if the JAR file does not exist. Also if the jar= attribute is used for a JAR file that does not exist, the warning would be displayed.

The following cases are possible:

1. The new jar= attribute is not used within the <panel> element:
The file name of the JAR file is automatically built as "bin/panels/className.jar" and waring message occurs if that file does not exist.

2. jar="myPanel.jar" is specified:
A warning occurs If myPanel.jar does not exist.

3. jar="":
The compiler does not try to automatically include any JAR file into the installer and no warning message occurs.

Comment by Florian Buehlmann [ 16/Mar/09 ]

For me it sounds ok to suppress the warning if the user specifies an empty jar tag (jar="") because the user want to add no jar file so we should not warn.
This would not change today's default.

Christian is it possible to send me a patch for the documentation?
I'll applay the change this week.

Comment by Florian Buehlmann [ 23/Mar/09 ]

Patch applayed and documentation updated.

Comment by Christian d'Heureuse [ 23/Mar/09 ]

Florian, thanks for applying the patch and updating the documentation. The DTD should also be updated.

Comment by Christian d'Heureuse [ 23/Mar/09 ]

Added patch for DTD.





[IZPACK-324] UserInputPanel is recreated anytime the data gets changed Created: 07/Mar/09  Updated: 06/Nov/09  Resolved: 21/Jun/09

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.3.0
Fix Version/s: 4.3.2

Type: Bug Priority: Critical
Reporter: Kjell Braden Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I have a panel with the following definition:

    <field type="check" variable="update.host.as">
        <spec txt="Application Server" id="update.host.as" set="true" true="true" false="false" />
    </field>
    <field type="check" variable="update.host.db">
        <spec txt="Database" id="update.host.db" set="false" true="true" false="false" />
    </field>

I currently cannot uncheck the update.host.as CheckBox, because it gets recreated afterwards with the original "true" state. In trace mode I see the following lines in the terminal:

Condition already registered.
Condition already registered.
check: value: true, set: true
Condition already registered.
Condition already registered.
check: value: true, set: false

These come from the addCheckBox method in UserInputPanel.java. I don't understand why the buttons have to be re-added everytime anything get's changed.



 Comments   
Comment by Dennis Reil [ 24/Mar/09 ]

Can you provide more information? I'm heavily using UserInputPanel and also the checkbox and I don't have a problem with that.

Comment by Dennis Reil [ 30/Mar/09 ]

That's a feature, not a bug

If saying set="true", the value will always be true as you specified.

You should do one of the following:

1. define a variable update.host.as with value true and say:

<field type="check" variable="update.host.as">
<spec txt="Application Server" id="update.host.as" set="$

{update.host.as}" true="true" false="false" />
</field>

or

2. (the more common way, which is not a good one in the checkbox case): use Izpack builtin conditions and define the field twice (one for the initial value and one for user input)

<field type="check" variable="update.host.as" condition="!izpack.input.update.host.as">
<spec txt="Application Server" id="update.host.as" set="true" true="true" false="false" />
</field>
<field type="check" variable="update.host.as" condition="izpack.input.update.host.as">
<spec txt="Application Server" id="update.host.as" set="${update.host.as}

" true="true" false="false" />
</field>

Comment by Dennis Reil [ 30/Mar/09 ]

This was not a bug, but wrong usage of the dynamic UserInput.

Comment by Kjell Braden [ 30/Mar/09 ]

Sorry for answering a bit late.

Please see the documentation on this feature in src/doc-reST/user-input.txt (line 570 onwards, svn rev 2707):

*set* ``- optional``

The ``set`` attribute accepts the values ``true`` and ``false``. Since the
attribute is optional it can also be omitted, which is interpreted as
``false``. If a value of ``true`` is used, the check box will be selected
when the UI is first presented.

I don't think that forcing the state with the set attribute is a feature then.

Comment by Kjell Braden [ 30/Mar/09 ]

I experience another issue which is most probably related to this one:
Having a directory field with set="$APPLICATIONS_DEFAULT_ROOT" and a checkbox in a UserInputPanel and clicking the checkbox results in the directory field changing to $APPLICATIONS_DEFAULT_ROOT, regardless of the user having set it to something different before.

Comment by Dennis Reil [ 30/Mar/09 ]

Yeah, as I said before, you will have to use conditions to check if there's user input or just show the default.

I think I have to add some documentation about that and at least remote the "when the UI is first presented" line.

Comment by Kjell Braden [ 30/Mar/09 ]

Alright. I'll workaround it as outlined above. You can close the issue if you like

Comment by Kjell Braden [ 10/Apr/09 ]

Sorry, I'll have to reopen the issue.

The way it used to work was this:

<field type="text" variable="db.host">
        <spec txt="Database server host:" size="60" set="localhost"/>
</field>
<field type="text" variable="db.port">
        <spec txt="Database server port:" size="60" set="1521"/>
</field>
<field type="text" variable="db.sid">
        <spec txt="Database instance name:" size="60" set="" />
</field>
<field type="password" variable="db.syspass">
        <spec>
                <pwd txt="Database syspass:" size="60" set="" />
        </spec>
</field>
<field type="combo" variable="db.arch">
        <spec txt="Architecture">
                <choice txt="x32" value="32" />
                <choice txt="x64" value="64" />
        </spec>
</field>
<field type="combo" variable="db.isXE">
        <spec txt="XE">
                <choice txt="No" value="false" />
                <choice txt="Yes" value="true" />
        </spec>
</field>

So, 3textfields, two of which had default values defined by their set attribute, one is empty by default, a password field, also empty, and two comboboxes.

The current behavior is the following: after the user filled in the textfields and the password field, he selects something from the comboboxes. However, the password field is empty afterwards.

I may be wrong or have not really understood the "new" UserInput system, but this looks very similar to the problem I outlined earlier. Could be a independent bug, though.

Comment by Julien Ponge [ 13/Apr/09 ]

As we are 1 week away from the release of 4.3.0, do you think that you can resolve the issue on time?

It is absolutly not a problem if you can't, just let me know as we can move the issue to 4.3.1.

Thanks a lot!

Comment by Kjell Braden [ 21/Jun/09 ]

I fixed the last issue I had in revision 2812.





[IZPACK-323] [PATCH] enhancement to XInfoPanel which allows setting the font Created: 06/Mar/09  Updated: 20/Apr/09  Resolved: 18/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.3.0
Fix Version/s: 4.3.0

Type: Bug Priority: Minor
Reporter: Dick Hollenbeck Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File XInfoPanel.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Allows setting the font in the text panel of XInfoPanel. This is especially helpful when needing a monospaced font to show a formatted readme file.



 Comments   
Comment by Julien Ponge [ 15/Mar/09 ]

The proposed change makes sense, is small, and is documented, so I agree with it.





[IZPACK-322] [PATCH] build.xml was not building Uninstaller properly Created: 06/Mar/09  Updated: 07/Mar/09  Resolved: 07/Mar/09

Status: Closed
Project: IzPack
Component/s: Build
Affects Version/s: 4.3.0
Fix Version/s: 4.3.0

Type: Bug Priority: Major
Reporter: Dick Hollenbeck Assignee: Kjell Braden
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux for sure, probably Windows also


Attachments: Text File build.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The uninstaller.jar was not containing the file com/izforge/izpack/adaptator/styleSheet.xsl

and this causes a null pointer exception at or near line 96 in adaptator/impl/XMLParser.java

Source xsltSource = new StreamSource(IXMLParser.class.getResource("styleSheet.xsl").openStream());



 Comments   
Comment by Kjell Braden [ 07/Mar/09 ]

Fixed in svn r2641





[IZPACK-321] The UserInputPanel should have clickable links Created: 06/Mar/09  Updated: 20/Apr/09  Resolved: 01/Apr/09

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Improvement Priority: Trivial
Reporter: Mathieu ANCELIN Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour
Environment:

All


Attachments: Zip Archive HyperlinkHandler.zip     Text File UserInputPanel.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

The UserInputPanel should have clickable links because select/copy/paste isn't very convenient, and for long URLs it's impossible to remember entirely.
So when a staticText is used with HTML code within, links should be opened in a web browser if they are clicked.



 Comments   
Comment by Mathieu ANCELIN [ 06/Mar/09 ]

This patch make links in staticText fields clickable and open it in a web browser.

Comment by Julien Ponge [ 15/Mar/09 ]

The proposed change makes sense.

However I am concerned by code duplication here, since the HyperLinkListener is a copy of the one found in HtmlInfoPanel. Hence the patch cannot be applied unless it is updated to propose a refactoring to avoid code duplicates.

Can you do that Mathieu?

Comment by Mathieu ANCELIN [ 31/Mar/09 ]

Hi Julien,

I am sorry for the delay. In responce to your previous comment, I've created a new util class that handle the opening of hyperlink in a browser. I also changed UserInputPanel and HTMLInfoPanel files to use this class. Is that what you wanted me to do ?

Comment by Julien Ponge [ 31/Mar/09 ]

Hi Mathieu,

Yes it sounds better like that. I will try it shortly.

Cheers

Comment by Julien Ponge [ 01/Apr/09 ]

Thanks a lot, it's in





[IZPACK-320] introduce console support for izPack installation Created: 06/Mar/09  Updated: 20/Apr/09  Resolved: 22/Mar/09

Status: Closed
Project: IzPack
Component/s: Build, Installer, Panels
Affects Version/s: None
Fix Version/s: 4.3.0

Type: New Feature Priority: Major
Reporter: Mounir el hajj Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive console_install.zip    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

This issue has been coded, and tested. The patch is generated starting from the trunk at revision 2638.
We need to have installation with command line support, to be able to run installation on remote servers with no X11 server.
We also need to automate the installs, without having to run the install in GUI mode, and then generating the automatic installation script. We also need to have the generated script in a property file style.

The main entry class com/izforge/izpack/installer/Installer.java, has been modified to take as arguments:
-console: to run install in interactive console mode
-options-template: to generate a property file whose name is specified in args[1]
-options: to run install while reading the properties from property file specified in args[1]

These 3 possibilities will instantiate a ConsoleInstaller who has 3 methods to achieve respectively the above
ConsoleInstaller works like AutomatedInstaller, by iterating over panels order, and instantiating a class whose name is the same as the panel name, appended with ConsoleHelper, implementing interface PanelConsole
The 3 methods in the interface are
public boolean runGeneratePropertiesFile(AutomatedInstallData installData, PrintWriter printWriter); will print all requested user inputs in printWriter to have the properties file
public boolean runConsoleFromPropertiesFile(AutomatedInstallData installData, Properties p); will read all requested user inputs from the properties p, which are read from the properties file
public boolean runConsole(AutomatedInstallData installData); will perform interactive console installation
I implemented this interface for the following (the most relevant until now):

  • FinishPanelConsoleHelper
  • HelloPanelConsoleHelper
  • InstallPanelConsoleHelper
  • TargetPanelConsoleHelper
  • UserInputPanelConsoleHelper


 Comments   
Comment by Julien Ponge [ 15/Mar/09 ]

Hi Mounir,

Sounds great, however I get failures when trying to apply the patch:

julien@infinity ~/C/izpack.git> patch --dry-run -p0 < ~/Downloads/console_install/patch.txt
(Stripping trailing CRs from patch.)
patching file src/build.xml
Hunk #2 FAILED at 199.
Hunk #3 FAILED at 888.
2 out of 3 hunks FAILED -- saving rejects to file src/build.xml.rej
(Stripping trailing CRs from patch.)
patching file src/lib/com/izforge/izpack/installer/ConsoleInstaller.java
(Stripping trailing CRs from patch.)
patching file src/lib/com/izforge/izpack/installer/Installer.java
(Stripping trailing CRs from patch.)
patching file src/lib/com/izforge/izpack/installer/PanelConsole.java
(Stripping trailing CRs from patch.)
patching file src/lib/com/izforge/izpack/installer/PanelConsoleHelper.java
(Stripping trailing CRs from patch.)
patching file src/lib/com/izforge/izpack/panels/FinishPanelConsoleHelper.java
(Stripping trailing CRs from patch.)
patching file src/lib/com/izforge/izpack/panels/HelloPanelConsoleHelper.java
(Stripping trailing CRs from patch.)
patching file src/lib/com/izforge/izpack/panels/InstallPanelConsoleHelper.java
(Stripping trailing CRs from patch.)
patching file src/lib/com/izforge/izpack/panels/TargetPanelConsoleHelper.java
(Stripping trailing CRs from patch.)
patching file src/lib/com/izforge/izpack/panels/UserInputPanelConsoleHelper.java
(Stripping trailing CRs from patch.)
patching file src/lib/com/izforge/izpack/rules/RulesEngine.java
julien@infinity ~/C/izpack.git>

Could you please check and update the patch?

Thanks a lot

Comment by Mounir el hajj [ 16/Mar/09 ]

Hi Julien

i have updated the patch. please make sure to have your working copy at revision 2638
and sorry for any incurred inconvenience

Thanks a lot
M

Comment by Julien Ponge [ 18/Mar/09 ]

Impressive!

In my limited tests on the IzPack own installer it worked fine.

Mounir, when a panel console class cannot be found, the panel is skipped right?

I would appreciate if other developers could have a look at this patch.

Comment by Mounir el hajj [ 19/Mar/09 ]

yes i confirm. it is similar to the automated installer, when a helper class for the panel is not found, the panel is skipped

Comment by Julien Ponge [ 22/Mar/09 ]

Merged. Thanks Mounir!

Comment by Mounir el hajj [ 23/Mar/09 ]

thank you Julien for your efforts and quick reactivity!

Comment by Julien Ponge [ 14/Apr/09 ]

Hi Mounir,

Could you please have a look at IZPACK-368?

Thanks a lot

Comment by Mounir el hajj [ 15/Apr/09 ]

Hi Julien

i will have a look

Thanks
M

Comment by Julien Ponge [ 15/Apr/09 ]

Thanks Mounir!





[IZPACK-319] [PATCH] UserInputPanel "dir" and "file" now support "mustExist" flag" Created: 05/Mar/09  Updated: 05/Apr/10  Resolved: 14/Mar/09

Status: Closed
Project: IzPack
Component/s: Panels
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Dick Hollenbeck Assignee: Dennis Reil
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File user_input.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

This patch adds and fixes:

1) adds: mustExist attribute to the spec of "dir" and "file" fields. It defaults to true so existing installations will not break. You can now use it to create directories and files.

2) fixes: The user input panel was not supporting the "set" attribute correctly. See my lines where I set the idata after getting a variable substitution from the set attribute idata.setVariable(variable, set);
updateUIElements() was undoing anything that the set attribute was attempting to accomplish for "dir" and "file" fields. This fix should be studied and applied to other field types which do not set the idata immediately.

Dick



 Comments   
Comment by Dennis Reil [ 06/Mar/09 ]

Applied the patch by Dick Hollenbeck

Comment by Kjell Braden [ 14/Mar/09 ]

I absolutely don't like how unconfigureable this is. In my installer, I want to be able to enter a path, or to just leave it empty. This Patch here requires to be able to create the specified path if mustExist=false, which is very bad imho.

So, why do we force this validation and only if that succeeds run the custom validator? Why don't we put this validation to the custom field validator and let the packager decide whether he needs it?

Comment by Kjell Braden [ 14/Mar/09 ]

I seem to have overlooked the allowEmptyValue field. It's undocumented btw! As you don't seem to think these validations are actual validations and belong to a seperate validator, I'm closing this again.

Comment by Dennis Reil [ 14/Mar/09 ]

Yeah, that's correct. I'm not yet finished with all documentation stuff.... I first have to implement the features and this patch was created shortly after I checked in the first version.

Comment by Noam Krendel [ 05/Apr/10 ]

Has this ever been made part of an actual release? I can't find it in 4.3.3?





[IZPACK-318] GUIInstaller constructor should display a message box when an exception occurs Created: 05/Mar/09  Updated: 20/Apr/09  Resolved: 23/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Christian d'Heureuse Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Graphical UI


Attachments: Text File IZPACK-318-Destroyer.patch     Text File IZPACK-318-GuiInstaller.patch    
Number of attachments : 2

 Description   

When an exception occurs within the GUIInstaller constructor, e.g. NoClassDefFoundError, the error is displayed at the console but no message box occurs. When the installer is started by e.g. double-clicking at the JAR file in Windows, no error message can be seen and it seems like nothing happens.

I suggest to move the current GUIInstaller constructor code into an init() subroutine and change the constructor to something like that:

public GUIInstaller() throws Throwable {
try

{ init(); }

// call original constructor code
catch (Throwable e) { // catch Throwables so that e.g. NoClassDefFoundError is included
try

{ // try to display a message box JOptionPane.showMessageDialog (null, "Error: "+e.toString(), "Error", JOptionPane.ERROR_MESSAGE); }

catch (Exception e2) {} // ignore possible exception from showMessageDialog
throw e; }} // re-throw the original exception



 Comments   
Comment by Christian d'Heureuse [ 07/Mar/09 ]

A similar problem also exists in the uninstaller.

When a NoClassDefFoundError occurs in Destroyer.getListenerLists(), no error message is displayed at the GUI.

Destroyer.run() should not only catch "Exception"s, but also "Throwable"s or at least "Error"s.

Comment by Julien Ponge [ 15/Mar/09 ]

Ok Christian.

Can you please submit a patch for the issue?

Thanks

Comment by Christian d'Heureuse [ 23/Mar/09 ]

Added patches for GuiInstaller.java and Destroyer.java.

(I additionally cleaned out some unnecessary code in Destroyer.java)

Comment by Julien Ponge [ 23/Mar/09 ]

Great!

Thanks a lot.





[IZPACK-317] Error in Compiler.getFullClassName() Created: 05/Mar/09  Updated: 20/Apr/09  Resolved: 15/Mar/09

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

Type: Bug Priority: Major
Reporter: Christian d'Heureuse 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   

The following statement at line 906 in Compiler.getFullClassName() contains a bug:

if (name.length() == pos + className.length() + 6) // "Main" class

It should be changed to:

if (pos >= 0 && name.length() == pos + className.length() + 6) // "Main" class

This bug occurs when the following conditions are met:

  • Another class file in the JAR file has a path name that is exactly one character longer than className.
    (one character because pos is -1, the +6 is for the file extension ".class")
  • This other class file appears before the correct class file in the JAR file.





[IZPACK-316] Suppress search heuristics in ShellLink.Resolve() Created: 05/Mar/09  Updated: 20/Apr/09  Resolved: 09/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Improvement Priority: Minor
Reporter: Christian d'Heureuse Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Issue Links:
dependent
is depended upon by IZPACK-233 Unicode/COIOSHelper.dll fails to buil... Closed
Number of attachments : 0

 Description   

I suggest to add the SLR_NOSEARCH flag to the following statement in ShellLink.cpp:

hres = p_shellLink [handle]->Resolve (NULL,
SLR_NO_UI | SLR_UPDATE);

When the target file does not exist and IShellLink::Resolve is called without the SLR_NOSEARCH flag, Windows uses heuristic searching to find another target. This leads to very strange effects. For example, when the target of a start menu link is an EXE file which does not exist and there is another EXE file in the same directory, IShellLink::Resolve changes the link to point to the other EXE file. The result is that there is a start menu entry with a certain name and description that points to the wrong EXE file.



 Comments   
Comment by Florian Buehlmann [ 06/Mar/09 ]

I would prefer to only build UNICODE version of the dll's for x86 and x64.
This would simplify the code.
In Addition i would like to combine the ShellLink and ShellLink_x64 directories to one ShellLink directory to simplify the directory structure.
Is this ok for all others?

Comment by Julien Ponge [ 07/Mar/09 ]

That ok for me.

Comment by Florian Buehlmann [ 09/Mar/09 ]

Upgraded ShellLink and COIOSHelper to MS VisualStudio2008.
Created x86 and x64 dll's for ShellLink and COIOSHelper (unicode only).
Changed directory structure for ShellLink and COIOSHelper to build x86 and x64 version in the same VS Project.
Changed Build.xml to include x86 and x64 dll's in the IzPack distribution.

Comment by Julien Ponge [ 09/Mar/09 ]

Wonderful!





[IZPACK-315] Localize hardcoded string in UninstallerFrame Created: 04/Mar/09  Updated: 04/Mar/09

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

Type: Improvement Priority: Minor
Reporter: Andrea Gualano 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   

String "IzPack - Uninstaller" in class com.izforge.izpack.uninstaller.UninstallerFrame line 99 is hardcoded, should be localizable like its counterpart "IzPack - Installation of ".






[IZPACK-314] Add configuration option for Panel Created: 04/Mar/09  Updated: 02/Nov/09  Resolved: 17/Mar/09

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

Type: Improvement Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It should be possible to add configuration information to a Panel, e.g.
<panel classname="MyCustomPanel" id="test">
<configuration>
<param>
<key>test</key>
<value>my test value.</value>
</param>
</configuration>
</panel>



 Comments   
Comment by Tiziano Furlan [ 02/Nov/09 ]

This is already possibile, it's just not documented (at least I've not found it on the docs).

The configuration/param/key,value tags are also missing from the DTD.

(version 4.3.1)





[IZPACK-313] Wrong mouse click behavior in PacksPanel / packs list Created: 03/Mar/09  Updated: 20/Apr/09  Resolved: 15/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Critical
Reporter: Christian d'Heureuse Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WinXP, Java 1.6.0_11-b03


Attachments: Text File IZPACK-313.patch    
Number of attachments : 1

 Description   

This error is new in 4.2.1 and did not occur in 4.2.0.

Steps to reproduce:

1. Start IzPack-install-4.2.1.jar and click "Next" until the PacksPanel is displayed.
In the packs list, all checkboxes are selected and the first pack (Core) is highlighted.

2. Click on the name of any of the other packs in the list, e.g. "HTML Documentation".
Most of the times, this click has no effect. But sometimes it works as expected: The other pack gets highlighted and the description of the pack occurs below.
On my computer, the correct action occurs only in about 1 of 20 clicks.

3. Click on one of the checkboxes.
In most of the cases, the checkbox is switched (as it should be). But sometimes the pack is highlighted instead of switching the checkbox state.
On my computer, the correct action occurs in about 19 of 20 clicks.

This error does not occur with the previous version IzPack-install-4.2.0.jar.



 Comments   
Comment by Christian d'Heureuse [ 03/Mar/09 ]

The error has been introduced with the fix for IZPACK-195 (revision 2467).

When I remove the following lines form PackPanelBase.java, the error disappears:

for (MouseListener mouseListener : packsTable.getMouseListeners())

{ packsTable.removeMouseListener(mouseListener); }
Comment by Christian d'Heureuse [ 12/Mar/09 ]

Added a patch to fix this bug.





[IZPACK-312] CompilerListener and SimpleCompilerListener are missing in izevent.jar Created: 03/Mar/09  Updated: 20/Apr/09  Resolved: 14/Apr/09

Status: Closed
Project: IzPack
Component/s: Build
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Improvement Priority: Minor
Reporter: Christian d'Heureuse Assignee: Klaus Bartz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File IZPACK-312.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

CompilerListener and SimpleCompilerListener are not included in izevent.jar. SimpleCompilerListener is in fact not included in any of the JAR files of the IzPack distribution.

Both classes are compiled in the Ant target compile.listener-base, but excluded in the Ant target build.listener-base. This makes no sense. Both classes should be in izevent.jar "to support creation of custom action jars without the IzPack source tree" (as noted in build.xml).

I suggest to remove the following line from build.xml:
<exclude name="com/izforge/izpack/event/Compiler.class"/>



 Comments   
Comment by Christian d'Heureuse [ 03/Mar/09 ]

The last line in the description of this issue has been mangled by Jira. (The "*" characters have been interpreted as text formatting codes for bold text).

The correct line 756 of build.xml is:

<exclude name="com/izforge/izpack/event/*Compiler*.class"/>

Comment by Klaus Bartz [ 11/Mar/09 ]

CompilerListener and SimpleCompilerListener are used AT creating a installation jar with the so called "compiler", they are not used IN the installation jar. izevent.jar was created to provide the classes used by the installation and/or uninstallation and will be merged automatically into the installation jar. Therefore the CompilerListener classes brings no benefit if they are in izevent.jar else they have to be included in the jar file which contains the CompilerListener.
Do not remove the exclude rule, please.

Comment by Christian d'Heureuse [ 11/Mar/09 ]

Klaus, thanks for your comment.

I understand that CompilerListener and SimpleCompilerListener must not be included in the installer/uninstaller JARs, but this would not be the case. I have tested it. In the Ant targets "build.installer" and "build.uninstaller", there is already an <include> sub-element for ezevent.jar to include only the needed classes.

Moreover, the Ant macro "build-compiler-listener" fails to compile classes that are based on SimpleCompilerListener. Even the included sample ChmodCompilerListener.java cannot be compiled, because SimpleCompilerListener is not in any of the JARs in the compiler classpath of the macro "build-listener". (Note that the out-commented "CUSTOM ACTION test" block in build.xml does not work anyway, because the sample programs are no longer within the @

{srcdir}

directory tree).

I suggest to include CompilerListener and SimpleCompilerListener in ezevent.jar, and to extend the macros "build-installer-listener" and "build-uninstaller-listener" to exclude them. I will add a patch for this change.

Comment by Christian d'Heureuse [ 11/Mar/09 ]

added a patch with the suggested changes on build.xml

Comment by Julien Ponge [ 12/Mar/09 ]

Klaus, would you be able to review the issue?

Comment by Christian d'Heureuse [ 15/Mar/09 ]

see also IZPACK-81 (it's patch modified build.xml to include only the needed classes from izevent.jar into the installer/uninstaller JARs)

Comment by Christian d'Heureuse [ 23/Mar/09 ]

Prerequisite for: IZPACK-329

Comment by Julien Ponge [ 02/Apr/09 ]

Hi Klaus,

What's your suggestion for this issue?

Thanks

Comment by Julien Ponge [ 13/Apr/09 ]

As we are 1 week away from the release of 4.3.0, do you think that you can resolve the issue on time?

It is absolutly not a problem if you can't, just let me know as we can move the issue to 4.3.1.

Thanks a lot!

Comment by Christian d'Heureuse [ 13/Apr/09 ]

Julien, I think there is no risk to applying this patch. You can easily verify in the current version of build.xml that CompilerListener and SimpleCompilerListener will not be included in the installer and uninstaller JARs, because the patch of IZPACK-81changed the zipfileset/includes for izevent.jar.





[IZPACK-311] Installer displays empty error message on NullPointerException Created: 02/Mar/09  Updated: 20/Apr/09  Resolved: 03/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Minor
Reporter: Christian d'Heureuse Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When a NullPointerException (without a detail message) occurs in the installer (as was the case with IZPACK-265), an empty message box is displayed.

The reason for this error is that NullPointerExceptions usually don't have an associated detail message.
The following code fragment in Unpacker.run() uses the detail message of the exception as the error message for the user:

handler.emitError("An error occured", err.getMessage());

When the exception has no detail message (i.e. getMessage() returns null), an empty message box is displayed. This is very confusing for the user and should be avoided.

A possible solution could be to generate an error message in this case. The message could include the exception name, e.g.:
A NullPointerException has occurred.
Or:
An internal error (NullPointerException) has occurred.



 Comments   
Comment by Florian Buehlmann [ 02/Mar/09 ]

A more useful message is now displayed like: "Internal error occured : " + err.toString();
This shows the NPE to the user.

Comment by Dennis Reil [ 03/Mar/09 ]

I think this should also be done in the MultiVolumeUnpacker.

Comment by Florian Buehlmann [ 03/Mar/09 ]

You are right. I murge the code to the MultiVolumeUnpacker to.

Comment by Florian Buehlmann [ 03/Mar/09 ]

Change is also made in MultiVolumeUnpacker.





[IZPACK-310] Pack size is 0 for loose=true Created: 01/Mar/09  Updated: 04/Mar/09  Resolved: 04/Mar/09

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

Type: Bug Priority: Critical
Reporter: Christian d'Heureuse Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File LoosePackSize.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The "Total space required" value for "loose" packs is always 0.

Reason:
For IZPACK-265 (Revision 2492), the following change has been made in PackFile.java, which sets length to 0 if the file is part of a loose pack:

public void setLoosePackInfo(boolean loose)
{
if (loose)

{ // file is part of a loose pack length = 0; }

}

In Packager.writePacks(), this length value is used to calculate the package size (Pack.nbytes):

// even if not written, it counts towards pack size
pack.nbytes += pf.length();



 Comments   
Comment by Florian Buehlmann [ 02/Mar/09 ]

The file size is set to zero because we skip this size of bytes in the pack input stream during installation. This forces a EOF Exception during installation of a lose pack if conditional files (os dependent) included in the pack.
I think the solution is to calculate the pack size during compilation and save the size in the Pack class. The other way is to remember the loose pack flag on each PackFile.

Comment by Florian Buehlmann [ 02/Mar/09 ]

The attached patch should fix the pack size problem.
Note:
The size of the pack is not correctly calculated because we add the size of all files to the pack even if the file is part of a conditional fileset.

Comment by Florian Buehlmann [ 02/Mar/09 ]

See attached patch which should fix this pack size problem.
The size of the pack is not calculated correctly if the pack contains conditional files or conditional filesets.

Comment by Christian d'Heureuse [ 02/Mar/09 ]

Thanks for the patch. I have tested it and it works fine.

Why is the disk space required to install a pack computed at compile-time and not at install-time, when the conditions can be evaluated?

Comment by Julien Ponge [ 02/Mar/09 ]

Thanks Florian. I have re-assigned the patch to you so that you can commit and notify the dev list.

Comment by Florian Buehlmann [ 03/Mar/09 ]

Thanks for the test.
Good question. To evalueate the size at install time it would be necessary to read all packs from the jar file and check the condition of each file in each pack. This could take a long time. You can create multiple conditional packs instead of one pack with conditional fileset's then the size would be correct.
I have to check if it were possible to calculate the pack size for each condition during compilation so that we have these values correctly at install time.

Comment by Florian Buehlmann [ 04/Mar/09 ]

It would be very complicated to calculate the correct pack size during compilation because we need to remeber a size for each condition and os-condition that is used in the pack.
During the installation the conditions can change so the displayed size could be wrong even we have it claculated correctly during compilation. We would have the same problem if we claculate the size during installation in addition to the time we need to calculate.
I think it's the best we let it as it is.





[IZPACK-309] AutomatedInstaller shouldn't be able to silently die Created: 27/Feb/09  Updated: 20/Apr/09  Resolved: 11/Mar/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Minor
Reporter: David Duponchel Assignee: David Duponchel
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 0001-AutomatedInstaller-refactor.patch    
Number of attachments : 1

 Description   

In an automated installer, if the automation helper fails (with an illogical xml for example) the application silently exit. It should print some useful informations.



 Comments   
Comment by David Duponchel [ 27/Feb/09 ]

A refactoring of the class AutomatedInstaller.
PanelAutomation#runAutomated now throw a meaningful InstallerException instead of returning false if something went wrong.

Comment by David Duponchel [ 11/Mar/09 ]

Fixed by refactoring the class AutomatedInstaller.
PanelAutomation#runAutomated now throw a meaningful InstallerException instead of returning false if something went wrong.





[IZPACK-308] Loose pack do not work if installation is startet from UNC path Created: 27/Feb/09  Updated: 20/Apr/09  Resolved: 27/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Critical
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File IZPACK-308-Alternative1.patch     Text File IZPACK-308-Alternative2.patch     Text File IZPACK-308-Alternative3.patch    
Number of attachments : 3

 Description   

If the installation files are on a file server and the installation is startet over the UNC path like java -jar \\server\install_files\setup.jar the loose pack files are not found.



 Comments   
Comment by Florian Buehlmann [ 27/Feb/09 ]

Loose packs are now working if the installation is started from a UNC path.

Comment by Christian d'Heureuse [ 22/Mar/09 ]

Florian, I run into this problem with Windows UNC paths with IzPack 4.2.1 and I started to write a patch before I saw your Jira entry and your patch.

I don't like how the special case of Windows UNC paths are handled in your patch. I have developed 3 alternative patches. Please have a look at them.

Patch 1 makes minimal changes to the original code by using the URI class instead of the URL class.

Patch 2 is an improvement to patch 1, to avoid creating a File object that contains a "!" within the path and a last path component ("info") within the JAR file. This could be a problem in some operating systems or in future or alternative Java implementations.

Patch 3 uses getProtectionDomain() instead of getResource() to find the path of the JAR file. This has the advantage of not having to extract the nested "file:" URL out of the outer "jar:" URL.

All three alternative patches don't need extra code to handle Windows UNC paths and should be more portable and future-proof than the current solution.

Comment by Christian d'Heureuse [ 23/Mar/09 ]

Related: IZPACK-347

Comment by Florian Buehlmann [ 23/Mar/09 ]

Christian thanks for the patch. Your solution is really better than mine. I change the code to be more flexible for the future.





[IZPACK-307] Refactoring of WebRepositoryAccessor Created: 26/Feb/09  Updated: 26/Feb/09

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

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

Number of attachments : 0

 Description   

The WebRepositoryAccessor is never instanciated and only a static method is used.
We should clean the useless code and refactore this class.






[IZPACK-306] testLineNumber from XMLParserTest fails. Created: 25/Feb/09  Updated: 20/Apr/09  Resolved: 25/Feb/09

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

Type: Bug Priority: Trivial
Reporter: David Duponchel Assignee: David Duponchel
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The test "testLineNumber" from the XMLParserTest test class should not fail.



 Comments   
Comment by David Duponchel [ 25/Feb/09 ]

A new line had been inserted in a long line. As a result, the test failed.
Resolved in revision 2629





[IZPACK-305] ConditionTest broken Created: 25/Feb/09  Updated: 20/Apr/09  Resolved: 25/Feb/09

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

Type: Bug Priority: Major
Reporter: Anthonin Bonnefoy Assignee: Anthonin Bonnefoy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

ConditionTest has been broken with the use of the new xml parser. It throws the current exception:

org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it.
at com.sun.org.apache.xerces.internal.dom.ParentNode.internalInsertBefore(ParentNode.java:352)
at com.sun.org.apache.xerces.internal.dom.ParentNode.insertBefore(ParentNode.java:284)
at com.sun.org.apache.xerces.internal.dom.NodeImpl.appendChild(NodeImpl.java:235)
at com.izforge.izpack.adaptator.impl.XMLElementImpl.addChild(XMLElementImpl.java:130)
at com.izforge.izpack.installer.ConditionTest.createVariableCondition(ConditionTest.java:95)
at com.izforge.izpack.installer.ConditionTest.setUp(ConditionTest.java:56)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)






[IZPACK-304] XPackFile doesn't transfer condition from Packfile Created: 25/Feb/09  Updated: 20/Apr/09  Resolved: 25/Feb/09

Status: Closed
Project: IzPack
Component/s: None
Affects Version/s: 4.0.0, 4.0.1, 4.1.0, 4.1.1, 4.2.0, 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The XPackFile, used in MultiVolumePackager doesn't take the condition from a packfile. Thus conditions are not working on files with MultiVolumePackager.



 Comments   
Comment by Dennis Reil [ 25/Feb/09 ]

XPackFile now takes the condition from the PackFile.





[IZPACK-303] Xinclude : href should take a path relative to the document Created: 24/Feb/09  Updated: 20/Apr/09  Resolved: 27/Feb/09

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

Type: Bug Priority: Major
Reporter: Anthonin Bonnefoy Assignee: Anthonin Bonnefoy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Currently, in case of a relative path, the file is resolved from the execution directory.
The natural behaviour would be to resolve it from the document that includes the xinclude element.



 Comments   
Comment by Dennis Reil [ 26/Feb/09 ]

I still get the same error. Mathew mentioned to set the system id or something like that. I don't see that in your changes.

Comment by Anthonin Bonnefoy [ 26/Feb/09 ]

Okay, I focused on the parse of an URL and forgotten the case of the InputStream.
I'm going to make testcase for the inputStream.

Comment by Dennis Reil [ 27/Feb/09 ]

Thanks Anthonin... It's now working as expected.





[IZPACK-302] Radio Button Key Behaviour & Accelerator Keys Created: 22/Feb/09  Updated: 30/Sep/09  Resolved: 30/Sep/09

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

Type: Improvement Priority: Minor
Reporter: Mathew Joseph Assignee: Julien Ponge
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Attachments: Java Source File InstallerFrame.java    
Number of attachments : 1

 Description   

1. I would be complete to have accelerator keys available to choose Next / Previous / Quit etc

2. Windows typically allows radio buttons to be changed with the arrow keys.



 Comments   
Comment by Julien Ponge [ 15/Mar/09 ]

Mathew, would you be able to work on a patch for this?

Comment by Mathew Joseph [ 15/Mar/09 ]

Sure can do. Just in case I dont find time in a hurry, Whats the release schedule for 4.3.0?

Comment by Julien Ponge [ 16/Mar/09 ]

The cutoff is in 2 weeks, and the release is for April 21st.

Comment by Mathew Joseph [ 22/Mar/09 ]

Had a go at this. The keyboard shortcuts for Next, Previous is simple enough and is just 3 lines of code. The part about Radio Button Key behaviour is actually 2 separate problems.

1. There is a radio button group in the License Page

This one is simpler I suppose because the code in IzPack can be changed to handle this. But is that the right way to go about it

2. Users can create radio button groups in UserInputPanels

This one is trickier because in principle the behavior of UI components should be dictated by the LAF libraries. So if I select the Windows LAF under jgoodies, that should provide me the radio button up arrow behavior since its more of a windows spec. Then ofcourse each LAF could have its own interpretation of keyboard behaviour. In principle, the first problem should also be solved under the LAF mechanism, which ensures there is a clear separation between the content of the panel and its LAF.

If you agree with this, whats the best way to modify the LAF jars. ?

Comment by Mathew Joseph [ 21/Jun/09 ]

Mm attaching the updated source file for just the keyboard shortcuts for Next/Previous/Quit.. nothing major, just 3 lines of code added.

Needed to know what your opinion was about the larger problem with the behaviour of arrows and changing behaviour via the LAF..

Comment by Mathew Joseph [ 21/Jun/09 ]

Patch for Next, Previous, Quit buttons

Comment by Julien Ponge [ 30/Sep/09 ]

Too old issue, and mnemonics are locale-dependent.





[IZPACK-301] Header Resize Behaviour Created: 22/Feb/09  Updated: 14/Aug/12  Resolved: 14/Aug/12

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

Type: Bug Priority: Minor
Reporter: Mathew Joseph Assignee: Tim Anderson
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   

Information: Header lines do not resize: Text disappears off the right of the screen when the window is resized. Everything else resizes.



 Comments   
Comment by Tim Anderson [ 14/Aug/12 ]

I don't think it makes sense for these to resize, so marking as Won't Fix. If you can attach screenshots of an installer before and after resize that demonstrate the need for header lines to resize, I'll re-open.





[IZPACK-300] Uninstall Path Display Length Created: 22/Feb/09  Updated: 18/Aug/12  Resolved: 18/Aug/12

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

Type: Improvement Priority: Minor
Reporter: Mathew Joseph Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Number of attachments : 0

 Description   

Uninstaller: cannot read the "Force deletion" path if its exceptionally long.



 Comments   
Comment by Tim Anderson [ 18/Aug/12 ]

In 5.0, the uninstaller dialog resizes to fit the path





[IZPACK-299] Confirmation Dialog Language Consistency Created: 22/Feb/09  Updated: 31/Jul/12  Resolved: 31/Jul/12

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

Type: Bug Priority: Major
Reporter: Mathew Joseph Assignee: Tim Anderson
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   

Confirmation dialog language consistency: if quit is chosen, options are Yes / No.
With create new installation directory dialog, options are Ok/Cancel



 Comments   
Comment by Tim Anderson [ 31/Jul/12 ]

A. For quit, the dialog has:

  • title = "Are you sure you want to quit"
  • text = "This will cancel the installation!"
  • buttons = Yes, No

B. For the directory creation, the dialog has:

  • title = "Message"
  • text = "The target directory will be created: <selected directory>
  • buttons = OK, Cancel

For A., it does not make much sense to change the buttons to "OK" and "Cancel" as the text becomes ambiguous - Cancel could be misinterpreted as being either to "Cancel the installation" or "Cancel the quit".

For B. the dialog would not make sense if the buttons were changed to "Yes" and "No".





[IZPACK-298] PacksPanel Key Behaviour Created: 22/Feb/09  Updated: 07/Aug/12  Resolved: 07/Aug/12

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

Type: Improvement Priority: Minor
Reporter: Mathew Joseph Assignee: Tim Anderson
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

Select Installation Packages: keyboard navigation: once focus is in "packs" selection pane, tab cannot be used to get out.
Enter does not select default button - next,
Space does not select the checkbox.



 Comments   
Comment by Tim Anderson [ 04/Aug/12 ]

These aren't bugs.

  • to get out of the packs selection table, you need to use Ctrl-Tab.
  • enter does not select the default button as the behaviour for enter in a table is to navigate to the next cell.
  • the check box needs to have the focus in order for space to work.

That said, it does make sense to be able to tab out of the table, and being able to press space in the selected row to toggle the checkboxes does simplify things.
Changing this to an improvement.

Comment by Tim Anderson [ 04/Aug/12 ]

Pull request is at: https://github.com/izpack/izpack/pull/48





[IZPACK-297] Izpack Enter Key Behaviour on License Agreement Screen Created: 22/Feb/09  Updated: 07/Aug/12  Resolved: 07/Aug/12

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

Type: Bug Priority: Major
Reporter: Mathew Joseph Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, WindowsXP/Vista


Number of attachments : 0

 Description   

Licensing Agreements: keyboard navigation: when focus is in agreement pane, "Enter" does not select default button - "Next"



 Comments   
Comment by Tim Anderson [ 04/Aug/12 ]

Fix for this is available at: https://github.com/izpack/izpack/pull/47

The default button is now triggered if enter is pressed whilst the text area has the focus.
Change has been applied to both the HTMLLicencePanel and LicencePanel





[IZPACK-296] Izpack Enter Key Behaviour Created: 22/Feb/09  Updated: 04/Aug/12  Resolved: 04/Aug/12

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

Type: Bug Priority: Minor
Reporter: Mathew Joseph Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP/Vista


Number of attachments : 0

 Description   

Using the default look and feel (i.e. with no guiprefs)
When a key has focus, for e.g., the "Previous" key, the enter button seems to always work on "Next". Works fine in Linux, but not in windowsXP/Vista



 Comments   
Comment by Tim Anderson [ 31/Jul/12 ]

This looks to be the behaviour explained here: http://www.devx.com/DevX/Tip/31605

Most GUI users also expect that when a control, in particular a button, has the focus, they can activate it by pressing the ENTER key. With Swing applications, however, this may not always be the case; in fact, pressing the ENTER key may sometimes activate a button that the user does not want to be activated. This is due to a change that was made to the Metal look-and-feel in Java 1.2. This is the default look-and-feel for Swing apps, and until version 1.2 it behaved the way most users expect it to, with the ENTER key activating a focused JButton. Since version 1.2 though, pressing ENTER will not activate a focused JButton in a Swing app using the Metal look-and-feel. Instead, the user must press the spacebar to activate the focused JButton.

Comment by Tim Anderson [ 31/Jul/12 ]

Pull request is at: https://github.com/izpack/izpack/pull/41





[IZPACK-295] Installer support of Win Setup API - replacing blocked files after reboot Created: 20/Feb/09  Updated: 09/Feb/10  Resolved: 26/Aug/09

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

Type: New Feature Priority: Major
Reporter: Rene Krell Assignee: Julien Ponge
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows (all)


Attachments: GZip Archive izpack-issues_295_405_against_r2844.patch.gz     GZip Archive izpack_win_setup_api.patch.tar.gz     Text File merge-out.txt     GZip Archive SetupAPI_win32pad_example.tar.gz    
Issue Links:
Related
relates to IZPACK-405 Add -console-auto option to read opti... Resolved
Supercedes
is superceded by IZPACK-520 Implement basic upgrade handling Resolved
Patch Submitted:
Yes
Number of attachments : 4

 Description   

I'd like to add a feature of installing files in Windows using the Windows Setup API, see http://msdn.microsoft.com/en-us/library/cc185682(VS.85).aspx. This API is used by native Windows installers to overwrite files after reboot which are blocked by running processes during install time.

I have already an own Java-based implementation of Ant tasks for this, using a native DLL over JNI. This works quite good, it's used in professional environments delivered to customers.

The problem to use these Ant tasks in IzPack as AntActionListener is that files must be added in install.xml in a conventional way, but saved in a temporary location, and then copied over with the Win Setup API Ant tasks. This works and I use this, but there's lost different funtionality of IzPack as the usage of automatically generated uninstallers.

Can some project member give me a more detailed guideline how and where to place this, before I start with some local patches?
I imagine to integrate this directly into install.xml as some special element as a complement of the already existing tags <fileset>, <singlefile> and <file>, which is packed into the installer jar but handled different during installation.

Thanks



 Comments   
Comment by Julien Ponge [ 22/Feb/09 ]

Hi René,

From the MSDN link that you gave, I read that this API should not be used anymore:

Setup API should no longer be used for installing applications. Instead, use the Windows Installer for developing application installers. Setup API continues to be used for installing device drivers.

I guess that indeed you need to complement the existing tags as you suggested.

You can manipulate the uninstaller (see how the registry listeners work).

I have one further question: how would your change work on other systems than Windows? I guess such files are somehow OS-specific, but sometimes they may not. What do you think?

Cheers

Comment by Rene Krell [ 22/Feb/09 ]

Hi Julien,
I'd like to declare the your questions as shortly as possible:

"Setup API" and "Windows Installer" are some completely different worlds.
Setup API handles single files in so called file queues. If target files are to be overwritten and if they are blocked at install time, they are written automatically by Setup API into a temporary location and overwritten after reboot automatically, too. There is no other way to do so in Windows at all. Otherwise, if I file is blocked there is no other way to get it overwritten than unblock it by shutting down the application which blocks it. In several situations such applications are needed in a running state during installation time. That's the use case when Setup API makes sense. The Setup API specification is very stable over several versions of Windows all time, as many functions of the Windows API.
Windows Installer is partly some complex alternative to IzPack for Windows, it's about doing complex installation transactions based on registered applications. It's on another abstraction level. And it would break the platform independence in a worse manner. Windows Installer might use Setup API internally, maybe. Furthermore, using Windows Installer makes an installer application depending on a preinstalled Windows Installer, which is on quite different feature level compare between the Windows "distributions". Native installers for Windows might use the Windows Installer itself, but IzPack should not, at least not yet.
Maybe one time Java for Windows will make it easier to copy blocked files in Windows, but at the moment there no such feature.
I haven't tested Setup API on Windows Vista and 2008, but on Windows XP and 2003 Server it works fine, for example.

What I do not want is to confuse existing IzPack tags too much.
This should be well specified and is to be discussed somewhere.

Some "brainstorming":

  • Setup API is Windows-specific and would be simply ignored on other systems. Blocked files do not exist on UNIX systems in that way as far as I know.
  • Copying a file or a bunch of files by Setup API should be declared explicitely in install.xml, on the other hand without this declarations all files should be copied in the classic way.
  • Attributes for limit tasks to specific target OS are automatically implied to "windows" on wanting copy a file using Setup API.
  • The JNI DLL used here takes about 55 KBytes of space in the installer, as other DLLs, too.

My favorite question at the moment:
Should this be made in a branch or how could this be handled within this project? In trunk?

And at least I have to get the permission of my company to offer code here that I made for them.

If this discussion would lead to an "yes" for introducing this feature I can propose the interface changes in install.xml and discuss it with you and all who are interested in to make the best possible solution of it. I have already patched 4.2.1 on my private computer with the sources I already have ready

Comment by Julien Ponge [ 23/Feb/09 ]

Ok I see.

  1. This should be made on your side (as I won't give you access to the SVN repository at the moment)
  2. You may use Git if you like, I maintain a repo at http://github.com/jponge/izpack/tree/master
  3. Once you have the feature working and documented, you can attach the patch (as a diff!) to the issue, and we wil review.
  4. Hopefuly it gets merged into the project, but I cannot make any promise at this stage

Cheers

Comment by Rene Krell [ 05/Mar/09 ]

Thank you. For now, I will work in a SVN copy of izpack-src/branches/4.2 and provide a patch as soon as there is a pre-tested result.

Comment by Rene Krell [ 30/Apr/09 ]

This is my patch for it. Would be nice if you had a look at it.

TODO:

  • translations (only eng, deu, cze at the moment)
  • compilation of the JNI DLLs in VC 32+64bit (Borland BCC 5.5 32 bit at the moment)

Maybe there are some formatting errors, I use the AnyEdit Eclipse plugin to remove trailing spaces at the end of lines, for example.

Thanks,
René

Comment by Rene Krell [ 02/May/09 ]

More TODOs:

  • Check automatically for Windows at install time, don't even try using file queues otherwise (will add it next week).
  • Put a warning at compile time if blockable files are not explicitely limited to Windows in install.xml
Comment by Rene Krell [ 04/May/09 ]

This is a more complete patch:

  • Enhanced documentation, more detailed specification and added a special section to "Advanced features" describing it more detailed with an example. The feature is now well-documented for anyone, I guess.
  • Added a compiler warning if the 'blockable' attribute is used on multiplatform installations (this is legal, but the user should be informed anyway, IMHO)
  • Added ignoring 'blockable' on non-Windows platforms
  • Removed invalid line break in translations for message box

Handling blockable files in an uninstaller is still not implemented, but prepared in the base classes, no new JNI DLLs will be needed.

The feature is pre-tested on Windows XP and OpenSUSE 11.1 (for compatibility on non-Windows systems).

Comment by Rene Krell [ 04/May/09 ]

Small typo fix in examples with some GUI text

Comment by Rene Krell [ 05/May/09 ]

My latest patch.

If you haven't already applied it for review:
This latest patch contains only a cleanup - removed some obsolete code from some previous implementations: Win API shutdown functions not used at all here.
There is no functional change, only the piece of code gets a bit smaller

Forgot to say even for the previous patches:
The patch applies against the current SVN trunk - should work fine with r2769

Note:
The WinSetupAPI.DLL and WinSetupAPI_64.DLL must be copied manually to
izpack-src/trunk/src/native/SetupAPI/
Or even better someone rebuilds them with Visual C++ in real 32 and 64 bit mode. At the moment both are 32bit compiled with Borland BCC 5.5, I don't have any other compiler and a 64bit system here at the moment. Hopefully the WinSetupAPI_64.DLL runs in 32-bit compatibility mode on 64-bit systems.

Comment by Julien Ponge [ 05/May/09 ]

Thanks, we'll put that under review soon.

Comment by Rene Krell [ 05/May/09 ]

Ok thanks.

As you will see, the affected components are not limited to the installer, only, as originally chosen on creating this issue. The following components are affected (I can't change this any more):

  • Build
  • Compiler
  • Documentation
  • Installer
  • Translations
  • Uninstaller (not yet, but hopefully soon)
Comment by Christian d'Heureuse [ 08/Jun/09 ]

Could this feature also be used to remove locked files after the uninstall? I have the problem that some files of the bundled JRE are locked while the uninstaller JAR is running. These files should be deleted after the uninstall JAR and the java.exe of the bundled JRE have completed. A reboot would not be necessary.

Comment by Rene Krell [ 08/Jun/09 ]

Hi Christian, this might work, see
http://msdn.microsoft.com/en-us/library/aa377425(VS.85).aspx
But rather than using it for deleting I would use the File.deleteOnExit() method in that case, instead, which should delete them afterwards. Of course, deleteOnExit() might be a problem for deleting files and directories recursively.
Personally I haven't tested the SetupQueueDelete API function much often, thus, I cannot guarantee that it will fit the your need in all points. Anyway, it is defined in the JNI interface brought by this patch and could be immediately used for testing.

Comment by Rene Krell [ 08/Jun/09 ]

But even here you can get into trouble on removing files recursively, since it removes only one or more single files, but not the directories in which blocked files are located.

Comment by Rene Krell [ 08/Jun/09 ]

The idea behind this feature is to mark files potentially blocked by running processes, so integrating it also in the uninstaller is a functionality which is should be also there in each case later, but isn't yet implemented in the current patch. I will put it there as soon as possible, at least for using it in IzPack in my local copy of the trunk.

Comment by Christian d'Heureuse [ 08/Jun/09 ]

René, thanks for your reply.

File.deleteOnExit() will probably not work to delete the files of the running JRE, because a process cannot delete it's own EXE and DLL files while it is running.

Comment by Rene Krell [ 12/Jun/09 ]

Just wondering: Anything new here in common, any opinion or progress? Thank you

Comment by Julien Ponge [ 12/Jun/09 ]

Assigned to me, I will make reviews soon

Comment by Julien Ponge [ 22/Aug/09 ]

I'm very sorry for only getting back to you now....

I tried to apply the patch and some hunks fail. I have attached a log file.

Would it be possible for you to update the patch?

Thanks a lot.

Comment by Rene Krell [ 24/Aug/09 ]

Hi Julien,
this is a common patch for both issues, 295 and 405.

Those issues are absolutely independent concerning the implementation. There are only some particular files affected by both and I'm not able to separate them now so quickly, because I enqueued those changes over half a year in trunk. I hope this will not be a big deal.

A a hint, I give you a list of classes:

Issue 405:
com.izforge.izpack.installer.Installer
com.izforge.izpack.installer.PanelConsole
... and all classes implementing PanelConsole.java:
com.izforge.izpack.panels.FinishPanelConsoleHelper

com.izforge.izpack.panels.HelloPanelConsoleHelper

com.izforge.izpack.panels.HTMLLicencePanelConsoleHelper

com.izforge.izpack.panels.InstallPanelConsoleHelper

com.izforge.izpack.panels.JDKPathPanelConsoleHelper

com.izforge.izpack.panels.LicencePanelConsoleHelper

com.izforge.izpack.panels.TargetPanelConsoleHelper

com.izforge.izpack.panels.UserInputPanelConsoleHelper

Issue 295 + 405:
src/doc-reST/advanced-features.txt
#405: Section "Unattended installations" (merged with previous issues)
#295: the rest
com.izforge.izpack.installer.ConsoleInstaller
#295: method checkedReboot(),
#405: the rest

Issue 295:
All other files and the DLLs (not in the patch) to build and copy.

Just ask if you get into trouble with this.

BTW: There are many formatting issues due to trailing white spaces in the source code. I would appreciate to use an automatic tool for eliminating them for better patches and formatting, such as the AnyEdit plugin for Eclipse.

Thanks, René

Comment by Rene Krell [ 24/Aug/09 ]

... the precompiled DLL files you can take from take from the previous patch GZ, to be copied to
bin/native/IzPack

Note: The _64 DLL isn't really a 64 bit one, but only a renamed 32 bit DLL. I don't have a 64 bit Windows environment available at this time.

Comment by Julien Ponge [ 26/Aug/09 ]

Great job I must say!

Thanks René!

Comment by Rene Krell [ 27/Aug/09 ]

Thanks also to my company, which gave me the time and possibility to integrate this here. Of course they use the result, also

This issue can still be enhanced:

  • put this also to the uninstaller to delete blocked files after reboot (I'm not sure whether this works in all Windows versions)

... and especially a call for help with:

  • translations (only english, czech and german at the moment)
  • compiling the DLLs for 32 and (real) 64 bit in a VC environment (instead of Borland compiler)
  • testing (especially with Vista and 64 bit)
Comment by Christian d'Heureuse [ 27/Aug/09 ]

Thanks for your work René.

> put this also to the uninstaller to delete blocked files after reboot

And: Delete blocked files after the Java VM running the uninstaller has terminated (when a Windows reboot is not necessary).





[IZPACK-294] MultiVolumePackager not working anymore Created: 19/Feb/09  Updated: 20/Apr/09  Resolved: 19/Feb/09

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

Type: Bug Priority: Critical
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The MultiVolumePackage is not working anymore. It seems to be hanging somewhere.



 Comments   
Comment by Dennis Reil [ 19/Feb/09 ]

The MultiVolumePackager had endless loops while writing parsables, executables, .... This seems to be due to refactoring code to Java 5 code and using iterators.





[IZPACK-293] UserInputPanel: new field type multiple files Created: 19/Feb/09  Updated: 20/Apr/09  Resolved: 19/Feb/09

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

Type: Improvement Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

As addition to the existing file field, a new field type for choosing more than file shall be implemented.






[IZPACK-292] Make PanelActions configurable Created: 18/Feb/09  Updated: 20/Apr/09  Resolved: 18/Feb/09

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

Type: Improvement Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

It should be possible to pass arbitrarely configuration information to panel actions,e.g.
<panel>
<action stage="" classname="">
<variable>...</variable>
</action>
</panel>



 Comments   
Comment by Dennis Reil [ 18/Feb/09 ]

It's now possible to add a configuration element inside an action to specify a configuration for this action. The actual format of child elements or attributes will depend on the action.

e.g.

<panel>
<action stage="" classname="">
<configuration>
<variable>JDBC_CONNECTOR_DRIVER</variable>
</configuration>
</action>
</panel>





[IZPACK-291] Refactoring and enhancing UserInputPanel Created: 17/Feb/09  Updated: 20/Apr/09  Resolved: 26/Mar/09

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

Type: Improvement Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The UserInputPanel will be refactored to get rid of the object[] uielements stuff.

The UserInputPanel shall also get more dynamic, so that changing conditions will soon be reflected by changing the ui directly, e.g. showing a text field only if a check box is selected.



 Comments   
Comment by Dennis Reil [ 20/Feb/09 ]

UserInputPanel now uses a UIElement object to create a list of objects which are shown in this panel. Special needs are implemented by subclasses. At the moment (the first step of refactoring), these are just internal classes and should be extracted in a further step.

Comment by Dennis Reil [ 20/Feb/09 ]

The UserInputPanel now creates builtin ExistenceConditions for every associated variable, i.e. a variable used in a field.

Example:

<field type="text" variable="JDBC_DRIVER_CLASS">
<spec id="jdbc.driver.class.lbl" set="$

{JDBC_DRIVER_CLASS_DEFAULT}" size="30" />
</field>

This has the JDBC_DRIVER_CLASS variable associated. The panel will automatically create a condition called izpack.input.JDBC_DRIVER_CLASS which tests if this variable is known/has a current value.

This condition can be used to show up fields with default values if no value is currently there and showing the user input if a value was entered.

Example2:
<field type="text" variable="JDBC_DRIVER_CLASS" conditionid="!izpack.input.JDBC_DRIVER_CLASS">
<spec id="jdbc.driver.class.lbl" set="${JDBC_DRIVER_CLASS_DEFAULT}

" size="30" />
</field>
<field type="text" variable="JDBC_DRIVER_CLASS" conditionid="izpack.input.JDBC_DRIVER_CLASS">
<spec id="jdbc.driver.class.lbl" set="$

{JDBC_DRIVER_CLASS}

" size="30" />
</field>

This will show up the value of the default variable if the user hasn't entered a value before and will show the user input if the user entered something.





[IZPACK-290] The Housekeeper.shutDown does not call the cleanup clients if there is only one cleanup client registered Created: 17/Feb/09  Updated: 17/Feb/09  Resolved: 17/Feb/09

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

Type: Bug Priority: Critical
Reporter: Brett Bergquist Assignee: Brett Bergquist
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

I notice that my installer was failing to perform some cleanup when testing with the proposed 4.2.1 release. I tracked this down to Housekeeper.shutDown which was changed for IZPACK-276.

There is a "one off" bug in the new code. The code currently reads:

for (int i = cleanupClients.size() - 1; i > 0; i--)

and this should read:

for (int i = cleanupClients.size() - 1; i >= 0; i--)



 Comments   
Comment by Brett Bergquist [ 17/Feb/09 ]

Applied fix to the trunk.

Comment by Brett Bergquist [ 17/Feb/09 ]

Fixed by the latest code change.





[IZPACK-289] The "The Built-In Variables" section referes to USER_name and APP_name and these should be USER_NAME and APP_NAME Created: 16/Feb/09  Updated: 16/Feb/09  Resolved: 16/Feb/09

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

Type: Bug Priority: Trivial
Reporter: Brett Bergquist Assignee: Brett Bergquist
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

The documentation file "installation-files.txt" incorrectly references built in variables USER_name and APP_name and these should be USER_NAME and APP_NAME.



 Comments   
Comment by Brett Bergquist [ 16/Feb/09 ]

Checked in fixed "installation-files.txt" to the trunk.





[IZPACK-288] Instantiation of custom conditions not working properly with IzPack maven plugin Created: 13/Feb/09  Updated: 20/Apr/09  Resolved: 17/Mar/09

Status: Closed
Project: IzPack
Component/s: Compiler, Maven plugin
Affects Version/s: 4.2.0, 4.2.1
Fix Version/s: 4.3.0

Type: Bug Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When using custom conditions with IzPack maven plugin, a class not found exception will be thrown because the classloader of the RulesEngine doesn't find the class.



 Comments   
Comment by Dennis Reil [ 17/Mar/09 ]

This is not really a bug, as it shows the error message during the compile process, where the conditions aren't supported. So it can be safely ignored.





[IZPACK-287] Run the tests suite from the build process Created: 12/Feb/09  Updated: 29/Oct/09  Resolved: 29/Oct/09

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

Type: Improvement Priority: Major
Reporter: Julien Ponge Assignee: Unassigned
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   

The current build process does not run the tests suite.

Although IzPack has a limited tests suite due to its age (it was started way before TDD was all the rage...), it is desirable to have it part of the build process. It is also advisable to encourage people to write tests.



 Comments   
Comment by Julien Ponge [ 03/Jun/09 ]

I'm delaying this as the tests need some polishing.

Comment by Julien Ponge [ 29/Oct/09 ]

I give up on this.





[IZPACK-286] Fixes for Italian translation Created: 11/Feb/09  Updated: 17/Feb/09  Resolved: 11/Feb/09

Status: Closed
Project: IzPack
Component/s: Translations
Affects Version/s: 4.2.0
Fix Version/s: 4.2.1

Type: Improvement Priority: Trivial
Reporter: Andrea Gualano Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ita.xml.diff    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

Fixed several typos and punctuation errors in the Italian langpack.



 Comments   
Comment by Julien Ponge [ 11/Feb/09 ]

Thanks!





[IZPACK-285] Possible execution of a java class before and after a panel Created: 11/Feb/09  Updated: 20/Apr/09  Resolved: 13/Feb/09

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

Type: Improvement Priority: Major
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependent
is depended upon by IZPACK-218 Need to provide the ability to call a... Closed
Number of attachments : 0

 Description   

It were very useful to add the possibility to run a specific java class befora a panel activates, before the panel validates and after the panel validation.
This could be done with an additional tag in the panel tag like the following:

<panel classname="UserInputPanel" id="my.panel.id" >
<validator classname="PanelValidator"/>
<actions>
<action stage="preactivate" classname="PreActivateAction" />
<action stage="prevalidate" classname="PreValidationAction" />
<action stage="postvalidate" classname="PostValidationAction" />
</actions>
</panel>

There is no possibility to pass parameters but in the action the user has access to AutomatedInstallData by passing it as a paramter into the action.



 Comments   
Comment by Julien Ponge [ 11/Feb/09 ]

Nice.

You should discuss this on the dev list.

Comment by Florian Buehlmann [ 12/Feb/09 ]

There is an additional action that is called before the constructor of the panel.
<action stage="preconstruct" classname="PreConstructionAction" />

Comment by Julien Ponge [ 12/Feb/09 ]

Dennis, I think Florian is already working on it, or am I missing something?

Comment by Florian Buehlmann [ 12/Feb/09 ]

I'm nearly finish. Just writing the documentation. Ready for checkin tomorrow.
=> Reassign to me

Comment by Dennis Reil [ 13/Feb/09 ]

ok...

Comment by Florian Buehlmann [ 13/Feb/09 ]

I would like to patch this back to 4.2.1 that I can use the 4.2.1 distribution for my own installers.
Is it possible to patch this back?

Comment by Julien Ponge [ 13/Feb/09 ]

Hi Florian,

This is really a new feature, so it should not go into 4.2.1. (I know it is less convenient for you, but that is really better not to mix everything)

I guess that meanwhile you can easily apply the patch on top of 4.2.1.

Cheers

Comment by Florian Buehlmann [ 13/Feb/09 ]

Bug is marked as enhancement, but I agree with you

Comment by Florian Buehlmann [ 13/Feb/09 ]

PanelActions are now available and documented.

Comment by Florian Buehlmann [ 13/Feb/09 ]

The actions are not working on automated installation

Comment by Florian Buehlmann [ 13/Feb/09 ]

Actions are now called during automated installation also.





[IZPACK-284] Localization is not supported while using a custom DataValidator Created: 09/Feb/09  Updated: 16/Feb/09  Resolved: 16/Feb/09

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

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

While implementing a custom DataValidator, error message keys are not successfully found in the relative langpack.

public class DatabaseServerValidator implements DataValidator {

@Override
public boolean getDefaultAnswer()

{ return false; }

@Override
public String getErrorMessageId()

{ return "database.connection.error"; }

@Override
public String getWarningMessageId() { return "database.connection.error"; }

@Override
public Status validateData(AutomatedInstallData data)

{ if(ConnectionTester.databaseServerTest(data.getVariable("database.driver.class"), data.getVariable("database.connection.url"), data.getVariable("database.connection.user"), data.getVariable("database.connection.password"))) return Status.OK; else return Status.ERROR; }

}

For example, using this validator, the message box reports (in case of error obviously):

Title: data.validation.error.title
Text: database.connection.error



 Comments   
Comment by Alessandro Dionisi [ 16/Feb/09 ]

It is sufficient to place the key into file CustomLangpack.xml_[ISO3Country] as following:

<langpack>
<str id="database.connection.error" txt="Unable to connect to the application server with the specified connection parameters"/>
</langpack>

and return the relative key into the validator class.

public class DatabaseServerValidator implements DataValidator {

@Override
public boolean getDefaultAnswer()

{ return false; }

@Override
public String getErrorMessageId()

{ return "database.connection.error"; }

}





[IZPACK-283] UserinputPanel stores wrong data in autoinstall.xml Created: 09/Feb/09  Updated: 17/Feb/09  Resolved: 09/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.0
Fix Version/s: 4.2.1, 4.3.0

Type: Bug Priority: Major
Reporter: Florian Buehlmann Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

If variables of a UserinputPanel are modified during validation or in a later process the unmodified user input is written to the autoinstall.xml file.
The autoinstall.xml file should always contain the actual value of the variable.



 Comments   
Comment by Florian Buehlmann [ 09/Feb/09 ]

The variables are now refreshed before written into autoinstall.xml





[IZPACK-282] Make the privileges escalation configurable through conditions Created: 08/Feb/09  Updated: 17/Feb/09  Resolved: 10/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer, Uninstaller
Affects Version/s: 4.2.0
Fix Version/s: 4.2.1

Type: Improvement Priority: Major
Reporter: Julien Ponge 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   

Basically working on my side, needs some further polishing.



 Comments   
Comment by Julien Ponge [ 09/Feb/09 ]

This will be supported through the conditions framework and some new constants to identify Windows XP, 2003, Vista and 7.

Comment by Julien Ponge [ 10/Feb/09 ]

The fix is in!

Comment by Julien Ponge [ 10/Feb/09 ]

I will make some refactorings on the changes that I have made to the rules engine:

  • remove the dependency on the elevator towards the rules engine
  • remove the staticness of some parts of the rules engine
  • get back to the original behavior of the constructor of the rules engine.
Comment by Julien Ponge [ 10/Feb/09 ]

Done the refactoring.





[IZPACK-281] Creation of Web Installers throws an exception Created: 07/Feb/09  Updated: 17/Feb/09  Resolved: 07/Feb/09

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

Type: Bug Priority: Major
Reporter: Anthonin Bonnefoy Assignee: Anthonin Bonnefoy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependent
is depended upon by IZPACK-224 Web Installers Closed
Number of attachments : 0

 Description   

The creation of a Web Installers based on the sample installation throws the following exception:

-> Fatal error :
null/packsinfo.xml (No such file or directory)
java.io.FileNotFoundException: null/packsinfo.xml (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
at java.io.FileOutputStream.<init>(FileOutputStream.java:70)
at java.io.FileWriter.<init>(FileWriter.java:46)
at com.izforge.izpack.compiler.Packager.writePacks(Unknown Source)
at com.izforge.izpack.compiler.PackagerBase.writeInstaller(Unknown Source)
at com.izforge.izpack.compiler.Packager.createInstaller(Unknown Source)
at com.izforge.izpack.compiler.Compiler.createInstaller(Unknown Source)
at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(Unknown Source)
at com.izforge.izpack.compiler.CompilerConfig.main(Unknown Source)
at com.izforge.izpack.compiler.Compiler.main(Unknown Source)

An immediate workaround is to create a 'null' directory.






[IZPACK-280] Remove NanoXML and use javax.xml instead Created: 06/Feb/09  Updated: 20/Apr/09  Resolved: 11/Feb/09

Status: Closed
Project: IzPack
Component/s: Build, Compiler, Installer, Panels, Uninstaller
Affects Version/s: None
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Julien Ponge Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File nanoxml-removal.patch.bz2    
Testcase included: yes
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The goal of this enhancement is to remove the aging, unmaintained NanoXML parser and use the one provided by the standard Java API.

The benefits are obvious:

  • reduced installers footprint
  • some features were not available in NanoXML (namespaces, xinclude, etc)
  • NanoXML had some unfixed bugs.

The work was conducted by Anthonin Bonnefoy and David Duponchel in a separate Git tree (see http://github.com/bonnefoa/izpack-refactorings/tree/master).

It is now ready to be proposed for merging into the IzPack Subversion repository.

As the changes are significant, IzPack developers are strongly encouraged to review it.



 Comments   
Comment by Julien Ponge [ 11/Feb/09 ]

Merged.

Bye-bye NanoXML, and thanks for having been part of the project for so many years





[IZPACK-279] Prototype: switch build process to maven Created: 06/Feb/09  Updated: 06/Feb/09

Status: In Progress
Project: IzPack
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Minor
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

A prototype for switching the IzPack build process to maven should be created.






[IZPACK-278] No warning messages when clicked "Quit" button Created: 05/Feb/09  Updated: 24/Apr/13

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

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

linux(Ubuntu8.04),IzPack-install-4.2.0


Attachments: JPEG File Quitmessage.JPG    
Number of attachments : 1

 Description   

When I installed the izpack step 7of 9 and clicked "Quit",it didn't show any warning messages to closed the window.



 Comments   
Comment by Christian d'Heureuse [ 08/Jun/09 ]

The same happens in step 8 of 9.
The quit buttons of InstallPanel and ShortcutPanel do not display a warning message.

Comment by Jeff Gordon [ 13/May/10 ]

Cause is probably related to: IZPACK-94 (Add confirmation dialog for cancel button)

Comment by Alwyn Schoeman [ 17/Aug/10 ]

If you want a warning message you need to do the following:

idata.canClose = false;
Unpacker.setDiscardInterrupt(false);

Then you will get a warning message, BUT if the user selects yes you lose control and Izpack pulls your installer from under your feet as you have no control over what happens when your installer quits.

Comment by Sreram Balasubramaniyan [ 03/Feb/13 ]

Am experiencing the same problem in Windows too. Worse, I have Shortcut Panel first and then Install Panel, so that warning doesn't come in subsequent panels too.

Any updates on this issue?

Comment by Rene Krell [ 04/Feb/13 ]

Because this issue has been reported a long time ago, which IzPack version do you re-report for? Is this still valid for 5.0.0-beta11?

Comment by Sreram Balasubramaniyan [ 08/Feb/13 ]

Atleast it is valid for the current stable version 4.3.5

Have removed the previous button from the installer frame for preventing the user from going back, but i couldn't get the warning message to display.

Comment by Sreram Balasubramaniyan [ 20/Mar/13 ]

Any updates on this issue? Is it closed in 5.0.0-beta11 version?

Comment by Sreram Balasubramaniyan [ 28/Mar/13 ]

Tested with 5.0.0 b11 version yesterday... but the same result. Worse the installer virtually hangs for around a minute before the installer exits without warning...

Will http://jira.codehaus.org/browse/IZPACK-604 be of any help? But that too, i think, will be of help only in our custom panels? What about PacksPanel and the like where we don't override?

Comment by Sven Thomas [ 04/Apr/13 ]

It is very likely that the installer creates the uninstaller.jar when it seems to hang for around a minute.
This is at least what I experienced with 5.0.0-beta11. The latest RC snapshot of izpack does that better: It only takes 1-2 seconds to create the uninstaller.jar.

This is unrelated to the issue of not having a warning message if clicking "Quit" at the InstallPanel and following panels, though. I can confirm that the latest RC snapshot has this issue as well.

Comment by Sreram Balasubramaniyan [ 24/Apr/13 ]

Thanks for your responses.

Have overridden the quit functionality and is now working fine in my application. However, the bug in IzPack (without my overriding) still persists.





[IZPACK-277] Support optional value child in dynamic variables Created: 05/Feb/09  Updated: 20/Apr/09  Resolved: 19/Feb/09

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

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

Number of attachments : 0

 Description   

It should be able to define a value of a dynamic variable either by defining it with the attribute value of the variable or by using a child element value to specify more complex constructs.

e.g.
<variable name="XML_Comment_Start" condition="!feature1_activated">
<value><Unable to render embedded object: File ([CDATA[<) not found.--]]></value>
</variable>



 Comments   
Comment by Dennis Reil [ 19/Feb/09 ]

dynamic variables now support a value child element, i.e. either an attribute value or an element value is needed.





[IZPACK-276] Librarian cleanup calls System.exit() Created: 04/Feb/09  Updated: 17/Feb/09  Resolved: 09/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer, Uninstaller
Affects Version/s: 4.2.0
Fix Version/s: 4.2.1, 4.3.0

Type: Bug Priority: Blocker
Reporter: Patrick Zbinden Assignee: Florian Buehlmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

any


Number of attachments : 0

 Description   

The Librarian class is register as CleanupClient in the constructor.
When Housekeeper.shutDown(int exitCode) is called, all registered CleanupClients should do the cleanup.

Now the problem is, that Librarian calls LibraryRemover.invoke1(). At the end of this method System.exit(0) is called, so all other CleanupClients won't be called anymore.

In my opinion, Librarian.cleanup should be the last cleanup called and should not use System.exit().



 Comments   
Comment by Florian Buehlmann [ 09/Feb/09 ]

The LibraryRemover do no longer call System.exit()
Changed the Housekeeper registration for the Librarian to make sure that the Librarian is the last cleanup action. This is the only way to keep all native libraries working until all cleanup actions are done.





[IZPACK-275] CompilerConfig fails retrieving the IzPack home directory Created: 03/Feb/09  Updated: 17/Feb/09  Resolved: 03/Feb/09

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

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

In void com.izforge.izpack.compiler.CompilerConfig.main(String[] args) there is the line

String izHome = System.getProperty("IZPACK_HOME");

but the compiler is called with

echo "$JAVACMD" -Xmx512m \
$IZPACK_OPTS \
-classpath "$

Unknown macro: {IZPACK_HOME}

/lib/standalone-compiler.jar" \
"-Dtools.jar=$TOOLS_JAR" \
"-Dizpack.home=$

" \
$MAIN_CLASS "$@"

so the property we actually need is

String izHome = System.getProperty("izpack.home");



 Comments   
Comment by Julien Ponge [ 03/Feb/09 ]

Thanks!





[IZPACK-274] Implement a JavaCurses or CHARVA based interface for the installer to run from a text terminal Created: 01/Feb/09  Updated: 25/Jan/13

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

Type: Wish Priority: Major
Reporter: Olivier Dehon Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux/Unix/Windows


Issue Links:
Duplicate
is duplicated by IZPACK-634 Console installations based on Curses Open
Number of attachments : 0

 Description   

I have seen quite a few requests for a pure "text-based" installer generation.
It would be nice if the installer could be based on JavaCurses or CHARVA, instead of mandatorily rely on a graphical environment.

-Olivier

P.S.: Just in case this sparks some interest, here are a few links:
http://www.pitman.co.za/projects/charva/index.html
http://sourceforge.net/projects/javacurses






[IZPACK-273] Loose pack only create direcotry structure on linux Created: 28/Jan/09  Updated: 17/Feb/09  Resolved: 01/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.0
Fix Version/s: 4.2.1

Type: Bug Priority: Major
Reporter: Florian Buehlmann Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File LooseFileLinux.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The installation of a loose pack do not work on linux / unix. There are no files copied and only the directory structure exists after the installation.
The evaluation of the path where the installer jar is located (Unpacher class) is wrong. This evaluation only works on windows.
For speed improvement on loose packs the source patch will not evaluated every time.

See attached patch how to fix the problem.



 Comments   
Comment by Julien Ponge [ 28/Jan/09 ]

Merged, thanks!





[IZPACK-272] Conditions not working correctly with backreferenced files Created: 27/Jan/09  Updated: 17/Feb/09  Resolved: 01/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.0.0, 4.0.1, 4.1.0, 4.1.1, 4.2.0
Fix Version/s: 4.2.1

Type: Bug Priority: Major
Reporter: Dennis Reil Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

When defining a different place for a file in a pack depending on a fulfilled or non-fulfilled connection, an EOF exception can be thrown, caused by the generated backreference.

<packs>
<pack name="Tomcat" required="no" id="tomcat.core">
<description>Apache Tomcat</description>
<fileset dir="apache-tomcat-5.5.23" targetdir="$

{INSTALL_PATH}/tomcat">
<include name="*/" />
</fileset>
<!--
<file src="apache-tomcat-5.5.23" targetdir="${INSTALL_PATH}

/tomcat" />
-->
</pack>
<pack name="Core" required="yes" id="cd.core">
<description>The core app</description>
<file src="coreapp.war" targetdir="$

{INSTALL_PATH}/tomcat/webapps" condition="izpack.selected.tomcat.core" />
<file src="coreapp.war" targetdir="${INSTALL_PATH}

/war" condition="!izpack.selected.tomcat.core" />
</pack>
</packs>



 Comments   
Comment by Dennis Reil [ 27/Jan/09 ]

Backreferenced file will not lead to skipping bytes in the input stream anymore. They are just skipped and the next packfile is taken.





[IZPACK-271] The same help is displayed on each UserInputPanel Created: 27/Jan/09  Updated: 17/Feb/09  Resolved: 01/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.0
Fix Version/s: 4.2.1

Type: Bug Priority: Major
Reporter: Florian Buehlmann Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File PanelHelps.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

If there are multiple UserInputPanels and each panel has it's own helps registered the helps would not displayed correctly.
The name of the help resources are built with the ClassName but this is the same for each UserInputPanel.
It would be usefuel to use the panel id if exist. Otherwise use a panel counter to build unique resource names.






[IZPACK-270] Using multiple HTMLInfoPanel fails (using ID) Created: 25/Jan/09  Updated: 11/Feb/09

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

Type: Bug Priority: Major
Reporter: Robert Jan van der Waals Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP


Number of attachments : 0

 Description   

I have tried using multiple HTMLInfoPanels each having a separate ID like so:

<resources>
<res id="HTMLInfoPanel.donate" src="donate.html"/>
<res id="HTMLInfoPanel.readme" src="readme.html"/>
</resources>

<panels>
<panel classname="HTMLLicencePanel" id="donate" />
<panel classname="HTMLLicencePanel" id="readme" />
</panels>

This failed, showing empty pages for both panels. Changing the code like below does work but does not allow me to use multiple HTMLInfoPanels:

<resources>
<res id="HTMLInfoPanel.info" src="readme.html"/>
</resources>

<panels>
<panel classname="HTMLLicencePanel" />
</panels>



 Comments   
Comment by Anthonin Bonnefoy [ 06/Feb/09 ]

Hello Robert,
I tried to use multiple HTMLInfoPanel and it worked without problems.
Did you mean
<panels>
<panel classname="HTMLInfoPanel" id="donate" />
<panel classname="HTMLInfoPanel" id="readme" />
</panels>
instead of
<panels>
<panel classname="HTMLLicencePanel" id="donate" />
<panel classname="HTMLLicencePanel" id="readme" />
</panels>
?
Can you give more informations on your problems?
Thanks in advance.

Comment by Earl Hood [ 11/Feb/09 ]

I get the same problem. The following is a snippet of the installation
file I use. In this example, I only create a single HTMLInfoPanel, but
try to use the id attribute:

<resources>
<res id="CustomLangpack.xml_eng"
src="install/langpack.eng.xml"/>
<res id="shortcutSpec.xml"
src="install/Win_shortcutSpec.xml"/>
<res id="HTMLInfoPanel.copyright"
src="install/install-info.html"/>
<res id="HTMLLicencePanel.licence"
src="install/license.html"/>
<res id="TargetPanel.dir.windows"
src="install/default-dir-win.txt"/>
<res id="TargetPanel.dir.unix"
src="install/default-dir-unix.txt"/>
</resources>

<panels>
<panel classname="HelloPanel"/>
<panel classname="HTMLInfoPanel" id="copyright"/>
<panel classname="HTMLLicencePanel"/>
<panel classname="TargetPanel"/>
<panel classname="PacksPanel"/>
<panel classname="ShortcutPanel"/>
<panel classname="SummaryPanel"/>
<panel classname="InstallPanel"/>
<panel classname="SimpleFinishPanel"/>
</panels>

When executed from the command-line, the following exception:

com.izforge.izpack.installer.ResourceNotFoundException: Cannot find named Resource: '/res/HTMLInfoPanel.info' AND '/res/HTMLInfoPanel.info_eng'
at com.izforge.izpack.installer.ResourceManager.getLanguageResourceString(Unknown Source)
at com.izforge.izpack.installer.ResourceManager.getURL(Unknown Source)
at com.izforge.izpack.panels.HTMLInfoPanel.loadHTMLInfoContent(Unknown Source)
at com.izforge.izpack.panels.HTMLInfoPanel.<init>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at com.izforge.izpack.installer.InstallerFrame.loadPanels(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.<init>(Unknown Source)
at com.izforge.izpack.installer.GUIInstaller.loadGUI(Unknown Source)
at com.izforge.izpack.installer.GUIInstaller.access$100(Unknown Source)
at com.izforge.izpack.installer.GUIInstaller$2.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
java.io.IOException: invalid url
at javax.swing.JEditorPane.setPage(JEditorPane.java:393)
at com.izforge.izpack.panels.HTMLInfoPanel.<init>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at com.izforge.izpack.installer.InstallerFrame.loadPanels(Unknown Source)
at com.izforge.izpack.installer.InstallerFrame.<init>(Unknown Source)
at com.izforge.izpack.installer.GUIInstaller.loadGUI(Unknown Source)
at com.izforge.izpack.installer.GUIInstaller.access$100(Unknown Source)
at com.izforge.izpack.installer.GUIInstaller$2.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

This was executed against IzPack 4.2.0, using standalone-compiler.jar.

Attempting multiple panels do not work either.





[IZPACK-269] Java process is not existing correctly if installer requirement feature is used Created: 23/Jan/09  Updated: 17/Feb/09  Resolved: 01/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.1.1
Fix Version/s: 4.2.1

Type: Bug Priority: Major
Reporter: Martin Wesemann Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP Professional


Attachments: Text File InstallerFrame.java.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The IzPack installer is not exiting correctly if the condition of an installer requirement evaluates to false. This is caused by the class InstallerFrame that does not shutdown the application explicitly. Instead the current function running in main thread ends but the already created event dispatched thread prevents the application from exiting.



 Comments   
Comment by Julien Ponge [ 25/Jan/09 ]

Sorry, but this patch does not apply on the current versions of the source code, and I could not find a match in InstallerFrame.

Comment by Martin Wesemann [ 26/Jan/09 ]

Yes it looks like it is fixed in the current version of the source tree. Method "checkInstallerRequirements()" is now placed in class "InstallerBase" and called in class "GUIInstaller". The method stops the application by calling "System.exit" if "checkInstallerRequirements()" evaluates to fales. But I expected that the application has to be stopped with "Housekeeper.shutdown()".





[IZPACK-268] look and feel = nimbus shows bad layouted dialog Created: 22/Jan/09  Updated: 21/Aug/12  Resolved: 21/Aug/12

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

Type: Bug Priority: Minor
Reporter: Lars Fischer Assignee: Tim Anderson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP with classic desktop styling, JRE 1.6_11, izpack 4.2.1-SNAPSHOT


Attachments: PNG File izpack-nimbus.png     PNG File izpack-nimbus-treepackpanel.png    
Number of attachments : 2

 Description   

trying to use

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

results in a bad looking question-dialog after choosing the install target. (look at attached image)



 Comments   
Comment by Lars Fischer [ 22/Jan/09 ]

TreePacksPanel also shows some error (look at second screen shot)

Comment by Tim Anderson [ 18/Aug/12 ]

I've updated the compiler and installer to reference the nimbus l&f classes included since JDK6 update 10.
This appears to correct layout problems.

Fix is at https://github.com/izpack/izpack/pull/60





[IZPACK-267] Add check to make sure user add izpack-standalone-compiler dependency to both project and plugin's dependencies list Created: 21/Jan/09  Updated: 22/Jan/09  Resolved: 21/Jan/09

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

Type: Improvement Priority: Major
Reporter: Dan Tran Assignee: Dan Tran
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   

the one in project's dependencies allows user to compile their izpack's related source

the one under build's plugin's dependencies is to build the user installer and skeleton files are copied over to user installer



 Comments   
Comment by Dan Tran [ 21/Jan/09 ]

better to document it





[IZPACK-266] Functionality to append new value to an existing registry value causes registry value to grow Created: 20/Jan/09  Updated: 20/Jan/09

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

Type: Improvement Priority: Minor
Reporter: Martin Wesemann Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP Professional


Attachments: Java Source File Win_RegistryHandler.java    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

There has been introduced a new functionality into the registry manipulation functionality tracked by issue IZPACK-112. This functionality allows it to append a new value to an existing registry value. This may be used to extend the windows PATH variable. This works fine as long the user is not installing the application over an existing installation without previously uninstalling it. In this case the Windows PATH variable is growing for each installation and contains duplicate entries.

I made a change to Win_RegistryHandler.java to search for existing entries in the given registry value if the $OLD_KEY_VALUE variable is given and do only appending the new value if it is not already there Currently this fix works really well but there are some drawbacks for the application design.

Design Issue:

  • This change is specific for manipulating Windows PATH variable structures placed in a class and function (Win_RegistryHandler.setValue()) doing general registry string value manipulation .

Functionality Issue:

  • This change will change the previous behavior and the user is not able to configure if it shall replace existing values or if it shall just append the given value. Maybe another attribute is needed to give control about it to the user in the registry spec.





[IZPACK-265] Installation of loose pack throws EndOfFileException Created: 19/Jan/09  Updated: 17/Feb/09  Resolved: 01/Feb/09

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

Type: Bug Priority: Critical
Reporter: Florian Buehlmann Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File LoosePackEOFException.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

During the installation of loose pack a EOFileException is thrown.
This happens if there are multiple filesets for different os like the following pack:

<pack name="MyPack" id="my.pack.id" required="yes" preselected="yes" loose="true">
<description/>
<fileset dir="../resources/win32" targetdir="$INSTALL_PATH/lib">
<os family="windows" arch="x86"/>
<include name="**"/>
</fileset>
<fileset dir="../resources/win64" targetdir="$INSTALL_PATH/lib">
<os family="windows" arch="amd64"/>
<include name="**"/>
</fileset>
</pack>

The effective problem is created during compile of the pack. If it is a file of loose pack the file size is not set to zero.
During installation of such a file we try to skip n bytes of the inputStream (see Unpacker.java:141) but the file is not included in the stream.






[IZPACK-264] Capitalization leads to ClassNotFound exception in com.izforge.izpack.rules.RulesEngine.java when using XOr condition Created: 19/Jan/09  Updated: 17/Feb/09  Resolved: 01/Feb/09

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

Type: Bug Priority: Major
Reporter: Boaz Harel Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Number of attachments : 0

 Description   

line 187 (below) turns the conditiontype to lowercase, followed by 189 that turns the first letter to uppercase. This works for most conditions, but fails for com.izforge.izpack.rules.XOrCondition.java. The string resulting from this code is XorCondition, and the compiler throws a ClassNotFound Exception.

185 else

{ 187 String conditiontype = condtype.toLowerCase(); conditionclassname = "com.izforge.izpack.rules." 189 + conditiontype.substring(0, 1).toUpperCase() + conditiontype.substring(1, conditiontype.length()); conditionclassname += "Condition"; 192 }

I kludged this together by adding this line at the end:
192 if (conditionclassname.equals("com.izforge.izpack.rules.XorCondition")) conditionclassname="com.izforge.izpack.rules.XOrCondition";

but this is clearly not a solution. Perhaps re-factoring the class name to XorCondition would be best, to conform to the naming convention.



 Comments   
Comment by Dennis Reil [ 20/Jan/09 ]

I replaced XOrCondition with XorCondition. Thus, the CNF exception should be avoided.





[IZPACK-263] Allows the configuration of the path where the uninstaller is written to Created: 19/Jan/09  Updated: 20/Apr/09  Resolved: 22/Jan/09

Status: Closed
Project: IzPack
Component/s: Compiler, Installer
Affects Version/s: 4.2.0, 4.3.0
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Florian Buehlmann Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File UninstallPath_Code.patch     Text File UninstallPath_Doc.patch    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

For the moment it is only possible to customize the name of the uninstaller (jar file name).
It would be nice if a user can customize the path where the uninstaller file is written to.
This could be configured like the following <info> entry:
<uninstaller name="uninstaller.jar" path="$NSTALL_PATH/app_remover">yes</uninstaller>



 Comments   
Comment by Julien Ponge [ 20/Jan/09 ]

I agree with the proposed new feature, but the patch needs to be improved:

  • with an update to the documentation in src/doc-reST
  • if possible, a reformating with curly braces on the next line so as to match our prefered code style.
Comment by Florian Buehlmann [ 21/Jan/09 ]

Attached two patches. The DOC patch includes the documentation changes.
The CODE patch is a reformated patch that should only include the needed changes to the code with the right formating.

Comment by Florian Buehlmann [ 21/Jan/09 ]

I removed the first patch file because it was badly formated code and contained to much changes.





[IZPACK-262] Conditions on panels are not respected on automated installation Created: 19/Jan/09  Updated: 11/May/12  Resolved: 01/Feb/09

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

Type: Bug Priority: Major
Reporter: Patrick Zbinden Assignee: Dennis Reil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any


Attachments: Text File IzPack_AutoInstallCondition_Patch_2.txt     Text File IzPack_AutoInstallCondition_Patch.txt    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

In automated installation, Panels are executed in every case, if conditions are used or not.
Installer should respect also conditions on panels, see attached patch.



 Comments   
Comment by Dennis Reil [ 20/Jan/09 ]

Applied a slightly modified version of Patricks patch.

Comment by Patrick Zbinden [ 20/Jan/09 ]

Recognized a problem, that now occured (in case of UserInputPanel, panelCounter was not incremented).
Fixing this with the patch, that I will attach.

Comment by Patrick Zbinden [ 20/Jan/09 ]

Incrementing panelInstanceCount, when skipping panel, see attached patch.

Comment by Dennis Reil [ 22/Jan/09 ]

applied the patch from Patrick Zbinden

Comment by Thomas Demande [ 08/May/12 ]

Doesn't work if condition is specified inside a separate conditions.xml file, with the <panelcondition> element.

if (p.hasCondition()
                   && !this.idata.getRules().isConditionTrue(p.getCondition(),
                               this.idata.variables))

should be replaced by

if (!idata.getRules().canShowPanel(p.getPanelid(), idata.getVariables()))
Comment by Julien Ponge [ 10/May/12 ]

Fancy a patch / pull request?

Comment by Thomas Demande [ 11/May/12 ]

Here you are: https://github.com/jponge/izpack/pull/18





[IZPACK-261] izpack2app - __file__ variable not found Created: 18/Jan/09  Updated: 17/Feb/09  Resolved: 01/Feb/09

Status: Closed
Project: IzPack
Component/s: Utilities
Affects Version/s: 4.2.0
Fix Version/s: 4.2.1

Type: Bug Priority: Major
Reporter: Roland Assignee: Julien Ponge
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Vista


Attachments: JPEG File izpack2exe.jpg    
Number of attachments : 1

 Description   

Running izpack2app from command line produces the following error (see pic below). I ran it from admin shell in Windows Vista. Any help would be appreciated.



 Comments   
Comment by Jason Halvorson [ 21/Jan/09 ]

The izpack2app.py seems to work fine for me. It is only the .exe file that is failing. I'm using Python 2.6.1 on XP.

Comment by Julien Ponge [ 29/Jan/09 ]

Fixed by replacing _file_ with sys.argv[0]





[IZPACK-260] Relative directories starting with ".." will not be recognized as relative this throws NullPointer Exception during installation Created: 16/Jan/09  Updated: 17/Feb/09  Resolved: 01/Feb/09

Status: Closed
Project: IzPack
Component/s: Compiler
Affects Version/s: 4.2.0, 4.3.0
Fix Version/s: 4.2.1

Type: Bug Priority: Major
Reporter: Florian Buehlmann Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File CalculateRelativePathCorrection.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

We have a definition of a pack like the following:
<pack name="MyPack" id="pack.mypack.id" required="yes" preselected="yes" loose="true">
<description/>
<fileset dir="../my/pack" targetdir="$INSTALL_PATH/MyPack">
<include name="**"/>
</fileset>
</pack>

During installation we get a NPE when try to install MyPack. After a bit of debugging I found a little bug during compilation of loose packs. If a path is starting with "../" is is not recognized as a relative path and the relativePath variable in the PackFile instance is set to null.

See attached patch how to fix this problem.






[IZPACK-259] On UserInputPanel only the LocaleDatabase form userInputLang.xml resource is available Created: 15/Jan/09  Updated: 17/Feb/09  Resolved: 01/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.0, 4.3.0
Fix Version/s: 4.2.1

Type: Improvement Priority: Minor
Reporter: Florian Buehlmann Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File UserInputPanle_LocaleDatabase.patch    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

On every UserInputPanel only the strings from userInputLang.xml are available. There is no way to use common IzPack strings on these panels.

The attached patch makes it possible to use strings form userInputLang.xml or from the common and custom IzPack language files.
The standard language files will be loaded first all strings defined in userInputLang.xml with the same id overrides the standard strings.






[IZPACK-258] Validators for packs Created: 12/Jan/09  Updated: 20/Apr/09  Resolved: 03/Feb/09

Status: Closed
Project: IzPack
Component/s: Compiler, Panels
Affects Version/s: 4.2.0
Fix Version/s: 4.3.0

Type: New Feature Priority: Major
Reporter: Kjell Braden Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File izpack_packsvalidator.diff     File izpack_packsvalidator.new.diff    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

I've several packs in my installer, and I would like to be able to run some
verifying tasks after one of them was selected. Something along the lines of:

  1. $user selects $special_pack and clicks "Next" in the PacksPanel.
  2. The installer checks the registry and notices that something similar to $special_pack is already installed.
  3. The installer asks the user whether to really install $special_pack.
  4. Now either...
    1. User selects no and $special_pack will not be installed or
    2. User selects yes and... you guessed it.

Some days ago I asked for this on the -user mailing list, but since I got no response, I decided to implement this myself. Attached you can find a patch which implements running validators for each pack.

How it works:

  1. You specify a validator-element for the pack you want to validate:
    <packs>
      <pack name="Something" [...]>
        <validator>my.Validator</validator>
        [...]
      </pack>
    </packs>
    
  2. You create a java class called my.Validator with a static method validate:
    package my
    public class Validator {
      public static boolean validate(AbstractUIHandler handler,
                InstallData idata, String packsId, boolean isSelected) {[...]};
    }
    
  3. You merge the class above into the installer.jar using the <mergejar>-Element in your xml.


 Comments   
Comment by Julien Ponge [ 28/Jan/09 ]

I approve this change to be merged into IzPack, pending an update of the patch with appropriate changes tp the documentation (see src/doc-resST).

Comment by Kjell Braden [ 02/Feb/09 ]

Please find attached the new version of the patch. Changes are: I'm now using an interface for the PacksValidator class. Documentation was added.





[IZPACK-257] New 'saveprevious' attribute in registry spec Created: 10/Jan/09  Updated: 20/Apr/09  Resolved: 03/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.0
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Eric Thomas Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File consolidated.patch     Zip Archive RegistryHandler_saveprevious.zip    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

On a Windows install/uninstall, the current behavior with the registry is to save a snapshot of the affected values before the install and then restore them after the uninstall. This behavior runs into trouble when an install is performed on top of an existing installation (which is commonly done to "refresh" files and update programs). The previous snapshot is lost and the second snapshot ends up containing values from the previous install, resulting in bogus values being left behind after the uninstall.

To address this, I've implemented an optional 'saveprevious' attribute in the '<value>' element of the registry specification. Here is documentation for "custom-actions.html#value-define-a-value" (place after description for 'override'):

saveprevious : optional. Save the previous value or not. Valid is "true" or "false", default is "true". Setting to "false" can result in better uninstall behavior when an install is performed on top of an existing installation.



 Comments   
Comment by Julien Ponge [ 28/Jan/09 ]

I approve this change to be applied in IzPack.

I have consolidated the proposed changes in a single patch that is available for review.





[IZPACK-256] Vista shortcuts bug workaround Created: 10/Jan/09  Updated: 17/Feb/09  Resolved: 11/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.0
Fix Version/s: 4.2.1

Type: Bug Priority: Major
Reporter: Eric Thomas Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ShellLink_shortcutWorkaround_patch.txt     Zip Archive ShellLink_shortcutWorkaround.zip    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

There's a weird bug in Windows Vista where, under some circumstances, shortcut files that are saved to a current-user location end up in an all-users location. I only see it happen when an installer is packaged in an 'izpack2exe'-wrapper executable. It doesn't seem to happen when an installer jar is executed directly. (I need the wrapper, though, because I'm putting "installer.exe" in the name to trigger Vista privileged-rights elevation.) When the shortcuts end up in the wrong location, they are left behind by the uninstaller.

I've debug-checked the IzPack code all the way into the native functions, and the IzPack code is attempting to save into the proper location. Given that the problem is in Windows Vista, the best workaround I've come up with is to modify 'ShellLink.save()' to make it test for the errant location and move the target file to the proper location as needed. The last-modified time of the target file is checked to make sure that it was just created, so there should be no chance of any wrong behavior from the workaround.



 Comments   
Comment by Julien Ponge [ 14/Jan/09 ]

I would agree with the proposed solution, however I would appreciate if somebody that worked on the shortcuts things (Elmar, Marc?) could also have a look.

Comment by Julien Ponge [ 11/Feb/09 ]

Thanks!





[IZPACK-255] New 'labelFontSize' modifier in 'guiprefs' Created: 10/Jan/09  Updated: 20/Apr/09  Resolved: 12/Feb/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.0, 4.3.0
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Eric Thomas Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive guiprefs_LabelFontSize.zip     Text File labelFontSize_patches.txt    
Patch Submitted:
Yes
Number of attachments : 2

 Description   

The attached patches add support for a 'labelFontSize' modifier in the 'guiprefs' element. Here is documentation for "advanced-features.html" (place after description for 'useLabelIcons'):

'labelFontSize': A float value used as a multiplier for the font size on labels created via the LabelFactory and IzPanel. Directly created labels are not affected.



 Comments   
Comment by Julien Ponge [ 11/Jan/09 ]

Why not... however isn't there a risk to have weird GUIs where some fonts are scaled and others don't?

Would you be able to attach some screenshots of IzPack installers to demonstrate that?

Comment by Julien Ponge [ 28/Jan/09 ]

Eric, I have decided not to merge this patch, sorry.

Comment by Eric Thomas [ 29/Jan/09 ]

Without the ability to increase the font size, the text on many prompts is tiny on systems with mid-to-large screen resolution. The resulting presentation on the GUI is poor and unprofessional, IMO. I fail to see what you classify as a "risk" – the new modifier is optional, so if a developer is concerned about scaling issues then they can simply not use it. I see no harm in this enhancement, and no other way (that I can find) to improve the font size on these prompts. It's operation is similar to the existing 'useLabelIcons' modifier.

Comment by Julien Ponge [ 29/Jan/09 ]

Thanks for the clarification, I will have another look.

Comment by Julien Ponge [ 12/Feb/09 ]

Merged!

Thanks Eric.

Comment by Eric Thomas [ 12/Feb/09 ]

Thanks for merging in my mods.





[IZPACK-254] New ShowCreateDirectoryMessage variable Created: 10/Jan/09  Updated: 20/Apr/09  Resolved: 14/Jan/09

Status: Closed
Project: IzPack
Component/s: Installer, Panels
Affects Version/s: 4.2.0
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Eric Thomas Assignee: Julien Ponge
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive PathInputPanel_ShowCreateDirMsg.zip    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The attached patch adds a 'ShowCreateDirectoryMessage' variable, which may be used to suppress the "target directory will be created" dialog. Here is documentation for "panels.html#targetpanel":

The 'ShowCreateDirectoryMessage' variable may be used to suppress the "target directory will be created" dialog. If the 'ShowCreateDirectoryMessage' variable is set to "false" then the dialog will not be shown. If the 'ShowCreateDirectoryMessage' variable is set to "true" or is not specified then the dialog will be shown if the target directory does not exist. See the "Variables Element" section for information on how to specify variables.



 Comments   
Comment by Julien Ponge [ 11/Jan/09 ]

Nice to have, and I'm sure lots of people will like it





[IZPACK-253] ShortcutPanel 'defaultCurrentUser' element Created: 10/Jan/09  Updated: 20/Apr/09  Resolved: 14/Jan/09

Status: Closed
Project: IzPack
Component/s: Installer, Panels
Affects Version/s: 4.2.0, 4.3.0
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Eric Thomas Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive ShortcutPanel_defaultCurrentUser.zip    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The attached patch adds support for a 'defaultCurrentUser' element to be used with the 'ShortcutPanel' specification. Here is documentation for "desktop-shortcuts.html" (place after description for "<skipIfNotSupported/>"):

<defaultCurrentUser/> may be specified to make "current user" be the default selection on the panel. If not specified then "all users" will be the default selection (if available).



 Comments   
Comment by Julien Ponge [ 11/Jan/09 ]

I agree for this improvement to be made.

Any comment?





[IZPACK-252] HTMLHelloPanel and variable parsing Created: 10/Jan/09  Updated: 20/Apr/09  Resolved: 14/Jan/09

Status: Closed
Project: IzPack
Component/s: Installer
Affects Version/s: 4.2.0
Fix Version/s: 4.3.0

Type: New Feature Priority: Major
Reporter: Eric Thomas Assignee: Julien Ponge
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive HTMLHelloPanel.zip    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The attached patches and source file add an 'HTMLHelloPanel', and add support for variable parsing in the 'HTMLInfoPanel'. Optional 'resPrefixStr' and 'showInfoLabelFlag' parameters are added to the 'HTMLInfoPanel' constructor for use by the 'HTMLHelloPanel' subclass. Also, a call to 'textArea.setCaretPosition(0)' to is put in to make the display start at the top of the document. Here is documentation for "panels.html":

HTMLHelloPanel
This panel allows an HTML document to be used as the "welcome" panel. It operates like the 'HTMLInfoPanel', except that the resource name "HTMLHelloPanel" is used (i.e., "HTMLHelloPanel.info").



 Comments   
Comment by Julien Ponge [ 11/Jan/09 ]

I would agree for this patch to be merged. I have tested and it properly displays images referenced by their resource id, which was quite important not to break.

Any other developer opinion on this one?

To Eric: it would be easier if your patches were uploaded as a single diff rather than a ZIP with diffs, original files, changed files and so on.

Comment by Eric Thomas [ 11/Jan/09 ]

OK. When multiple IzPack source modules are patched in a given mod, would you rather have multiple "...patch.txt" files or a single "patch.txt" file covering all the patched modules?

Comment by Julien Ponge [ 11/Jan/09 ]

Yes, we'd rather have just 1 patch file as it makes it easier to handle.

See IZPACK-240 for instance.

Thanks a lot.

Comment by Julien Ponge [ 14/Jan/09 ]

Thanks a lot!





[IZPACK-251] Parsing application version from program-source file Created: 10/Jan/09  Updated: 22/Jan/09  Resolved: 14/Jan/09

Status: Closed
Project: IzPack
Component/s: Compiler
Affects Version/s: 4.2.0, 4.3.0
Fix Version/s: 4.3.0

Type: Improvement Priority: Major
Reporter: Eric Thomas Assignee: Julien Ponge
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive CompilerConfig_parseVerFromSrc.zip    
Patch Submitted:
Yes
Number of attachments : 1

 Description   

The attached patch adds support for parsing the application version value from a program-source file. Here is modified documentation for "installation-files.html":

<appversion> : the application version. The version value may be specified directly, or it can be parsed from an application source file via the following attributes:
specSourceFile : path and name of file to be parsed.
specMatchString : match string of characters before version value.
After the match string, spaces, an equals sign, and surrounding double-quotes will be removed (if found). Example usage:
<appversion specSourceFile="../lib/com/izforge/izpack/compiler/Compiler.java"
specMatchString="public final static String IZPACK_VERSION"/>



 Comments   
Comment by Julien Ponge [ 11/Jan/09 ]

I am not very convinced by the usefulness of this feature.

Why not simply use text substitution mechanisms as found in Ant or Maven to replace strings in your installer XML descriptor, Java classes and more?

Comment by Eric Thomas [ 11/Jan/09 ]

I use JBuilder, so ant/maven is not available for text substitution. The VERSION definition in my application source file controls the program version, so this patch allows me to set the version value in just one place (the same place I always have). I think that simply setting the version value in a source file is pretty common out there.

Comment by Julien Ponge [ 14/Jan/09 ]

I take the decision of rejecting the proposed change, sorry...





[IZPACK-250] ProcessPanelWorker: Passing JobList to the handler Created: 09/Jan/09  Updated: 30/Jan/09  Resolved: 30/Jan/09

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

Type: Wish Priority: Major
Reporter: Patrick Zbinden Assignee: Julien Ponge
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any


Attachments: Text File IzPack_ProcessingJobs_Patch.txt     Text File IzPack_ProcessPanel_Patch2.txt     Text File IzPack_ProcessPanel_Patch.txt    
Patch Submitted:
Yes
Number of attachments : 3

 Description   

We have our own implementation of ProcessPanel extended from standard IzPack ProcessPanel.
We would like to show a List of the JobNames to the user, before the jobs started. Therefore we need to have the possibility to get the JobList.

Would it be a problem for you to for example replace startProcessing(int no_of_jobs) to startProcessing(List<ProcessingJob> jobList) ?

See attached patch.



 Comments   
Comment by Julien Ponge [ 09/Jan/09 ]

I think you forgot to attach the patch

Comment by Patrick Zbinden [ 09/Jan/09 ]

Oops, sorry. Here we go

Comment by Julien Ponge [ 11/Jan/09 ]

The change is not intrusive indeed, but what is the point of merging it?

It would make sense if we also had your extended ProcessPanel

Comment by Patrick Zbinden [ 12/Jan/09 ]

It's quite compicated, because we have a lot of dependencies. But I tried to do it, as you can see in attached Patch.
As you can see there, we show all the jobs, that have to be done. That's the reason we need the jobs (or job names) before the start.

Have a look at it and please tell me your decision.

Comment by Julien Ponge [ 28/Jan/09 ]

Patrick, I have decided not to include the patch, sorry.

Comment by Patrick Zbinden [ 29/Jan/09 ]

Ok, I can understand your decision.
But would it be a big problem to you, if ProcessPanelWorker would give the handler a list of Strings with the job names?
for example by a method loadProcessNames(List<String> jobNames) called at the end of readSpec?

Please have a look at the patch, that I'll attach in a minute.

Comment by Patrick Zbinden [ 29/Jan/09 ]

Here's the patch I mentioned before.

Comment by Julien Ponge [ 29/Jan/09 ]

Problem is that your patch adds useless code in IzPack...

Is this really difficult for you to maintain your patch on top of IzPack? I don't think that you'll get frequent conflicts. You may also have a look a DVCS like Git to handle it (I maintain an IzPack git repo on github so that would be really easy to follow).

Cheers

Comment by Patrick Zbinden [ 30/Jan/09 ]

Hi Julien
No, it's not a big thing to maintain our patch.
But I thought, it could also be interesting for other people to give the possibility to show the job names, before the jobs start.
This gives people the possiblity to show not only how many, but also which jobs are going to be executed.
For example, if you have a job that runs a very long time, people would see that and can plan how long the installation will have.

That's the point, why we want to show the job names before they start.

If you don't want to give this possiblity, please close this issue, I won't open it again

Comment by Julien Ponge [ 30/Jan/09 ]

Hi Patrick,

I'm closing the issue (no offense!).

Do not hesitate to propose other changes though, as the acceptance / rejection is on a case-by-case basis





[IZPACK-249] izpack-standalone-compiler does not have all needed classes Created: 09/Jan/09  Updated: 17/Feb/09  Resolved: 01/Feb/09

Status: Closed
Project: IzPack
Component/s: Compiler
Affects Version/s: 4.0.1, 4.1.0, 4.1.1, 4.2.0, 4.3.0
Fix Version/s: 4.2.1

Type: Bug Priority: Major
Reporter: Dan Tran Assignee: Dan Tran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File IZPACK-249.patch    
Number of attachments : 1

 Description   

izpack-standalone-installer currently has a bunch of classes excluded from root, but place one one of those inner jar

http://www.nabble.com/no-InstallListener-in-maven-dependency-izpack-standalone-compiler-td21353479.html



 Comments   
Comment by Dan Tran [ 09/Jan/09 ]


this is really a blocking issue for maven user

Comment by Dan Tran [ 09/Jan/09 ]

hi team, any objection about me placing event jar's classes to standalone package, is there any thing else I missed?

Comment by Julien Ponge [ 09/Jan/09 ]

No objection, but you may send an email to dev@(...), as I am not sure everyone is actively monitoring JIRA notifications.

Comment by Dan Tran [ 09/Jan/09 ]

attached is one liner change patch

Comment by Julien Ponge [ 09/Jan/09 ]

+1

Comment by Dan Tran [ 09/Jan/09 ]

added and deploy a new izpack-standalone-snapshot-4.2.1-SNAPSHOT to codehaus's snapshot repo

Revision: 2466
Author: dantran
Date: 1:15:19 PM, Friday, January 09, 2009
Message:
IZPACK-249: add izevent.jar's classes to standalone-compiler.jar


Modified : /izpack-src/trunk/src/build.xml

waiting for user's feedback before closing it

Comment by Lars Fischer [ 12/Jan/09 ]

new 4.2.1-SNAPSHOT works for me to compile with a previously missing class





Generated at Thu May 14 08:18:47 CDT 2015 by Rene Krell using JIRA 6.1.6#6162-sha1:7af547ce7c84dbb7c1e345a65437ed7b85efffa2.