lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Tests, Contribs, and Releases
Date Thu, 17 May 2007 00:37:33 GMT
Yeah, I hate to admit it and start another round of Maven vs. ANT,  
but Maven does take care of darn near all these issues.  :-)  To  
share my experience, we are actually in the process of upgrading from  
Maven 1 to Maven 2.  The docs are good for the basics (i.e. 80-90% of  
what you need), but as soon as you want to get in deeper, it becomes  
difficult to figure out w/o digging into the code.  Having said that,  
I still think it is worthwhile for what we do.

Plus, since Maven is Apache, it has a lot of things built into it for  
managing Apache releases, like signing, publishing, etc.

Now, for us, Maven for the core is quite simple and would be real  
easy to setup, it is the contribs that will take a little work to get  
in place, but still wouldn't be all that difficult.

To answer your question, though, I don't see any reason not to make  
the changes to make the current process more repeatable.


On May 16, 2007, at 6:07 PM, Paul Smith wrote:

> Does Lucene have a gump run descriptor?  That's quite useful for  
> tracking this sort of thing too.  It's very good at nagging! :)
> The standard maven assembly packaging runs the unit tests by  
> default too.  Changing the lucene build system to maven is not  
> something you'd want to jump at without careful thought , but might  
> be worth considering.  I used to be anti-maven, but since version  
> 2, and since Curt Arnold has been setting up the log4j build  
> environment for maven, I've been quite impressed with it's capability.
> cheers,
> Paul Smith
> On 17/05/2007, at 8:02 AM, Chris Hostetter wrote:
>> Hey everybody, this thread has been sitting in my inbox for a while
>> waiting for me to have a few minutes to look into it...
>> junit-errors-tf3571676.html
>> In a nutshell, when a guy from Debian went looking to package  
>> Lucene he
>> noticed that the official 2.1.0 release contained 2 test failures  
>> -- one
>> each in the highlighter and spellchecker contribs.
>> The specifics of the test failures don't really interest me as  
>> much as the
>> question: how did we manage to have a release with test failures?
>> A few things have jumped out at me while looking into this...
>> 1) the task "build-contrib" can be used to walk the contrib directory
>>    building each contrib, the task "test-contrib" can be used to  
>> walk the
>>    contrib directory testing each contrib.
>> 2) the "test" task only tests the lucene-core ... it does not  
>> depend on
>>    (or call) "test-contrib"
>> 3) The "nightly" build task depends on the "test" and "package- 
>> tgz" task
>>    (which depends on "build-contrib") but at no point is "test- 
>> contrib"
>>    run.
>> 4) The steps for creating an official release...
>>    ...specify using the "dist" and
>>    "dist-src" tasks -- neither of which depend on *ANY* tests  
>> being run
>>    (let alone contrib tests)
>> This seems very strange to me ... i would think that we would want:
>>   a) nightly builds to run the tests for all contribs, ala...
>>      <target name="nightly" depends="test, build-contrib, test- 
>> contrib, package-tgz">
>>   b) the release insctructions to make it clear that all unit  
>> tests (core
>>      and contrib) should be run prior to creating teh distribution.
>> Does anyone see any reason not to make these changes?
>> -Hoss
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> Paul Smith
> Core Engineering Manager
> Aconex
> The easy way to save time and money on your project
> 696 Bourke Street, Melbourne,
> VIC 3000, Australia
> Tel: +61 3 9240 0200  Fax: +61 3 9240 0299
> Email:
> This email and any attachments are intended solely for the  
> addressee. The contents may be privileged, confidential and/or  
> subject to copyright or other applicable law. No confidentiality or  
> privilege is lost by an erroneous transmission. If you have  
> received this e-mail in error, please let us know by reply e-mail  
> and delete or destroy this mail and all copies. If you are not the  
> intended recipient of this message you must not disseminate, copy  
> or take any action in reliance on it. The sender takes no  
> responsibility for the effect of this message upon the recipient's  
> computer system.

Grant Ingersoll
Center for Natural Language Processing

Read the Lucene Java FAQ at 

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

View raw message