Under IzPack 3.11.0, when I include parse="yes" on my install.xml resource declaration statements, the compiler and/or installer seems to ignore the corresponding resources altogether. Under IzPack 3.10.2, the same statements successfully parsed and processed the resources.
Example:
<resources>
<res id="HTMLInfoPanel.info" src="Info.html" parse="yes" />
<res id="LicencePanel.licence" src="License.txt" parse="yes" />
.
<res id="TargetPanel.dir.windows" src="WindowsPath.txt"
parse="yes" />
.
</resource>
When I switched to 3.11.0, the HTMLInfoPanel and LicencePanel show blank content upon install and the TargetPanel shows a default path instead of the one in WindowsPath.txt. No compiler or installer error messages are given. If I remove the parse="yes" attribute, everything works fine except that variables are not substituted.
Things I have tried: (1) adding type="plain" or "xml" did not help; (2) using -DTRACE=true when launching the installer JAR file did not reveal any useful info.
I am using the IzPack standalone compiler and Java 1.6.0.
The attached zip file contains my 'IzPack' ECLIPSE project which I used to experiment with this problem. It includes all the files I am using to compile and install a test program excluding the IzPack 'standalone-compiler.jar' file. You can build and run the test standalone via the default target of my /IzPack/build/build.xml ANT config file (you will have to tweak the parameters in /IzPack/build/build.properties to fit your environment). The 'izpack.home' property in build.properties determines which version of IzPack is linked to.
If you have any workarounds for this problem I would very much appreciate you letting me know.
THANKS!
Bug
Closed
Major
IzPack 3.11.0 seems to ignore resources declared with the 'parse' attribute
I checked the source code and discovered how to fix this bug as follows:
In method addResources(XMLElement) in file /src/lib/com/izforge/izpack/compiler/CompilerConfig.java, change line #1369 as follows:
OLD: is = new BufferedInputStream(url.openStream());
NEW: is = new BufferedInputStream(originalUrl.openStream());
The bug is that when the 'parse="yes"' attribute is added to the resource declaration, the code preceding the above statement assigns the temporary parsed output file path to variable 'url', which initially contained the input path (the resource file). The input path was also assigned to 'originalUrl', so that's the variable to use in the above statement.