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 Mon, 15 Oct 2001 11:01:24 GMT
I just think its incredibly sloppy to have non tasks at the project level. I
guess there aren't too many other people that are bothered by this.

Another suggestion that came up earlier in this thread was rather than an
init attribute on project, an <init> element. This wouldn't allow depends=
or if/unless=, and would just be a logical grouping of things that would
otherwise float at the project level. It would also allow any type of target
to appear "at the top", rather than the rather haphazard undocumented list
that exists today.

Tim

> -----Original Message-----
> From: Diane Holt [mailto:holtdl@yahoo.com]
> Sent: Friday, October 12, 2001 3:06 PM
> To: ant-dev@jakarta.apache.org
> Subject: RE: top level tags in ant vs. "init" task as an attribute of
> proj ect
> 
> 
> --- Tim Dawson <tdawson@wamnet.com> wrote:
> > 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.
> 
> There are a couple of things here. One is that if jar-example 
> depends on
> compile and compile depends on init, then the dependencies 
> should be done
> that way -- ie:
>   <target name="jar-example" depends="compile">
> ...
>   <target name="compile" depends="init">
> It's up to the build-file writer to not forget to specify the
> dependencies, and if they do, then the build -should- fail, 
> so the oops
> can be corrected.

yes. that's certainly true. I was trying to come up with
an example and I didn't think it through. I should have simply
used <taskdef> and <property> tasks in my init, to display
the need.

> The other is, if you have some targets that depend on an init 
> target and
> others that don't, then you couldn't use your (proposed) 
> "init" attribute

the point was stuff that goes into init was things that *every*
target would depend on. again, chalk it up to a bad example.

> to <project> anyway, so you're still going to end up having 
> to specify the
> dependency for those targets that do depend on it. 
> Personally, I don't see
> a big win for adding an "init" to <project>.
> 
> (Suppose I might as well also mention that I don't mind the 
> project-level
> tasks either.)
> 
> Diane
> 
> =====
> (holtdl@yahoo.com)
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> 

Mime
View raw message