[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] 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: |
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: |
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:
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: |
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: 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: ------------------------------------------------------------------------------------------------------------ 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: |
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: | 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 |
Comments |
Comment by Rene Krell [ 12/May/15 ] |
Did you run the installer with the according permissions, like root? |
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. |
Comment by Rene Krell [ 11/May/15 ] |
Sent pull request #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: | 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: 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. |
[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:
|
[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:
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: | installer.xml |
Number of attachments : | 1 |
Description |
When defining a pack, you can include files with three different definitions:
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:
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:
|
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. |
[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: |
|
||||||||||||
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 |
Comment by Aitor Sánchez [ 12/Mar/15 ] |
This ticket seems to be related with the issue |
Comment by Rene Krell [ 19/Mar/15 ] |
PR #329 merged. |
[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: |
|
||||||||
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:
|
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: | installer.PNG 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. |
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' 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. 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. |
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. |
[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? |
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. |
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. |
Comment by Rene Krell [ 05/Mar/15 ] |
Merged according PR https://github.com/izpack/izpack/pull/325 |
[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. |
[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 |
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 linux,version=null,arch=unknown,symbolicName=null,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactoryTest$L windows,version=null,arch=unknown,symbolicName=null,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactoryTest debian_linux,version=null,arch=unknown,symbolicName=null,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactor windows,version=6.1,arch=unknown,symbolicName=WINDOWS_7,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactory windows,version=null,arch=x64,symbolicName=null,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactoryTest$Win windows,version=null,arch=x86,symbolicName=null,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactoryTest$Win windows,version=6.1,arch=x64,symbolicName=WINDOWS_7,javaVersion=null=com.izforge.izpack.util.DefaultTargetPlatformFactoryTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec +++ 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 java.io.FileNotFoundException: D:\Sumeet\Wawanesa\PRASE%20Build%20POC\IzPack\SourceCode\izpack\izpack-util\target\test-classe 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! Results : Failed tests: Tests in error: Tests run: 22, Failures: 1, Errors: 1, Skipped: 0 [INFO] ------------------------------------------------------------------------ Please refer to D:\Sumeet\Wawanesa\PRASE Build POC\IzPack\SourceCode\izpack\izpack-util\target\surefire-reports for the indiv Please refer to D:\Sumeet\Wawanesa\PRASE Build POC\IzPack\SourceCode\izpack\izpack-util\target\surefire-reports for the indiv |
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, |
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:
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. |
[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: |
|
||||||||
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. 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: |
|
||||||||||||
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 2. 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" |
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: |
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). |
Comment by Rene Krell [ 19/Mar/15 ] |
PR #332 merged. |
[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: |
|
||||||||
Number of attachments : | 0 |
Description |
There should be a possibility to interrupt a running target and waiting for a user response. |
[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> |
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 ? |
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. |
[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. 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: |
|
||||||||||||||||
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 above items could be ideally added as feature, maybe having its descriptor or even source code (Maven module) completely separated. A feature should be defined as one block of XML in install.xml and might consist of:
The implementation should then plug into a given API which is still to define. Plugin points could be:
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. This issue is still an open discussion.
|
Comments |
Comment by Rene Krell [ 02/Feb/15 ] |
I'm thinking about a small-sized OSGI framework fulfilling many of the above points. 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: | installer.xml test-IZPACK-1216-5.0.0-rc4.jar test-IZPACK-1216-5.0.0-rc5-SNAPSHOT-with-IZPACK1215.jar test-IZPACK-1216-5.0.0-rc5-SNAPSHOT-with-IZPACK1216.jar | ||||||||
Issue Links: |
|
||||||||
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- As expected the refresh() does terminate, but the value of var5 is stable not before the second DataCheckPanel. test- The refresh() does terminate with a loop detection |
Comment by Tom Helpstone [ 02/Feb/15 ] |
test- 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: | InstallerTest-before-IZPACK-1215.jar InstallerTest-with-IZPACK-1215.jar installer.xml | ||||||||
Issue Links: |
|
||||||||
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- After Implementing |
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: |
|
||||||||
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 ] |
Comment by Rene Krell [ 30/Jan/15 ] |
Pull request #308 merged. |
[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> 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 |
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: <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. |
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: |
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 |
Number of attachments : | 0 |
Description |
Attempting to build izpack from master results in the following errors: 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: |
Comment by Rene Krell [ 19/Jan/15 ] |
Pull request https://github.com/izpack/izpack/pull/302 merged. |
[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 The end tag "natives" miss "/" http://docs.codehaus.org/pages/viewpage.action?pageId=230398039 : The correct call to the listener seems to be : |
Comments |
Comment by Rene Krell [ 06/Jan/15 ] |
Thank you. 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: |
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: |
|
||||||||||||
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. 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: |
|
||||||||||||||||
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: |
|
||||||||||||
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: |
|
||||||||
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. <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. |
[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: |
|
||||||||
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. Update: Further changes which might also break existing environments:
|
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: |
|
||||||||
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: |
|
||||||||||||||||
Number of attachments : | 0 |
Description |
This issue is some kind of refinement of Miles' issue 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:
Unfreezing variables:
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: |
|
||||||||||||||||||||||||||||
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: | executablebug.txt |
Number of attachments : | 1 |
Description |
Using both forms of the executable statement, the program does not get executed. |
[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: |
|
||||||||||||
Number of attachments : | 0 |
Description |
This issue enhances the introduced read-only fields and panels from issue 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 UserInputSpec.xml: Introduced by <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 <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. |
[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: |
|
||||||||
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. |
[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: | install.xml 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. <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. |
Comment by Ron Wheeler [ 16/Jan/15 ] |
Thanks. Fixed my problem |
[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 |
[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: |
|
||||||||||||
Number of attachments : | 0 |
Description |
<laf name="konststoff"> causes a NullPointerException <laf name="kunststoff"> 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: |
|
||||||||
Number of attachments : | 0 |
Description |
<laf name="metal"> |
Comments |
Comment by Rene Krell [ 19/Jan/15 ] |
Duplicate of |
[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: |
|
||||||||
Number of attachments : | 0 |
Description |
<laf name="aqua"> [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-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"> |
[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"> |
[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: | install.xml laf_blog_error_log.txt |
Number of attachments : | 2 |
Description |
When install.xml includes When the laf section is removed, the installer runs. I could not get |
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. <guiprefs width="800" height="600" resizable="no"> |
[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"/> |
[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. |
Comments |
Comment by Tom Helpstone [ 20/Nov/14 ] |
sent pull request 292 |
Comment by Rene Krell [ 21/Nov/14 ] |
Pull request merged. |
[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: | installer.xml test-DependentVars-1.0.0.jar test-DependentVars-1.0.1.jar test-DependentVars-1.0.2.jar test-DependentVars-1.0.3.jar test-DependentVars-1.0.4.jar | ||||||||||||
Issue Links: |
|
||||||||||||
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 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():
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: variant 2: 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 |
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 |
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). |
Comment by Tom Helpstone [ 27/Jan/15 ] |
Installer with an additional fix for dynamic variables with checkonce="true" |
Comment by Rene Krell [ 27/Jan/15 ] |
I tried your latest installer 1.0.2 on Linux. |
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. 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. |
Comment by Tom Helpstone [ 28/Jan/15 ] |
This Issue is not fixed in 5.0.0-rc5-SNAPSHOT (5037a) |
Comment by Tom Helpstone [ 28/Jan/15 ] |
This installer is based on 5.0.0-rc5-SNAPSHOT (5037a) |
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 |
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 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. |
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. |
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 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 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. |
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: 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. |
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: 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" |
Attachments: | com.izforge.izpack.util.PrivilegedRunnerTest.txt TEST-com.izforge.izpack.util.PrivilegedRunnerTest.xml |
Number of attachments : | 2 |
Description |
Checkout master branch on commit 40a713e IzPack util module |
[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 ] |
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 |
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. |
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. |
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 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. |
[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: is mssing: Example usage: |
[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: | singleinstance.PNG | ||||||||
Issue Links: |
|
||||||||
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
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. |
[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: | NPE.JPG 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> 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: // destination = destination.replace('/', File.separatorChar); // Not all occurencies of slashes are path separators. To differ else { destination = destination.replace('/', File.separatorChar); } return destination; here is the stack trace, that I copied from eclipse debug: I attached screen shoots with error. |
[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..."/> /Infrared360-Tomcat7-ServicePack-$ {server.version}-installer.jar" " <info> [echo] Running IzPack to build the installer... 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: |
|
||||||||||||||||
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: |
|
||||||||
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: |
|
||||||||
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: In this phase this affects:
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: |
|
||||||||
Number of attachments : | 0 |
Description |
The resources packsLang.xml is currently ignored for translating package names according to The following parts are affected by this issue:
|
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) |
Comment by Rene Krell [ 12/Sep/14 ] |
Pull request #271 merged. 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: |
[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: |
|
||||||||
Number of attachments : | 0 |
Description |
This is a regression against RC2: There has been introduced the following change on dynamic variables: This is useful for cleaning up variables that are not needed but has one side effect: 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-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: |
Comments |
Comment by Rene Krell [ 26/Aug/14 ] |
Forgot to announce: https://github.com/izpack/izpack/pull/269 |
[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 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 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 ] |
Comment by Tom Helpstone [ 26/Aug/14 ] |
It could be valuable to allow optionally a ini-file format for the varfile. Example: [section1] would be equivalent to section1.var1=value1 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: 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 I've also updated the PR to include support for ini files. It works as follows, Example: would be equivalent to |
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. 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. |
[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. <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. 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"> 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 |
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. |
[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. I've also realize processor does not compile for combo boxes. 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 ] |
Comment by Rene Krell [ 14/Aug/14 ] |
Pull request #256 merged. |
[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
2. testNotWritable gets the wrong "root" directory
|
Comments |
Comment by Miles Tjandrawidjaja [ 12/Aug/14 ] |
Comment by Rene Krell [ 13/Aug/14 ] |
Pull request #264 merged. |
[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 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.
|
Comments |
Comment by Miles Tjandrawidjaja [ 05/Aug/14 ] |
Comment by Rene Krell [ 11/Aug/14 ] |
Resolved merge conflicts and pushed merge request #260 manually. |
[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. 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 ] |
Comment by Rene Krell [ 11/Aug/14 ] |
Pull requesr #258 merged. |
[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 ] |
Comment by Rene Krell [ 11/Aug/14 ] |
Pull request #257 merged. |
[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 ] |
Comment by Rene Krell [ 26/Jul/14 ] |
Pull request merged. |
[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 |
|
Comments |
Comment by Miles Tjandrawidjaja [ 24/Jul/14 ] |
PR sent: https://github.com/izpack/izpack/pull/252 |
Comment by Rene Krell [ 24/Jul/14 ] |
Pull request #252 merged. |
[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. Button is supported both in console and gui installations. |
Comments |
Comment by Miles Tjandrawidjaja [ 22/Jul/14 ] |
Comment by Rene Krell [ 26/Jul/14 ] |
Interesting feature, worth to go to 5.0, no breakings or destabilizing code. |
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. |
[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 ] |
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. 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 ] |
Comment by Rene Krell [ 22/Jul/14 ] |
Pull request merged. |
Comment by Rene Krell [ 22/Jul/14 ] |
Please adapt the documentation with the hint of accidentally breaking existing installers. |
Comment by Miles Tjandrawidjaja [ 22/Jul/14 ] |
Sorry it looks like I forgot to test with not declaring the splash image as a resource. |
Comment by Miles Tjandrawidjaja [ 22/Jul/14 ] |
SEVERE: Image icon resource not found in /resources/Splash.image |
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: 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: | bad_border.png imageToLeft.png 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 |
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"> And imageToRight.png had these gui prefs, <guiprefs width="800" height="600" resizable="no"> |
Comment by Rene Krell [ 07/Nov/14 ] |
Merged pull request https://github.com/izpack/izpack/pull/285. |
[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 |
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. 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: Tests run: 22, Failures: 3, Errors: 0, Skipped: 0 |
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: 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:
Usage of the above would be something like: Alternatively or additionally, we could also have a file passed in as an argument that contains all needed variable=value pairs: |
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. |
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:
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: 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 ] |
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: |
|
||||||||
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-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: | CorrectedSteps2Finished.png CorrectedSteps2.png CorrectedStepsFinished.png CorrectedSteps.png install.xml Step3of3_ButDisplayedAs3of4.png 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. 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. |
Comment by Thomas Hauser [ 16/Jul/14 ] |
Hello Jens, 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 ] |
Comment by Rene Krell [ 14/Jul/14 ] |
Pull request merged. |
[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 ] |
Comment by Rene Krell [ 11/Aug/14 ] |
Pull request #230 merged. |
[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 specify the minimum and maximum amount of rows that are possible to be dynamically located. We could validate based on a given column. Custom fields can take in a condition id just like any other fields. The auto.xml for custom fields should generate the auto.xml as though the fields defined in the custom field were defined as regular. Console installation displays custom fields as though displaying the individual fields as normal. Summarizing a custom field will show the attributes with a number pre-appended. It may be easier to understand the custom field by looking at a sample specification. Let me know of any questions or concerns. |
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. |
Comment by Rene Krell [ 16/Jul/14 ] |
Pull request #229 merged. |
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. 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" override="false" override="asktrue" override="askfalse" 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" <info> <locale> <guiprefs width="800" height="600" resizable="no"> <panels> <packs> <parsable targetfile="${INSTALL_PATH} /test.properties"/> </izpack:installation> and the auto.xml is <?xml version="1.0" encoding="UTF-8" standalone="no"?> |
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. |
[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 |
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 ] |
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. As an example: 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. |
Comment by Francisco Canas [ 16/Jul/14 ] |
You're welcome. I've also added some basic documentation for this feature here: |
[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. |
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' etc... |
Comments |
Comment by Rene Krell [ 07/Jul/14 ] |
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"> |
Comments |
Comment by Rene Krell [ 04/Jul/14 ] |
Comment by Rene Krell [ 04/Jul/14 ] |
Pull request merged. 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'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 : |
[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 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 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". |
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: |
|
||||||||
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 |
Comments |
Comment by Miles Tjandrawidjaja [ 08/Jul/14 ] |
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 ] |
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. 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: |
|
||||||||||||||||
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>
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:
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 |
Comment by Rene Krell [ 09/Dec/14 ] |
Has the same background like |
[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:
Unpack packs should execute in the following new order:
|
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: |
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: | conditions.xml packs.xml 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. |
Comments |
Comment by Miles Tjandrawidjaja [ 16/Jun/14 ] |
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. |
Comments |
Comment by Miles Tjandrawidjaja [ 13/Jun/14 ] |
Comment by Rene Krell [ 04/Jul/14 ] |
Pull request merged |
Comment by Rene Krell [ 07/Jul/14 ] |
[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 |
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: |
|
||||||||
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: |
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: 'Complex' expression: 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. |
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. |
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 ] |
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: |
|
|||||||||||||||||||||||||
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:
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:
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: | izpack5_hierarchy.graphml 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. 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). |
Comment by Miles Tjandrawidjaja [ 15/Jul/14 ] |
AsideWhile 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 ] |
Comment by Rene Krell [ 16/Jul/14 ] |
Pull request #233 merged. |
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:
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: |
|
|||||||||||||||||||||||||
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:
|
[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. 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 ] |
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: |
|
||||||||
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. 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: 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. |
Comments |
Comment by Rubén Bressler [ 21/May/14 ] |
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! 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. IzPack automatically recognizes the used language from your local environment. |
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 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: All the file has been adapted and modified in order to sort the keys in the |
[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, The custom input panel will be 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, |
[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: | ConsoleDemo.zip | ||||||||
Issue Links: |
|
||||||||
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. |
Comments |
Comment by Miles Tjandrawidjaja [ 24/Jun/14 ] |
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. 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. So it looks like the issue can be reproduced when the user does not have a ~/.inputrc file. 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 114.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: 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. Is there an alternative to jline? |
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/. |
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. If there are plans to release RC3 soon I would opt for disabling for Windows. |
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. |
Comment by Rene Krell [ 17/Jul/14 ] |
The pull request has been reverted, adoption of jline is too dirty. |
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:
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:
Whether the initialization works can be gathered by launching the installer like this: |
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. |
[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, <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> Kindly help me in resolving this issue. Thanks, |
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: | 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. |
Comment by Tom Helpstone [ 07/May/14 ] |
Yes, the pull request has been merged. |
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 |
[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: | shortcutSpec.xml |
Number of attachments : | 1 |
Description |
I am using Izpack 5 RC2 for my project . <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 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 |
Comments |
Comment by Francisco Canas [ 09/Jul/14 ] |
Comment by Rene Krell [ 16/Jul/14 ] |
Pull request #228 merged. |
[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
|
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: 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. 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: | 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 BUILD FAILED 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. |
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. 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. <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: |
|
||||||||
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 ] |
Comment by Rene Krell [ 09/May/14 ] |
Pull request merged. |
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. |
[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. 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. |
Comments |
Comment by Rene Krell [ 09/Apr/14 ] |
Development hint after a shot analysis: Parsing is executed here: |
Comment by Rene Krell [ 07/Oct/14 ] |
Duplicate of |
[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: |
[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:
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. |
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. 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: |
[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 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:
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. |
[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. 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. Solution: Set the variable when checkbox is decided to set itself as selected or not. |
Comments |
Comment by Miles Tjandrawidjaja [ 27/Mar/14 ] |
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? 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: |
[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 <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: 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 : /public_data" size="40" mustExist="false" create="true" /> 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: |
|
||||||||
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. 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 ] |
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) |
Comments |
Comment by Miles Tjandrawidjaja [ 20/Mar/14 ] |
Comment by Rene Krell [ 21/Mar/14 ] |
Pull request merged. |
[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. |
Comment by Rene Krell [ 20/Mar/14 ] |
Pull request merged. |
[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? 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:
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. |
Comment by Michael Schnupp [ 18/Mar/14 ] |
To reproduce:
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>. |
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. |
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: | IZPACK-1064.tar.gz 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. 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, |
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). 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? |
Comment by Rene Krell [ 25/Mar/14 ] |
I attached a minimum project 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/
Please make your version of the project, attach it and tell us,
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). My issue is the directory fields are automatically populated with the user's current working directory. There are multiple scenarios to reproduce the issue, |
Comment by Vedavalli Radhika [ 08/Apr/14 ] |
Hi Rene, Is there any other details required from my end? Thanks, |
Comment by Rene Krell [ 08/Apr/14 ] |
Hi, I saw it, thanks. |
Comment by Vedavalli Radhika [ 15/Apr/14 ] |
Rene, Your response is crucial for us to deliver the installers to the client. Can you help me on this? |
Comment by Rene Krell [ 15/Apr/14 ] |
Hi, I commented Just a common note, although it actually doesn't belong here: |
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. |
Comment by Rene Krell [ 27/May/14 ] |
Ok thank you for the note. Using the latest version is always a good choice |
[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. <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:
|
Comments |
Comment by Sébastien Christy [ 07/Mar/14 ] |
Patch proposed in pull request #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. 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. |
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.
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). [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". 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). 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. |
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:
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. |
[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: |
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. |
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? |
Comment by Tim Anderson [ 27/Feb/14 ] |
Mocking the test objective is no substitute for actually testing it.
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. |
[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-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. |
[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. 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 |
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. |
[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] 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.
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.
|
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: |
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. |
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] [1msample [0m [36mRUNNING[0m
00:00:51.688 [INFO] [1mizpack-172[0m [36mRUNNING[0m
00:00:52.787 [INFO] [1mizpack-172[0m [31mFAILURE[0m (0:00:01.062) [31mJava returned: 1[0m
00:00:55.869 [INFO] [1msample [0m [31mFAILURE[0m (0:00:04.141) [31mJava returned: 1[0m
00:00:55.870 [INFO]
00:00:55.870 [INFO] -------------------------------------------------------------------------------
00:00:55.870 [INFO] Test Summary ([1m0:00:04.201[0m)
00:00:55.871 [INFO] Passed: [31m0[0m
00:00:55.871 [INFO] Failed: [31m2[0m
00:00:55.871 [INFO] -------------------------------------------------------------------------------
00:00:55.871 [INFO]
00:00:55.872 [INFO] The following tests [31mfailed[0m:
00:00:55.874 [INFO] * [31mizpack-172[0m - [1m/home/build/.jenkins/workspace/izpack-maxtrix-master/jdk/JDK-1.7-u40/izpack-maven-plugin/src/it/izpack-172/build.log[0m
00:00:55.874 [INFO] * [31msample[0m - [1m/home/build/.jenkins/workspace/izpack-maxtrix-master/jdk/JDK-1.7-u40/izpack-maven-plugin/src/it/sample/build.log[0m
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: |
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: 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.
--- a/izpack-installer/src/main/java/com/izforge/izpack/util/os/Win_RegistryHandler.java package com.izforge.izpack.util.os; +import java.util.ArrayList; -import java.util.List; |
[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. |
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. [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? 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. .}} |
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. 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. 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: |
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:
--- a/izpack-panel/src/main/java/com/izforge/izpack/panels/shortcut/ShortcutPanel.java --- a/izpack-panel/src/main/java/com/izforge/izpack/panels/shortcut/ShortcutPanelLogic.java + public void createAndRegisterShortcutsBugFix() throws Exception |
[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.
--- a/izpack-panel/src/main/java/com/izforge/izpack/panels/installationgroup/InstallationGroupPanel.java |
[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
--- a/izpack-installer/src/main/java/com/izforge/izpack/installer/util/SummaryProcessor.java |
[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");
--- a/izpack-uninstaller/src/main/java/com/izforge/izpack/uninstaller/gui/UninstallerFrame.java |
[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"/> And i am calling this userInputSpec.xml into Install.xml in the following code: <resources> <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, |
[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: | 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:
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. 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. |
[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. 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 |
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. at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) 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. 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(). |
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 --> 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). |
[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: |
|
||||||||
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. |
[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:
|
[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: |
|
||||||||
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. |
[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: |
|
||||||||||
Sub-Tasks: |
|
||||||||||
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: |
|
||||||||
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: |
|
||||||||
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: |
|
||||||||
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: |
|
||||||||
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: |
|
||||||||
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 The reason is the automatic escape handling of the core utilities for reading those files. For dynamic variables, add an option |
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: |
|
||||||||
Number of attachments : | 0 |
Description |
There are the following main reasons for updating to JDOM 2:
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: |
|
||||||||
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. 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: |
|
||||||||
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. |
[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: |
|
||||||||||||||||
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: |
|
||||||||
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. |
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. |
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. |
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. |
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.
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 |
[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: | trace.png | ||||||||
Issue Links: |
|
||||||||
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. |
[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 ] |
[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:
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.
AbstractInstallationFinder would provide a skeleton implementation, including
|
[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: |
|
||||||||||
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: 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:
|
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 ] |
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: the resulting entry in new.wrapper.conf is 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: The documentation goes here: |
[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 |
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: | pic1.jpg |
Number of attachments : | 1 |
Description |
Step to reproduce:
2. Add this file like a resource of HTMLHelloPanel into install.xml 3. Add HTMLHelloPanel into panels section 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: |
|
||||||||
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> conditions.xml <condition type="variable" id="testCondition"> |
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"> 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. |
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. Not that complicated, I start with that now.
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. 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): In a custom validator, you can still choose whether to use 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. 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: |
|
||||||||||||||||
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. |
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: |
|
||||||||
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: |
|
||||||||
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: |
|
||||||||||||
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. |
[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:
HOT-FIXTemporarily 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-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 When trying to create web installer this gives below error. Writing Pack 1: Purge Databases Any idea how to resolve this.. as this is related to this issue. Regards, |
[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 ] |
[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 |
Attachments: | setup-5.0.0-beta11.jar setup-5.0.0-rc1.jar 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:
As I already mentioned, these problems were not observed with the version 5.0.0-beta11. |
Comments |
Comment by Samir Chouaieb [ 05/Jun/13 ] |
The problem is indeed the early replacement of the variables. 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. 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 |
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. I think that the user awaits that the directory he has chosen gets displayed and not the default one. |
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. 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(). On the other hand your suggestion is good because we could better separate the concerns. |
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 |
Attachments: | exception.txt 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. 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. |
Comments |
Comment by Tim Anderson [ 26/May/13 ] |
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: | 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-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: |
|
||||||||||||||||||||
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: |
|
||||||||
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 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" |
Issue Links: |
|
||||||||
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. 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: | ProcessExplorer.png RegQueryThreadStack.png |
Number of attachments : | 2 |
Description |
Expected BehaviorOne should be able to read a windows registry key using dynamic variables as documented at: Actual OutcomeOnce 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
This is where my installer gets stuck at and after 20 mins I terminated the process:
|
Comments |
Comment by Paul Bors [ 20/Apr/13 ] |
See also:
Equivalent dos command when run on my desktop results in:
|
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. 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. |
[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: | izPack jar packaged icons.png |
Number of attachments : | 1 |
Description |
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. |
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. |
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 |
[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: | 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 |
Comment by Tim Anderson [ 10/Mar/14 ] |
[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: |
Comments |
Comment by Tim Anderson [ 17/Mar/13 ] |
Shouldn't do. They can either end in ConsolePanel, or for backwards compatibility, Console, or ConsoleHelper.
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 |
Comment by Sven Thomas [ 18/Mar/13 ] |
And I forgot 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. |
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. |
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: 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.
|
[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): 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. |
[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: // 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); }
|
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:
|
[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: |
|
||||||||
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: |
|
||||||||
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: |
|
||||||||
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: |
|
||||||||
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: |
|
||||||||
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: |
|
||||||||
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: |
|
||||||||
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. |
[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: |
|
||||||||
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: |
|
||||||||
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 ] |
[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. 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. 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. 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.
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. 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: |
|
||||||||
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. |
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
Now, on pressing Previous, the InstallPanel reappears, which is still right, but the InstallPanel installs again immediately without confirmation - bad:
I'd suggest the following approaches:
|
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. |
Comment by Rene Krell [ 19/Feb/13 ] |
I'm still not sure, what could be the most universal approach. |
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. <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 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: | ClassNotFoundException.txt install_sample.jar IzPack-NoTargetPanel-sample.zip | ||||||||
Issue Links: |
|
||||||||
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. 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. |
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:
|
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)? |
Comment by Karim de Fombelle [ 12/Aug/13 ] |
Reproduced on an installer built with maven plugin version 5.0.0-beta11 |
[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: | install_sample.jar IzPack-sample.zip | ||||||||||||||||
Issue Links: |
|
||||||||||||||||
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. 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 second one needs a change in the source code: P.S.: Any ETA on a new beta version of 5.0.0? I'd really like to have the bugfix of |
Comments |
Comment by Sven Thomas [ 18/Feb/13 ] |
And another related thing that came to my mind: |
[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. 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. |
[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: | chn_UTF8.xml IzPack - Installation of Jajuk_092.png Unicode.java Unicode.png | ||||||||
Issue Links: |
|
||||||||
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] <!-- See ISO3 country codes in /prog/IzPack/bin/langpacks/installer --> <!-- The listeners section for CustomActions --> <packs> <!-- Files to include in every platform --> <!-- Windows specific --> <!--Unix specific --> <!--OSX specific --> |
Comments |
Comment by Rene Krell [ 16/Feb/13 ] |
Please zip and add your original langPack XML file you reported this for. |
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. |
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 |
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. At first, the locale is typically set on the system. 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. Shortly spoken: |
Comment by Rene Krell [ 21/Feb/13 ] |
There is no universal SANS SERIF font, there is a lot of them. 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: 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: 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. 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: | 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" ...> |
[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 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 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 |
Comment by Sven Thomas [ 04/Feb/13 ] |
Oh sorry, didn't see that. |
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 |
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 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? |
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: " didn't help. The <panels> section contains amongst others: 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? 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 |
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 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: I thought this should be a very simple process, but either I missed something important or it's bugged in beta11. |
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. |
Comment by Sven Thomas [ 31/Jan/13 ] |
Yeah but... I don't use any properties in my installer. Paste from first comment: 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 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): "/> 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. |
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). |
Comments |
Comment by Johan Kaving [ 25/Jan/13 ] |
Duplicates 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). |
Comments |
Comment by Johan Kaving [ 25/Jan/13 ] |
I have created a pull request containing a fix here: |
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: | 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: 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) |
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: /target/main/izpack/installer.xml</installFile> </baseDir> |
Comments |
Comment by Rene Krell [ 22/Jan/13 ] |
Successfully tested and merged your pull request in 5.0.0-rc1-SNAPSHOT. |
[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 |
[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> (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> after all for 32-bit, and chnage to <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 |
[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. |
[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 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: | CompilerConfig.java CompilerConfigTest.java JRE7_10-64bit - Copy.zip 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: Index that will work: 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. 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 |
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. Please make a local branch with the name 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 |
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 Thank you |
Comment by Bruno F [ 02/Aug/13 ] |
Ok. I've just sent the pull request! |
Comment by Rene Krell [ 02/Aug/13 ] |
It worked out, congrats |
Comment by Bruno F [ 02/Aug/13 ] |
Thanks! |
Comment by Rene Krell [ 02/Aug/13 ] |
Yes, it updated the same pull request instead of opening a new one, as expected. Well done. |
Comment by Rene Krell [ 02/Aug/13 ] |
As discussed and seen on Github, the pull request seems to be ok now. 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 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', |
Comments |
Comment by Martin Grihangne [ 14/Dec/12 ] |
Additional details: The problem occurs when navigating through the installer according to this sequence :
|
Comment by Pascale ANDRIANATREHANA [ 18/Jul/13 ] |
Hi, What is the status of this bug ? 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
|
[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. |
Comment by Rene Krell [ 13/Dec/12 ] |
If the above is fixed, another problem occurs in this situation in izpack-test: 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 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): <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: |
|
||||||||
Number of attachments : | 0 |
Description |
The panel.order attribute in userInputSpec.xml doesn't make any sense. The documentation says: <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: |
|
||||||||
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 attribute in userInputSpec.xml should not be relevant here at all. |
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 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 BehaviorRunning the installer via the -console mode it should skip over any panel that does not have an associated *ConsoleHelper. Actual OutcomeInvoking 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
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. |
Comment by Rene Krell [ 30/Apr/13 ] |
Hi Paul,
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. |
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. |
[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: | izpack_simplefinish.png |
Number of attachments : | 1 |
Description |
When using a SimpleFinishPanel instead of a FinishPanel at the end of an IzPack installer, |
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. 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. Francois |
Comments |
Comment by Rene Krell [ 22/Jan/13 ] |
This seems to be the same reason like |
[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"?> </arg> </arg> <job name="Launch Tomcat, please wait..."> |
[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. 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 |
[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: | IZPack_V5_No_Target_Panel.zip | ||||||||
Issue Links: |
|
||||||||
Number of attachments : | 1 |
Description |
When an installer has no TargetPanel then the GUI disappears without any notice. Even if I set the variables: 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? |
Comment by Mulcamd [ 10/May/13 ] |
Hi I created a little sample based on the sample provided with IZPack 4, see attachment. After the selection no further dialogs appear. |
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. 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 ... ] and a corresponding GUI error popup. |
Comments |
Comment by Francois Le Fevre [ 31/Oct/12 ] |
Dear all, <izpack.plugin.version>5.0.0-beta10</izpack.plugin.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, 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> <dependency> </version> 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 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 do you have any idea? INFO: dynamic variable birdswui.host: My izapck.xml <?xml version="1.0" encoding="iso-8859-1" ?> <info> -$ {sbwh6.arch}</appname> </appversion> <javaversion>1.6</javaversion> </authors> |
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 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <groupId>fr.a</groupId> <artifactId>b</artifactId> <name>BB</name> <packaging>jar</packaging> <properties> <izpack.plugin.version>5.0.0-beta11-SNAPSHOT</izpack.plugin.version> </properties> <dependencies> <dependency> <scope>provided</scope> </dependency> <dependency> <groupId>org.codehaus.izpack</groupId> <artifactId>izpack-panel</artifactId> <version>${izpack.version} </version> <dependency> </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> <!-- installFile>${project.basedir}/src/main/izpack/izpack.xml</installFile --> <installFile>${staging.dir} /izpack.xml</installFile> </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> <pluginManagement> <profiles> </profiles> <repository> <pluginRepositories> <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,
And I do not have again the uninstaller problem! Thanks a lot for your advice Rene. Francoix <plugin> <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> <dependency> <groupId>org.codehaus.izpack</groupId> <artifactId>izpack-uninstaller</artifactId> <version>${izpack.version} </version> Now I have only the problem of Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com/izforge/izpack/panels/imgpacks/ImgPacksPanelAutomationHelper |
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. |
[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' 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: |
[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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Number of attachments : | 0 |
Description |
17-okt-2012 18:35:21 INFO: Logging initialized at level 'INFO' |
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. the property file installer.properties contains the desired information. |
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. |
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:
Notes:
The following panels still have no console implementation:
|
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 |
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: | install.jar install.xml |
Number of attachments : | 2 |
Description |
At the last panel, finish panel, the installer hangs for more than a minute and then quits. 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"? |
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] |
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. 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 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: 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. 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-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: | 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 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-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 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. 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! |
Comment by Tim Anderson [ 21/Sep/12 ] |
Pull request applied. Renamed the following langpack resources and their corresponding flags:
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 |
Number of attachments : | 0 |
Description |
The same uninstaller works fine under Windows XP 32 bits, but does not work under Windows 7 64 bits. 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 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) |
Attachments: | Dialog Directory exists Are you sure.JPG |
Number of attachments : | 1 |
Description |
When the directory exists, a dialog, see attachment, is shown. |
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 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. |
[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. |
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: | error2.log error.log Install_XML.zip |
Number of attachments : | 3 |
Description |
In my installer which runs fine in 4.3.5. I get the error: 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 Windows XP. |
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. Does this patch also fixes https://jira.codehaus.org/browse/IZPACK-855? |
Comment by Tim Anderson [ 15/Sep/12 ] |
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-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: $ {TARGET.DIR}"/> In 5.0 beta 11 I get the directory based on the <appname> The documentation says: The question is what is "DEFAULT_INSTALL_PATH". Is this the value of $INSTALL_PATH or the value from <appname>? HOWEVER, adding the code below solves my problem (workaround) <variable name="TargetPanel.dir.mac_osx" value="${INSTALL_PATH} "/> |
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 |
Attachments: | error.log error_small.log Error uninstallation information.jpg 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 ... ] 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. YET, I still find it strange that I get this error. 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). 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. |
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! |
[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: |
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. |
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: | ExampleAdjusted.zip Example.zip | ||||||||||||||||
Issue Links: |
|
||||||||||||||||
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 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 <packaging>izpack-jar</packaging> althought I'd recommend it in case you have a separate Maven module for the installer creation. 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: 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. |
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 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 |
Comments |
Comment by Rene Krell [ 23/Aug/12 ] |
The change introduces also variable substitution for the attribute |
[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.
|
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: | 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: Patch (for instance from a previous installation): 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: 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:
|
[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. 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: | izpack-configaction-current.xml izpack-configaction-proposed-with-separate-sets.xml izpack-configaction-proposed.xml 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 ( I propose working on the following specific bits and pieces.
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). |
Comment by Daniel Abson [ 23/Aug/12 ] |
You mean like this idea of yours on the dev list: <configurables> |
Comment by Rene Krell [ 23/Aug/12 ] |
This has been just a suggestion. |
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. |
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. <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. |
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:
|
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 |
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. |
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 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: | 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 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-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. |
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:
These should be replaced by XSDs and also uploaded to the website.
In addition to the above, there also needs to be a schema for shortcut specs. Suggested conventions, borrowing from Spring:
E.g., izpack-installation.xsd is the schema for install.xml files. 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. 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. 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:
The goal ist to make a clean API and user XML interface, embed filters in a nested <filters> element. |
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: | install.xml log.txt |
Number of attachments : | 2 |
Description |
IzPack is not compile install.xml with <properties> section. |
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. |
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: | CompileIzPack_v4_older.cmd compile.log errors_1.log errors_2.log Installer_Windows_shortcutSpec.xml install.xml Licence.txt 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. <shortcut applications="no" description="$APP_NAME on the web" |
Comments |
Comment by Mulcamd [ 04/Aug/12 ] |
I made a mistake to fill the fix version invalid to 4.3.2 |
Comment by Mulcamd [ 04/Aug/12 ] |
I made a mistake filling the fix version invalid. 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. Could you please fix this in 4.3.6! I also tried 5.0 beta 10 standalone, but then I get all kinds of errors: ... INFO: The next panel of 4 is panel number 5 |
Comment by Mulcamd [ 07/Sep/12 ] |
Added the error logs when running with IZPack 5 Attachment error_2.log is from a real installer. |
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. |
Comment by Mulcamd [ 08/Sep/12 ] |
Were can I download the latest snapshot? |
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/ <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. First, I can confirm that issue http://jira.codehaus.org/browse/IZPACK-687 has been solved! I could not compile my installers, because: I googled, but could not find information on the error. Any suggestions? Full log attached, |
Comment by Mulcamd [ 08/Sep/12 ] |
Fatal error : 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. |
Comment by Mulcamd [ 13/Sep/12 ] |
Back to the original shortcut issue in 4.3.5. 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 |
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:
In the <os name> form, the os name is one of:
For 4.3.6,
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:
Available platforms can be found in the class Platforms. The names are the lowercase versions of those defined.
Differences from 4.3.5 In 4.3.5, resources were used rather than variables. Resources were searched for with the following names
|
[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. |
[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 |
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" ?> Here's the shortcutspec.xml:
<shortcuts> <skipIfNotSupported/> <programGroup defaultName="TFFS" location="applications"/> <shortcut <createForPack name="Base"/> </shortcut> <shortcut <createForPack name="Base"/> </shortcuts> |
Comments |
Comment by Tim Anderson [ 04/Jul/12 ] |
Please use the mailing list to ask questions before raising bug reports. <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:
|
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:
|
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] 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' |
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 <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> <dynamicvariables> <resources> <res id="TargetPanel.dir.unix" src="@{config.dir} /targetdir.unix.conf" /> /targetdir.unix.conf" /> targetdir.windows.conf: $ {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 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: | crashlog.txt 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 |
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: | 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 ] |
Comment by Dustin Kut Moy Cheung [ 15/Jun/12 ] |
[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: | izpack_1.png 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: | 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 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: | 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. |
[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: | 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. -> Fatal error : |
Comments |
Comment by Daniel Abson [ 11/Jun/12 ] |
I think this is related to 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 |
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: |
Comment by Daniel Abson [ 12/Jun/12 ] |
Perhaps this issue should be closed in favour of |
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 All failed! Is this fixed |
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 |
Comment by Daniel Abson [ 14/Jun/12 ] |
Might be you can ignore my previous comment - looks like |
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. 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:
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 "$INSTALL_PATH\Uninstaller\uninstaller.jar"" description="Uninstall XWiki" initialState="normal" programGroup="yes" desktop="no" startMenu="no"/> </shortcuts> Only 3 shortcuts install in 4.3.5:
So 3 are not installing at all:
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 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. 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: | 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! <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" 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 |
Attachments: | 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. |
Comments |
Comment by David Leuenberger [ 14/May/12 ] |
Comment to the environment: |
Comment by David Leuenberger [ 14/May/12 ] |
attach new version |
Comment by Tim Anderson [ 18/May/12 ] |
This is a duplicate of |
[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). 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: | 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 |
[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. 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:
|
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: | 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) 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
|
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: | param-name_value-change-fixed.patch 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 |
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:
|
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: | info.html installer.xml 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 |
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. |
[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: | 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: | panel-action-param.patch panel-action-param-stacktrace.txt remove-xstream-provider.patch 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 --
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. 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-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. |
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: | IZPACK-789 selectpath-1.png selectpath-2.png targetpath-1.png 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 |
Comment by Dustin Kut Moy Cheung [ 27/Mar/12 ] |
[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).
The RulesEngineImpl dependency on ClassPathCrawler should be removed. |
[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. |
[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. Panels requiring objects not provided by the container can
|
[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. 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". 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 " " The given defaults make it compatible with the previous behavior. |
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> <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> 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. |
Comments |
Comment by Tim Anderson [ 19/Mar/12 ] |
Also added integration tests:
|
[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: 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/. 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:
|
[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 |
Attachments: | 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. .:: IzPack - Version 5.0.0-beta10 ::. < compiler specifications version: 1.0 >
-> Processing : install.xml < my install xml content printed here> Setting the installer information Copying the skeleton installer (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):
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.: 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. 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. 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>: |
Comment by Rene Krell [ 13/Mar/12 ] |
Regarding the implementation:
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")
|
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: 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. <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.
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: |
|
||||||||||||
Number of attachments : | 0 |
Description |
Just not to forget: |
Comments |
Comment by Rene Krell [ 09/Mar/12 ] |
Developers need a guidline how to use it. Installer logging levels:
|
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 |
[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 ... //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. |
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:
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. |
[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: |
|
||||||||||||||||
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 ... ] and a corresponding GUI error popup. |
Comments |
Comment by Andreas Schöneck [ 07/Mar/12 ] |
Duplicate of |
[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: |
|
||||||||||||||||
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.
Hopefully this will play as nice together as it sounds. 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. |
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: 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. |
Comment by Rene Krell [ 15/Mar/12 ] |
Regarding XStream: I could even imagine dividing XML parsing into compiler and installer. 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 |
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 following Maven IzPack Plugin configuration options should be added to enable this feature:
|
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: | 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: | 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"> And in CustomLangpack.xml_eng: <str id="username.password.text" txt="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: I change standalone-compiler version from 4.3.4 to 4.3.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. |
[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: | 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. 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: | 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: | izpack-gchauvet-uninstaller.patch |
Patch Submitted: |
Yes
|
Number of attachments : | 1 |
Description |
Izpack register uninstaller in regedit in despite of attribute <uninstaller write="no" /> |
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 ] |
|
[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: | eng.xml.patch test.png |
Patch Submitted: |
Yes
|
Number of attachments : | 2 |
Description |
Used to be: Expected: |
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.
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: Advantages:
Disadvantage:
|
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. |
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: | install.xml 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). 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 |
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" ?> <createForPack name="MyApplication Client"/> <shortcut <createForPack name="MyApplication Client"/> </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 |
Number of attachments : | 0 |
Description |
Uninstaller is always written regardless of write attribute or condition. Source of the problem is in UninstallDataWriter.isUninstallShouldBeWriten How to reproduce: Possible workaround is to use an empty 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: |
Comment by Rene Krell [ 16/Mar/12 ] |
Should work now in the latest git 5.0.0-beta11-SNAPSHOT, give it a try. |
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. |
[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. Source of the problem is in ConsoleInstaller.iterateAndPerformAction How to reproduce: |
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 How to reproduce: Stack trace:
|
[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: | 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"> |
[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: | 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 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: | 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 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. |
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 |
[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: | 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.
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 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). java -Dself.mod.debugPort2=8002 -Dself.mod.debugPort3=8003 -jar uninstaller.jar to enable debugging for phase2 and phase3. 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. Invalid or corrupt jarfile c:/Program Files/MyApp/Uninstaller/uninstaller.jar If the write fails:
|
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 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 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: 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 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" > $ {FILE_SEPARATOR}dbase" create="true" mustExist="false" /> 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. 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. 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:
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. 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. 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: | 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: | 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. 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: 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. Exception in thread "AWT-EventQueue-0" com.izforge.izpack.api.exception.IzPackException: java.lang.NullPointerException — Sample ant task under 5.0 <taskdef name="IzPack" classpathref="izp" classname="com.izforge.izpack.ant.IzPackTask"> /lib"> |
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 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: | 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: | 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(). ... 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: | 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. |
[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 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: |
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: | izpack_character_encoding_problem.png |
Number of attachments : | 1 |
Description |
I have defaultTargetPanel and packs are installing to this location: " os="windows"></file> It works fine, BUT if username contains special characters, like À or ö, it converts them into: ,, 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. |
[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 works with 4.3.2 but with 4.3.4 I get this: seems that line number info is missing: 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: | installer.xml 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 |
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 but the installer proceeds withouit error if I also include the HTMLInfoPanel. |
Comment by Tim Anderson [ 18/Aug/12 ] |
Fixed by changes made for |
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. |
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 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? |
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: " 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} " /> |
Comment by Tim Anderson [ 21/Sep/12 ] |
I can't reproduce this locally with the latest 5.0.0-beta11-SNAPSHOT. |
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.
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). |
[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> 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? |
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 |
[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 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)
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:
Updated integration tests:
|
[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...> 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 |
Comments |
Comment by Dan Tran [ 03/Sep/11 ] |
fixed at commit 26ad940b983936cf6497373236656fb718ff2603 ----------------------------------------------------------------------- Summary of changes: |
[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: | org.ini4j.IniTest.txt org.ini4j.OptionsTest.txt org.ini4j.spi.IniFormatterTest.txt org.ini4j.spi.IniParserTest.txt org.ini4j.spi.IniSourceTest.txt org.ini4j.spi.OptionsFormatterTest.txt org.ini4j.spi.OptionsParserTest.txt |
Number of attachments : | 7 |
Description |
here is the test summay Tests in error: 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 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. |
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). |
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: 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: 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 :-| |
Comment by Emmanuel Hugonnet [ 04/Nov/11 ] |
Most of the problems were linked to end of lines when parsing files. |
Comment by Tim Anderson [ 20/Dec/11 ] |
This is still failing on window (windows 7, JDK 1.6) |
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. |
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:
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
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 |
[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:
|
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 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
----------------------------------------------------------------------- Summary of changes: |
[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: | Compile_4_3.bat compile_5_beta_10.bat Compile_5_beta_8.bat log_compile_4_3.txt log_compile_5_beta_8.txt 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. Using excactly the same script with version 5 I get the error: 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: 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>echo 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: 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>echo 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 |
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. |
[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: | Izpack685UninstallListener.java |
Number of attachments : | 1 |
Description |
Examining the source code for 4.3.0 and latest in anonymous git, izpack The status indicator in the uninstaller dialog gives the false impression |
Comments |
Comment by Earl Hood [ 11/Aug/11 ] |
I've attached an uninstall listener that The listener checks after file deletion for I think IzPack itself should intrinsically |
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. |
[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:
|
Comments |
Comment by Dan Tran [ 03/Sep/11 ] |
[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 |
Attachments: | izpackissue.png 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. --------------- /**
|
[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, |
[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, 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: To meet this requirement what I propose to deliver are the following updates: Unpacker.java/MultiVolumeUnpacker.java: 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. // Set file modification time if specified This means the PackFile class has a redundant property set (see below): 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: Potential impact, 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, |
[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: | Uninstaller.patch Uninstaller.patch 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. 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 : |
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. |
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: | 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". |
Comments |
Comment by Tim Anderson [ 27/Jan/12 ] |
Have you included the x64 versions of the dlls in your install.xml? <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: | izpack2exe_py_et_20110609.zip |
Patch Submitted: |
Yes
|
Number of attachments : | 1 |
Description |
The changes to "utils\wrappers\izpack2exe\izpack2exe.py" via issue I believe the attached version of "izpack2exe.py" will address the |
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> I get the following error: [ERROR] FATAL ERROR |
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: | AbstractPanelConsoleHelper.java DelegatePanelConsoleHelper.java JDKPathPanelConsoleHelper.java 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. 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 <info> <variables> <guiprefs resizable="no" width="480" height="360"> <locale> <panels> <packs> </pack> <pack name="web" required="yes"> <description>WEB Applications</description> <fileset dir="webapp" targetdir="${INSTALL_PATH} /webapp" override="true"/> </packs> </installation> Copying the skeleton installer [ End ] 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 jar -tvf installer.jar|grep TargetPanel 2373 Fri Apr 29 09:51:02 CEST 2011 com/izforge/izpack/panels/target/TargetPanel.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 ] |
[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:
On a desktop computer, using the "-console", there's no issue raised but nothing seems to happen: |
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. 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. |
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. |
Comments |
Comment by Rene Krell [ 01/Oct/12 ] |
Please have a look at: 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: | 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)); The AndCondition constructor itself does the following: this.leftoperand = operand1; 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 |
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 |
[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: | install.xml |
Number of attachments : | 1 |
Description |
I'm using izpack-maven-plugin : 5.0.0-beta7 GUI Installation works (java -jar installer.jar) 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. |
Comments |
Comment by Patrick Zbinden [ 03/May/11 ] |
Have problems with git, so I'll explain my suggestion: 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 |
Comment by Rene Krell [ 01/May/13 ] |
Is this still relevant at all in the 4.X branch? Regarding:
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 |
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 |
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 : ; |
[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: | 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: a user only needs to type Trying to execute the uninstaller jar created using the ZipOutputStream causes the following error: Suggested solution: I can try to create a patch, but I am still trying to get familiar with git jexec Reference |
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 |
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: | ProcessPanel.patch.txt 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 <!-- IzPack related setup --> /lib" > % ant fubar-selection: all: BUILD SUCCESSFUL |
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: | ShortcutPanel.java.patch |
Number of attachments : | 1 |
Description |
Create an install like this. <listeners> <panel classname="CheckedHelloPanel"/> When you reach ShortcutPanel press back and then next. java.lang.Exception: could not get an instance of IShellLink, failed to co-create instance java.lang.NullPointerException 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). |
Comment by Ł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? |
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 |
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 Replace line 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, |
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, 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 ). 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: Workaround: 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:
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). |
Comments |
Comment by Florin B [ 15/Mar/11 ] |
The received error message is "This directory can not be written ...." |
[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: | izpack-processpanel.patch 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: | 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. 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. |
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 — <info> <variables> <guiprefs resizable="no" width="480" height="360"> <locale> <panels> <packs> </pack> <pack name="web" required="yes"> <description>WEB Applications</description> <fileset dir="webapp" targetdir="${INSTALL_PATH} /webapp" override="true"/> </packs> </installation> Copying the skeleton installer [ End ] 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 jar -tvf installer.jar|grep TargetPanel 2373 Fri Apr 29 09:51:02 CEST 2011 com/izforge/izpack/panels/target/TargetPanel.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: | 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 |
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: The uninstall does the following (the problem is indicated by **): (2) I'm running version 4.3.3. |
[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.
|
[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: | 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 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 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: |
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 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: |
[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: | NPE_UserPathPanel.patch 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 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. $ 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). |
[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. 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. |
[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" When running the installer the result is: (If I run the installer INFO: refreshing dynamic variables |
Comments |
Comment by Rene Krell [ 18/Jan/11 ] |
Fixed in master, commit 44bbf91b8c9b39268981ad8e04a66c8b96060d51. |
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" and also: <variable name="hostname" checkonce="true" 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 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. |
[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: | 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. |
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 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 So it appears that the JDKPath variable won't get set and substituted 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: |
|
||||||||
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:
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. |
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. 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:
|
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. 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" |
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 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. |
Comment by Tom Grünheit [ 03/May/11 ] |
I have the same problem with 5.0.0-beta7 ... see my comment in Rgds |
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: | 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: Steps to apply these changes: 1. Right Click on Desktop |
Comments |
Comment by Niambh Scullion [ 04/Nov/10 ] |
Apologies, I meant to also say, |
[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. |
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: | Izpack-4.3.1-treepacks.png 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> |
Comments |
Comment by Stéphan AIME [ 08/Jun/11 ] |
I tried to add a first dummy hidden pack: <packs> But this leads into an ArrayOutOfBoundsException: Exception in thread "AWT-EventQueue-0" java.lang.IndexOutOfBoundsException: Index: 9, Size: 9 |
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 |
Attachments: | FinnishFirstPage.gif 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 |
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. 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`: And in the source for the main IzPack JFrame: 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 |
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); }} /**
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: | 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 CompilerData compilerData = new CompilerData(compression, kind, null, Instead, it tries to set it with: But then it seems that when i get to CompilerConfig#getXMLTree(), it |
Comments |
Comment by Mark Miller [ 24/Sep/10 ] |
from the mailing list:
|
Comment by Anthonin Bonnefoy [ 11/Oct/10 ] |
Pico container was not correctly initialised. |
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 |
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. Everything works fine in the GUI side. 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: The Pack1 definition: The A definition in conditions.xml: The A selection in userInputSpec.xml: |
[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. 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 To resolve/workaround the issue I have removed uninstaller="SummaryLoggerInstallerListener. Regards, |
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? |
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 In userInputSpec.xml (which defines the UserInputPanel) <field type="search" variable="license_locn"> 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"> 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: | 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... |
Comments |
Comment by Anthonin Bonnefoy [ 11/Oct/10 ] |
The problem was due to some remains of non-functional maven 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 at com.izforge.izpack.merge.resolve.ClassPathCrawler.searchClassInClassP On windows xp, java 1.6 |
Comments |
Comment by Anthonin Bonnefoy [ 15/Sep/10 ] |
Reproducible on linux and windows : |
Comment by Anthonin Bonnefoy [ 23/Sep/10 ] |
Fix in 5.0.0-beta2 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 Instead, it should pick up the correct uninstaller path. |
Comments |
Comment by Mark Miller [ 10/Sep/10 ] |
should be:
|
Comment by Mark Miller [ 15/Dec/10 ] |
I have made a fix for this off 4.3.3 here: |
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. 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. |
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 Source (Next Steps Section)
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: | 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; 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. java.lang.SecurityException: Invalid signature file digest for Manifest main attributes 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: 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? 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: | diff1.txt diff.txt | ||||||||||||||||
Issue Links: |
|
||||||||||||||||
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. Index: UserInputPanel.java
// validate the input
|
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: | diff1.txt diff.txt | ||||||||
Issue Links: |
|
||||||||
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:
|
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 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. |
[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.
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: | 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: | 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: 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: 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é, 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. |
[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 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.) hlp.append("Path=" + $P_QUOT + $Path + $P_QUOT + 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) 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. myInstallScript.appendln(new String[] { 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. myUninstallScript.appendln(new String[] { 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. 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 |
[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. |
[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.
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: |
|
||||||||
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: | 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. |
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. |
[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: |
|
||||||||
Number of attachments : | 0 |
Description |
As described in 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: |
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: | 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: Current behavior: 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: Current behavior: |
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: | 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. 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: The installer reports an error: C:\Entwicklung\jvoicexml\org.jvoicexml>java -jar jvxml-install-0.7.3.EA.jar at com.izforge.izpack.installer.Unpacker.run(Unknown Source) The web installer was build with: <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> The ANT snippet to create the installer is the following: <izpack input="$ {etc}/install.xml" output="$ {dist.install.jar}" " 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 } while (read > 0); |
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: else { result.append(ch); } } catch (MalformedURLException e) { return url; }} /**
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: | com.izforge.izpack.integration.InstallationTest.txt |
Number of attachments : | 1 |
Description |
Installation Test (com.izforge.izpack.integration.InstallationTest) fails when compiling izpack. Stacktrace: |
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: | 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. 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: | 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:
======= PATCH DESCRIPTION ======= The self-extracting package consists of three parts concatenated together: We assume that the Linux end user has certain basic tools available (sh, head/tail, chmod, mkdir, rm, tar). ======= PATCH FILES ======= Binaries for Linux, downloaded and built on Red Hat Enterprise Linux 3.0 Update 7: Utility written by me: |
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: This also needs to be in git: 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: | FinishPanel.java.patch 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). |
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 |
Comment by Mark Miller [ 15/Dec/10 ] |
I have backported a fix for this off 4.3.3 here: 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. 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: | 0001-allow-for-multiple-validators-in-text-field.patch 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: | 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 |
Comments |
Comment by Ben Golding [ 05/Apr/10 ] |
Also consider use of bbfreeze to convert izpack2exe.py to izpack2exe (linux binary). 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: |
[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: |
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. |
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. 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. 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: 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 |
Comment by Jonas Stenberg [ 28/Sep/12 ] |
We solved this by having an install.bat script for windows containing the following lines: ...then we package the install.bat and the installer.jar in a zip file for distribution. |
[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: 7-Zip (A) 4.64 Copyright (c) 1999-2009 Igor Pavlov 2009-01-03 C:\Program: WARNING: The system cannot find the file specified. Creating archive installer.7z WARNINGS for files: File size Ratio Format Name Packed 0 files. Workaround: use a relative path |
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: '7za' is not recognized as an internal or external command, Workaround: |
[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:
The log file contains this:
--------------- 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. |
[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: <run-privileged check="strict" />
the installing user must have admin rights for installation. 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: this panel-configuration.xml contains as example this: 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, 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: | FileInputField.java StringTool.java UserInputPanel.java 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 problem is in the "FileInputField.class": public File getSelectedFile() return result; The result of "JTextField.getText()" will never be NULL! JTextField tef = new JTextField(); File file = new File( "" ); Conclution: Read every "JTextField.getText()" with something "trimToNULL()" (even the userinput of "space" shoult be not a problem). public static String trimToNull( String 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. |
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: | 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-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, |
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: | scr1.png 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: | 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. |
[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() 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. The xml structure can look like the following: |
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. <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". 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. |
[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: | 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)); 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: | 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: | ShellLink_cxx.patch ShellLink.dll ShellLink_rc.patch 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. |
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: |
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. |
[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: |
|
||||||||
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> <dynamicvariables> /installation.properties" type="options" <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: 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: | 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: | 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: | 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. I refactored the parse system to achieve this with IzPack alone. Syntax in install.xml is as follows: Example: 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: | InstallerFrame.layout.patch InstallerFrame.patch UninstallData.patch |
Number of attachments : | 3 |
Description |
InstallerFrame.java starts the installation process by executing // We show the frame 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); So the checkedhellopanel seems to be unaware that the UninstallString may be located in the HKCU instead of HKLM. So I suspect that fixing this is simple: just check the HKCU as well before bailing out. ----- |
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. <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. |
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" |
Attachments: | JavaApplicationStub |
Number of attachments : | 1 |
Description |
I've experimented with izpack2app and have found newer Mac Log: 15/02/10 16:14:26 [0x0-0x10a10a].GenealogyJ[45202] [JavaAppLauncher I've resolved this issue by replacing JavaApplicationStub with a newer 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. 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: | CompilerConfig_4.3.4v2.java 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> |
Comments |
Comment by Tuomo Soinio [ 15/Feb/10 ] |
As I cannot figure out a way to re-open 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:
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 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: 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: | izpack-527.diff VariableSubstitutor-escape-patch 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 |
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: |
|
||||||||
Number of attachments : | 0 |
Description |
For integrating upgrade handling there is a need to pre-configure an installed application. Requirements:
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. |
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: |
|
||||||||
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> <condition type="variable"> This should be possible also for dynamic variables: <dynamicvariables> <condition type="dynamicvariable"> 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> <condition type="dynamicvariable" id="condfromdynvar"> |
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. |
[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: | UserInputPanelConsoleHelper.java 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. |
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: | ConsoleInstaller.java 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> <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: | 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: |
|
||||||||||||||||||||||||
Number of attachments : | 0 |
Description |
I intend to introduce upgrade handling in IzPack into discussion. Major requirements that might be provided:
Note: |
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: | install.xml izpack_issue_519.patch | ||||||||
Issue Links: |
|
||||||||
Testcase included: | yes | ||||||||
Number of attachments : | 2 |
Description |
I prepared an enhanced and more flexible dynamic variable assignment system. This includes:
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:
|
Comment by Rene Krell [ 09/Feb/10 ] |
Added a patch that shows the current implementation state for discussion. |
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. |
Comment by Rene Krell [ 11/Feb/10 ] |
Replaced files:
|
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:
|
Comments |
Comment by Julien Ponge [ 08/Feb/10 ] |
Follow-up on the list:
|
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:
For uninstallation, the exec-admin file is written by UninstallDataWriter to indicate that the uninstaller should elevate privileges.
|
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" izPackDir="${basedir} "> " override="true"/> "/> Those should be handled as if they would have been defined by the <variable> element in install.xml. |
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 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: | 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: | 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: | 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: 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: | 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 >
-> Processing : install.xml -> Fatal error : |
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-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: | 1.jpg 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> 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="[Íê³É]"/> |
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. 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: | IZPACK-501.patch | ||||||||
Issue Links: |
|
||||||||
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] 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. |
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 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. 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. ? |
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 |
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: | 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: |
[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: | izpack-installer-headless-templates.diff |
Number of attachments : | 1 |
Description |
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: | 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: | 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> <fileset dir="plain" targetdir="$ {INSTALL_PATH}" override="true"> <exclude name="${INSTALL_SUBPATH} /etc/*"/> 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: | ProcessorDirFieldNew.patch ProcessorDirField.patch |
Number of attachments : | 2 |
Description |
Processor for field should be available for all the field types. |
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. |
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 ] |
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: 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: | AgentConfigProcesses.xml changes-4.3.1-to-4.3.2.diff.bz2 install-trace-4.3.1.log install-trace-4.3.2.log izpack-installer-definition.xml |
Number of attachments : | 5 |
Description |
Notes: |
Comments |
Comment by Charles Leu [ 10/Nov/09 ] |
Additional Notes/Corrections: |
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:
|
Comment by Charles Leu [ 11/Nov/09 ] |
|
Comment by Charles Leu [ 19/Nov/09 ] |
Notes:
|
Comment by Charles Leu [ 19/Nov/09 ] |
|
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-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: | temp-dir-4.3.3.diff 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. |
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- |
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 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: | Unix_Shortcut.java 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. |
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 |
Attachments: | install.xml UserInputPanel-5.0.png UserInputPanel-cutoff.png 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. |
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): :" 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: | 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: | eng.patch 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: | UserInputPanel.patch | ||||||||
Issue Links: |
|
||||||||
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. 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. |
Comments |
Comment by Mark Miller [ 20/Dec/10 ] |
see |
[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) } 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"> $ {FILE_SEPARATOR}${MOD_PATH}${FILE_SEPARATOR}data" The documentation says that this will create the directory if not exists, but I get always an error messages: |
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, |
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:
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? |
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. |
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.
|
[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:
|
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: | 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: | 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. |
Comment by Tom Helpstone [ 18/Nov/14 ] |
You do not mention, whether you are using <variables> or <dynamicvariables>. 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? Regards, |
[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"> The following gives the exception <pack name="Inculder" id="includer" required="no"> The exception is : |
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-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, |
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: |
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. 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> /Readme.txt" /> /shortcutSpec.xml" /> Related Issues: issue |
[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: | 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 <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"/> The following code that must replace the method TargetPanel.panelActivate /**
|
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) <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: | 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 |
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"> (1) When entering the panel for the first time, the defaults '127.0.0.1' and 'secret' (scrambled using *) are shown 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: " 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: | IZPACK-453-jponge.diff IzPack_ResourceBundle_DokuPatch.txt IzPack_ResourceBundle_Patch.txt 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" 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="Heading.image" src="heading_Brand1.png" condition="is.Brand1"/> 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. ResourceManager should then look for the asked resource in the following order: i.e. Thank you in advance |
Comment by Patrick Zbinden [ 01/Feb/10 ] |
Hello Attached a patch to realize the "resource bundle". If the patch will be applied, I can also send you the patch for documentation. Regards |
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. 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 |
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()) 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: | izpack_installer.patch |
Patch Submitted: |
Yes
|
Number of attachments : | 1 |
Description |
If: Then: I solved the problem by doing the following: Attached you can find the patch. |
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. 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. |
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. |
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 <pack name="Core" required="yes" size="10000000"/> Given:
After compilation, the Pack.getSize() method will return:
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: | 0001-fix-for-tree-pack-viewer-first-one-always-greyed-out.patch 0002-same.patch install.xml 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, this means that ghost installations remain in the registry, that windows things error: "Java Virtual Machine Launcher" |
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: | 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" |
Attachments: | 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 Better way: |
[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: | bug1.gif bug2.gif ISO-ITU-OSI-100-install(2).jar traces first run.txt traces second run.txt 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... 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: 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. i.e. <file src="abc.txt" todir="$INSTALL_PATH/abc" /> Write a script sh/bat file something like this 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: | 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. b) On repeated installation an (additional) shortcut in the program group "Other" is created c) Consequently these additional shortcuts are not removed, when I run the uninstaller d) Categories don't have any effect? e) Desktop icons on Gnome don't work |
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: |
|
||||||||
Number of attachments : | 0 |
Description |
The Uninstaller does not delete all folders. The installation folder and the uninstaller folder are not deleted. |
Comments |
Comment by Julien Ponge [ 30/Sep/09 ] |
Fixed by |
[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. |
[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. |
[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. |
[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: | Bug.jpg |
Number of attachments : | 1 |
Description |
When using the danish language pack some values are missing. 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: Greetings |
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. getBytes() uses the current codepage, but the XML is UTF-8 by default. |
Comments |
Comment by Roman Platonov [ 05/Aug/09 ] |
Hi! |
Comment by Lauri Korpela [ 07/Aug/09 ] |
This sounds like a duplicate of |
Comment by Timothy Fridey [ 18/Mar/11 ] |
Looks like this should be marked as fixed. Fixed since 4.3.2 see: |
[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: | 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. 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. java.lang.NullPointerException while trying to download http://www-intra.sozvers The web installer should catch such errors and report correctly which package failed to download and why. 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: | 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: | 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 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, |
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. However it works fine if "os" is provided as attribute. /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 is used instead of <executable targetfile="${LBPLUGIN_INSTALL_PATH} /uninstall.sh" stage="never" os="unix"/> |
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 /uninstall.sh" stage="never"> |
Comment by Kjell Braden [ 27/Jan/10 ] |
Hi! Sorry for leaving you alone for so long. I just found |
[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: |
|
||||||||
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. Index: UserInputPanel.java
// validate the input
|
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. Kind regards |
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 Julien, you've posted a comment in that ticket that no further releases are planned for 4.3 code branch. Thank you in advance! Kind regards |
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-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:
|
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 |
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: | 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
|
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. 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. |
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. |
[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 In my project I have a UserInputPanel which presents a FileInputField, 1.) make VariableExistanceCondition aware of $ENV[] variables |
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 |
Attachments: | install.xml test_install.jar 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.' |
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, |
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: | 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-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? |
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. |
[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: | 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> 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"/> 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:
|
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!). See also registrySpec.xml-format which also references packs by name: <registry> |
[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: | 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!" |
[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: | 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 |
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: | 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 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> 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: property in the build file. |
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. What happens: 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: | izpack_enhance_unattended_installs_patch_r2796.txt.gz izpack-issues_295_405_against_r2844.patch.gz | ||||||||
Issue Links: |
|
||||||||
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: I have already prepared an implementation in my local SVN copy of the trunk which would handle this. |
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:
This meets all requirements for unattended installations for me at this time. |
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, 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: Issue 295 + 405: 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 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: |
[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 |
Attachments: | 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"> <field type="text" variable="username"> Here is the stacktrace: at com.izforge.izpack.validator.DBConnectionValidator.validate(DBConnectionValidator.java:122) 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. |
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"/> 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" [...] /> <res id="LicencePanel.licence" src="$trunk/LICENSE" [...] /> |
Comments |
Comment by Christoph Panwinkler [ 26/Jan/10 ] |
also on Windows 7 with variables declared in install.xml e.g. <pack name="Java Runtime" parent="Core" required="yes"> " targetdir="$ {INSTALL_PATH}\jdk"> |
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 Add the marked lines (sorry about the formatting loss): // We get the fileset list File dir = new File(dir_attr); if (!dir.isAbsolute()) { dir = new File(basedir, dir_attr); } //ADDITION***************************************************** //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: | 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. |
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 + final String vAllow = + } + private boolean isThereIsAnyWhitespace(String path) + }
|
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:
|
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. |
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: | build_xml_for_LicensePanelConsoleHelpers_20090608_patch.txt 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: | 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 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: | izdiff.txt Wremja-Installer-1.0-SNAPSHOT.jar |
Number of attachments : | 2 |
Description |
I've got an installer created with IzPack and the <pack200/> option enabled. <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 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: | 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: |
|
||||||||
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)
So, it seems that the process does not return. The script with the pseudo unique name is correctly written (and returns the correct path when called externally). But the call to , true ).trim(); 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. |
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: | 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. 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"> |
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. |
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: |
|
||||||||
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: | IZPACK-386-Uninstaller.patch UninstallerElevation.patch |
Patch Submitted: |
Yes
|
Number of attachments : | 2 |
Description |
The fix for 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:
Note that the patch for PrivilegedRunner.java is intended to be applied after the patch of |
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 |
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: | 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:
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: | install.xml 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. 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: |
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 I would expect evaluation of the condition at install-time. |
[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: | JDKPanel.patch 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. |
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. |
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: | izpack2exe.py 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' I have a resources section like this <resources> <res id="TargetPanel.dir" src="@{filtered.resources.dir} /target-panel-dir.txt" /> |
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: | pol.gif 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ę przeczytać poniższe informację: "/>
but should be: <str id="InfoPanel.info" txt="Proszę przeczytać poniż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 |
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. ManagementFactory.getRuntimeMXBean().getInputArguments() to determine what argumnents were passed to the JVM, and passes these to spawned processes.
Any -DDEBUG and -DTRACE argument will be passed to spawned processes. |
Comment by Tim Anderson [ 05/Aug/12 ] |
Turns out that RuntimeMXBean.getInputArguments() doesn't handle spaces in arguments, so path names get mangled. 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: 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: | patch_20090528.txt patch-24-8-2009.txt patch.txt src_lib_com_izforge_izpack_panels_InstallationGroup_20090601_build_patch.txt src_lib_com_izforge_izpack_panels_InstallationGroup_20090601_patches.txt src_lib_com_izforge_izpack_panels_UserInputPanelConsoleHelper_052609_patch.txt src_lib_com_izforge_izpack_panels_UserInputPanelConsoleHelper_20090529_patch.txt src_lib_com_izforge_izpack_panels_UserInputPanelConsoleHelper_20090601_patch.txt 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. 1) Using title field in UserInPutPanel causes Exception and following input fields are skipped 2) Using check field in UserInPutPanel causes Exception and following input fields are skipped 3) Rule field in UserInputPanel is not implemented, those fields are simply skipped 4) Panel validators are not called 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. |
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? Thank you, |
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 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 @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): @5) JDKPathPanel, DefaultTargetPane not Implemented, therefore no change expected Additional finding: |
Comment by Mounir el hajj [ 17/Apr/09 ] |
please try this new patch M |
Comment by Peter Heiles [ 17/Apr/09 ] |
I will try out the newer patch, for now my Test Case for 2: |
Comment by Peter Heiles [ 17/Apr/09 ] |
Just tested the changes: display: " Server IP: [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). |
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 @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
|
Comment by Peter Heiles [ 20/Apr/09 ] |
Added patches to fix described problems: |
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. |
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:
Next capabilities to add are:
|
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 < } 125,128c123 — |
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:
|
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:
|
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: 1.: Initial display 2. select "1" 3. Redisplay: 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. 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: | ita.xml.diff |
Patch Submitted: |
Yes
|
Number of attachments : | 1 |
Description |
Standardized translation of "progress" to "progresso". |
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: | izpack-365.patch |
Number of attachments : | 1 |
Description |
[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: |
|
||||||||||||
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:
|
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. |
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> 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: | Screenshot-Izpack-lan.png |
Number of attachments : | 1 |
Description |
Hi, I forgot to tell you that, So if the chn display "中文", the twn is the same too. 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: |
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", 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. |
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. |
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
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="java" id="setCatalina"> <installerrequirements> I tried with Izpack4.3 test release and below is the error log: Total time: 10 seconds
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Sou |
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" ?> <!-- To compile it :
<installation version="1.0"> <!-- <!-- <!-- <!-- <variables> <dynamicvariables> <conditions> <installerrequirements> <!-- <!-- <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 name="HiddenTest" required="no" preselected="yes" hidden="true" condition="izpack.selected.hideme"> </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" /> </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"> It throws the following error while loading the TreePacksPanel and shows and empty panel. If it is not fixed for TreePacksPanel, Can it be? |
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 |
[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. 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} " " ? Thank you. Best regards, |
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: 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 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". Also note that this might be related to |
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:
|
[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? |
Comments |
Comment by Florian Buehlmann [ 23/Mar/09 ] |
Possible solution: 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: | IZPACK-349.patch 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: |
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 emitWarning() returns: The comment is currently: It should be: |
[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: | 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-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: | 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: | twn.gif twn.xml |
Number of attachments : | 2 |
Description |
Hi, I come from Taiwan, and our language is Chinese traditional. 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: | IZPACK-339.patch UnpackerFileNotFoundWarning.patch | ||||||||||
Sub-Tasks: |
|
||||||||||
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: |
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 |
Comment by Florian Buehlmann [ 16/Mar/09 ] |
I was able to applay the patch, that's ok. |
[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: | 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: | 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
|
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 |
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, |
[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: | IZPACK-335-DTD.patch 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. 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: |
|
||||||||||
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> <conditions> <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)+(!T) => F+F => F I believe many others may be experiencing the same trouble with conditionals that I did because of this. Thanks, |
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. 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: 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, |
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: | 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. 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. |
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 |
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: | IZPACK-331.patch 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: 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: | 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: |
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.
|
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 https://izpack.github.io/documentation/installation-files.html#os-make-a-library-os-dependent 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: |
|
|||||||||||||||||||||||||||||||||||
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: | IZPACK-325-DTD.patch jarAttributeForPanelElement2.patch jarAttributeForPanelElement3.patch 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: /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:
|
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 |
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: 2. jar="myPanel.jar" is specified: 3. jar="": |
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. Christian is it possible to send me a patch for the documentation? |
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"> </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" /> |
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):
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: |
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: | 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: | 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: | HyperlinkHandler.zip 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. |
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: | 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. The main entry class com/izforge/izpack/installer/Installer.java, has been modified to take as arguments: These 3 possibilities will instantiate a ConsoleInstaller who has 3 methods to achieve respectively the above
|
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 Thanks a lot |
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 Thanks a lot |
Comment by Mounir el hajj [ 15/Apr/09 ] |
Hi Julien i will have a look Thanks |
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: | 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); 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: | IZPACK-318-Destroyer.patch 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 { // call original constructor code catch (Exception e2) {} // ignore possible exception from showMessageDialog |
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:
|
[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: |
|
||||||||
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, 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. |
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. |
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. |
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: | 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. 2. Click on the name of any of the other packs in the list, e.g. "HTML Documentation". 3. Click on one of the checkboxes. 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 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: | 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: |
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. |
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 |
Comment by Christian d'Heureuse [ 23/Mar/09 ] |
Prerequisite for: |
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-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 The reason for this error is that NullPointerExceptions usually don't have an associated detail message. 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.: |
Comments |
Comment by Florian Buehlmann [ 02/Mar/09 ] |
A more useful message is now displayed like: "Internal error occured : " + err.toString(); |
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: | LoosePackSize.patch |
Patch Submitted: |
Yes
|
Number of attachments : | 1 |
Description |
The "Total space required" value for "loose" packs is always 0. Reason: public void setLoosePackInfo(boolean loose) } In Packager.writePacks(), this length value is used to calculate the package size (Pack.nbytes): // even if not written, it counts towards pack size |
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. |
Comment by Florian Buehlmann [ 02/Mar/09 ] |
The attached patch should fix the pack size problem. |
Comment by Florian Buehlmann [ 02/Mar/09 ] |
See attached patch which should fix this pack size problem. |
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. |
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. |
[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: | 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. |
Comment by David Duponchel [ 11/Mar/09 ] |
Fixed by refactoring the class AutomatedInstaller. |
[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: | IZPACK-308-Alternative1.patch IZPACK-308-Alternative2.patch 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: |
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. |
[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. |
[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. |
[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. |
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. |
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: | 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. |
Comments |
Comment by Tim Anderson [ 31/Jul/12 ] |
A. For quit, the dialog has:
B. For the directory creation, the dialog has:
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. |
Comments |
Comment by Tim Anderson [ 04/Aug/12 ] |
These aren't bugs.
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. |
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. |
[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) |
Comments |
Comment by Tim Anderson [ 31/Jul/12 ] |
This looks to be the behaviour explained here: http://www.devx.com/DevX/Tip/31605
|
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: | izpack-issues_295_405_against_r2844.patch.gz izpack_win_setup_api.patch.tar.gz merge-out.txt SetupAPI_win32pad_example.tar.gz | ||||||||||||||||
Issue Links: |
|
||||||||||||||||
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? 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:
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, "Setup API" and "Windows Installer" are some completely different worlds. What I do not want is to confuse existing IzPack tags too much. Some "brainstorming":
My favorite question at the moment: 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.
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:
Maybe there are some formatting errors, I use the AnyEdit Eclipse plugin to remove trailing spaces at the end of lines, for example. Thanks, |
Comment by Rene Krell [ 02/May/09 ] |
More TODOs:
|
Comment by Rene Krell [ 04/May/09 ] |
This is a more complete patch:
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: Forgot to say even for the previous patches: Note: |
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):
|
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 |
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, 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.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: Issue 295: 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 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:
... and especially a call for help with:
|
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. |
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> |
[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"> </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" /> " size="30" /> 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 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: | 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: |
|
||||||||
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. <panel classname="UserInputPanel" id="my.panel.id" > 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. |
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. |
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. |
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 @Override @Override public String getWarningMessageId() { return "database.connection.error"; } @Override } For example, using this validator, the message box reports (in case of error obviously): Title: data.validation.error.title |
Comments |
Comment by Alessandro Dionisi [ 16/Feb/09 ] |
It is sufficient to place the key into file CustomLangpack.xml_[ISO3Country] as following: <langpack> and return the relative key into the validator class. public class DatabaseServerValidator implements DataValidator { @Override @Override } |
[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. |
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:
|
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: |
|
||||||||
Number of attachments : | 0 |
Description |
The creation of a Web Installers based on the sample installation throws the following exception: -> Fatal error : 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: | 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:
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: | 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. |
Comment by Jeff Gordon [ 13/May/10 ] |
Cause is probably related to: |
Comment by Alwyn Schoeman [ 17/Aug/10 ] |
If you want a warning message you need to do the following: idata.canClose = 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 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. |
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. 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() |
[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
but the compiler is called with
so the property we actually need is
|
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: |
|
||||||||
Number of attachments : | 0 |
Description |
I have seen quite a few requests for a pure "text-based" installer generation. -Olivier P.S.: Just in case this sparks some interest, here are a few links: |
[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: | 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. 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> <include name="*/" /> </fileset> <!-- <file src="apache-tomcat-5.5.23" targetdir="${INSTALL_PATH} /tomcat" /> <file src="coreapp.war" targetdir="${INSTALL_PATH} /war" condition="!izpack.selected.tomcat.core" /> |
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: | 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. |
[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> <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> <panels> |
Comments |
Comment by Anthonin Bonnefoy [ 06/Feb/09 ] |
Hello Robert, |
Comment by Earl Hood [ 11/Feb/09 ] |
I get the same problem. The following is a snippet of the installation <resources> <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' 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: | 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: | izpack-nimbus.png izpack-nimbus-treepackpanel.png |
Number of attachments : | 2 |
Description |
trying to use <laf name="nimbus"> 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. 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: | 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 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:
Functionality Issue:
|
[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: | LoosePackEOFException.patch |
Patch Submitted: |
Yes
|
Number of attachments : | 1 |
Description |
During the installation of loose pack a EOFileException is thrown. <pack name="MyPack" id="my.pack.id" required="yes" preselected="yes" loose="true"> 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. |
[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: 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: | UninstallPath_Code.patch 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). |
Comments |
Comment by Julien Ponge [ 20/Jan/09 ] |
I agree with the proposed new feature, but the patch needs to be improved:
|
Comment by Florian Buehlmann [ 21/Jan/09 ] |
Attached two patches. The DOC patch includes the documentation changes. |
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: | IzPack_AutoInstallCondition_Patch_2.txt 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. |
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). |
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: | 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: | CalculateRelativePathCorrection.patch |
Patch Submitted: |
Yes
|
Number of attachments : | 1 |
Description |
We have a definition of a pack like the following: 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: | 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. |
[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: | izpack_packsvalidator.diff 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
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:
|
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: | consolidated.patch 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: | ShellLink_shortcutWorkaround_patch.txt 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: | guiprefs_LabelFontSize.zip 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: | 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: | 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: | 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 |
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 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: | 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: |
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: | IzPack_ProcessingJobs_Patch.txt IzPack_ProcessPanel_Patch2.txt IzPack_ProcessPanel_Patch.txt |
Patch Submitted: |
Yes
|
Number of attachments : | 3 |
Description |
We have our own implementation of ProcessPanel extended from standard IzPack ProcessPanel. 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. 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. 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 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: | 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 |
Comments |
Comment by Dan Tran [ 09/Jan/09 ] |
|
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 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 |