thanks for the answer. :)
i would be interesting in investigating a mechanism to try and integrate
such a heuristic into an interface that a task could implement, such that
you could have real incremental conditions on any task that wanted it. this
is a problem that comes up often in the non-java world.
johnc
> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 10, 2001 2:36 AM
> To: [EMAIL PROTECTED]
> Subject: Re: incremental building
>
>
> John Camelon <[EMAIL PROTECTED]> wrote:
>
> > the inherent timestamping using </tstamp> doesn't determine that
> > these IDL's don't need to be regenerated
>
> I think you are expecting far too much from the tstamp task - it just
> sets a couple of properties initializing them from the current time.
>
> What you really want is either <uptodate> or <apply>. Assuming an
> idlcompiler named idl2java that creates Foo.java from Foo.idl (totally
> made up, I'm sure things are little bit more complicated at your site,
> but to give you an idea) you could do:
>
> <uptodate property="no-idl-regen" targetfile="Foo.java">
> <srcfiles dir="." includes="Foo.idl" />
> </uptodate>
>
> <target .... unless="no-idl-regen">
> run idl2java on Foo.idl
> </target>
>
> or to do this in one pass (mapping all .idl files to .java files and
> processing them in a single task):
>
> <apply executable="idl2java">
> <srcfile />
>
> <fileset dir="." includes="**/*.idl" />
> <mapper type="glob" from="*.idl" to="*.java" />
> </apply>
>
> which will recursively scan your basedir for files with the extension
> .idl, compare their last modification time with the one of the
> corresponding .java file (if present) and run the command if (1) the
> .java file is not there or (2) is older than the .idl file.
>
> Stefan
>
