suggestions

[Craig Longman <cr...@begeek.com>]

i've only very recently really started looking at the build process in
ant, and have some observations that i have found might have been useful
for me.  i would like to post them here and get some feedback before i
investigate any further.

1) it seems like some way of quickly comparing a property to some value
would be helpful.  as an '=' is almost certainly never going to be a
valid character in a property, this kind of thing should work pretty
well:
  <target name="target" if="some.property=hello"/>
  <target name="target" if="some.property=goodbye"/>

as just a simple way of combining a simple comparison.  this will let
the build file set one property to contain different values, depending
on what needs to be done.  it seems the general feeling in ant is that
different property names are better, but i still find that using a
property name pointing to a value that indicates whats going on is the
right thing sometimes (like jdbc.driver=pgsql, rather than
jdbc.driver.pgsql=true for eg).

2) something that calls one or more targets AFTER a target has
completed.  for example, in my init target, i often have properties that
i need to conditionally set, and currently the only way to easily do
that is multiple targets with 'if' attributes.  but, i would still want
to ensure that the init is completed first, while still ensuring that
the other conditional-inits are completed immediately following the init
target.

3) some way to silence a target.  i've been using simple 'check' targets
frequently, to ensure that the buildfile is only called with the correct
targets and not called to execute an internal only target for eg.  but,
this means that there are multiple 'check-XXX' listed in the output that
do nothing other than clutter it up.  it would be nice if we could
indicate that a target not announce that it is running, or perhaps only
announce itself if it actually runs, so if the conditions that the
target depends on fail, then nothing gets printed out.

4) some way to indicate that a target is to be only called from the
build file itself, not externally.  this is basically what i'm trying to
simulate in 3), but being able to code it directly in the build file
might be helpful.

that's all i can think of right now.  anyone got any comments or
suggestions for these?

cheers,

     CraigL->Thx();

Re: suggestions

[Peter Donald <do...@apache.org>]

On Fri, 21 Sep 2001 03:17, Diane Holt wrote:
> > 4) some way to indicate that a target is to be only called from the
> > build file itself, not externally.  this is basically what i'm trying to
> > simulate in 3), but being able to code it directly in the build file
> > might be helpful.
>
> I suppose an attribute could be added to <target> (eg., "external";
> defaults to yes), but I'm not knowledgeable enuf with Ant's internals to
> say for sure how easy that would be to do.

We kinda/sorta have this in latest CVS. Only targets with documentation are 
reported using -projecthelp and in a way they are considered user-callable 
targets and the rest are considered internal targets. 

-- 
Cheers,

Pete

The big mistake that men make is that when they turn thirteen or fourteen and
all of a sudden they've reached puberty, they believe that they like women.
Actually, you're just horny. It doesn't mean you like women any more at
twenty-one than you did at ten.                --Jules Feiffer (cartoonist)

Re: suggestions

[Peter Donald <do...@apache.org>]

On Fri, 21 Sep 2001 15:34, Craig Longman wrote:
> On Thu, 2001-09-20 at 21:54, Peter Donald wrote:
> > > > --- Craig Longman <cr...@begeek.com> wrote:
> > > > >   <target name="target" if="some.property=hello"/>
> > > > >   <target name="target" if="some.property=goodbye"/>
> >
> > Because as soon as we did that there would almost imeadiately be someone
> > who wanted != and then probably < or > or ...
> >
> > Before too long you could have
> >
> > <target name="target" if="((x='y')&&(y>z+u))||(a~=b)"/>
>
> hehe.  yes, i guess you're absolutely right here.  in fact, i had even
> had a thought that if you could do an '=XXX', then why not use a regexp
> as the rhs and then you could do anything.  give 'em an inch... ;-)

;)

> > The if/else target attributes were originally added with much objection
> > from ant-dev and there are some (ie me) who would like to see them
> > removed altogether ;)
>
> interesting.  i am really not sure how i would do some of the things i
> need to do though.  at least, i think i need to do them.  anyway, i
> think if they're kept simple, they can be useful.

Basically an <if/> task so 

<target name="foo" if="X.set"/>

would become

<target name="foo">
 <if test="X.set">
  
 </if>
</target>

This would mean that the notion of <target/> go back to it's original notion 
as a unit of work rather than what it is used for now (basiclly an if block). 
It would also allow much more flexability inside targets.

> > <target name="bar" depends="foo" />
> > <target name="foo" depends="before"/>
>
> very clever.  the only problem is that this would mean i would be
> calling the 'bar' target, when what i really wanted to call was the
> 'foo' target.  but, this definitely acheives the desired effect, albeit
> being a /little/ convoluted.  and i'm sure playing with the names would
> still have the build code read sensibly.

The idea is to get away from thinking notions of order and towards thinking 
notions of dependencies. So what you sound like you want is something like

<target name="foo" depends="bar" />
<target name="bar" depends="old-foo" />
<target name="old-foo" depends="before"/>

So whatever you want to be executed last has to depend on what you want to 
execute first ;)

-- 
Cheers,

Pete

------------------------------------------------------
 Mark Twain: "In the real world, the right thing never
