ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Koberg <>
Subject Re: Cached results?
Date Thu, 16 Oct 2008 21:57:46 GMT

On Oct 16, 2008, at 5:47 PM, Dominique Devienne wrote:

> On Thu, Oct 16, 2008 at 1:48 PM, Robert Koberg <> wrote:
>> Actually, there is more. You will want to check all document  
>> functions to
>> see what other  is being used and if it has changed. I actually have
>> something like that, but it works off a hierarchical config file  
>> (something
>> like what apache forrest uses but more recursive in orientation)  
>> that is not
>> really.
> Ah ah, indeed, I didn't think about doc() calls. But aren't these
> dependent on variables, and the primary XML document's content
> possibly, while the import/include must use URLs only, possibly
> dependent on params only?
> I'm no expert at XSLs, but just dealing with import/include would
> already be an improvement.
>> Instead of parsing the XSL, I use 2 custom URIResolvers to gather the
>> dependent files and put that into a cache entry object.
> This is smart! you're intercepting the calls to discover which
> resources are used. You must then keep a cache in the filesystem then
> though. (there's already a cache impl linked to <uptodate> I think).
> While you're at it, why not find out which result document(s) were
> generated, especially is XSLT 2.0 where it's no longer an extension
> and part of the language?

That is really not a problem either, at least for saxon (and we really  
don't have any other choice...). Saxon exposes a a similar resolver  
interface for output :)


> Just kidding, <javac> doesn't compile a file
> if the generated .class for an inner class are been removed, that's
> the same kind of limitation.
> Thanks for the precision Rob. --DD
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message