[Ant] Status of the "init" target & properties?

["Kuiper, Arnout" <Ar...@nl.origin-it.com>]

Hi,

While writing the manual, I came over some unclear issues.

Can somebody tell me what the final decision is regarding the use of the
"init" target?
Should it be used or not? (Personally I would vote for the use of it).

Also the use of properties is a bit unclear. Right now the properties are
evaluated at read/parsing time (via a hack in the Property task). But in the
mailing list are some threads about setting properties at runtime.

Can somebody shine a light on this one?

Arnout Kuiper

Re: [Ant] Status of the "init" target & properties?

[co...@costin.dnt.ro]

> Anyway, I proposed a small change that should make everyone happy
>
> <project ... init="...">
>
> and, if found, the "init" attribute will indicate what target should be
> used to initialize. This allows me to be happy since we are not having
> anything hidden and you to be happy since you get the init target
> functionality.

+0 - but I don't have the time to do this right now.
Anything is fine as long as the build works, and probably we can keep
it as it is till we solve the properties.

> > Yes, properties were a hack ( a very useful one IMHO), and we need to fix it.
> > The idea is to evaluate them at run time, and that will also mean that only
> > some attributes will allow the use of properties ( i.e it's task responsibility
> >
> > to call replace() ).
> > ( since ant works for most of the tasks - there is no urgency to fix this,
> > but we have to keep in mind it's broken and we have to fix it someday,
> > or it will haunt us)
>
> I don't get this. Can you elaborate more?

ProjectHelper reads the XML. When it find a <property> it calls setProperty,
and before setting attributes of tasks it calls replaceProperties().

Ant start the execution _after_ the XML was read, and all replacement are
already done.

It works like Entity in XML - except that it has a bit more flexibility ( all system

properties are like pre-defined entitites, etc).

Please don't tell me it's a bad design - again, it was a hack and it is very usefull

and can be fixed. I just used the simplest way to add properties to get rid of
hard-coded paths and to avoid having to do global replace ( plus I wanted
to be able to customize the build process using .antrc or local build properties).

Costin

RE: [Ant] Status of the "init" target & properties?

[Conor MacNeill <co...@m64.com>]

> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> costin@costin.dnt.ro wrote:
> >
> > > Can somebody tell me what the final decision is regarding the
> use of the
> > > "init" target?
> > > Should it be used or not? (Personally I would vote for the use of it).
> >
> > I would vote for it too, but we have a -1 from Stefano and I
> have no time
> > to argue about this. Unless Stefano change his vote, it's on my
> todo list
> > to remove the init if possible. That's how it works :-)
>
> I will change my vote to -0 if nobody is with me (I hate to veto stuff,
> I'm not smarter than any of you, damn it).
>
> Anyway, I proposed a small change that should make everyone happy
>
> <project ... init="...">
>

I am with you. I support your original -1. I didn't like the "specialness"
of the init target and I support your proposal to define which task is the
init task.

Cheers
Conor

Re: [Ant] Status of the "init" target & properties?

[Stefano Mazzocchi <st...@apache.org>]

costin@costin.dnt.ro wrote:
> 
> > Can somebody tell me what the final decision is regarding the use of the
> > "init" target?
> > Should it be used or not? (Personally I would vote for the use of it).
> 
> I would vote for it too, but we have a -1 from Stefano and I have no time
> to argue about this. Unless Stefano change his vote, it's on my todo list
> to remove the init if possible. That's how it works :-)

I will change my vote to -0 if nobody is with me (I hate to veto stuff,
I'm not smarter than any of you, damn it).

Anyway, I proposed a small change that should make everyone happy

<project ... init="...">

and, if found, the "init" attribute will indicate what target should be
used to initialize. This allows me to be happy since we are not having
anything hidden and you to be happy since you get the init target
functionality.

Note: if "init" is not present, and the <target name="init"> is, the
target should _NOT_ be called at init.
 
> > Also the use of properties is a bit unclear. Right now the properties are
> > evaluated at read/parsing time (via a hack in the Property task). But in the
> > mailing list are some threads about setting properties at runtime.
> 
> Yes, properties were a hack ( a very useful one IMHO), and we need to fix it.
> The idea is to evaluate them at run time, and that will also mean that only
> some attributes will allow the use of properties ( i.e it's task responsibility
> 
> to call replace() ).
> ( since ant works for most of the tasks - there is no urgency to fix this,
> but we have to keep in mind it's broken and we have to fix it someday,
> or it will haunt us)

I don't get this. Can you elaborate more?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

Re: [Ant] Status of the "init" target & properties?

[co...@costin.dnt.ro]

> Can somebody tell me what the final decision is regarding the use of the
> "init" target?
> Should it be used or not? (Personally I would vote for the use of it).

I would vote for it too, but we have a -1 from Stefano and I have no time
to argue about this. Unless Stefano change his vote, it's on my todo list
to remove the init if possible. That's how it works :-)


> Also the use of properties is a bit unclear. Right now the properties are
> evaluated at read/parsing time (via a hack in the Property task). But in the
> mailing list are some threads about setting properties at runtime.

Yes, properties were a hack ( a very useful one IMHO), and we need to fix it.
The idea is to evaluate them at run time, and that will also mean that only
some attributes will allow the use of properties ( i.e it's task responsibility

to call replace() ).
( since ant works for most of the tasks - there is no urgency to fix this,
but we have to keep in mind it's broken and we have to fix it someday,
or it will haunt us)

Costin