happens in the right place at the right time. It is 
the task of journalists and historians to rectify 
this error."
------------------------------------------------------

Re: suggestions

[Craig Longman <cr...@begeek.com>]

On Thu, 2001-09-20 at 21:54, Peter Donald wrote:
> > > --- Craig Longman <cr...@begeek.com> wrote:
> > > >   <target name="target" if="some.property=hello"/>
> > > >   <target name="target" if="some.property=goodbye"/>
>
> Because as soon as we did that there would almost imeadiately be someone who 
> wanted != and then probably < or > or ... 
> 
> Before too long you could have
> 
> <target name="target" if="((x='y')&&(y>z+u))||(a~=b)"/>

hehe.  yes, i guess you're absolutely right here.  in fact, i had even
had a thought that if you could do an '=XXX', then why not use a regexp
as the rhs and then you could do anything.  give 'em an inch... ;-)

> The if/else target attributes were originally added with much objection from 
> ant-dev and there are some (ie me) who would like to see them removed 
> altogether ;)

interesting.  i am really not sure how i would do some of the things i
need to do though.  at least, i think i need to do them.  anyway, i
think if they're kept simple, they can be useful.

> > <target name="foo" depends="before" after="bar">
> > ...
> > </target>
> 
> Looks like
> 
> <target name="bar" depends="foo" />
> <target name="foo" depends="before"/>

very clever.  the only problem is that this would mean i would be
calling the 'bar' target, when what i really wanted to call was the
'foo' target.  but, this definitely acheives the desired effect, albeit
being a /little/ convoluted.  and i'm sure playing with the names would
still have the build code read sensibly.

> > having a public/private type of attribute.
> 
> It has been proposed and KBed before but it may make it in come Ant2.

cool too.

thanks very much for your answers.

cheers,

     CraigL->Thx();

Re: suggestions

[Craig Longman <cr...@begeek.com>]

On Thu, 2001-09-20 at 21:54, Peter Donald wrote:
> 
> > <target name="foo" depends="before" after="bar">
> > ...
> > </target>
> 
> Looks like
> 
> <target name="bar" depends="foo" />
> <target name="foo" depends="before"/>

hmm, actually i started to implement this, and i my particular case it
won't work as i actually have 3+ targets i want executed AFTER the 'foo'
target.  still, a useful pattern to remember.

thanks,

     CraigL->Thx();

Re: suggestions

[Peter Donald <do...@apache.org>]

On Fri, 21 Sep 2001 06:04, Craig Longman wrote:
> On Thu, 2001-09-20 at 13:17, Diane Holt wrote:
> > --- Craig Longman <cr...@begeek.com> wrote:
> > > 1) it seems like some way of quickly comparing a property to some value
> > > would be helpful.  as an '=' is almost certainly never going to be a
> > > valid character in a property, this kind of thing should work pretty
> > > well:
> > >   <target name="target" if="some.property=hello"/>
> > >   <target name="target" if="some.property=goodbye"/>
> >
> > Diligently (very very :) asked for a looong time ago, and turned down
> > flat. (I ended up having a modified Target.java for quite awhile for that
> > very reason. With the advent of <condition> in 1.4, that can finally
> > [yay!] go away.)
>
> any valid reason why it was turned down?  just not something the
> maintainer(s) liked?
> the condition in 1.4 might help me for somethings, but it is so
> verbose.  one thing i've never liked about so many projects, is the
> tendency to making something so verbose it is no longer readable.  the
> '=' option mentioned here is so much more readable than a multi-line
> condition tag, and is also right in the target tag, which is where you'd
> expect it to be.

Because as soon as we did that there would almost imeadiately be someone who 
wanted != and then probably < or > or ... 

Before too long you could have

<target name="target" if="((x='y')&&(y>z+u))||(a~=b)"/>

The if/else target attributes were originally added with much objection from 
ant-dev and there are some (ie me) who would like to see them removed 
altogether ;)

> <target name="foo" depends="before" after="bar">
> ...
> </target>

Looks like

<target name="bar" depends="foo" />
<target name="foo" depends="before"/>

> will look at this. but again, sounds like a lot of typing just to
> silence a target.  thanks.

More control will occur in Ant2.

> not sure either.  i will look into it perhaps.  i was thinking that the
> same analogy as the java access would work.  having a public/private
> type of attribute.  probably a public defaulting to yes.  i think that
> this would make sense to have.  ant seems to really encourage multiple
> targets, but it could be dangerous if an internal only target was
> invoked directly.  i'll see.

It has been proposed and KBed before but it may make it in come Ant2.

-- 
Cheers,

Pete

*------------------------------------------------*
| You can't wake a person who is pretending      |
|       to be asleep. -Navajo Proverb.           |
*------------------------------------------------*

Re: suggestions

[Craig Longman <cr...@begeek.com>]

