Mailing List Archive

otis 02/02/26 17:10:58

Modified: . build.xml
Log:
- Moved properties from build.properties in here. build.properties should be
removed and replaced by build.properties.sample.
Targets docweb-index and docweb-war I have commented out since it requires
an Ant task that is not a part of Ant distribution yet. These should be
uncommented when this task makes it into the Ant distribution.
Submitted by: Erik Hatcher
Reviewed by: Otis Gospodnetic

Revision Changes Path
1.21 +196 -80 jakarta-lucene/build.xml

Index: build.xml
===================================================================
RCS file: /home/cvs/jakarta-lucene/build.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- build.xml 13 Feb 2002 16:52:02 -0000 1.20
+++ build.xml 27 Feb 2002 01:10:58 -0000 1.21
@@ -5,6 +5,67 @@
<property file="${user.home}/build.properties"/>
<property file="build.properties"/>

+ <property name="name" value="lucene"/>
+ <property name="Name" value="Lucene"/>
+ <property name="version" value="1.2-rc5-dev"/>
+ <property name="year" value="2000-2002"/>
+ <property name="final.name" value="${name}-${version}"/>
+ <property name="debug" value="off"/>
+
+ <property name="project.name" value="site"/>
+ <property name="docs.src" value="./xdocs"/>
+ <property name="docs.dest" value="./docs"/>
+
+ <property name="src.dir" value="./src/java"/>
+ <property name="demo.src" value="./src/demo"/>
+ <property name="demo.jsp" value="./src/jsp"/>
+ <property name="test.src" value="./src/test"/>
+ <property name="anttask.src" value="./src/ant"/>
+ <property name="docs.dir" value="./docs"/>
+ <property name="lib.dir" value="./lib"/>
+ <property name="dist.dir" value="${final.name}"/>
+ <property name="dist-src.dir" value="${final.name}-src"/>
+
+ <!-- javadoc packages -->
+ <property name="packages" value="org.apache.lucene.*"/>
+
+ <property name="javadoc.link" value="http://java.sun.com/products/jdk/1.3/docs/api/"/>
+
+ <property name="build.compiler.pedantic" value="false"/>
+
+ <property name="build.dir" value="./bin"/>
+ <property name="build.classes" value="${build.dir}/classes"/>
+ <property name="build.lib" value="${build.dir}/lib"/>
+ <property name="build.javadocs" value="${build.dir}/docs/api"/>
+ <property name="build.src" value="${build.dir}/src"/>
+
+ <property name="build.demo" value="${build.dir}/demo"/>
+ <property name="build.demo.src" value="${build.demo}/src"/>
+ <property name="build.demo.classes" value="${build.demo}/classes"/>
+ <property name="build.demo.name" value="${name}-demos-${version}"/>
+ <property name="build.demo.war.name" value="luceneweb"/>
+
+ <property name="build.anttask" value="${build.dir}/anttask"/>
+ <property name="build.anttask.classes" value="${build.anttask}/classes"/>
+
+ <property name="build.docweb" value="${build.dir}/docweb"/>
+ <property name="build.docweb.war.name" value="lucenedocweb"/>
+
+ <property name="build.test" value="${build.dir}/test"/>
+ <property name="build.test.src" value="${build.test}/src"/>
+ <property name="build.test.classes" value="${build.test}/classes"/>
+
+ <property name="junit.src" value="${basedir}/src/test"/>
+ <property name="junit.classes" value="${build.dir}/unit-classes"/>
+ <property name="junit.reports" value="${build.dir}/unit-reports"/>
+
+ <property name="javacc.home" value="."/>
+ <property name="javacc.zip.dir" value="${javacc.home}/lib"/>
+ <property name="javacc.zip" value="${javacc.zip.dir}/JavaCC.zip"/>
+
+ <property name="jakarta.site2.home" value="../jakarta-site2"/>
+
+
<!-- Build classpath -->
<path id="classpath">
<pathelement location="${build.classes}"/>
@@ -38,15 +99,15 @@
<mkdir dir="${build.dir}"/>
<mkdir dir="${build.classes}"/>
<mkdir dir="${build.src}"/>
-
- <available
- property="javacc.present"
+
+ <available
+ property="javacc.present"
classname="COM.sun.labs.javacc.Main"
classpath="${javacc.zip}"
/>
-
- <available
- property="junit.present"
+
+ <available
+ property="junit.present"
classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask"
/>
</target>
@@ -54,7 +115,7 @@
<target name="javacc_check" depends="init" unless="javacc.present">
<echo>
##################################################################
- JavaCC not found.
+ JavaCC not found.
JavaCC Home: ${javacc.home}
JavaCC Zip: ${javacc.zip}

@@ -62,7 +123,7 @@

&lt;http://www.webgain.com/products/java_cc/&gt;

