ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Ant build.xml
Date Mon, 03 Apr 2000 18:30:38 GMT

>Is there any reason for building ant distribution in the same directory
>as the ant source?
>I find it very bad - it is hard to tell what file is the source and what
>is the result of the build, and "ant dist" doesn't create a distribution
>but just a messed-up source tree.
>If nobody -1 it, I would like to use ../build/ant for ant build and
>../dist/ant for ant

+1.  I had changed it similarly before, but Stefano changed it back.  Lets
change it once again, and keep it that way.

>I also think it's a good idea to use a common property  ( "buid.dir" )
>for all projects as the base for the build work dir, and "dist.dir" as
>base for all dist directories.

I'm not sure I have an opinion on the subject, but for completeness, here
is what xml-cocoon does:

   <property name="dist.root" value="./dist"/>
   <property name="dist.dir" value="${dist.root}/${name}-${version}"/>

>A third proposal - let's tag the workspace ( Apr. 4  or anything ) - it
>is important to have a "known" ant that is used to build other projects.
>If possible, please don't change the ant's build.xml with the latest and
>greatest features - right now it works, and if it's not broken don't fix
>it. You can ( and should ) create test cases for any change, but
>build.xml is not intended as a test suite.

Ant will be tagged 3.1 this week.

Hopefully, people use the current build.xml as an example of best
practices.  The change I recently made was to move the properties out of
the init task.  It is conceivable that at some point in the future,
properties defined in the init task will be scoped to that task (per a
suggestion by Duncan).

I believe that people should have a right to assume that the current
build.xml for Ant from CVS can be built using the current Ant from CVS.
And that the current build.xml for Tomcat from CVS can be build using
either the current Ant from CVS *or* from the last posted binary of Ant.

What I don't believe people are free to assume is that they can mix and
match items taken from CVS at different points in time for the same

>It would also be nice to not change ant behavior or remove features -
>people are using ant as a build tool. Ant has a very clear design that
>allows you to desing new tags without changing existing ones, and to
>specify what implementation you want for a certain tag. Just extend or
>create new tags based on the tags you feel are "wrong", and use them in
>your own build.xml. I would rather use a stupid but stable ant, instead
>of a very smart ant that changes every day.


There was consensus that <init> targets were bad.  After much discussion, I
went through and changed all the build.xml's in all the jakarta and xml
projects so that they would not depend on this feature.  After a few weeks,
I went though and deleted the support for the init tags.

It turns out that I had confused the implementation (all taskdefs and
properties found outside of a target were implicitly added to the init
target) with the intent (such tags were to be supported, the init target
was just a convenient means).  So I am in the process of repeating this
process in reverse.

At the same time, there is agreement that the javac shouldn't implicitly
decide to copy all files it doesn't recognize to the output directory.  I'm
in the process of changing all the build.xmls to explicitly copy all the
necessary support files, so that when this functionality is removed nobody
will be affected.

- Sam Ruby

View raw message