[#IZPACK-15] The <xinclude> directive does not work when trying include relative resources where the compile is not run from the same directory as the installation file. - jira.codehaus.org

IzPack

The <xinclude> directive does not work when trying include relative resources where the compile is not run from the same directory as the installation file.

Created: 23/Feb/08 09:02 PM Updated: 29/Feb/08 02:29 PM Resolved: 24/Feb/08 02:19 PM

Return to search

Component/s:

Compiler

Affects Version/s:

3.11.0

Fix Version/s:

4.0.0

Time Tracking:

Not Specified

File Attachments:	1. IZPACK-15.patch (2 kB)
Environment:	Windows Visa Premium

Description

« Hide

The <xinclude> directive does not work when trying include relative resources where the compile is not run from the same directory as the installation file. The verify, using the sample, create locales.xml file in the same directory as the install.xml. The content of this file should look like:

<?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
<xfragment>
        <langpack iso3="eng"/>
        <langpack iso3="fra"/>    
</xfragment>

and then change the <locales> component in install.xml to look like:

    <locale>
        <!--
        <langpack iso3="eng"/>
        <langpack iso3="fra"/>
        -->
        <xinclude href="locales.xml" parse="xml"/>
    </locale>

Running the compiler on this produces this output:

c:\package\IzPack>compile sample/install.xml -b ./sample -o sample/install.jar

.::  IzPack - Version 3.11.0 ::.

< compiler specifications version: 1.0 >

- Copyright (c) 2001-2008 Julien Ponge
- Visit http://izpack.org/ for the latest releases
- Released under the terms of the Apache Software License version 2.0.

-> Processing  : sample/install.xml
-> Output      : sample/install.jar
-> Base path   : ./sample
-> Kind        : standard
-> Compression : default
-> Compr. level: -1
-> IzPack home : .

-> Fatal error :
   Error parsing installation file
com.izforge.izpack.compiler.CompilerException: Error parsing installation file
        at com.izforge.izpack.compiler.CompilerConfig.getXMLTree(CompilerConfig.java:1763)
        at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:316)
        at com.izforge.izpack.compiler.CompilerConfig.main(CompilerConfig.java:2230)
        at com.izforge.izpack.compiler.Compiler.main(Compiler.java:709)
Caused by: net.n3.nanoxml.XMLException: net.n3.nanoxml.XMLParseException: could not load content, SystemID='file:.', Line=30
        at net.n3.nanoxml.StdXMLParser.parse(StdXMLParser.java:203)
        at com.izforge.izpack.compiler.CompilerConfig.getXMLTree(CompilerConfig.java:1759)
        ... 3 more

(tip : use -? to get the commmand line parameters)
c:\package\IzPack>

The problem is that the "systemID" passed to the XMLElement constructor is "file:.". I tracked this down and found two problems. In CompilerConfig.java at line 1738, the code reads

            reader = new StdXMLReader(new FileInputStream(filename));

this uses the StdXMLReader that takes an input stream. Inside that constructor, the systemID is set to "file:.". A second problem is that at the end of that constructor is a line that reads:

        this.startNewStream(new StringReader(charsRead.toString()));

which pushes on the stream stack a input stream that will immediately see EOF because "charsRead" is a StringBuffer created right in this constructor and is empty.

I attempted to fix this problem by adding the line:

            reader.setSystemID(file.toURL().toExternalForm());

at line 1739 in CompilerConfig.java, but that did not work because of the initial stream that is pushed on as mentioned above. As soon as one character was read from the reader, it would hit EOF, pop off the stream which would restore the "file:." systemID, undoing the the setting that I just did with the above line.

So the fix is to add the line that I added and to remove the start of the new stream in the StdXMLReader constructor.

Description

<?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
<xfragment>
        <langpack iso3="eng"/>
        <langpack iso3="fra"/>    
</xfragment>

