Make it easier to adapt ant build process to where the lucene libs are

[GoogleCodeExporter]

Currently a build after a clean checkout of the sources will always fail since 
the build process does not know where the lucene libraries are located. There 
is also no easy way to configure this without actually modifying build.xml

I propose to change build.xml so that the user can easily configure the 
location of the lucene libraries by either specifying an environment variable, 
by providing build.properties file or by copying/linking the directory with the 
lucene libraries into the current directory.

I attach a modified build.xml that would accomplish this. The location of the 
directory containing the Lucene jar files can be specified by the environment 
variable LUCENE_LIBDIR or by setting the property "lucenelibdir" in 
build.properties.

Original issue reported on code.google.com by johann.petrak@gmail.com on 3 Sep 2010 at 8:48

Attachments:

• build.xml

[GoogleCodeExporter]

This is an ongoing issue. We've always made lucene classes available by 
instructing users to add the lucene jars to their classpath variable. A longer 
term solution would be to use package to manage the dependencies automatically 
such as maven.

Do you think it's a big benefit to have this configured in the build file? I 
guess it would probably make it easier to design clear error messages.

Original comment by widd...@google.com on 3 Sep 2010 at 6:58

[GoogleCodeExporter]

To be honest, I do not like Maven and I am probably not the only one.
My propsed build file will not change anything for the worse but gives various 
options of how people can include their existing Lucene library. A little 
sentence in a README or BUILD file could clear those up. 
If the user does not use either of this options, everything will be handled 
just like before, so no damate is done but replacing the current version with 
this version.

Original comment by johann.petrak@gmail.com on 3 Sep 2010 at 10:55

[GoogleCodeExporter]

Is there any chance for this modified buil.xml to get checked in? As it just 
gives the user additional options to include the lucene libs in the build it 
should  not break anything existing.

Original comment by johann.petrak@gmail.com on 14 Sep 2010 at 9:38

[GoogleCodeExporter]

Hi there,

It broke my build because I didn't have the LUCENE_LIBDIR variable set. I fixed 
this with export LUCENE_LIBDIR=".../lucene-3.0.1/", but still the benefit of 
setting this over adding the Lucene jars to your classpath doesn't seem that 
big (for setting the classpath I have to add two jars, not one directory, 
that's all). I don't think it's worth breaking everyone's existing build 
process for this, at least.

I may be using the new build files slightly wrongly though - if you can 
document the new process so that the integration with the old one is more 
seamless then we should consider going ahead.

Thanks,
Dominic

Original comment by widd...@google.com on 14 Sep 2010 at 3:32

[GoogleCodeExporter]

Ahh, you are right, I accidently left the part in the build.xml file that uses 
"./lucenelib" as a fallback if neither the environment variable LUCENE_LIBDIR 
nor the property lucenelibdir is set. Since that directory does not exist in 
your case, the build will fail.
My suggestion would be to either add an (empty) "./lib" directory and use that 
as a fallback instead of ./lucenelib (having a lib dir seems to be somewhat a 
convention for java projects with an ant buildfile ... the user can copy all 
the jars the project depends on there or the project can include the correct 
jars by default there). 

I would be interested what you mean by "adding the Lucene jars to your 
classpath"? Do you manually edit the build.xml file?

My interest is really to make this build.xml file work for as many users as 
possible as smoothly as possible.

Original comment by johann.petrak@gmail.com on 14 Sep 2010 at 6:48

[GoogleCodeExporter]

Which line should be removed from the build file? I still haven't got this to 
work without setting LUCENE_LIBDIR explicitly.

So if I do:
$ export LUCENE_LIBDIR=/home/widdows/software/lucene/lucene-3.0.1/
$ ant

my build works, and doesn't work without this.

"adding the Lucene jars to your classpath" literally means setting your 
CLASSPATH environment variable as Java's main way of finding resources. 
Nowadays I've seen quite a few docs saying "java -cp ..." so I wonder if 
hard-coding your CLASSPATH as an environment variable in your shell setup is 
considered brittle. But I'd like to keep supporting this mode if possible.

Also to compile the tests and extensions you need ParallelColt and junit, so in 
my bash setup I have

CLASSPATH=$CLASSPATH:/home/widdows/software/lucene/lucene-3.0.1/lucene-demos-3.0
.1.jar
CLASSPATH=$CLASSPATH:/home/widdows/software/lucene/lucene-3.0.1/lucene-core-3.0.
1.jar
CLASSPATH=$CLASSPATH:/home/widdows/software/junit/junit4.4/junit-4.4.jar
CLASSPATH=$CLASSPATH:/home/widdows/software/ParallelColt/bin/

I'd rather not have to set a PARALLEL_COLT_LIBDIR and JUNIT_LIBDIR, the 
possibility for environment variable names not lining up with those expected by 
the build file looks like it would increase the number of things the user has 
to get just right.

Please let me know if there's a way of doing this so that the ant build works 
fine if the dependencies are already in the CLASSPATH variable.

Sorry again for the delayed responses.

Original comment by widd...@google.com on 20 Sep 2010 at 5:45

[GoogleCodeExporter]

I am attaching a new version of build.xml that should cover all ways how one 
could want to configure this:
* If you do nothing, this should this time really work as the original and 
should use whatever is in CLASSPATH if that one is set
* if you want to use a specific environment variable for the additional libs 
needed by the semanticvectors package, you can set SEMVECT_LIBDIR to a 
directory containing those jars
* if you want to set it in build.properties, create a build.properties file in 
the same directory as build.xml and add a line "libdir=<thepathtothelibdir>"
* if you just add a directory lib to the current directory and place the jars 
there, they will automatically be used.

These options are also mentioned in a comment in the beginning of the build.xml 
file.

Original comment by johann.petrak@gmail.com on 20 Sep 2010 at 7:27

Attachments:

• build.xml

[GoogleCodeExporter]

Thanks, I just submitted the build file, works for me so far.

Would you be willing to add instructions to the InstallationInstructions page 
on the Wiki? I can make you a project developer for that.

Original comment by widd...@google.com on 21 Sep 2010 at 4:01

[GoogleCodeExporter]

Sure, i'd be happy to do that.

Original comment by johann.petrak@gmail.com on 21 Sep 2010 at 4:31

[GoogleCodeExporter]

Fixed and documented now.

Original comment by johann.petrak@gmail.com on 28 Oct 2010 at 8:01

• Changed state: Fixed

[GoogleCodeExporter]

Many many thanks.

Original comment by widd...@google.com on 28 Oct 2010 at 8:13