From rubys@us.ibm.com Mon Apr 3 18:35:38 2000 Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 96861 invoked from network); 3 Apr 2000 18:35:38 -0000 Received: from e22.nc.us.ibm.com (32.97.136.228) by locus.apache.org with SMTP; 3 Apr 2000 18:35:38 -0000 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA13032 for ; Mon, 3 Apr 2000 14:17:03 -0500 From: rubys@us.ibm.com Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id OAA64184 for ; Mon, 3 Apr 2000 14:35:36 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568B6.0066214E ; Mon, 3 Apr 2000 14:35:31 -0400 X-Lotus-FromDomain: IBMUS To: ant-dev@jakarta.apache.org Message-ID: <852568B6.00661FAD.00@d54mta04.raleigh.ibm.com> Date: Mon, 3 Apr 2000 14:30:38 -0400 Subject: Re: Ant build.xml Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N >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 >distribution. +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: >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 project. >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. Hmm. There was consensus that 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