lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject Re: cvs commit: jakarta-lucene build.xml
Date Wed, 27 Feb 2002 21:43:03 GMT

--- Jon Scott Stevens <> wrote:
> on 2/27/02 10:08 AM, "Dmitry Serebrennikov" <>
> wrote:
> > As a new and cluless user of Ant, here's my vote:
> >   +1 on not requiring editing of build.xml
> >   +1 on keeping default properties in build.xml
> >   +1 on providing with comments as to what
> can
> > be overriden and how
> >   +1 on *no*
> > 
> > I prefer to be there because it gives me as
> a
> > cluless user a clear idea as to what to do to customize things. If
> > simply file is there, I wouldn't even think that
> some
> > other file called '" could be created to customize
> > things (even if after reading the build.xml I could figure out that
> > there is an include statement or something). I think having
> > file would confuse things a bit more than
> required.
> > 
> > The BUILD, COMPILE, or build.readme files can actually explain the
> fact
> > that ant should be used for building, how to customize settings,
> what
> > the ant targets are, how to run ant, and what version of ant is
> needed.
> > 
> Those same files can also explain to create a to
> override
> the instead of having to rename a file...I think
> you are
> also overlooking the fact that by having defaults in build.xml you
> need to
> also maintain the same defaults in That is
> bad.

I imagined as a mostly blank file with a short
description about it's purpose at the top and maybe one commented out
example for people to follow.
So we wouldn't have to keep properties in sync with build.xml.

> Here is the text I use in Scarab's README.txt file to explain
> things...I'm
> sure it could be cleaned up to be more easily understood...
> Anyway, I'm happy to continue to discuss this, but I think I have
> provided a
> very strong and compelling case for the reasons why I like build
> systems to
> do things the way that I explained. I also already voted -1 towards
> having a
> as well as storing default properties in the
> build.xml. Are people overlooking that vote now? Yes, I'm more than
> happy to also provide a patch and do the work.

Ah, you are a committer here, so that -1 definitely has to count (for
some reason I thought you were not a commiter and hence didn't take
that -1 as seriously). Sorry about that.
I'm all for somebody else finishing this business.
Will you do it even if people vote not to use your suggestions?

Dmitry already gave a +1 for no, which could be a
-1.  Dmitry, are you a commiter?  I don't see your name on


> Thanks,
> -jon
> | S E T T I N G S                                                    
>   |
> The Scarab build process depends on having a few properties which are
> defined in the build/ These properties should be
> set
> accordingly *before* you build Scarab. If you would like to customize
> these settings, then you should not edit the
> build/
> The settings in the build/ are fairly well
> documented.
> Instead, one should create a ~/ and/or a
> build/ file and place the properties in those files
> which override the properties in the build/ The
> build
> system will take the first property it can find and use that. It will
> first look for the ~/ and then look for the
> build/
> Chances are that you are going to have to define your own database
> and
> mail server properties as well as a few other properties. Please look
> in
> the scarab/build/ for a list of things that you can
> define.

Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message