Ah, yes, build.properties is still being sucked in by build.xml.
Ok, I'm moving build.properties to build.properties.sample, commenting
out everything it the latter (we can clean it up later), removing
former from the CVS.
This should clean things up.
Anything else needs to be done?
Otis
--- Erik Hatcher <[EMAIL PROTECTED]> wrote:
> Well, just to clarify.... if you change something in build.properties
> it
> *will* (by design) take effect! Thats what its all about! :)
>
> Erik
>
>
> ----- Original Message -----
> From: "Otis Gospodnetic" <[EMAIL PROTECTED]>
> To: "Lucene Developers List" <[EMAIL PROTECTED]>
> Sent: Wednesday, February 27, 2002 12:00 PM
> 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 <[EMAIL PROTECTED]> wrote:
> > > ----- Original Message -----
> > > From: "Otis Gospodnetic" <[EMAIL PROTECTED]>
> > >
> > > > 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:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