- Then, create a .ant.properties file either in your home
+ Then, create a build.properties file either in your home
directory, or within the Lucene directory and set the javacc.home
property to the path where JavaCC.zip is located. For example,
if you installed JavaCC in /usr/local/java/javacc2.0, then set the
@@ -85,24 +146,24 @@
<!-- ================================================================== -->
<target name="compile" depends="init,javacc_check" if="javacc.present">
<mkdir dir="${build.src}/org/apache/lucene/analysis/standard"/>
- <javacc
- target="${src.dir}/org/apache/lucene/analysis/standard/StandardTokenizer.jj"
+ <javacc
+ target="${src.dir}/org/apache/lucene/analysis/standard/StandardTokenizer.jj"
javacchome="${javacc.zip.dir}"
outputdirectory="${build.src}/org/apache/lucene/analysis/standard"
/>
-
+
<delete file="${build.src}/org/apache/lucene/analysis/standard/ParseException.java"/>
<mkdir dir="${build.src}/org/apache/lucene/queryParser"/>
- <javacc
- target="${src.dir}/org/apache/lucene/queryParser/QueryParser.jj"
+ <javacc
+ target="${src.dir}/org/apache/lucene/queryParser/QueryParser.jj"
javacchome="${javacc.zip.dir}"
outputdirectory="${build.src}/org/apache/lucene/queryParser"
/>
-
- <javac
- srcdir="${src.dir}:${build.src}"
- includes="org/**/*.java"
- destdir="${build.classes}"
+
+ <javac
+ srcdir="${src.dir}:${build.src}"
+ includes="org/**/*.java"
+ destdir="${build.classes}"
debug="${debug}">
<classpath refid="classpath"/>
</javac>
@@ -114,48 +175,48 @@
<!-- -->
<!-- ================================================================== -->
<target name="jar" depends="compile" if="javacc.present">
- <jar
- jarfile="${build.dir}/${final.name}.jar"
+ <jar
+ jarfile="${build.dir}/${final.name}.jar"
basedir="${build.classes}"
excludes="**/*.java"
/>
</target>

<target name="jardemo" depends="compile,demo" if="javacc.present">
- <jar
- jarfile="${build.demo}/${build.demo.name}.jar"
+ <jar
+ jarfile="${build.demo}/${build.demo.name}.jar"
basedir="${build.demo.classes}"
excludes="**/*.java"
/>
</target>

<target name="wardemo" depends="compile,demo,jar,jardemo" if="javacc.present">
- <mkdir dir="${build.demo}/${build.war.name}"/>
- <mkdir dir="${build.demo}/${build.war.name}/WEB-INF"/>
- <mkdir dir="${build.demo}/${build.war.name}/WEB-INF/lib"/>
-
- <copy todir="${build.demo}/${build.war.name}">
+ <mkdir dir="${build.demo}/${build.demo.war.name}"/>
+ <mkdir dir="${build.demo}/${build.demo.war.name}/WEB-INF"/>
+ <mkdir dir="${build.demo}/${build.demo.war.name}/WEB-INF/lib"/>
+
+ <copy todir="${build.demo}/${build.demo.war.name}">
<fileset dir="${demo.jsp}">
<include name="**/*.jsp"/>
<include name="**/*.xml"/>
</fileset>
</copy>

- <copy todir="${build.demo}/${build.war.name}/WEB-INF/lib">
+ <copy todir="${build.demo}/${build.demo.war.name}/WEB-INF/lib">
<fileset dir="${build.dir}">
<include name="*.jar"/>
</fileset>
</copy>

- <copy todir="${build.demo}/${build.war.name}/WEB-INF/lib">
+ <copy todir="${build.demo}/${build.demo.war.name}/WEB-INF/lib">
<fileset dir="${build.demo}">
<include name="*.jar"/>
</fileset>
</copy>

<jar
- jarfile="${build.demo}/${build.war.name}.war"
- basedir="${build.demo}/${build.war.name}"
+ jarfile="${build.demo}/${build.demo.war.name}.war"
+ basedir="${build.demo}/${build.demo.war.name}"
excludes="**/*.java"
/>
</target>
@@ -167,21 +228,21 @@
<!-- ================================================================== -->
<target name="jar-src" depends="init,javacc_check" if="javacc.present">
<mkdir dir="${build.src}/org/apache/lucene/analysis/standard"/>
- <javacc
- target="${src.dir}/org/apache/lucene/analysis/standard/StandardTokenizer.jj"
+ <javacc
+ target="${src.dir}/org/apache/lucene/analysis/standard/StandardTokenizer.jj"
javacchome="${javacc.zip.dir}"
outputdirectory="${build.src}/org/apache/lucene/analysis/standard"
/>
-
+
<delete file="${build.src}/org/apache/lucene/analysis/standard/ParseException.java"/>
<mkdir dir="${build.src}/org/apache/lucene/queryParser"/>
- <javacc
+ <javacc
target="${src.dir}/org/apache/lucene/queryParser/QueryParser.jj"
javacchome="${javacc.zip.dir}"
outputdirectory="${build.src}/org/apache/lucene/queryParser"
/>

