Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Mark Miller
You should take a look at the precommit target you pointed me at! - Mark On Dec 2, 2012, at 3:00 PM, Michael McCandless luc...@mikemccandless.com wrote: Woops, I committed a fix ... Mike McCandless http://blog.mikemccandless.com On Sun, Dec 2, 2012 at 5:53 PM, Policeman Jenkins

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Michael McCandless
Yes, my bad, sorry :( I share your view that it's annoyingly slow to run the top-level ant precommit, especially when it's a tiny change. So this time I took a shortcut and ran ant javadocs in lucene/core as a proxy for a top-level ant precommit, yet that was not good enough because the ecj

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Steve Rowe
On Dec 4, 2012, at 2:45 PM, Michael McCandless luc...@mikemccandless.com wrote: I'd really love to have a per-module ant precommit. +1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail:

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Chris Hostetter
: I'd really love to have a per-module ant precommit. That's not really viable is it? small tweaks in one class might leave everything fine and dandy in that module, but another module that depends on it could break as a result (eg: removing a method/variable that is {@link}ed to, etc...)

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Mark Miller
Well perhaps there is a middle ground - 'quasi-precommit' that just checks fast stuff per module… (eg doesn't build all the javadocs) Then we would catch more, but perhaps not everything. Precommit is scary slow and if it's so slow no one will use it, it's almost not so helpful. - Mark On

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Michael McCandless
On Tue, Dec 4, 2012 at 3:00 PM, Mark Miller markrmil...@gmail.com wrote: Well perhaps there is a middle ground - 'quasi-precommit' that just checks fast stuff per module… (eg doesn't build all the javadocs) Right, is seems like a good number off the checks (no tabs, nocommits, author tags, ecj

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Steve Rowe
I think one useful middle point might be to only run checks on modules that have pending changes. Yes, as Hoss points out, an unchanged module's javadocs might no longer work (etc.), but I don't think that's the common case. On Dec 4, 2012, at 3:00 PM, Mark Miller markrmil...@gmail.com wrote:

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Robert Muir
I think the slowness problem can be fixed way easier than that. Actually in my opinion the main bug is the speed of building javadocs themselves. Today this requires lots of building of useless jars and some other things that are unnecessary. I also think javadocs for a module get rebuilt across

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Mark Miller
We are not talking about weakening them on Jenkins though. It won't wait till release time, it will be caught 10 min later by Jenkins. But if we can make it faster and keep all the checks, then by all means! Mark Sent from my iPhone On Dec 4, 2012, at 12:23 PM, Robert Muir rcm...@gmail.com

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Robert Muir
On Tue, Dec 4, 2012 at 3:33 PM, Mark Miller markrmil...@gmail.com wrote: We are not talking about weakening them on Jenkins though. It won't wait till release time, it will be caught 10 min later by Jenkins. Right but that then doesnt really improve the situation (its less than 10 minutes to

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Mark Miller
I guess my point is that since no one runs it (except perhaps you), it's not really helping anything. And the broken build is really more minor than a true broken build if tests at least still pass. Personally, I'm pretty okay with a nocommit failing the build for 30 minutes if the tests still

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Steve Rowe
I'm running it. It takes just over 4 minutes for me. Pretty minor IMHO. On Dec 4, 2012, at 5:26 PM, Mark Miller markrmil...@gmail.com wrote: I guess my point is that since no one runs it (except perhaps you), it's not really helping anything. And the broken build is really more minor

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-04 Thread Mark Miller
On Dec 4, 2012, at 4:18 PM, Steve Rowe sar...@gmail.com wrote: I'm running it. It takes just over 4 minutes for me. Pretty minor IMHO. I suppose if you have long tests anyway - typically my solr tests run takes 3:30 to 4 minutes, so doubling my time is not really something I'm ready to

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-02 Thread Policeman Jenkins Server
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3026/ Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC All tests passed Build Log: [...truncated 25027 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60: The following error occurred

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!

2012-12-02 Thread Michael McCandless
Woops, I committed a fix ... Mike McCandless http://blog.mikemccandless.com On Sun, Dec 2, 2012 at 5:53 PM, Policeman Jenkins Server jenk...@sd-datasolutions.de wrote: Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3026/ Java: 32bit/jdk1.7.0_09 -server