[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="http://izpack.org/schema/langpack" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://izpack.org/schema/langpack http://izpack.org/schema/5.0/izpack-langpack-5.0.xsd"> <str id="pack.application" txt="My Application" /> <str id="pack.application.description" txt="This pack contains only application files without templates." /> <str id="pack.templates" txt="Application templates" /> <str id="pack.templates.description" txt="This pack contains the application templates." /> templates." /> </izpack:langpack> File resource packsLang.xml_deu <?xml version="1.0" encoding="UTF-8"?> <izpack:langpack version="5.0" xmlns:izpack="http://izpack.org/schema/langpack" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://izpack.org/schema/langpack http://izpack.org/schema/5.0/izpack-langpack-5.0.xsd"> <str id="pack.application" txt="Meine Anwendung" /> <str id="pack.application.description" txt="Dieses Paket enthÃÆ’€lt nur Anwendungs-Dateien ohne Templates." /> <str id="pack.templates" txt="Templates" /> <str id="pack.templates.description" txt="Anwendungs-Templates" /> templates." /> </izpack:langpack> |
Comment by Rene Krell [ 11/May/15 ] |
The difference in behavior between console and GUI installation mode seems to be a flaw in exception handling. |
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="http://izpack.org/schema/configurationactions" xsi:schemaLocation="http://izpack.org/schema/configurationactions http://izpack.org/schema/5.0/izpack-configurationactions-5.0.xsd"> <pack name="Demo" > <configurationaction order="afterpack" > <configurable tofile="demo.properties" type="options"> <entry key="key1" operation="remove" /> <entry key="key2" operation="remove" lookupType="regexp" value=".*" /> </configurable> </configurationaction> </pack> </izpack:configurationactions> "key2" will be removed, but "key1" isn't removed, but should be so also. I've tested in 5.0.0-rc5-SNAPSHOT, but the problem should exist since 2010. |
Comments |
Comment by Tom Helpstone [ 24/Feb/15 ] |
The error s caused by an wrong if-condition in com.izforge.izpack.util.config.SingleConfigurableTask in method deleteOptions(). The analog method keepOptions() is done well. |
Comment by Tom Helpstone [ 24/Feb/15 ] |
Even worse: Because of the wrong if-condition entries will be removed regardless of their value, when an old value is configured for selection. |
Comment by Tom Helpstone [ 24/Feb/15 ] |
sent PR 320 |
Comment by Rene Krell [ 24/Feb/15 ] |
Oops, good catch, thank you. |
Comment by Rene Krell [ 24/Feb/15 ] |
Pull request merged. |
[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="http://izpack.org/schema/userinput" xsi:schemaLocation="http://izpack.org/schema/userinput http://izpack.org/schema/5.0/izpack-userinput-5.0.xsd"> <panel id="panel.test"> <field type="title" txt="Test panel" id="text.test.title" /> <field type="radio" variable="dbsystem"> <spec txt="with set"> <choice txt="MSSQL" value="mssql" id="text.dbsystem.mssql" /> <choice txt="Oracle" value="oracle" id="text.dbsystem.oracle" set="true" /> <choice txt="SAP Hana" value="hdb" id="text.dbsystem.hana" /> </spec> </field> <field type="divider"/> <field type="radio" variable="dbsystem2"> <spec txt="with default"> <choice txt="MSSQL" value="mssql" id="text.dbsystem.mssql" /> <choice txt="Oracle" value="oracle" id="text.dbsystem.oracle" default="true" /> <choice txt="SAP Hana" value="hdb" id="text.dbsystem.hana" /> </spec> </field> <field type="divider"/> <field type="radio" variable="dbsystem3"> <spec txt="just relying on variable"> <choice txt="MSSQL" value="mssql" id="text.dbsystem.mssql" /> <choice txt="Oracle" value="oracle" id="text.dbsystem.oracle" /> <choice txt="SAP Hana" value="hdb" id="text.dbsystem.hana" /> </spec> </field> </panel> </izpack:userinput> install.xml ... <conditions> <condition type="exists" id="haveInstallPath"> <variable>INSTALL_PATH</variable> </condition> </conditions> .... <dynamicvariables> <variable name="dbsystem" value="mssql" condition="!haveInstallPath"/> <variable name="dbsystem" value="hdb" condition="haveInstallPath"/> <variable name="dbsystem2" value="mssql" condition="!haveInstallPath"/> <variable name="dbsystem2" value="hdb" condition="haveInstallPath"/> <variable name="dbsystem3" value="mssql" condition="!haveInstallPath"/> <variable name="dbsystem3" value="hdb" condition="haveInstallPath"/> </dynamicvariables> .... <panels> <panel classname="TargetPanel" id="panel.target"/> <panel classname="UserInputPanel" id="panel.test"/> <panel classname="InstallPanel"/> </panels> ... There are always working the defaults just for the first of the radio fields, not for the subsequent fields, regardless if the default should come from the variable value itself or from the set/default attributes of each choice. |
Comments |
Comment by Rene Krell [ 26/Jan/15 ] |
Created pull request https://github.com/izpack/izpack/pull/305 with a fix. |
Comment by Rene Krell [ 27/Jan/15 ] |
Pull request merged. |
[IZPACK-1211] UserInputPanel: Missing variable resolution in attribute <field><spec text="..."/><field> including the according translations Created: 22/Jan/15 Updated: 24/Feb/15 Resolved: 24/Feb/15 |
|
Status: | Resolved |
Project: | IzPack |
Component/s: | Panels |
Affects Version/s: | 5.0 |
Fix Version/s: | 5.0 |
Type: | Bug | Priority: | Minor |
Reporter: | Rene Krell | Assignee: | Rene Krell |
Resolution: | Fixed | Votes: | 0 |
Labels: | 5.0.0-rc5 | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Number of attachments : | 0 |
Description |
Provided there is a panel specification in userInputSpec.xml like this: <panel id="panel.test"> <field type="title" txt="Test panel" id="text.test.title" /> <field type="staticText" align="left" txt="${INSTALL_PATH}${FILE_SEPARATOR}${application.folder}" /> <field type="text" variable="targetsettings.target"> <spec txt="Target directory: ${INSTALL_PATH}${FILE_SEPARATOR}" id="text.targetsettings.target" size="20" set="${application.folder}" /> <validator class="com.izforge.izpack.panels.userinput.validator.NotEmptyValidator" txt="Target directory path is mandatory!" id="text.targetsettings.target.error" /> </field> </panel> and a <panel> section in install.xml like this <panels> <panel classname="TargetPanel" id="panel.target"/> <panel classname="UserInputPanel" id="panel.test"/> ... </panels> there doesn't happen any variable resolution for the txt="Target directory: ${INSTALL_PATH}${FILE_SEPARATOR}" attribute value including its translations although the according variables are set. Should be translated here to make variable replacement consistent everywhere. |
Comments |
Comment by Rene Krell [ 22/Jan/15 ] |
Created pull request: https://github.com/izpack/izpack/pull/304 It should solve this problem in common. All static text fields of Swing installers are translated on panel activation now by default, without forcing the developer to override this in the according field implementation explicitly. This way there are also other fields fixed that were affected by this, for instance rule fields. |
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="http://izpack.org/schema/configurationactions" xsi:schemaLocation="http://izpack.org/schema/configurationactions http://izpack.org/schema/5.0/izpack-configurationactions-5.0.xsd"> <pack name="Core files"> <configurationaction order="afterpack"> <!-- Patch and merge all property files --> <configurableset type="options" cleanup="true" keepOldKeys="false" keepOldValues="true" overwrite="true" todir="${INSTALL_PATH}/config" condition="isCompatibleUpgrade"> <fileset dir="${INSTALL_PATH}/config"> <include name="*.properties.configbak"/> </fileset> <mapper type="glob" from="*.properties.configbak" to="*.properties"/> </configurableset> <configurable type="options" cleanup="true" tofile="${INSTALL_PATH}/config/system.properties" condition="isCompatibleUpgrade"> <entry key="prop1" value="false"/> <entry key="prop2" value="true"/> </configurable> </configurationaction> </pack> </izpack:configurationactions> The expectation is first to overtake old values of preserved keys to the new configuration and after that explicitly setting prop1 and prop2. <izpack:configurationactions version="5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:izpack="http://izpack.org/schema/configurationactions" xsi:schemaLocation="http://izpack.org/schema/configurationactions http://izpack.org/schema/5.0/izpack-configurationactions-5.0.xsd"> <pack name="Core files"> <configurationaction order="afterpack"> <!-- Patch and merge all property files --> <configurableset type="options" cleanup="true" keepOldKeys="false" keepOldValues="true" overwrite="true" todir="${INSTALL_PATH}/config" condition="isCompatibleUpgrade"> <fileset dir="${INSTALL_PATH}/config"> <include name="*.properties.configbak"/> <exclude name="system.properties*"/> </fileset> <mapper type="glob" from="*.properties.configbak" to="*.properties"/> </configurableset> <configurable type="options" cleanup="true" keepOldKeys="false" keepOldValues="true" patchfile="${INSTALL_PATH}/config/system.properties.configbak" tofile="${INSTALL_PATH}/config/system.properties" condition="isCompatibleUpgrade"> <entry key="prop1" value="false"/> <entry key="prop2" value="true"/> </configurable> </configurationaction> </pack> </izpack:configurationactions> It should be fixed to meet the initial expectation. |
[IZPACK-1156] Allow replaceInstallPath attribute for file fields Created: 18/Aug/14 Updated: 19/Aug/14 |
|
Status: | Open |
Project: | IzPack |
Component/s: | Installer |
Affects Version/s: | 5.0 |
Fix Version/s: | 5.0 |
Type: | Improvement | Priority: | Minor |
Reporter: | Ahmed Abu Lawi | Assignee: | Unassigned |
Resolution: | Unresolved | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Number of attachments : | 0 |
Description |
Allow a replaceInstallPath attribute that can be added to the specs of a user input panel file, directory or multiple file field. If this attribute is set to true, the installer will check to see if the install path is a sub path of the given file or directory and replace any instances of the install path with the variable, ${INSTALL_PATH}. While performing the auto install, the ${INSTALL_PATH} variable will be substituted with the install path provided at the top of the auto-install.xml file. This feature will allow users of the auto install to update the install path in only one part of the auto-install.xml file instead of updating every path that needs be changed. |
Comments |
Comment by Rene Krell [ 19/Aug/14 ] |
I don't still understand this sufficiently, especially the advantage of this. If this concerns just an auto-install.xml you can use every kind of XML preprocessing (Maven Config Processor Plugin) to replace some placeholders. 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 |