[izpack-devel] Some more Xinclude thoughts

Dennis Reil Dennis.Reil at reddot.de
Mon Dec 17 08:32:31 CET 2007 

You can define conditions to exclude packs which are not required for certain products.

Regards,
   Dennis


-----Ursprüngliche Nachricht-----
Von: izpack-devel-bounces at lists.berlios.de [mailto:izpack-devel-bounces at lists.berlios.de] Im Auftrag von Matthew Fudge
Gesendet: Samstag, 15. Dezember 2007 19:14
An: izpack-devel at lists.berlios.de
Betreff: Re: [izpack-devel] Some more Xinclude thoughts

Hi Tino,
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.

Any ideas?


cheers
matfud


----- 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

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" />
or
b) <foreach var="module" values="$modulelist">
  <xinclude href="../../$module/config/installer.xml" />
</foreach>

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...

Bye,

Tino.

> ----- 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

-- 
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





      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

_______________________________________________
izpack-devel mailing list
izpack-devel at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/izpack-devel

More information about the izpack-devel mailing list