- <jar jarfile="${build.dir}/${final.name}-src.jar">
+ <jar jarfile="${build.dir}/${final.name}-src.jar">
<fileset dir="${build.dir}" includes="**/*.java"/>
</jar>
</target>
@@ -193,23 +254,23 @@
<!-- ================================================================== -->
<target name="demo" depends="compile" if="javacc.present">
<mkdir dir="${build.demo}"/>
-
+
<copy todir="${build.demo.src}">
<fileset dir="${demo.src}">
<include name="**/*.java"/>
<include name="**/*.jj"/>
</fileset>
</copy>
-
- <javacc
- target="${build.demo.src}/org/apache/lucene/demo/html/HTMLParser.jj"
+
+ <javacc
+ target="${build.demo.src}/org/apache/lucene/demo/html/HTMLParser.jj"
javacchome="${javacc.zip.dir}"
outputdirectory="${build.demo.src}/org/apache/lucene/demo/html"
/>
-
+
<mkdir dir="${build.demo.classes}"/>
-
- <javac
+
+ <javac
srcdir="${build.demo.src}"
includes="**/*.java"
destdir="${build.demo.classes}"
@@ -234,7 +295,7 @@

<mkdir dir="${build.test.classes}"/>

- <javac
+ <javac
srcdir="${build.test.src}"
includes="**/*.java"
destdir="${build.test.classes}"
@@ -250,20 +311,20 @@
<!-- ================================================================== -->
<target name="test-unit" depends="compile,test" if="junit.present">
<!-- Import JUnit task -->
- <taskdef
- name="junit"
+ <taskdef
+ name="junit"
classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask"
/>

<mkdir dir="${junit.classes}"/>
<mkdir dir="${junit.reports}"/>
- <javac
- srcdir="${junit.src}"
- includes="**/*.java"
- destdir="${junit.classes}"
+ <javac
+ srcdir="${junit.src}"
+ includes="**/*.java"
+ destdir="${junit.classes}"
debug="${debug}">
<classpath refid="classpath"/>
- </javac>
+ </javac>

<junit printsummary="yes" haltonfailure="no" >
<classpath refid="junit.classpath"/>
@@ -280,8 +341,8 @@
<!-- -->
<!-- ================================================================== -->
<target name="docs-prepare">
- <available
- classname="org.apache.velocity.anakia.AnakiaTask"
+ <available
+ classname="org.apache.velocity.anakia.AnakiaTask"
property="AnakiaTask.present"
classpathref="anakia.classpath"
/>
@@ -289,21 +350,21 @@

<target depends="docs-prepare" name="prepare-error" unless="AnakiaTask.present">
<echo>
- AnakiaTask is not present! Please check to make sure that
+ AnakiaTask is not present! Please check to make sure that
you have jakarta.site2.home set correctly.
</echo>
</target>

<target name="docs" depends="prepare-error" if="AnakiaTask.present">
- <taskdef
- name="anakia"
+ <taskdef
+ name="anakia"
classname="org.apache.velocity.anakia.AnakiaTask"
>
<classpath refid="anakia.classpath"/>
</taskdef>
-
- <anakia
- basedir="${docs.src}"
+
+ <anakia
+ basedir="${docs.src}"
destdir="${docs.dest}/"
extension=".html" style="./site.vsl"
projectFile="stylesheets/project.xml"
@@ -321,7 +382,7 @@
<include name="**/*.jpg"/>
</fileset>
</copy>
-
+
<!-- In case we have CSS someday
<copy todir="${docs.dest}" filtering="no">
<fileset dir="${docs.src}">
@@ -390,7 +451,7 @@
</copy>
<copy file="${build.dir}/${final.name}.jar" todir="${dist.dir}"/>
<copy file="${build.demo}/${build.demo.name}.jar" todir="${dist.dir}"/>
- <copy file="${build.demo}/${build.war.name}.war" todir="${dist.dir}"/>
+ <copy file="${build.demo}/${build.demo.war.name}.war" todir="${dist.dir}"/>
</target>

