build process changes

[Erik Hatcher]

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:

       dist/
         lucene-XX.tar.gz
         lucene-src-XX.tar.gz
         lucene-XX.zip
         lucene-src-XX.zip
         contrib/
           highligher-XX.tar.gz
   ---

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.

        Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Doug Cutting]

Thanks for doing all this!  It looks great!

Erik Hatcher wrote:
> 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.

I agree.

> The current build
> process builds the same 4 distribution files as before rather than one
> set for each component.

This looks good to me.

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

I think it is a bad idea to release contrib stuff on its own cycle.
Release coherence was the major reason to bring everything under a
single source tree.  How the files are packaged is the only real question.

I think bundling everything into a single download, as you've done, is
good.  Keeping the jars separate, but with synchronized version numbers,
is what's important.  You've done this.  Thanks!

My only amdendment might be to place all of the contrib jars in a single
directory.

Doug


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Erik Hatcher]

On May 2, 2005, at 2:52 PM, Doug Cutting wrote:
> Thanks for doing all this!  It looks great!

*whew* - thanks.  As always, let me know if there is anything further  
I can do.  I'll tidy things up as I go with it.

>> 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.
>>
>
> I think it is a bad idea to release contrib stuff on its own cycle.  
> Release coherence was the major reason to bring everything under a  
> single source tree.  How the files are packaged is the only real  
> question.
>
> I think bundling everything into a single download, as you've done,  
> is good.  Keeping the jars separate, but with synchronized version  
> numbers, is what's important.  You've done this.  Thanks!
>
> My only amdendment might be to place all of the contrib jars in a  
> single directory.

My rationale for keeping all the contrib components in their own  
subdirectories was to allow room for eventual documentation or other  
files that might want to come along for the ride (like maybe a  
dependent ASL'd JAR?).

I'd be happy to change it if that is the desire though.

     Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Doug Cutting]

Erik Hatcher wrote:
> My rationale for keeping all the contrib components in their own  
> subdirectories was to allow room for eventual documentation or other  
> files that might want to come along for the ride (like maybe a  
> dependent ASL'd JAR?).

That makes sense.

> I'd be happy to change it if that is the desire though.

I think that all of the jars we create should be prefixed with 'lucene-'
and end with the version.  That will make it easier for folks to copy
them into lib directories and still know what they've got.  The main jar
could be renamed 'lucene-core'. So, in the end, this might look like:

lucene-core-1.9-rc1-dev.jar
lucene-demos-1.9-rc1-dev.jar
contrib/analyzers/lucene-analyzers-1.9-rc1-dev.jar
contrib/db/lucene-db-1.9-rc1-dev.jar
contrib/highlighter/lucene-highlighter-1.9-rc1-dev.jar
contrib/lucene-ant/lucene-ant-1.9-rc1-dev.jar
contrib/lucene-wordnet/lucene-wordnet-1.9-rc1-dev.jar
contrib/lucli/lucene-lucli-1.9-rc1-dev.jar
contrib/memory/lucene-memory-1.9-rc1-dev.jar
contrib/misc/lucene-misc-1.9-rc1-dev.jar
contrib/similarity/lucene-similarity-1.9-rc1-dev.jar
contrib/snowball/lucene-snowball-1.9-rc1-dev.jar
contrib/spellchecker/lucene-spellchecker-1.9-rc1-dev.jar
contrib/swing/lucene-swing-1.9-rc1-dev.jar

Comments?

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Erik Hatcher]

On May 5, 2005, at 3:52 PM, Doug Cutting wrote:

>> I'd be happy to change it if that is the desire though.
>>
>
> I think that all of the jars we create should be prefixed with  
> 'lucene-' and end with the version.  That will make it easier for  
> folks to copy them into lib directories and still know what they've  
> got.  The main jar could be renamed 'lucene-core'. So, in the end,  
> this might look like:
>
> lucene-core-1.9-rc1-dev.jar
> lucene-demos-1.9-rc1-dev.jar
> contrib/analyzers/lucene-analyzers-1.9-rc1-dev.jar
> contrib/db/lucene-db-1.9-rc1-dev.jar
> contrib/highlighter/lucene-highlighter-1.9-rc1-dev.jar
> contrib/lucene-ant/lucene-ant-1.9-rc1-dev.jar
> contrib/lucene-wordnet/lucene-wordnet-1.9-rc1-dev.jar
> contrib/lucli/lucene-lucli-1.9-rc1-dev.jar
> contrib/memory/lucene-memory-1.9-rc1-dev.jar
> contrib/misc/lucene-misc-1.9-rc1-dev.jar
> contrib/similarity/lucene-similarity-1.9-rc1-dev.jar
> contrib/snowball/lucene-snowball-1.9-rc1-dev.jar
> contrib/spellchecker/lucene-spellchecker-1.9-rc1-dev.jar
> contrib/swing/lucene-swing-1.9-rc1-dev.jar
>
> Comments?

All seems good to me.  I have made the adjustments locally.  I'll  
give it a day or so for comments and commit if no issues for this  
scheme come up.

     Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Yonik Seeley]

Definitely.  That's exactly our usecase... copying all the jars we
need (or perhaps all of them) into the lib directory of our webapp.

-Yonik

On 5/5/05, Doug Cutting <[hidden email]> wrote:
> I think that all of the jars we create should be prefixed with 'lucene-'
> and end with the version.  That will make it easier for folks to copy
> them into lib directories and still know what they've got.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Barry Hawkins]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Agreed.  Not that I have a vote, but that convention has made many of
the Jakarta Commons libs much easier to track in my projects.

Yonik Seeley wrote:

> Definitely.  That's exactly our usecase... copying all the jars we
> need (or perhaps all of them) into the lib directory of our webapp.
>
> -Yonik
>
> On 5/5/05, Doug Cutting <[hidden email]> wrote:
>
>>I think that all of the jars we create should be prefixed with 'lucene-'
>>and end with the version.  That will make it easier for folks to copy
>>them into lib directories and still know what they've got.

[...]

- --
Barry Hawkins
All Things Computed
site: www.alltc.com
weblog: www.yepthatsme.com

Registered Linux User #368650
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCe65cHuKcDICy0QoRAgyBAKCbzWddYu7e7Lo/Lus3gPh7l2nq2wCeJwZz
CtObfc1F7+JtyMcgrtfWL0k=
=9NRE
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]