On Thu, 2001-09-20 at 13:17, Diane Holt wrote:
> --- Craig Longman <cr...@begeek.com> wrote:
> > 1) it seems like some way of quickly comparing a property to some value
> > would be helpful.  as an '=' is almost certainly never going to be a
> > valid character in a property, this kind of thing should work pretty
> > well:
> >   <target name="target" if="some.property=hello"/>
> >   <target name="target" if="some.property=goodbye"/>
> 
> Diligently (very very :) asked for a looong time ago, and turned down
> flat. (I ended up having a modified Target.java for quite awhile for that
> very reason. With the advent of <condition> in 1.4, that can finally
> [yay!] go away.)

any valid reason why it was turned down?  just not something the
maintainer(s) liked?
the condition in 1.4 might help me for somethings, but it is so
verbose.  one thing i've never liked about so many projects, is the
tendency to making something so verbose it is no longer readable.  the
'=' option mentioned here is so much more readable than a multi-line
condition tag, and is also right in the target tag, which is where you'd
expect it to be.

> > 2) something that calls one or more targets AFTER a target has
> > completed.  for example, in my init target, i often have properties that
> > i need to conditionally set, and currently the only way to easily do
> > that is multiple targets with 'if' attributes.  but, i would still want
> > to ensure that the init is completed first, while still ensuring that
> > the other conditional-inits are completed immediately following the init
> > target.
> 
> Maybe I'm just not fully awake yet this morning, but -- you lost me. The
> only I know of to start another target before the first one is done is to
> include an <antcall>/<ant> in it, then have additional tasks after that.
> Eg:
>   <target name="foo">
>     <echo message="I'm foo..."/>
>     <antcall target="bar"/>
>     <echo message="I'm foo again."/>
>   </target>
>   <target name="bar">
>     <echo message="I'm bar..."/>
>   </target>

well, considering all the other problems with variables i've been having
when using antcall, i was looking for some other solution.  so, i would
have:

<target name="foo" depends="before" after="bar">
...
</target>

so, when this target is invoked, the 'before' target will be invoked
first, then the 'foo' target is invoked, and then finally (assuming no
failures) the 'bar' target is invoked.

this preserves the 'nature' of calling subtargets, and presuming props
are handled in the same way in the 'after' attribute as they are in the
'depends' attribute, the unique behaviour of ant and antcall can be
ignored.

> BTW: There's a problem with logging on this -- the "[echo] I'm foo again."
> ends up printing out as a task of target bar (oops).

i noticed that and commented on it in a previous thread.

> > 3) some way to silence a target.
> 
> Use NoBannerLogger.

will look at this. but again, sounds like a lot of typing just to
silence a target.  thanks.

> > 4) some way to indicate that a target is to be only called from the
> > build file itself, not externally.  this is basically what i'm trying to
> > simulate in 3), but being able to code it directly in the build file
> > might be helpful.
> 
> I suppose an attribute could be added to <target> (eg., "external";
> defaults to yes), but I'm not knowledgeable enuf with Ant's internals to
> say for sure how easy that would be to do.

not sure either.  i will look into it perhaps.  i was thinking that the
same analogy as the java access would work.  having a public/private
type of attribute.  probably a public defaulting to yes.  i think that
this would make sense to have.  ant seems to really encourage multiple
targets, but it could be dangerous if an internal only target was
invoked directly.  i'll see.

thanks,

     CraigL->Thx();

Re: suggestions

[Diane Holt <ho...@yahoo.com>]

--- Craig Longman <cr...@begeek.com> wrote:
> 1) it seems like some way of quickly comparing a property to some value
> would be helpful.  as an '=' is almost certainly never going to be a
> valid character in a property, this kind of thing should work pretty
> well:
>   <target name="target" if="some.property=hello"/>
>   <target name="target" if="some.property=goodbye"/>

Diligently (very very :) asked for a looong time ago, and turned down
flat. (I ended up having a modified Target.java for quite awhile for that
very reason. With the advent of <condition> in 1.4, that can finally
[yay!] go away.)

> 2) something that calls one or more targets AFTER a target has
> completed.  for example, in my init target, i often have properties that
> i need to conditionally set, and currently the only way to easily do
> that is multiple targets with 'if' attributes.  but, i would still want
> to ensure that the init is completed first, while still ensuring that
> the other conditional-inits are completed immediately following the init
> target.

Maybe I'm just not fully awake yet this morning, but -- you lost me. The
only I know of to start another target before the first one is done is to
include an <antcall>/<ant> in it, then have additional tasks after that.
Eg:
  <target name="foo">
    <echo message="I'm foo..."/>
    <antcall target="bar"/>
    <echo message="I'm foo again."/>
  </target>
  <target name="bar">
    <echo message="I'm bar..."/>
  </target>

BTW: There's a problem with logging on this -- the "[echo] I'm foo again."
ends up printing out as a task of target bar (oops).

> 3) some way to silence a target.

Use NoBannerLogger.

> 4) some way to indicate that a target is to be only called from the
> build file itself, not externally.  this is basically what i'm trying to
> simulate in 3), but being able to code it directly in the build file
> might be helpful.

I suppose an attribute could be added to <target> (eg., "external";
defaults to yes), but I'm not knowledgeable enuf with Ant's internals to
say for sure how easy that would be to do.

Diane

=====
(holtdl@yahoo.com)



__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/