<!-- ================================================================== -->
@@ -400,11 +461,11 @@
<!-- ================================================================== -->
<target name="package-zip" depends="package"
description="--> Generates the Lucene distribution as .zip">
-
+
<delete file="${basedir}/${final.name}.zip"/>
- <zip
- zipfile="${basedir}/${final.name}.zip"
- basedir="${basedir}/"
+ <zip
+ zipfile="${basedir}/${final.name}.zip"
+ basedir="${basedir}/"
includes="**/${final.name}/**"
/>
</target>
@@ -416,17 +477,17 @@
<!-- ================================================================== -->
<target name="package-tgz" depends="package"
description="--> generates the lucene distribution as .tar.gz">
-
+
<delete file="${basedir}/${final.name}.tar"/>
<delete file="${basedir}/${final.name}.tar.gz"/>
- <tar
- tarfile="${basedir}/${final.name}.tar"
- basedir="${basedir}/"
+ <tar
+ tarfile="${basedir}/${final.name}.tar"
+ basedir="${basedir}/"
includes="**/${final.name}/**"
/>
-
- <gzip
- zipfile="${basedir}/${final.name}.tar.gz"
+
+ <gzip
+ zipfile="${basedir}/${final.name}.tar.gz"
src="${basedir}/${final.name}.tar"
/>
</target>
@@ -478,11 +539,11 @@
<!-- ================================================================== -->
<target name="package-zip-src" depends="package-src"
description="--> Generates the Lucene sources as .zip">
-
+
<delete file="${basedir}/${final.name}-src.zip"/>
<zip
- zipfile="${basedir}/${final.name}-src.zip"
- basedir="${basedir}/"
+ zipfile="${basedir}/${final.name}-src.zip"
+ basedir="${basedir}/"
includes="**/${final.name}-src/**"
/>
</target>
@@ -494,17 +555,17 @@
<!-- ================================================================== -->
<target name="package-tgz-src" depends="package-src"
description="--> Generates the Lucene distribution as .tar.gz">
-
+
<delete file="${basedir}/${final.name}-src.tar"/>
<delete file="${basedir}/${final.name}-src.tar.gz"/>
- <tar
+ <tar
tarfile="${basedir}/${final.name}-src.tar"
basedir="${basedir}/"
includes="**/${final.name}-src/**"
/>
-
- <gzip
- zipfile="${basedir}/${final.name}-src.tar.gz"
+
+ <gzip
+ zipfile="${basedir}/${final.name}-src.tar.gz"
src="${basedir}/${final.name}-src.tar"
/>
</target>
@@ -542,4 +603,59 @@
<delete file="${basedir}/${final.name}-src.tar.gz"/>
<delete file="${basedir}/${final.name}-src.zip"/>
</target>
+
+ <!-- ================================================================== -->
+ <!-- Build the Ant index task -->
+ <!-- ================================================================== -->
+ <!--
+ <target name="anttask-init">
+ <property name="anttask.classes" location="${build.dir}/anttask/classes"/>
+ <mkdir dir="${anttask.classes}"/>
+ </target>
+
+ <target name="anttask-compile" depends="compile,anttask-init">
+ <javac
+ srcdir="${anttask.src}"
+ destdir="${anttask.classes}"
+ debug="${debug}">
+ <classpath refid="classpath"/>
+ </javac>
+ </target>
+ -->
+
+ <!-- ================================================================== -->
+ <!-- Build the DocWeb app -->
+ <!-- ================================================================== -->
+ <target name="docweb-init">
+<!-- <mkdir dir="${}"/> -->
+ </target>
+
+ <!--
+ <target name="docweb-index" depends="javadocs,anttask-compile,docweb-init">
+ <taskdef name="index"
+ classname="org.apache.lucene.ant.IndexTask">
+ <classpath>
+ <pathelement location="${anttask.classes}"/>
+ <path refid="classpath"/>
+ </classpath>
+ </taskdef>
+
+ <index index="${build.docweb}/index"
+ overwrite="false">
+ <fileset dir="${docs.dir}"/>
+ <fileset dir="${build.javadocs}"/>
+ </index>
+
+ </target>
+
+ <target name="docweb-war" depends="jar,jardemo,docweb-index">
+ <war warfile="${build.docweb}/${build.docweb.war.name}.war"
+ webxml="${demo.jsp}/WEB-INF/web.xml">
+ <fileset dir="${demo.jsp}" excludes="WEB-INF/"/>
+ <lib dir="${build.demo}" includes="*.jar"/>
+ <lib dir="${build.dir}" includes="*.jar"/>
+ <webinf dir="${build.docweb}" includes="index/"/>
+ </war>
+ </target>
+ -->
</project>




--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

on 2/26/02 5:10 PM, "otis@apache.org" <otis@apache.org> wrote:

> - Moved properties from build.properties in here. build.properties should be
> removed and replaced by build.properties.sample.

-1.

A better way to deal with this is to follow what Scarab and other projects
do which is to do this:

