lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject build process changes
Date Mon, 02 May 2005 01:27:08 GMT
I have done some extensive rearranging of the build system to 
facilitate the inclusion of the contrib pieces into future source and 
binary distributions.  I'll describe it in more detail below.

First - if you have any problems with the Lucene build process as it 
currently stands in Subversion, let me know.  All existing targets 
should still work as it did before.  Just typing "ant" will build the 
Lucene JAR file as it has done.

The building of the contrib components individually still needs some 
adjustments, but the pieces do build successfully for me.  To build all 
the contrib pieces now, run "ant build-contrib" at the top-level.  
Running "dist-all" target incorporates the contrib pieces into the 
source and binary .zip/.tar.gz files.

Please provide feedback on what, if anything, needs to be changed to 
make it viable for a 1.9 release.  I will continue to tinker with the 
odds and ends.  Some known issues are that only JAR files build by the 
contrib projects are put into the distribution, which means 
contrib/javascript is not distributed currently.  Javadoc documentation 
is built into the main documentation, but any other documentation 
within a contrib project is not incorporated (though there isn't much 
documentation to distribute on these pieces anyway, unfortunately).  
Running unit tests of all the contrib components as part of the main 
build is not done.

I believe it was Doug that had proposed the following:
  "ant dist" will create something like:


However it seems much simpler for us to only distribute 
lucene-XX.tar.gz/zip and lucene-XX-src.tar.gz/.zip rather than 
distributing each contrib component separately.  The current build 
process builds the same 4 distribution files as before rather than one 
set for each component.  What are your thoughts on what files we should 
actually distribute?  There is merit to having them all bundled 
together, built at the same time, and labeled the same to ensure 
compatibility.  And there is also an argument to be made to letting 
each component release on its own cycle.  We could have both - but 
perhaps for 1.9/2.0 we should keep it simple and bundle it all together 
and revisit individual component releases then.  Distributing the 
binaries of these components is a huge improvement over the "do it 
yourself" procedure before, so we'll already have a huge improvement in 
our distribution I think.


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

View raw message