[izpack-devel] Some more Xinclude thoughts

Tino Schwarze berlios.de at tisc.de
Sat Dec 15 18:26:17 CET 2007

Hi Matthew,

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 most
> 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 (like
> 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 fail).
> 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 modules
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 statement,
I'd need some foreach macro, like this:
a) <xinclude foreach_var="module" foreach_list="$modulelist"
    href="../../$module/config/installer.xml" />
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 compiler
(variables would have to be passed by command line or we get a
chicken-and-egg problem) to resolve foreach loops and alter the document
structure accordingly.

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:
<xinclude href="modules.xml"/>
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 code
> > for CompilerConfig#addResources
> >
>  (http://svn.berlios.de/svnroot/repos/izpack/izpack-src/trunk/src/lib/com/izforge/izpack/compiler/CompilerConfig.java)
> > In that file it appears that the "parse" attribute (on a "res"
> > element) causes variable substitution to occur at compile time (sorry
> > I don't have an IDE to help me track through the code at the moment
>  to
> > see if this is really the case).
> I don't have an IzPack/IDE setup there, currently, so I'm just trying
>  to
> 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 introducing
> 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 currently
> using a wrapper script to substitute some magic comments by XML
>  snippets.
> On the other hand, we'd still need to substitute the magic comments by
> appropiate <xinclude> tags since the number of modules may vary...
> Bye+Thanks for the work,
> Tino.
> -- 
> www.craniosacralzentrum.de
> www.lebensraum11.de
> www.spiritualdesign-chemnitz.de
> Tino Schwarze * Parkstraße 17h * 09120 Chemnitz
> _______________________________________________
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/izpack-devel
>       ___________________________________________________________
> Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
> _______________________________________________
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/izpack-devel


Tino Schwarze * Parkstraße 17h * 09120 Chemnitz

More information about the izpack-devel mailing list