<!-- Give user a chance to override without editing this file
(and without typing -D each time it compiles it -->
<property file="${user.home}/lucene.build.properties" />
<property file="${user.home}/build.properties" />
<property file="${basedir}/build.properties" />
<property file="${basedir}/default.properties" />

First, rename build.properties to default.properties

Next, a developer can create one or more of the following files:

~/build.properties
~/lucene.build.properties
lucene/build.properties

That way, developers don't need to rename files in order to make things work
and the 'default' properties don't clutter up the build.xml file.

Thanks,

-jon


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

----- Original Message -----
From: <otis@apache.org>
To: <jakarta-lucene-cvs@apache.org>
Sent: Tuesday, February 26, 2002 8:10 PM
Subject: cvs commit: jakarta-lucene build.xml


> otis 02/02/26 17:10:58
>
> Modified: . build.xml
> Log:
> - Moved properties from build.properties in here. build.properties
should be
> removed and replaced by build.properties.sample.
> Targets docweb-index and docweb-war I have commented out since it
requires
> an Ant task that is not a part of Ant distribution yet. These should
be
> uncommented when this task makes it into the Ant distribution.
> Submitted by: Erik Hatcher
> Reviewed by: Otis Gospodnetic

Just to clarify.... the <index> task I submitted to lucene-dev is not going
to be committed to Ant. Its rightful home is with the Lucene codebase and
that is why I submitted it here. (Otherwise I would have committed it to
Ant myself! :)

I would love to have it in use in the Lucene build to create the
documentation search engine web, perhaps as an additional distributable for
release builds. I am looking for improvements and feedback on IndexTask and
its Lucene API usage (which I hacked together with little knowledge of what
I was doing at the time).

Erik



--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

They would not have to rename files to make things work... all the
properties got embedded into build.xml, so therefore no external files are
needed with the default config.

To customize is when you'd copy build.properties.sample, or hand create your
own tweaking the properties you wanted to override.

I prefer this because it keeps all defauilt build info inside build.xml
rather than there being two files necessary.

Erik

----- Original Message -----
From: "Jon Scott Stevens" <jon@latchkey.com>
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Sent: Tuesday, February 26, 2002 8:19 PM
Subject: Re: cvs commit: jakarta-lucene build.xml


> on 2/26/02 5:10 PM, "otis@apache.org" <otis@apache.org> wrote:
>
> > - Moved properties from build.properties in here. build.properties
should be
> > removed and replaced by build.properties.sample.
>
> -1.
>
> A better way to deal with this is to follow what Scarab and other projects
> do which is to do this:
>
> <!-- Give user a chance to override without editing this file
> (and without typing -D each time it compiles it -->
> <property file="${user.home}/lucene.build.properties" />
> <property file="${user.home}/build.properties" />
> <property file="${basedir}/build.properties" />
> <property file="${basedir}/default.properties" />
>
> First, rename build.properties to default.properties
>
> Next, a developer can create one or more of the following files:
>
> ~/build.properties
> ~/lucene.build.properties
> lucene/build.properties
>
> That way, developers don't need to rename files in order to make things
work
> and the 'default' properties don't clutter up the build.xml file.
>
> Thanks,
>
> -jon
>
>
> --
> To unsubscribe, e-mail:
<mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:lucene-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

If you have the properties both in build.properties.sample and build.xml,
then it is two places that you have to maintain them in.

-jon

on 2/26/02 6:02 PM, "Erik Hatcher" <lists@ehatchersolutions.com> wrote:

> They would not have to rename files to make things work... all the
> properties got embedded into build.xml, so therefore no external files are
> needed with the default config.
>
> To customize is when you'd copy build.properties.sample, or hand create your
> own tweaking the properties you wanted to override.
>
> I prefer this because it keeps all defauilt build info inside build.xml
> rather than there being two files necessary.
>
> Erik
>
> ----- Original Message -----
> From: "Jon Scott Stevens" <jon@latchkey.com>
> To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
> Sent: Tuesday, February 26, 2002 8:19 PM
> Subject: Re: cvs commit: jakarta-lucene build.xml
>
>
>> on 2/26/02 5:10 PM, "otis@apache.org" <otis@apache.org> wrote:
>>
>>> - Moved properties from build.properties in here. build.properties
> should be
>>> removed and replaced by build.properties.sample.
>>
>> -1.
>>
>> A better way to deal with this is to follow what Scarab and other projects
>> do which is to do this:
>>
>> <!-- Give user a chance to override without editing this file
>> (and without typing -D each time it compiles it -->
>> <property file="${user.home}/lucene.build.properties" />
>> <property file="${user.home}/build.properties" />
>> <property file="${basedir}/build.properties" />
>> <property file="${basedir}/default.properties" />
>>
>> First, rename build.properties to default.properties
>>
>> Next, a developer can create one or more of the following files:
>>
>> ~/build.properties
>> ~/lucene.build.properties
>> lucene/build.properties
>>
>> That way, developers don't need to rename files in order to make things
> work
>> and the 'default' properties don't clutter up the build.xml file.
>>
>> Thanks,
>>
>> -jon
>>
>>
>> --
>> To unsubscribe, e-mail:
> <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
>> For additional commands, e-mail:
> <mailto:lucene-dev-help@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

--
Standard rules apply: Ask any questions, and you get the job. ;-)


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

Agreed. I would say that this is a good argument for getting rid of
build.properties.sample altogether. Its not really needed, and anyone
wanting to tweak anything would likely have the know-how to figure out which
property they wanted to override by just looking at the top of build.xml.

I don't disapprove of the way you recommend. I think we can just chalk it
up to a matter of preference.

There are many projects that follow the build.properties.sample pattern
(Slide, Cactus, Commons, Struts, at least on my local perhaps slightly
outdated codebases).

I actually prefer no build.properties.sample.

My argument against default.properties is that lazy folks would just edit
properties there rather than figuring out that they could override them by
creating a new file. A developer is much less likely to touch build.xml,
and would quickly (with a little bit of Ant know-how) see the override files
available.

Erik

----- Original Message -----
From: "Jon Scott Stevens" <jon@latchkey.com>
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Sent: Tuesday, February 26, 2002 9:37 PM
Subject: Re: cvs commit: jakarta-lucene build.xml


> If you have the properties both in build.properties.sample and build.xml,
> then it is two places that you have to maintain them in.
>
> -jon
>
> on 2/26/02 6:02 PM, "Erik Hatcher" <lists@ehatchersolutions.com> wrote:
>
> > They would not have to rename files to make things work... all the
> > properties got embedded into build.xml, so therefore no external files
are
> > needed with the default config.
> >
> > To customize is when you'd copy build.properties.sample, or hand create
your
> > own tweaking the properties you wanted to override.
> >
> > I prefer this because it keeps all defauilt build info inside build.xml
> > rather than there being two files necessary.
> >
> > Erik
> >
> > ----- Original Message -----
> > From: "Jon Scott Stevens" <jon@latchkey.com>
> > To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
> > Sent: Tuesday, February 26, 2002 8:19 PM
> > Subject: Re: cvs commit: jakarta-lucene build.xml
> >
> >
> >> on 2/26/02 5:10 PM, "otis@apache.org" <otis@apache.org> wrote:
> >>
> >>> - Moved properties from build.properties in here. build.properties
> > should be
> >>> removed and replaced by build.properties.sample.
> >>
> >> -1.
> >>
> >> A better way to deal with this is to follow what Scarab and other
projects
> >> do which is to do this:
> >>
> >> <!-- Give user a chance to override without editing this file
> >> (and without typing -D each time it compiles it -->
> >> <property file="${user.home}/lucene.build.properties" />
> >> <property file="${user.home}/build.properties" />
> >> <property file="${basedir}/build.properties" />
> >> <property file="${basedir}/default.properties" />
> >>
> >> First, rename build.properties to default.properties
> >>
> >> Next, a developer can create one or more of the following files:
> >>
> >> ~/build.properties
> >> ~/lucene.build.properties
> >> lucene/build.properties
> >>
> >> That way, developers don't need to rename files in order to make things
> > work
> >> and the 'default' properties don't clutter up the build.xml file.
> >>
> >> Thanks,
> >>
> >> -jon
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> > <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> >> For additional commands, e-mail:
> > <mailto:lucene-dev-help@jakarta.apache.org>
> >>
> >>
> >
> >
> > --
> > To unsubscribe, e-mail:
<mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
<mailto:lucene-dev-help@jakarta.apache.org>
>
> --
> Standard rules apply: Ask any questions, and you get the job. ;-)
>
>
> --
> To unsubscribe, e-mail:
<mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:lucene-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

on 2/26/02 7:45 PM, "Erik Hatcher" <lists@ehatchersolutions.com> wrote:

> Agreed. I would say that this is a good argument for getting rid of
> build.properties.sample altogether. Its not really needed, and anyone
> wanting to tweak anything would likely have the know-how to figure out which
> property they wanted to override by just looking at the top of build.xml.
>
> I don't disapprove of the way you recommend. I think we can just chalk it
> up to a matter of preference.
>
> There are many projects that follow the build.properties.sample pattern
> (Slide, Cactus, Commons, Struts, at least on my local perhaps slightly
> outdated codebases).

Notice that you mention projects which have been influenced by Craig's build
system "ideas". :-)

> I actually prefer no build.properties.sample.
>
> My argument against default.properties is that lazy folks would just edit
> properties there rather than figuring out that they could override them by
> creating a new file. A developer is much less likely to touch build.xml,
> and would quickly (with a little bit of Ant know-how) see the override files
> available.

If we can get more projects to use a standard of having people create their
own 'build.properties' then that isn't an issue.

IMHO, build.xml shouldn't contain any properties that should be overridden
by the user.

The (lazy) user shouldn't have to even look at the build.xml to figure out
what they should do to customize things. Doing so requires a (not so lazy)
knowledge of Ant and XML which they might not have.

Having them create their own build.properties to override the
default.properties allows them to only look at a simple (lazy) properties
text file.

The argument of needing both a build.xml and default.properties doesn't
really fly with me. The user shouldn't even have to look at the build.xml
*ever*.

-jon


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

on 2/26/02 8:23 PM, "Jon Scott Stevens" <jon@latchkey.com> wrote:

> The argument of needing both a build.xml and default.properties doesn't
> really fly with me. The user shouldn't even have to look at the build.xml
> *ever*.
>
> -jon

I liken reading the build.xml to requiring users to read ./configure or
./Makefile to figure out how to customize things. Icky.

-jon


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

----- Original Message -----
From: "Jon Scott Stevens" <jon@latchkey.com>

> Notice that you mention projects which have been influenced by Craig's
build
> system "ideas". :-)

