You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Donnie Hale <do...@haleonline.net> on 2001/12/18 04:46:43 UTC

RE: Proper use of (enhancement ???)

Thought I'd keep this suggestion separate from my question. Hopefully the
"dev" folks will see it.

To my mind, it would be more intuitive if there was an optional
"depends.refid" attribute on the <target> element (pick a name you like).

Then I could declare a fileset (does fileset allow an "id" attribute?) which
I could later use for conditional execution of a task based on whether any
files in the fileset were more recent than when the script execution began
(evaluation occurring when the target begins being processed):

<target name="jar2.jar" depends="jar1.jar" depend.refid="jar1.fileset">
    ...
</target>

Maybe there's a way to do that now and I'm missing it. If not, that seems to
me to be the most straightforward way to declare the dependency of a target
on something that can't be easily deduced from the task type (as can be done
with, for example, javac).

FWIW...

Donnie


> -----Original Message-----
> From: Donnie Hale [mailto:donnie@haleonline.net]
> Sent: Monday, December 17, 2001 10:33 PM
> To: ant-user@jakarta.apache.org
> Subject: Proper use of <uptodate>
>
>
> I've checked the docs and faq on this and am still a little unsure of how
> <uptodate> is intended to be used.
>
> Here's my situation:
>
> src/**/*.java
>     classes/**/*.class
>         lib/jar1.jar
>             lib/jar2.jar
>
> The indentations imply dependencies. I want to make sure that
> jar2 is built
> if jar1 had to have been built, either because it didn't exist or was
> out-of-date with respect to any of the .class files. Importantly, I don't
> want jar2 built it exists and if jar1 wasn't rebuilt, as that's a fairly
> expensive step.
>
> As I see it, there are 3 possible situations when the script begins:
>
> 1) jar1 exists but is out of date (jar1 and jar2 should be built)
> 2) jar 2 doesn't exist (jar1 and jar2 should be built)
> 3) jar1 exists and is up-to-date (jar 1 should not be built, jar
> 2 should be
> built if it's out-of-date)
>
> So I've tried putting an <uptodate> in my prepare task, and that seems to
> make sure jar2 doesn't get built if jar1 is up-to-date. And I have an
> <uptodate> in my jar1 task. But, with "unless" on my jar2 task,
> that doesn't
> ensure that my jar2 task gets run if the jar1 task is run.
>
> My <uptodate> is of the form:
>
> <uptodate property="jar2.notrequired" target="${libdir}/jar2.jar">
>     <srcfiles dir="${libdir}" includes="jar1.jar" />
> </uptodate>
>
> The docs on <uptodate> give a completely out-of-context example, so that's
> why I'm stuck. Any advice would be helpful. Also, how do "if" and "unless"
> interpret (quoting the docs) "the property that must [not] be be
> set"? Does
> that mean set to anything? Or just not set to the value "false"?
> Lastly, is
> there a way to "unset" a property in a task?
>
> Thanks much,
>
> Donnie
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Proper use of (enhancement ???)

Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Donnie Hale" <do...@haleonline.net>
Sent: Monday, December 17, 2001 10:46 PM

[...]

> Then I could declare a fileset (does fileset allow an "id" attribute?)
which
> I could later use for conditional execution of a task based on whether any
> files in the fileset were more recent than when the script execution began
> (evaluation occurring when the target begins being processed):

I just wanted to quickly reply that, yes, <fileset> has an "id" attribute.
All datatypes do, actually.

I'm not going to be able to do the rest of your issue justice with my
schedule right now, but I wanted to at least chime in on the "id" question.

    Erik



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>