[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: |
![]() |
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 |
[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: |
![]() |
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: |
![]() |
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: |
![]() ![]() |
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 |
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: |
![]() ![]() ![]() ![]() |
||||||||
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: |
![]() ![]() ![]() |
||||||||
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: |
![]() |
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: |
![]() ![]() |
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: |
![]() ![]() |
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: |
![]() ![]() ![]() ![]() ![]() ![]() |
||||||||||||
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: |
![]() ![]() |
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)
|
|
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: |
![]() |
||||||||
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: |
![]() ![]() |
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)
|
|
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: |
![]() ![]() ![]() |
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: |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 |
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: |
![]() ![]() ![]() |
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)
|
|
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)
|
|
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)
|
|
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)
|
|
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)
|
|
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: |
![]() ![]() |
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)
|
|
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)
|
|
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: |
![]() |
||||||||
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)
|
|
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: |
![]() |
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: |
![]() |
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: |
![]() |
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: |
![]() ![]() |
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 |
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: |
![]() |
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: |
![]() |
||||||||
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: |
![]() |
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: |
![]() ![]() ![]() |
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: |
![]() ![]() |
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: |
![]() |
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: |
![]() ![]() |
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: |
![]() |
Number of attachments : | 1 |
Description |
Comments |
Comment by Paul Bors [ 16/Apr/13 ] |
Attached izPack jar packaged icons.png |
[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: |
![]() |
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: |
![]() ![]() ![]() |
||||||||
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: |
![]() ![]() |
||||||||||||||||
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: |
![]() ![]() ![]() ![]() |
||||||||
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: |
![]() |
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 "/> 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: |
![]() |
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: |
![]() ![]() ![]() ![]() |
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 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: |
![]() |
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: |
![]() |
||||||||
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 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: |
![]() ![]() |
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: |
![]() |
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: |
![]() |
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: |
![]() ![]() ![]() |
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: |
![]() ![]() ![]() ![]() |
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: |
![]() ![]() |
||||||||||||||||
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: |
![]() |
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: |
![]() ![]() ![]() ![]() |
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 ] |
|
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: |
![]() |
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: |
![]() ![]() |
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: |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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: |
![]() ![]() |
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: |
![]() |
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: |
![]() ![]() |
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: |
![]() |
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: |
![]() |
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: |
![]() |
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: |
![]() |
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: |
![]() |
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: |
![]() |
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 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: |
![]() ![]() |
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: |
![]() ![]() ![]() |
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: |
![]() |
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: |
![]() ![]() ![]() ![]() |
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: |
![]() ![]() ![]() ![]() ![]() |
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: |
![]() |
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: |
![]() |
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: |
![]() |
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: |
![]() |
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: |
![]() |
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: |
![]() |
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: |
![]() ![]() |
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 |