ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <tdaw...@wamnet.com>
Subject RE: top level tags in ant vs. "init" task as an attribute of proj ect
Date Fri, 12 Oct 2001 14:58:32 GMT
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Wednesday, October 10, 2001 8:26 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: top level tags in ant vs. "init" task as an attribute of
> proj ect
> 
> 
> On Wed, 10 Oct 2001 23:10, Tim Dawson wrote:
> > > comiitters don't like notion of "magic" names for tasks.
> >
> > ... and I would have been one of them!  Keeping things clear and
> > straightforward should be the defualt, and "magic" names 
> certainly wouldn't
> > provide that.  This is also why I don't like the ability to 
> put things
> > other than targets directly under project -- its not clear 
> at all which
> > tasks are allowed at the top level, and which aren't... 
> until you try.
> 
> I am all for that.
> 
> > But I don't think allowing an init target has anything to 
> do with "magic"
> > names...  If the project element allowed an "init" 
> attribute, then the
> > target name wouldn't be magic; at least no more than the 
> default target is.
> 
> I am not all for this though. This seems to be adding 
> complexity without any 
> real benefit. We already have a method for exectuting a 
> target before others 
> (namely depend attribute of target) so I would prefer to use 
> this rather than 
> creating another project property.

adding complexity where?

when I look at my build files, I see a lot of unnecessary complexity when I
look at the depends="init" attributes on each and every target.  and then
the mess that occurs when I forget to add it... especially to a target that
normally works because its usually included as a dependency, e.g.

<project name="example1" default="jar-example">
  <target name="init">
    do some necessary stuff, e.g. <mkdirs>
  </target>
  
  <target name="compile">
    <!-- depends on init, but I forgot to add it -->
    <javac>....
  </target>
  
  <target name="jar-example" depends="init,compile">
    <jar>...
  </target>
</project>

Now, most of the time, the compile works fine because by default I run the
jar-example task, which executes init before executing compile.  But if I
were to manually execute "ant compile", it would fail.

<project name="example1" init="init" default="jar-example">
  <target name="init">
    do some necessary stuff, e.g. <mkdirs> <property>
  </target>
  
  <target name="compile">
    <!-- safely rely on the mkdirs and other necessary stuff ->
    <javac>....
  </target>
  
  <target name="jar-example" depends="compile">
    <jar>...
  </target>
</project>

This, IMHO, makes it worth adding.  Especially (though I didn't illustrate
this) when you have a bunch of out-of-target tasks that work, it gets really
confusing as to why parts of compile would work but not others...

Alternately, we should just allow anything to appear at the root level,
because that is the init task.  Ok, I'm being facetious - I wouldn't really
want this, but it is a logical extension of the current position.

Tim

Mime
View raw message