Hey, I'm not pro-build.properties.sample either! :) It was my suggestion
to migrate from everything in build.properties. Take it as an "incremental
refactoring"!

> If we can get more projects to use a standard of having people create
their
> own 'build.properties' then that isn't an issue.

Thats one of my main goals in life - and the instigator of this discussion.

> IMHO, build.xml shouldn't contain any properties that should be overridden
> by the user.

There shouldn't be any properties that *should* be overridden. Only if they
*want* to.

> Having them create their own build.properties to override the
> default.properties allows them to only look at a simple (lazy) properties
> text file.
>
> The argument of needing both a build.xml and default.properties doesn't
> really fly with me. The user shouldn't even have to look at the build.xml
> *ever*.

There is indeed much merit to these ways.

In some of my work/personal projects I actually use &properties; as an
entity reference and include the properties snippet in from an external
file, which has the <property file="..."/> stuff so that all my sub-projects
automatically have all the general and project specific property stuff
defined. It seems silly to always have build.src=src in a
default.properties, or would you place this particular one in build.xml
since it shouldn't be overridden?

Anyway, we're way off topic for lucene-dev. I'm merely making suggestions
for my preferences and best practices and believe your suggestions are
excellent and that our differences are mostly stylistic. Ant has its share
of "issues", not the least of which is standardization of this kind of
thing. I do feel there needs to be more in the way of standardization of
these things: target names, directory structure, how properties are loaded,
etc. There was a great thread on an Alexandria e-mail list about build.xml
standards quite a while ago which brought up a lot more of these kinds of
issues. I'm not sure a consensus was ever reached - the goal, at least, was
to document those standards and publicize them - I don't think it ever
happened or at least it didn't get distributed widely.

Erik



--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

Ah, I wish we had a discussion like this when the original suggestions
were made, not now that things have been patched and committed.

I never had a problem with the original Lucene setup, having 2 files
did not bother me, and I think it is easier to edit property=value text
files than Ant's XML.
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).

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.

That's my 16 lipas.
Otis

--- Jon Scott Stevens <jon@latchkey.com> wrote:
> on 2/26/02 5:10 PM, "otis@apache.org" <otis@apache.org> wrote:
>
> > - Moved properties from build.properties in here. build.properties
> should be
> > removed and replaced by build.properties.sample.
>
> -1.
>
> A better way to deal with this is to follow what Scarab and other
> projects
> do which is to do this:
>
> <!-- Give user a chance to override without editing this file
> (and without typing -D each time it compiles it -->
> <property file="${user.home}/lucene.build.properties" />
> <property file="${user.home}/build.properties" />
> <property file="${basedir}/build.properties" />
> <property file="${basedir}/default.properties" />
>
> First, rename build.properties to default.properties
>
> Next, a developer can create one or more of the following files:
>
> ~/build.properties
> ~/lucene.build.properties
> lucene/build.properties
>
> That way, developers don't need to rename files in order to make
> things work
> and the 'default' properties don't clutter up the build.xml file.
>
> Thanks,
>
> -jon
>
>
> --
> To unsubscribe, e-mail:
> <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-dev-help@jakarta.apache.org>
>


__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

----- Original Message -----
From: "Otis Gospodnetic" <otis_gospodnetic@yahoo.com>

> 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



--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

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 <lists@ehatchersolutions.com> wrote:
> ----- Original Message -----
> From: "Otis Gospodnetic" <otis_gospodnetic@yahoo.com>
>
> > 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:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

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 build.properties.sample with comments as to what can
be overriden and how
+1 on *no* default.properties

I prefer build.properties.sample to be there because it gives me as a
cluless user a clear idea as to what to do to customize things. If
simply default.properties file is there, I wouldn't even think that some
other file called 'build.properties" 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
default.properties 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.

Dmitry



--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

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" <otis_gospodnetic@yahoo.com>
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
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 <lists@ehatchersolutions.com> wrote:
> > ----- Original Message -----
> > From: "Otis Gospodnetic" <otis_gospodnetic@yahoo.com>
> >
> > > 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:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:lucene-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

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 <lists@ehatchersolutions.com> 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" <otis_gospodnetic@yahoo.com>
> To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
> 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 <lists@ehatchersolutions.com> wrote:
> > > ----- Original Message -----
> > > From: "Otis Gospodnetic" <otis_gospodnetic@yahoo.com>
> > >
> > > > 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:lucene-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:lucene-dev-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-dev-help@jakarta.apache.org>
>


__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

on 2/27/02 10:08 AM, "Dmitry Serebrennikov" <dmitrys@earthlink.net> 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 build.properties.sample with comments as to what can
> be overriden and how
> +1 on *no* default.properties
>
> I prefer build.properties.sample to be there because it gives me as a
> cluless user a clear idea as to what to do to customize things. If
> simply default.properties file is there, I wouldn't even think that some
> other file called 'build.properties" 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
> default.properties 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 build.properties to override
the default.properties 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 build.properties.sample. That is bad.

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
build.properties.sample 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.

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/default.properties. 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/default.properties.

The settings in the build/default.properties are fairly well documented.

Instead, one should create a ~/build.properties and/or a
build/build.properties file and place the properties in those files
which override the properties in the build/default.properties. The build
system will take the first property it can find and use that. It will
first look for the ~/build.properties and then look for the
build/default.properties.

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/default.properties for a list of things that you can
define.


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

--- Jon Scott Stevens <jon@latchkey.com> wrote:
> on 2/27/02 10:08 AM, "Dmitry Serebrennikov" <dmitrys@earthlink.net>
> 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 build.properties.sample with comments as to what
> can
> > be overriden and how
> > +1 on *no* default.properties
> >
> > I prefer build.properties.sample to be there because it gives me as
> a
> > cluless user a clear idea as to what to do to customize things. If
> > simply default.properties file is there, I wouldn't even think that
> some
> > other file called 'build.properties" 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
> > default.properties 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 build.properties to
> override
> the default.properties 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 build.properties.sample. That is
> bad.

I imagined build.properties.sample 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
> build.properties.sample 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 default.properties, which could be a
-1. Dmitry, are you a commiter? I don't see your name on
http://jakarta.apache.org/lucene/docs/whoweare.html

Thanks,
Otis

> 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/default.properties. 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/default.properties.
>
> The settings in the build/default.properties are fairly well
> documented.
>
> Instead, one should create a ~/build.properties and/or a
> build/build.properties file and place the properties in those files
> which override the properties in the build/default.properties. The
> build
> system will take the first property it can find and use that. It will
> first look for the ~/build.properties and then look for the
> build/default.properties.
>
> 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/default.properties for a list of things that you can
> define.


__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

on 2/27/02 1:43 PM, "Otis Gospodnetic" <otis_gospodnetic@yahoo.com> wrote:

> I imagined build.properties.sample 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.

As I said before, it would be a terrible idea to require people to read the
build.xml file to figure out what properties they need to override. I liken
that to requiring people to read a Makefile or ./configure script.

> 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 default.properties, which could be a
> -1. Dmitry, are you a commiter? I don't see your name on
> http://jakarta.apache.org/lucene/docs/whoweare.html

If someone gives me a -1, then we are in a stalemate and need to continue to
discuss this further. I gave my response to Dmitry's posting, lets wait for
his response.

p.s. Double negatives are not very clear. Either vote +1 or -1.

-jon


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

>
>
>
>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 default.properties, which could be a
>-1. Dmitry, are you a commiter? I don't see your name on
>http://jakarta.apache.org/lucene/docs/whoweare.html
>
Yes, I'm am a commiter, although my major contribution is still pending
(support for TermVectors). Hopefully, once the release goes out, I can
bring my code up to date and commit into the CVS (but this is off topic).
I voted +1 intentionally, so as not to give a -1 against the other
option. I'm ok with whatever is decided in other words.




--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

*whew* what a bunch of trouble I stirred up. I apologize folks. I'm a firm
believer in getting Ant usage more standardized, its just there is a lot of
competing ways of such "standardization". Thank you Jon for enlightening me
a bit into your reasons - it has been helpful for my own views. I actually
like the way you're spelling things out - what I don't like is that it takes
two files to do so and risks a user modifying default.properties (because
users don't read documentation anyway, even if it is right at the top of the
file they are editing!). As an Ant committer, I'm 'committed' to making our
build file world a happier place.

Erik


----- Original Message -----
From: "Dmitry Serebrennikov" <dmitrys@earthlink.net>
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Sent: Wednesday, February 27, 2002 7:57 PM
Subject: Re: cvs commit: jakarta-lucene build.xml


> >
> >
> >
> >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 default.properties, which could be a
> >-1. Dmitry, are you a commiter? I don't see your name on
> >http://jakarta.apache.org/lucene/docs/whoweare.html
> >
> Yes, I'm am a commiter, although my major contribution is still pending
> (support for TermVectors). Hopefully, once the release goes out, I can
> bring my code up to date and commit into the CVS (but this is off topic).
> I voted +1 intentionally, so as not to give a -1 against the other
> option. I'm ok with whatever is decided in other words.
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:lucene-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

on 2/27/02 7:05 PM, "Erik Hatcher" <lists@ehatchersolutions.com> wrote:

> *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...

> I apologize folks. I'm a firm
> believer in getting Ant usage more standardized, its just there is a lot of
> competing ways of such "standardization". Thank you Jon for enlightening me
> a bit into your reasons - it has been helpful for my own views. I actually
> like the way you're spelling things out

Thanks.

> - what I don't like is that it takes
> two files to do so

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.

Maybe some of you have never had to deal with autoconf/automake/aclocal. It
requires TONS of little files all over the place. :-)

> and risks a user modifying default.properties (because
> users don't read documentation anyway, even if it is right at the top of the
> file they are editing!).

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.

> As an Ant committer

And I'm one of the first users and one of the very first committers. :-)
Looking back in the CVS log, I see commits I made to ant nearly 1.5 years
ago. :-)

>, 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. :-)

-jon


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

----- Original Message -----
From: "Jon Scott Stevens" <jon@latchkey.com>
> > *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, <property
file="${user.home}/build.properties"/> - 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: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

on 2/27/02 10:02 PM, "Erik Hatcher" <lists@ehatchersolutions.com> wrote:

> 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, <property
> file="${user.home}/build.properties"/> - 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).

Hmm...I'm not sure of that type of forceful standardization either...but
that is a result of some of the influence Sam Ruby has on me...:-)

>> 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 did a lot of the build system for Apache JServ...ewwww....

>> 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.

Yea, we could take a sha1 hash of the default.properties and not run it if
it doesn't pash the hash. :-)

> At least makefiles have fairly consistent conventions that are followed,
> right?

Nope. Not at all. The only thing that is somewhat consistent is the name of
the targets.

> At our local JUG next week someone is presenting briefly on Scarab...

Out of curiosity, I'm curious who that is. :-) Feel free to respond
privately.

> I can't wait to see it (I haven't yet).

Feel free to play with...

http://scarab.whichever.com

It is a runbox that is re-built from CVS head nightly.

> Better yet, when will we see it in
> action instead of Bugzilla?! ;)

You can install it at any point. We are currently on b4 and are about to
release b5 in the next day or so.

-jon


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

----- Original Message -----
From: "Jon Scott Stevens" <jon@latchkey.com>

> > 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, <property
> > file="${user.home}/build.properties"/> - 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).
>
> Hmm...I'm not sure of that type of forceful standardization either...but
> that is a result of some of the influence Sam Ruby has on me...:-)

I'm not sure of it either. I'm just thinking out loud. Certainly Ant
should not constrain its capabilities just to force one way of doing
something, but somehow these things should be at least documented so that
build file writers can have guidelines to follow. Yes, I know - I should
volunteer! Well, I am trying to do my part, really I am! :)

> > At least makefiles have fairly consistent conventions that are followed,
> > right?
>
> Nope. Not at all. The only thing that is somewhat consistent is the name
of
> the targets.

Even that is a free for all with Ant build files mostly.

Erik



--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>