Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 97326 invoked from network); 28 Feb 2002 06:02:09 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 28 Feb 2002 06:02:09 -0000 Received: (qmail 22225 invoked by uid 97); 28 Feb 2002 06:02:18 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 22209 invoked by uid 97); 28 Feb 2002 06:02:17 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 22198 invoked from network); 28 Feb 2002 06:02:17 -0000 X-Sent: 28 Feb 2002 06:02:17 GMT Message-ID: <021501c1c01d$789611d0$6601a8c0@darden.virginia.edu> From: "Erik Hatcher" To: "Lucene Developers List" References: Subject: Re: cvs commit: jakarta-lucene build.xml Date: Thu, 28 Feb 2002 01:02:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Jon Scott Stevens" > > *whew* what a bunch of trouble I stirred up. > > Please don't associate a discussion with trouble. :-) There is no trouble > here...we all have ideas on how to make something work and we are just > expressing them... Thanks for that! > I really don't see the issue with two files. Can you please elaborate on > what the real issue is here? I mean, you download the distribution and the > user/developer shouldn't even really care if there is 2 or 50. Its not as much an "issue" as a preference. And its actually no big deal whatsoever. The biggest thing Ant and all the projects that use it is STANDARDIZATION! One way or another, build.properties.sample / default.properties - doesn't matter functionally. The standardization has to be at a much deeper level than that... and somehow the Ant engine itself needs to enforce or at least prod these things. For example, - that almost should be *implicit* in Ant to do this. Loading build.properties should almost be implicit too. With all the build files out there that don't follow these conventions we really have a mess (i.e. its difficult to pick up a source tree with a build.xml and build it without looking into build.xml to see what makes it tick). > Maybe some of you have never had to deal with autoconf/automake/aclocal. It > requires TONS of little files all over the place. :-) Thankfully no I haven't had to much. > I don't see a problem with the user modifying that file either. It is really > up to them to shoot themselves in their own foot. Agreed. Its not really a problem, but since you're saying they shouldn't modify it by convention, shouldn't Ant itself help enforce that somehow? Ant should almost make us do things the "right" way rather than everyone out there doing their own thing. At least makefiles have fairly consistent conventions that are followed, right? > >, I'm 'committed' to making our > > build file world a happier place. > > +1!!!!!!!!!! > > Everyone has told me that Scarab has one of the easiest to use build systems > out there. :-) At our local JUG next week someone is presenting briefly on Scarab... I can't wait to see it (I haven't yet). Better yet, when will we see it in action instead of Bugzilla?! ;) Erik -- To unsubscribe, e-mail: For additional commands, e-mail: