Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 3061 invoked from network); 27 Feb 2002 20:30:35 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 27 Feb 2002 20:30:35 -0000 Received: (qmail 4896 invoked by uid 97); 27 Feb 2002 20:30:39 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 4879 invoked by uid 97); 27 Feb 2002 20:30:39 -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 4868 invoked from network); 27 Feb 2002 20:30:38 -0000 From: "Daniel Calvo" To: "Lucene Developers List" Subject: RE: cvs commit: jakarta-lucene build.xml Date: Wed, 27 Feb 2002 17:32:01 -0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <94F890AC98E9AF478F08FEFAC7467C7C010FA2@riker01> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi, I'm ok with either solution, provided that there's an easy and well documented way to override default properties (specifically javacc.home, which I think started this thread). Another option would be having only default properties in build.xml (the ones that should never be changed) and use build.properties to customize a local instalation, with properties that define external packages, jars, etc., such as javacc.home and jakarta.site2.home. --Daniel > -----Original Message----- > From: Doug Cutting [mailto:DCutting@grandcentral.com] > Sent: quarta-feira, 27 de fevereiro de 2002 13:49 > To: 'Lucene Developers List' > Subject: RE: cvs commit: jakarta-lucene build.xml > > > We should remove build.properties from CVS. Then things will be consistent. > > Separately we should resolve whether to add a default.properties file. > Personally, I don't have a strong feeling about this. If forced to vote, > I'd currently vote for leaving the defaults in build.xml, but I won't object > if the majority wish to move default values to a default.properties file. > > Doug > > > -----Original Message----- > > From: Otis Gospodnetic [mailto:otis_gospodnetic@yahoo.com] > > Sent: Wednesday, February 27, 2002 9:01 AM > > To: Lucene Developers List > > Subject: Re: cvs commit: jakarta-lucene build.xml > > > > > > That build.properties in CVS looking like it is always used (because > > it's not called .sample or something such) looks like it would confuse > > people ("I changed XYZ in build.properties, but it didn't take effect. > > Why?"), that's what I was referring to when I said half-baked. > > In any case, I'll wait to hear some more opinions. > > > > Otis > > > > --- Erik Hatcher wrote: > > > ----- Original Message ----- > > > From: "Otis Gospodnetic" > > > > > > > I do think having defaults in build.xml and not > > build.properties is > > > > better than having defaults in build.properties and that using > > > > build.properties for overriding defaults instead of changing > > > build.xml > > > > is better (simpler for people to do, less error prone, requires > > > less > > > > knowledge). > > > > > > I think there is some confusion. *Never* have Jon or I suggested > > > anything > > > about build.xml being edited. It should *never* be edited by an end > > > user > > > just simply wanting to build Lucene from source code. The > > discussion > > > is > > > over best practices: whether properties should be in the > > build.xml or > > > default.properties. Neither of those should be edited by this > > > end-user. > > > For someone to build and change the destination of the > > output, he/she > > > would > > > simply create a build.properties (in both Jon and I's > > scheme) and set > > > that > > > one property. That is all. > > > > > > > It would be good if others could share their opinions and > > votes, so > > > > that I can move things out of the half-baked state on build in the > > > CVS > > > > repository. > > > > > > Whats half-baked about it? Properties are in build.xml now, right? > > > Is > > > there still a build.properties? That won't matter given that the > > > properties > > > are the same value and Ant has property immutability. But if > > > build.properties is still there, I recommend just removing it or > > > renaming > > > it. And certainly Jon's scheme is fine if you choose do so - rename > > > build.properties to default.properties, and remove the properties I > > > added in > > > build.xml. (keep in mind that I renamed a property or two so that > > > the demo > > > WAR and my docweb WAR had unique descriptive properties). > > > > > > Erik > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Greetings - Send FREE e-cards for every occasion! > > http://greetings.yahoo.com > > > > -- > > To unsubscribe, e-mail: > > For additional commands, e-mail: > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: