Michael Cepek wrote:
Ah, I see. The key point is that invoking a series of targets from the
command line:
$ ant clean-all build-all
doesn't work the same as:
Yes.
That's fine. I wasn't suggesting that Ant be changed. It's just
confusing and perhaps should be clarified in the manual.
I have
Ah, I see. The key point is that invoking a series of targets from the
command line:
$ ant clean-all build-all
doesn't work the same as:
That's fine. I wasn't suggesting that Ant be changed. It's just
confusing and perhaps should be clarified in the manual.
I have also noticed that tar
Michael Cepek wrote:
This doesn't seem right to me.
Well, right or wrong, that is the way Ant has worked since the start and
it will not be changed now. The paragraph you are quoting is about the
dependencies in a single Ant target evaluation. So if Laurie had a target
and he executes
ant targe
This doesn't seem right to me.
The "Using Ant" chapter of the "Ant User Manual" has always seemed
pretty clear on the subject:
"In a chain of dependencies stretching back from
a given target [...] each target gets executed
only once, even when more than one target
depends on it."
Great, thanks for the tip! :-)
L.
Matt Benson wrote:
Laurie:
Since Ant 1.6.3 you can have this behavior by setting
the magic property "ant.executor.class" to
"org.apache.tools.ant.helper.SingleCheckExecutor".
This is not documented in the 1.6.3 manual as was
intended, however. The situation will
Great, thanks for the tip! :-)
L.
Matt Benson wrote:
Laurie:
Since Ant 1.6.3 you can have this behavior by setting
the magic property "ant.executor.class" to
"org.apache.tools.ant.helper.SingleCheckExecutor".
This is not documented in the 1.6.3 manual as was
intended, however. The situation will
Laurie:
Since Ant 1.6.3 you can have this behavior by setting
the magic property "ant.executor.class" to
"org.apache.tools.ant.helper.SingleCheckExecutor".
This is not documented in the 1.6.3 manual as was
intended, however. The situation will be corrected in
the next release.
Thanks,
Matt
---
On May 6, 2005, at 8:41 PM, Laurie Harper wrote:
I was only expecting 'init' to be run once... that's the way I
remember things working. Am I doing something wrong, or is Ant?
You're not doing anything wrong... you're just remembering wrong :-)
The way it's working is the way it works.
cheers,
—ml
It's been a while since I've written an Ant build file, so I may be
missing something obvious here... can anyone shine a light for me? I
have targets that have common dependencies and if I try to run them in a
single invocation Ant executes the common dependency repeatedly.
Here's an example:
$
* Mark Lundquist <[EMAIL PROTECTED]> [2005-02-12 09:01]:
>
> Hey Alan, good to hear from you!
>
> On Feb 11, 2005, at 5:57 PM, Alan Gutierrez wrote:
>
> >Mark
> >
> >I'm now using XSLT to generate my Ant files. Any place where
> >there is iteration, or any sort of logic, XSLT makes i
* Mark Lundquist <[EMAIL PROTECTED]> [2005-02-12 09:01]:
>
> Hey Alan, good to hear from you!
>
> On Feb 11, 2005, at 5:57 PM, Alan Gutierrez wrote:
>
> >Mark
> >
> >I'm now using XSLT to generate my Ant files. Any place where
> >there is iteration, or any sort of logic, XSLT makes i
On Feb 11, 2005, at 10:01 AM, Matt Benson wrote:
I don't know what version of ant-contrib you are
using, but later versions include the for task which
is a hybrid of foreach and macrodef, whose chief
benefit is that it avoids the incursion of an entirely
new project context, unlike foreach. Transl
Hey Alan, good to hear from you!
On Feb 11, 2005, at 5:57 PM, Alan Gutierrez wrote:
Mark
I'm now using XSLT to generate my Ant files. Any place where
there is iteration, or any sort of logic, XSLT makes it simple
and straghtforward.
I know you work with XSLT, so I'm going to enc
* Mark Lundquist <[EMAIL PROTECTED]> [2005-02-11 12:47]:
>
> On Feb 10, 2005, at 11:41 AM, Matt Benson wrote:
>
> >Looks like your main question is how to accumulate,
> >then iterate, over these modules.
>
> Pretty much, except for two things:
>
> 1) Stylistically, I'd prefer to that the iterat
On Feb 10, 2005, at 12:01 PM, Dominique Devienne wrote:
(b) create a task for each module (e.g., "modules:killer-app") that
calls in the module subdirectory and also does some other stuff;
You mean create a target, right!?
yes, which I was thinking is "create a task" in the same sense that
is sa
--- Mark Lundquist <[EMAIL PROTECTED]> wrote:
>
> list="${modules:modules}"
> target="modules.build-module"
> param="name"
> />
>
I don't know what version of an
On Feb 10, 2005, at 11:41 AM, Matt Benson wrote:
Looks like your main question is how to accumulate,
then iterate, over these modules.
Pretty much, except for two things:
1) Stylistically, I'd prefer to that the iteration be implicit rather
than explicit, i.e. a declarative style...
2) I'd like t
> From: Mark Lundquist [mailto:[EMAIL PROTECTED]
>
> I've got several "modules" that I need to be able to build into various
> projects. So what I think I'd like to be able to do is use
> and then be able to just call out the modules like so:
>
>
>
>
>
>
> The idea i
Looks like your main question is how to accumulate,
then iterate, over these modules. It looks as though
ant-contrib has some helpful tasks. You could set a
new property for each of your modules: module.foo=foo
or whatever. Then it appears you could use
ant-contrib's propertyselector task with
Hi,
I've been using ant for some time, but I'm no expert. I just joined
this list. And here's my question! :-)
Actually, I can't even think how to phrase this question in any more
general terms :-)... so I'll just describe specifically what I'm trying
to accomplish (part of it will only make
20 matches
Mail list logo
