[izpack-devel] Some more Xinclude thoughts
matfud at yahoo.com
Sat Dec 15 19:13:48 CET 2007
Thanks for the prompt reply.
Im having simlar kinds of problems. The xinclude mostly helps but does have limitations.
The "xinclude" element is recursive such that included documents/fragments are also processed and
thier "xinclude"s are included. I'm planning, primarily, on using it in this context.
So I'm hoping your second suggestion is sufficient for my needs as the first would require a fairly large chunk of
rework inside izpack (as you noted the xinclude stuff I wrote is in the parser and does not interact with izpack
in any way and therefore cannot have access to the variable/properties defined in izpack install files) while the second
seems to currently work with the xinclude stuff.
I have been considering adding something like "foreach" and possibly some conditional processing. However I am not
sure that it would be that useful. If I added it then it would likely be added to the xml parser and therefore would not have
access to izpack variables/properties. There is probably some w3c standard I can bastardise to handle this but I'm not
sure if it is worth it.
Another problem I am currently having is realted to the "pack" element. I can quite easily include packs (using pack-ref or xinclude)
but thier "required" attribute is causing issues. Product 'B' includes product 'A'. As such Product 'B' xincludes/pack-refs a number of
packs from product 'A'. Product 'A' has a "pack" element that is marked as required, however for product 'B' that pack is optional.
----- Original Message ----
From: Tino Schwarze <berlios.de at tisc.de>
To: izpack-devel at lists.berlios.de
Sent: Saturday, 15 December, 2007 5:26:17 PM
Subject: Re: [izpack-devel] Some more Xinclude thoughts
On Sat, Dec 15, 2007 at 08:26:29AM -0800, Matthew Fudge wrote:
> It sounds like you have similar problems to myself.
> Yep, I've been down the magic comments route. Some times it's the
> suitable approach and we still use them for some stuff. However since
> I am currently involved in creating a new build/install system for a
> number of older products I thought it might be nice to use tools
> IzPack) that would enable me to do away with magic comments (although
> I think we'll still be left with some).
> Actually the maigc comments weren't too bad when we where using ant
> (although we didn't use them for installers (have you ever seen the
> xml file that InstallAnywhere creates?)) but under maven they are
> turning out to be a bit of a pain in the arse.
> The xinclude code allows you to specify fallbacks if the specified
> href can not be found. This fallback can actually be an empty element
> in which case the entire xinclude just disappears (and does not
> This may address some of your issues wrt including varying numbers of
> modules (if you can structure it correctly).
Solving this "nicely" would require some sophisticated macro stuff. In
my case, we've got a product which is composed of modules (some of them
are mandatory and always there). The point is, I don't know what
are there or may be there in the future. Therefore I've got a script in
the core module which takes a list of modules to include in the
installer. The script knows where to find the appropiate XML snippets
and includes them.
The XML inclusion for know only happens in two files (installer.xml and
compilationSpec.xml). To automate this or replace by a single
I'd need some foreach macro, like this:
a) <xinclude foreach_var="module" foreach_list="$modulelist"
b) <foreach var="module" values="$modulelist">
<xinclude href="../../$module/config/installer.xml" />
Hm, doesn't sound too complicated to implement. (Note that I've never
looked at the XInclude specs!) Either way, NanoXML couldn't handle the
xinclude tag any more since it wouldn't know the value of $module.
But it shouldn't be too hard to add a preprocessing step to the
(variables would have to be passed by command line or we get a
chicken-and-egg problem) to resolve foreach loops and alter the
While I'm thinking this through, it doesn't sound easy any more. :-|
Another approach would be to include an XML which includes other XMLs:
Then we could generate modules.xml like this:
<xinclude href="../../module1/config/installer.xml" />
<xinclude href="../../module2/config/installer.xml" />
This would also work for resources and should be easier to create using
ant or maven...
> ----- Original Message ----
> From: Tino Schwarze <berlios.de at tisc.de>
> To: izpack-devel at lists.berlios.de
> Sent: Saturday, 15 December, 2007 3:25:47 PM
> Subject: Re: [izpack-devel] Some more Xinclude thoughts
> Hi Matthew,
> On Sat, Dec 15, 2007 at 08:03:28AM -0700, Matthew Fudge wrote:
> > Perhaps you could clarify somthing for me. I was looking at the
> > for CompilerConfig#addResources
> > In that file it appears that the "parse" attribute (on a "res"
> > element) causes variable substitution to occur at compile time
> > I don't have an IDE to help me track through the code at the moment
> > see if this is really the case).
> I don't have an IzPack/IDE setup there, currently, so I'm just trying
> remember stuff. I mixed this up with the <parsable> tag where parsing
> happens at installation time.
> Yes, the above code parses at compile time. I would opt for
> an "parsexml" attribute which is independent of the parse attribute.
> This way the user has freedom of choice: No parsing, just XML parsing
> (=including), just variable parsing or both.
> Hm, this xinclude stuff may be useful for me as well - we're
> using a wrapper script to substitute some magic comments by XML
> On the other hand, we'd still need to substitute the magic comments
> appropiate <xinclude> tags since the number of modules may vary...
> Bye+Thanks for the work,
> Tino Schwarze * Parkstraße 17h * 09120 Chemnitz
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
> Support the World Aids Awareness campaign this month with Yahoo! For
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
Tino Schwarze * Parkstraße 17h * 09120 Chemnitz
izpack-devel mailing list
izpack-devel at lists.berlios.de
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com
More information about the izpack-devel