and then change the <locales> component in install.xml to look like:

    <locale>
        <!--
        <langpack iso3="eng"/>
        <langpack iso3="fra"/>
        -->
        <xinclude href="locales.xml" parse="xml"/>
    </locale>

Running the compiler on this produces this output:

c:\package\IzPack>compile sample/install.xml -b ./sample -o sample/install.jar

.::  IzPack - Version 3.11.0 ::.

< compiler specifications version: 1.0 >

- Copyright (c) 2001-2008 Julien Ponge
- Visit http://izpack.org/ for the latest releases
- Released under the terms of the Apache Software License version 2.0.

-> Processing  : sample/install.xml
-> Output      : sample/install.jar
-> Base path   : ./sample
-> Kind        : standard
-> Compression : default
-> Compr. level: -1
-> IzPack home : .

-> Fatal error :
   Error parsing installation file
com.izforge.izpack.compiler.CompilerException: Error parsing installation file
        at com.izforge.izpack.compiler.CompilerConfig.getXMLTree(CompilerConfig.java:1763)
        at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:316)
        at com.izforge.izpack.compiler.CompilerConfig.main(CompilerConfig.java:2230)
        at com.izforge.izpack.compiler.Compiler.main(Compiler.java:709)
Caused by: net.n3.nanoxml.XMLException: net.n3.nanoxml.XMLParseException: could not load content, SystemID='file:.', Line=30
        at net.n3.nanoxml.StdXMLParser.parse(StdXMLParser.java:203)
        at com.izforge.izpack.compiler.CompilerConfig.getXMLTree(CompilerConfig.java:1759)
        ... 3 more

(tip : use -? to get the commmand line parameters)
c:\package\IzPack>

The problem is that the "systemID" passed to the XMLElement constructor is "file:.". I tracked this down and found two problems. In CompilerConfig.java at line 1738, the code reads

            reader = new StdXMLReader(new FileInputStream(filename));

this uses the StdXMLReader that takes an input stream. Inside that constructor, the systemID is set to "file:.". A second problem is that at the end of that constructor is a line that reads:

        this.startNewStream(new StringReader(charsRead.toString()));

which pushes on the stream stack a input stream that will immediately see EOF because "charsRead" is a StringBuffer created right in this constructor and is empty. I attempted to fix this problem by adding the line:

            reader.setSystemID(file.toURL().toExternalForm());

Show »

Sort Order:

[ Permalink | « Hide ]

Brett Bergquist added a comment - 24/Feb/08 08:06 AM

More testing indicates that this is not the complete fix. I will update when I know more.

[ Permalink | « Hide ]

Julien Ponge added a comment - 24/Feb/08 08:26 AM

As for ~~IZPACK-13~~, I am waiting for a patch when you think that you have a good fix.

[ Permalink | « Hide ]

Brett Bergquist added a comment - 24/Feb/08 10:32 AM

Here is the patch to fix this problem and also the ~~IZPACK-13~~ issue. They are two different issues but I did not have time to get a clean copy again and just change CompileConfig.java for the second issue so this patch has the one line fix for issue ~~IZPACK-13~~.

This patch does two things:

It modifies StdXMLReader.java.setSystemID method such that it pops off the current systemID on the stream stack and replaces it with the systemID given as well as set the current systemID. This is needed because the StdXMLReader constructor that constructs an instance from a stream creates a stream from an empty StringBuffer that will popped off at the first access and will replace the current systemID with "file:.". Note that the StdXMLReader.fileReader is also affected (and will now work properly) since it invokes the stream constructor and then attempts to set the systemID.
It modifies CompilerConfig to set the systemID with the URL of the main installer input file (if the input is coming from a file). It does this by calling setSystemID on the reader after it is created with the FileInputStream.

The previous fix of just removing the extra StringReader being pushed onto the stream stack had the effect of allowing the compiler to work correctly but then the installation would fail. Something must be relying on the fact that this empty stream is present and maybe having it restore the "file:." systemID. This change does not change that behavior so now the compilation and installation both work relative <xinclude> references.