From ant-user-return-13341-apmail-jakarta-ant-user-archive=jakarta.apache.org@jakarta.apache.org Fri Oct 05 07:03:56 2001 Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@jakarta.apache.org Received: (qmail 39161 invoked by uid 500); 5 Oct 2001 07:03:55 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: ant-user@jakarta.apache.org Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 39152 invoked from network); 5 Oct 2001 07:03:54 -0000 Message-Id: <4.3.1.2.20011005090349.01ef3008@lucas> X-Sender: jchees@lucas X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 05 Oct 2001 09:09:39 +0200 To: ant-user@jakarta.apache.org From: Jim Cheesman Subject: RE: Book on Ant In-Reply-To: <5.1.0.14.0.20011005083622.0219eb60@actwelsvr14> References: <1DDAD1E1E099D411891300508BF38111017050F9@kwdmsx10.lgnet.co .uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 10:41 PM 04/10/01, you wrote: >At 12:46 3/10/2001 +0100, Bhadra, Jatin wrote: >>I think it is a very good idea to have a chapter that gives suggestions on >>designing projects and build process. I think as Java forces developers to >>write good code. ANT should forces developers to have better project design, >>version control of releases and build process. > >I don't think Java forces developers to write good code - bad developers >write bad code no matter the language. I believe the advantage with Java >is rather that it makes it easier for good developers to write good code. Hear hear! (As I rather rudely pointed out earlier... ;) >Similarly, Ant doesn't (and IMHO shouldn't) mandate good practice - simply >because good practice varies so much from situation to situation. Instead, >it just makes it easier to have a good process because all the building >blocks are there. > >>Basically the idea is that build should be automated end to end, From >>extraction from version control to deployment on application server or any >>target. > >I agree - except that I'd add that it need not be a single automated >process. For example, our process starts with blank directories, gets >source and finishes with archiving the completed build onto our server. We >then use separate processes for deployment to Internal Testing, Business >Acceptence Testing and Production. > >We've found that some parts of the process require human decision making >and shouldn't be automatic. I'd add that a good look through the archives should show up much of where the problems are - definitely cover these. But for a "value-added" book, you're going to need to go beyond the typical "how do I do X with ant?" type questions - and that's where Bevan's and Scott's points are so valid. I know how to RTFM, what I don't have is your experience on the projects you've worked on, and like many I work almost exclusively on one platform and don't have a great deal of experience with others. So, some hints and tips on typical failure points in typical projects would be great - learning from other's mistakes is so much nicer than learning from my own ;) Jim, rambling with only the one coffee inside. -- * Jim Cheesman * Trabajo: jchees@msl.es - (34)(91) 724 9200 x 2360 If we do not succeed, we run the risk of failure.