Build failed in Jenkins: Lucene-trunk-Linux-Java6-64-test-only #3511
See builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/3511/ -- [...truncated 1005 lines...] [junit4:junit4] Completed on J2 in 0.85s, 7 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestAutomatonQuery [junit4:junit4] Completed on J6 in 0.48s, 6 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced2 [junit4:junit4] Completed on J3 in 1.00s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestDocCount [junit4:junit4] Completed on J6 in 0.22s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestSimpleExplanationsOfNonMatches [junit4:junit4] Completed on J7 in 1.03s, 69 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestUniqueTermCount [junit4:junit4] Completed on J6 in 0.20s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.TestSmallFloat [junit4:junit4] Completed on J7 in 0.22s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestWildcardRandom [junit4:junit4] Completed on J5 in 0.67s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq [junit4:junit4] Completed on J3 in 0.34s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestComplexExplanationsOfNonMatches [junit4:junit4] Completed on J0 in 0.51s, 22 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spans.TestNearSpansOrdered [junit4:junit4] Completed on J2 in 0.53s, 10 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides [junit4:junit4] Completed on J5 in 0.12s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.document.TestDocument [junit4:junit4] Completed on J7 in 0.17s, 8 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestFilteredSearch [junit4:junit4] Completed on J0 in 0.19s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce [junit4:junit4] Completed on J3 in 0.28s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSetupTeardownChaining [junit4:junit4] Completed on J7 in 0.17s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestNoDeletionPolicy [junit4:junit4] Completed on J2 in 0.49s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestDocIdSet [junit4:junit4] Completed on J0 in 0.17s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestDocValuesScoring [junit4:junit4] Completed on J5 in 0.33s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer [junit4:junit4] Completed on J7 in 0.19s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestSubScorerFreqs [junit4:junit4] Completed on J3 in 0.11s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestFilterAtomicReader [junit4:junit4] Completed on J0 in 0.13s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter [junit4:junit4] Completed on J5 in 0.24s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.store.TestFileSwitchDirectory [junit4:junit4] Completed on J7 in 0.18s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestDateFilter [junit4:junit4] Completed on J3 in 0.14s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms [junit4:junit4] Completed on J6 in 1.20s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.TestSortedVIntList [junit4:junit4] Completed on J2 in 0.35s, 19 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.TestIdentityHashSet [junit4:junit4] Completed on J1 in 2.40s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSeedFromUncaught [junit4:junit4] Completed on J0 in 0.15s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestPositionIncrement [junit4:junit4] Completed on J5 in 0.18s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.TestRecyclingByteBlockAllocator [junit4:junit4] Completed on J7 in 0.11s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.document.TestDateTools [junit4:junit4] Completed on J3 in 0.15s, 5 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.store.TestDirectory [junit4:junit4] IGNOR/A 0.12s J6 | TestDirectory.testThreadSafety [junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly) [junit4:junit4] Completed on J6 in 0.25s, 8 tests, 1 skipped [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestCodecReported [junit4:junit4] Completed on J2 in 0.16s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.TestSearch [junit4:junit4] Completed on J1 in 0.17s, 1 test [junit4:junit4] [junit4:junit4] Suite:
Build failed in Jenkins: Lucene-trunk-Linux-Java7-64-test-only #3505
See builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/3505/ -- [...truncated 1009 lines...] [junit4:junit4] Completed on J4 in 0.51s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestTermVectorsWriter [junit4:junit4] Completed on J5 in 1.63s, 13 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.similarities.TestSimilarity2 [junit4:junit4] Completed on J1 in 0.76s, 7 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestDocTermOrds [junit4:junit4] Completed on J6 in 1.33s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestParallelAtomicReader [junit4:junit4] Completed on J2 in 0.60s, 6 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestExceptionInBeforeClassHooks [junit4:junit4] Completed on J5 in 0.44s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestPayloads [junit4:junit4] Completed on J6 in 0.59s, 7 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestMultiLevelSkipList [junit4:junit4] Completed on J3 in 0.98s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.TestExternalCodecs [junit4:junit4] Completed on J1 in 0.81s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule [junit4:junit4] Completed on J5 in 0.39s, 5 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestPrefixRandom [junit4:junit4] Completed on J0 in 3.91s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.automaton.TestBasicOperations [junit4:junit4] Completed on J4 in 1.16s, 8 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced2 [junit4:junit4] Completed on J2 in 1.23s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestComplexExplanationsOfNonMatches [junit4:junit4] Completed on J3 in 0.48s, 22 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestCheckIndex [junit4:junit4] Completed on J1 in 0.35s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestWildcardRandom [junit4:junit4] Completed on J6 in 0.53s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestDocCount [junit4:junit4] Completed on J0 in 0.36s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq [junit4:junit4] Completed on J4 in 0.42s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.automaton.TestSpecialOperations [junit4:junit4] Completed on J5 in 0.57s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestPerSegmentDeletes [junit4:junit4] Completed on J3 in 0.13s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex [junit4:junit4] Completed on J6 in 0.15s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.TestSearchForDuplicates [junit4:junit4] Completed on J2 in 0.39s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestIndexFileDeleter [junit4:junit4] Completed on J0 in 0.22s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestDocIdSet [junit4:junit4] Completed on J5 in 0.18s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer [junit4:junit4] Completed on J3 in 0.25s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSameRandomnessLocalePassedOrNot [junit4:junit4] Completed on J6 in 0.18s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings [junit4:junit4] IGNOR/A 0.03s J2 | Test2BPostings.test [junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly) [junit4:junit4] Completed on J2 in 0.13s, 1 test, 1 skipped [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterConfig [junit4:junit4] Completed on J4 in 0.32s, 9 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestSubScorerFreqs [junit4:junit4] Completed on J0 in 0.18s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.store.TestFileSwitchDirectory [junit4:junit4] Completed on J6 in 0.25s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms [junit4:junit4] Completed on J1 in 0.90s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.codecs.appending.TestAppendingCodec [junit4:junit4] Completed on J4 in 0.14s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.TestSortedVIntList [junit4:junit4] Completed on J5 in 0.37s, 19 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter [junit4:junit4] Completed on J3 in 0.32s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestPositionIncrement [junit4:junit4] Completed on J0 in 0.15s, 2
Jenkins build is back to normal : Lucene-trunk-Linux-Java6-64-test-only #3512
See builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/3512/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Jenkins build is back to normal : Lucene-trunk-Linux-Java7-64-test-only #3506
See builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/3506/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Build failed in Jenkins: Lucene-trunk-Linux-Java7-64-test-only #3505
This reproduces for me. [junit4:junit4] Suite: org.apache.lucene.index.TestBackwardsCompatibility [junit4:junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestBackwardsCompatibility -Dtests.method=testExactFileNames -Dtests.seed=6FC6BE093CC5EA0B -Dtests.slow=true -Dtests.locale=hi_IN -Dtests.timezone=Australia/NSW -Dtests.file.encoding=UTF-8 [junit4:junit4] FAILURE 1.74s J3 | TestBackwardsCompatibility.testExactFileNames [junit4:junit4] Throwable #1: java.lang.AssertionError: incorrect filenames in index: expected: [junit4:junit4] _0.cfe [junit4:junit4] _0.cfs [junit4:junit4] _0.si [junit4:junit4] _0_1.del [junit4:junit4] segments.gen [junit4:junit4] segments_2 [junit4:junit4] or _0.cfe [junit4:junit4] _0.cfs [junit4:junit4] _0.si [junit4:junit4] _0_1.liv [junit4:junit4] segments.gen [junit4:junit4] segments_2 [junit4:junit4] actual: [junit4:junit4] _0.fld [junit4:junit4] _0.inf [junit4:junit4] _0.pst [junit4:junit4] _0.si [junit4:junit4] _0.vec [junit4:junit4] _0_0.len [junit4:junit4] _0_1.liv [junit4:junit4] _0_10.dv [junit4:junit4] _0_11.dv [junit4:junit4] _0_12.dv [junit4:junit4] _0_13.dv [junit4:junit4] _0_14.dv [junit4:junit4] _0_15.dv [junit4:junit4] _0_16.dv [junit4:junit4] _0_17.dv [junit4:junit4] _0_18.dv [junit4:junit4] _0_19.dv [junit4:junit4] _0_2.len [junit4:junit4] _0_20.dv [junit4:junit4] _0_21.len [junit4:junit4] _0_22.len [junit4:junit4] _0_3.len [junit4:junit4] _0_4.len [junit4:junit4] _0_5.len [junit4:junit4] _0_8.dv [junit4:junit4] _0_9.dv [junit4:junit4] segments.gen [junit4:junit4] segments_2 [junit4:junit4]at __randomizedtesting.SeedInfo.seed([6FC6BE093CC5EA0B:9E6D150EDC0278C2]:0) [junit4:junit4]at org.junit.Assert.fail(Assert.java:93) [junit4:junit4]at org.apache.lucene.index.TestBackwardsCompatibility.testExactFileNames(TestBackwardsCompatibility.java:608) [junit4:junit4]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4:junit4]at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit4:junit4]at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit4:junit4]at java.lang.reflect.Method.invoke(Method.java:601) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) [junit4:junit4]at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) [junit4:junit4]at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) [junit4:junit4]at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) [junit4:junit4]at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) [junit4:junit4]at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) [junit4:junit4]at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) [junit4:junit4]at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) [junit4:junit4]at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4:junit4]at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:345) [junit4:junit4]at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:769) [junit4:junit4]at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:429) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) [junit4:junit4]at
RE: Build failed in Jenkins: Lucene-trunk-Linux-Java7-64-test-only #3505
Hi, this is just another one that fails now because of LogMergePolicy randomization. This was added by my commit, because TieredMergePolicy randomized the settings for the limits for CFS creation, but not LogMergePolicy. TestBackwardsCompatibility is a test that looks for exactly the file names as expected, so in my opinion it should not use a randomized LogMergePolicy at all, but instead use the default one. I'll check change the test after breakfast. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Sunday, August 26, 2012 10:01 AM To: dev@lucene.apache.org; buil...@flonkings.com Subject: Re: Build failed in Jenkins: Lucene-trunk-Linux-Java7-64-test-only #3505 This reproduces for me. [junit4:junit4] Suite: org.apache.lucene.index.TestBackwardsCompatibility [junit4:junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestBackwardsCompatibility -Dtests.method=testExactFileNames -Dtests.seed=6FC6BE093CC5EA0B - Dtests.slow=true -Dtests.locale=hi_IN -Dtests.timezone=Australia/NSW -Dtests.file.encoding=UTF-8 [junit4:junit4] FAILURE 1.74s J3 | TestBackwardsCompatibility.testExactFileNames [junit4:junit4] Throwable #1: java.lang.AssertionError: incorrect filenames in index: expected: [junit4:junit4] _0.cfe [junit4:junit4] _0.cfs [junit4:junit4] _0.si [junit4:junit4] _0_1.del [junit4:junit4] segments.gen [junit4:junit4] segments_2 [junit4:junit4] or _0.cfe [junit4:junit4] _0.cfs [junit4:junit4] _0.si [junit4:junit4] _0_1.liv [junit4:junit4] segments.gen [junit4:junit4] segments_2 [junit4:junit4] actual: [junit4:junit4] _0.fld [junit4:junit4] _0.inf [junit4:junit4] _0.pst [junit4:junit4] _0.si [junit4:junit4] _0.vec [junit4:junit4] _0_0.len [junit4:junit4] _0_1.liv [junit4:junit4] _0_10.dv [junit4:junit4] _0_11.dv [junit4:junit4] _0_12.dv [junit4:junit4] _0_13.dv [junit4:junit4] _0_14.dv [junit4:junit4] _0_15.dv [junit4:junit4] _0_16.dv [junit4:junit4] _0_17.dv [junit4:junit4] _0_18.dv [junit4:junit4] _0_19.dv [junit4:junit4] _0_2.len [junit4:junit4] _0_20.dv [junit4:junit4] _0_21.len [junit4:junit4] _0_22.len [junit4:junit4] _0_3.len [junit4:junit4] _0_4.len [junit4:junit4] _0_5.len [junit4:junit4] _0_8.dv [junit4:junit4] _0_9.dv [junit4:junit4] segments.gen [junit4:junit4] segments_2 [junit4:junit4] at __randomizedtesting.SeedInfo.seed([6FC6BE093CC5EA0B:9E6D150EDC0278C2] :0) [junit4:junit4] at org.junit.Assert.fail(Assert.java:93) [junit4:junit4] at org.apache.lucene.index.TestBackwardsCompatibility.testExactFileNames(TestB ackwardsCompatibility.java:608) [junit4:junit4] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4:junit4] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 57) [junit4:junit4] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI mpl.java:43) [junit4:junit4] at java.lang.reflect.Method.invoke(Method.java:601) [junit4:junit4] at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRu nner.java:1559) [junit4:junit4] at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(Randomiz edRunner.java:79) [junit4:junit4] at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Randomiz edRunner.java:737) [junit4:junit4] at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Randomiz edRunner.java:773) [junit4:junit4] at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Randomiz edRunner.java:787) [junit4:junit4] at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSet upTeardownChained.java:50) [junit4:junit4] at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCach eSanity.java:51) [junit4:junit4] at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfte rRule.java:45) [junit4:junit4] at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.ev aluate(SystemPropertiesInvariantRule.java:55) [junit4:junit4] at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThrea dAndTestName.java:48) [junit4:junit4] at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgn oreAfterMaxFailures.java:70) [junit4:junit4] at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.ja va:48) [junit4:junit4] at
RE: Build failed in Jenkins: Lucene-trunk-Linux-Java7-64-test-only #3505
OK, I fixed at revision: 1377384 The problem here was that the test was already setting CFS ratio to 1.0, but the rarely() was jumping in, setting the maximum segment size for CFS files to 0.3 MB and that was too much. I added an override like for CFS ratio, too. I will check the other tests that explicitely set CFS ratio to 1.0 to also set the maximum size to positive inf (the default). - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Sunday, August 26, 2012 10:16 AM To: dev@lucene.apache.org Subject: RE: Build failed in Jenkins: Lucene-trunk-Linux-Java7-64-test-only #3505 Hi, this is just another one that fails now because of LogMergePolicy randomization. This was added by my commit, because TieredMergePolicy randomized the settings for the limits for CFS creation, but not LogMergePolicy. TestBackwardsCompatibility is a test that looks for exactly the file names as expected, so in my opinion it should not use a randomized LogMergePolicy at all, but instead use the default one. I'll check change the test after breakfast. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Sunday, August 26, 2012 10:01 AM To: dev@lucene.apache.org; buil...@flonkings.com Subject: Re: Build failed in Jenkins: Lucene-trunk-Linux-Java7-64-test-only #3505 This reproduces for me. [junit4:junit4] Suite: org.apache.lucene.index.TestBackwardsCompatibility [junit4:junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestBackwardsCompatibility -Dtests.method=testExactFileNames -Dtests.seed=6FC6BE093CC5EA0B - Dtests.slow=true -Dtests.locale=hi_IN -Dtests.timezone=Australia/NSW -Dtests.file.encoding=UTF-8 [junit4:junit4] FAILURE 1.74s J3 | TestBackwardsCompatibility.testExactFileNames [junit4:junit4] Throwable #1: java.lang.AssertionError: incorrect filenames in index: expected: [junit4:junit4] _0.cfe [junit4:junit4] _0.cfs [junit4:junit4] _0.si [junit4:junit4] _0_1.del [junit4:junit4] segments.gen [junit4:junit4] segments_2 [junit4:junit4] or _0.cfe [junit4:junit4] _0.cfs [junit4:junit4] _0.si [junit4:junit4] _0_1.liv [junit4:junit4] segments.gen [junit4:junit4] segments_2 [junit4:junit4] actual: [junit4:junit4] _0.fld [junit4:junit4] _0.inf [junit4:junit4] _0.pst [junit4:junit4] _0.si [junit4:junit4] _0.vec [junit4:junit4] _0_0.len [junit4:junit4] _0_1.liv [junit4:junit4] _0_10.dv [junit4:junit4] _0_11.dv [junit4:junit4] _0_12.dv [junit4:junit4] _0_13.dv [junit4:junit4] _0_14.dv [junit4:junit4] _0_15.dv [junit4:junit4] _0_16.dv [junit4:junit4] _0_17.dv [junit4:junit4] _0_18.dv [junit4:junit4] _0_19.dv [junit4:junit4] _0_2.len [junit4:junit4] _0_20.dv [junit4:junit4] _0_21.len [junit4:junit4] _0_22.len [junit4:junit4] _0_3.len [junit4:junit4] _0_4.len [junit4:junit4] _0_5.len [junit4:junit4] _0_8.dv [junit4:junit4] _0_9.dv [junit4:junit4] segments.gen [junit4:junit4] segments_2 [junit4:junit4]at __randomizedtesting.SeedInfo.seed([6FC6BE093CC5EA0B:9E6D150EDC0278C2] :0) [junit4:junit4]at org.junit.Assert.fail(Assert.java:93) [junit4:junit4]at org.apache.lucene.index.TestBackwardsCompatibility.testExactFileNames( TestB ackwardsCompatibility.java:608) [junit4:junit4]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4:junit4]at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 57) [junit4:junit4]at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess orI mpl.java:43) [junit4:junit4]at java.lang.reflect.Method.invoke(Method.java:601) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedR u nner.java:1559) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(Randomi z edRunner.java:79) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Randomi z edRunner.java:737) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Randomi z edRunner.java:773) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Randomi z edRunner.java:787)
[jira] [Commented] (SOLR-874) Dismax parser exceptions on trailing OPERATOR
Alexander S. commented on SOLR-874 Dismax parser exceptions on trailing OPERATOR Hi, sorry for asking this here, but is the next error related to this issue? Aug 26, 2012 8:22:33 AM org.apache.solr.common.SolrException log SEVERE: org.apache.solr.common.SolrException at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:134) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:165) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:365) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:279) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:300) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: org.apache.lucene.queryParser.ParseException: Cannot parse '"admission";"adolescent";"adrenal gland disorders";"adrenocortical carcinoma";"adrenoleukodystrophy see leukodystrophies";"advocacy";"afd";"affordability";"african american health";"africaso";"aga";"aganglionic megacolon";"aggressive mastocytosis";"aging";"agranulocytic angina";"agu";"agyria";"ahc";"ahd";"ahds";"ahus";"aicardi syndrome";"aids";"aids and infections";"aids and pregnancy";"': Lexical error at line 1, column 391. Encountered: EOF after : "" at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:216) at org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:79) at org.apache.solr.search.QParser.getQuery(QParser.java:143) at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:105) ... 21 more Caused by: org.apache.lucene.queryParser.TokenMgrError: Lexical error at line 1, column 391. Encountered: EOF after : "" at org.apache.lucene.queryParser.QueryParserTokenManager.getNextToken(QueryParserTokenManager.java:1229) at org.apache.lucene.queryParser.QueryParser.jj_scan_token(QueryParser.java:1733) at org.apache.lucene.queryParser.QueryParser.jj_3R_2(QueryParser.java:1616) at org.apache.lucene.queryParser.QueryParser.jj_3_1(QueryParser.java:1623) at org.apache.lucene.queryParser.QueryParser.jj_2_1(QueryParser.java:1609) at org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1288) at org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1274) at org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1234) at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:206) ... 24 more And this one also looks very similar http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201203.mbox/%3C007b01ccf78e$9171c1f0$b45545d0$@gmail.com%3E Best, Alex This message is automatically generated by JIRA. If you think it was
[jira] [Comment Edited] (SOLR-874) Dismax parser exceptions on trailing OPERATOR
Alexander S. edited a comment on SOLR-874 Dismax parser exceptions on trailing OPERATOR Hi, sorry for asking this here, but is the next error related to this issue? Aug 26, 2012 8:36:24 AM org.apache.solr.common.SolrException log SEVERE: org.apache.solr.common.SolrException at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:134) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:165) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:365) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:279) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:300) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: org.apache.lucene.queryParser.ParseException: Cannot parse '"hgps" "hhho" "hhrh" ...truncated... "kidney stones" "kidney transplant" "kidney trafq=type:Tweet': Lexical error at line 1, column 6783. Encountered: EOF after : "\"kidney trafq=type:Tweet" at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:216) at org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:79) at org.apache.solr.search.QParser.getQuery(QParser.java:143) at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:105) ... 21 more Caused by: org.apache.lucene.queryParser.TokenMgrError: Lexical error at line 1, column 6783. Encountered: EOF after : "\"kidney trafq=type:Tweet" at org.apache.lucene.queryParser.QueryParserTokenManager.getNextToken(QueryParserTokenManager.java:1229) at org.apache.lucene.queryParser.QueryParser.jj_ntk(QueryParser.java:1772) at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1555) at org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1317) at org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1274) at org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1234) at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:206) ... 24 more And this one also looks very similar http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201203.mbox/%3C007b01ccf78e$9171c1f0$b45545d0$@gmail.com%3E Best, Alex This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-874) Dismax parser exceptions on trailing OPERATOR
Alexander S. edited a comment on SOLR-874 Dismax parser exceptions on trailing OPERATOR Hi, sorry for asking this here, but is the next error related to this issue? Aug 26, 2012 8:36:24 AM org.apache.solr.common.SolrException log SEVERE: org.apache.solr.common.SolrException at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:134) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:165) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:365) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:279) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:300) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: org.apache.lucene.queryParser.ParseException: Cannot parse '"hgps" "hhho" "hhrh" ...truncated... "kidney stones" "kidney transplant" "kidney trafq=type:Tweet': Lexical error at line 1, column 6783. Encountered: EOF after : "\"kidney trafq=type:Tweet" at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:216) at org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:79) at org.apache.solr.search.QParser.getQuery(QParser.java:143) at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:105) ... 21 more Caused by: org.apache.lucene.queryParser.TokenMgrError: Lexical error at line 1, column 6783. Encountered: EOF after : "\"kidney trafq=type:Tweet" at org.apache.lucene.queryParser.QueryParserTokenManager.getNextToken(QueryParserTokenManager.java:1229) at org.apache.lucene.queryParser.QueryParser.jj_ntk(QueryParser.java:1772) at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1555) at org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1317) at org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1274) at org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1234) at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:206) ... 24 more "kidney trafq=" should be "kidney transplantation" fq='type:Tweet', so it looks like the query string was truncated. And this one also looks very similar http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201203.mbox/%3C007b01ccf78e$9171c1f0$b45545d0$@gmail.com%3E Best, Alex This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
[jira] [Updated] (SOLR-3758) DirectSolrSpellChecker doesn't work when using group.
Christian Johnsson updated SOLR-3758 DirectSolrSpellChecker doesnt work when using group. Change By: Christian Johnsson (26/Aug/12 10:32) Environment: LinuxDebian6 /SolrCloudwith2shardsand2replicas. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Build failed in Jenkins: Lucene-trunk-Linux-Java7-64-test-only #3527
See builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/3527/changes Changes: [uschindler] Fix more test to not fail when rarely() selects a maximum segment size -- [...truncated 974 lines...] [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestComplexExplanationsOfNonMatches [junit4:junit4] Completed on J7 in 0.37s, 22 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestPerSegmentDeletes [junit4:junit4] Completed on J2 in 0.25s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterConfig [junit4:junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestIndexWriterConfig -Dtests.method=testLiveChangeToCFS -Dtests.seed=308EF24A26E68207 -Dtests.slow=true -Dtests.locale=es_PE -Dtests.timezone=Africa/Gaborone -Dtests.file.encoding=UTF-8 [junit4:junit4] FAILURE 0.09s J6 | TestIndexWriterConfig.testLiveChangeToCFS [junit4:junit4] Throwable #1: java.lang.AssertionError [junit4:junit4]at __randomizedtesting.SeedInfo.seed([308EF24A26E68207:B90C0968E9FED504]:0) [junit4:junit4]at org.junit.Assert.fail(Assert.java:92) [junit4:junit4]at org.junit.Assert.assertTrue(Assert.java:43) [junit4:junit4]at org.junit.Assert.assertFalse(Assert.java:68) [junit4:junit4]at org.junit.Assert.assertFalse(Assert.java:79) [junit4:junit4]at org.apache.lucene.index.TestIndexWriterConfig.testLiveChangeToCFS(TestIndexWriterConfig.java:351) [junit4:junit4]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4:junit4]at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit4:junit4]at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit4:junit4]at java.lang.reflect.Method.invoke(Method.java:601) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) [junit4:junit4]at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) [junit4:junit4]at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) [junit4:junit4]at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) [junit4:junit4]at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) [junit4:junit4]at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) [junit4:junit4]at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) [junit4:junit4]at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) [junit4:junit4]at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4:junit4]at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:345) [junit4:junit4]at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:769) [junit4:junit4]at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:429) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) [junit4:junit4]at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) [junit4:junit4]at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) [junit4:junit4]at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) [junit4:junit4]at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) [junit4:junit4]at
Build failed in Jenkins: Lucene-trunk-Linux-Java7-64-test-only #3528
See builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/3528/ -- [...truncated 968 lines...] [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestMultiLevelSkipList [junit4:junit4] Completed on J5 in 0.63s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestMultiFields [junit4:junit4] Completed on J6 in 0.86s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestExceptionInBeforeClassHooks [junit4:junit4] Completed on J0 in 0.44s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.similarities.TestSimilarity2 [junit4:junit4] Completed on J2 in 0.80s, 7 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestOmitPositions [junit4:junit4] Completed on J3 in 0.55s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestTermRangeQuery [junit4:junit4] Completed on J4 in 0.66s, 7 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestRegexpRandom [junit4:junit4] Completed on J7 in 0.39s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestBooleanOr [junit4:junit4] Completed on J5 in 0.48s, 5 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule [junit4:junit4] Completed on J2 in 0.44s, 5 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestCheckIndex [junit4:junit4] Completed on J5 in 0.24s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestDocCount [junit4:junit4] Completed on J2 in 0.19s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestComplexExplanationsOfNonMatches [junit4:junit4] Completed on J7 in 0.40s, 22 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced2 [junit4:junit4] Completed on J0 in 0.86s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestSimpleExplanationsOfNonMatches [junit4:junit4] Completed on J6 in 0.76s, 69 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestUniqueTermCount [junit4:junit4] Completed on J5 in 0.18s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestSizeBoundedForceMerge [junit4:junit4] Completed on J3 in 0.55s, 11 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpanExplanationsOfNonMatches [junit4:junit4] Completed on J4 in 0.54s, 31 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestPerSegmentDeletes [junit4:junit4] Completed on J7 in 0.20s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex [junit4:junit4] Completed on J0 in 0.17s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.TestSearchForDuplicates [junit4:junit4] Completed on J2 in 0.30s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestCachingWrapperFilter [junit4:junit4] Completed on J5 in 0.22s, 5 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.store.TestCopyBytes [junit4:junit4] Completed on J1 in 5.71s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestDocIdSet [junit4:junit4] Completed on J3 in 0.10s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer [junit4:junit4] Completed on J4 in 0.14s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSameRandomnessLocalePassedOrNot [junit4:junit4] Completed on J7 in 0.16s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings [junit4:junit4] IGNOR/A 0.02s J0 | Test2BPostings.test [junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly) [junit4:junit4] Completed on J0 in 0.08s, 1 test, 1 skipped [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestSubScorerFreqs [junit4:junit4] Completed on J2 in 0.15s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestTopDocsCollector [junit4:junit4] Completed on J6 in 0.30s, 8 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter [junit4:junit4] Completed on J5 in 0.13s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestDateFilter [junit4:junit4] Completed on J1 in 0.22s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites [junit4:junit4] Completed on J3 in 0.14s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.codecs.appending.TestAppendingCodec [junit4:junit4] Completed on J4 in 0.21s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestSegmentTermEnum [junit4:junit4] Completed on J7 in 0.15s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestBooleanScorer [junit4:junit4] Completed on J0 in 0.18s, 3 tests
RE: Build failed in Jenkins: Lucene-trunk-Linux-Java7-64-test-only #3528
Fixed. Sorry for noise! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: buil...@flonkings.com [mailto:buil...@flonkings.com] Sent: Sunday, August 26, 2012 11:46 AM To: dev@lucene.apache.org; sim...@apache.org Subject: Build failed in Jenkins: Lucene-trunk-Linux-Java7-64-test-only #3528 See builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/3528/ -- [...truncated 968 lines...] [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestMultiLevelSkipList [junit4:junit4] Completed on J5 in 0.63s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestMultiFields [junit4:junit4] Completed on J6 in 0.86s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestExceptionInBeforeClassHooks [junit4:junit4] Completed on J0 in 0.44s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.similarities.TestSimilarity2 [junit4:junit4] Completed on J2 in 0.80s, 7 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestOmitPositions [junit4:junit4] Completed on J3 in 0.55s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestTermRangeQuery [junit4:junit4] Completed on J4 in 0.66s, 7 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestRegexpRandom [junit4:junit4] Completed on J7 in 0.39s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestBooleanOr [junit4:junit4] Completed on J5 in 0.48s, 5 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule [junit4:junit4] Completed on J2 in 0.44s, 5 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestCheckIndex [junit4:junit4] Completed on J5 in 0.24s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestDocCount [junit4:junit4] Completed on J2 in 0.19s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestComplexExplanationsOfNonMatches [junit4:junit4] Completed on J7 in 0.40s, 22 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced2 [junit4:junit4] Completed on J0 in 0.86s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestSimpleExplanationsOfNonMatches [junit4:junit4] Completed on J6 in 0.76s, 69 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestUniqueTermCount [junit4:junit4] Completed on J5 in 0.18s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestSizeBoundedForceMerge [junit4:junit4] Completed on J3 in 0.55s, 11 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpanExplanationsOfNonMatches [junit4:junit4] Completed on J4 in 0.54s, 31 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestPerSegmentDeletes [junit4:junit4] Completed on J7 in 0.20s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex [junit4:junit4] Completed on J0 in 0.17s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.TestSearchForDuplicates [junit4:junit4] Completed on J2 in 0.30s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestCachingWrapperFilter [junit4:junit4] Completed on J5 in 0.22s, 5 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.store.TestCopyBytes [junit4:junit4] Completed on J1 in 5.71s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestDocIdSet [junit4:junit4] Completed on J3 in 0.10s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer [junit4:junit4] Completed on J4 in 0.14s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSameRandomnessLocalePassedOrNot [junit4:junit4] Completed on J7 in 0.16s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings [junit4:junit4] IGNOR/A 0.02s J0 | Test2BPostings.test [junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly) [junit4:junit4] Completed on J0 in 0.08s, 1 test, 1 skipped [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestSubScorerFreqs [junit4:junit4] Completed on J2 in 0.15s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestTopDocsCollector [junit4:junit4] Completed on J6 in 0.30s, 8 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter [junit4:junit4] Completed on J5 in 0.13s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestDateFilter [junit4:junit4] Completed on J1 in 0.22s, 2 tests [junit4:junit4] [junit4:junit4] Suite:
Jenkins build is back to normal : Lucene-trunk-Linux-Java7-64-test-only #3529
See builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/3529/changes - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3664) risk of inconsistency in solr(contrib)-module-thirdparty dependencies
Lance Norskog commented on SOLR-3664 risk of inconsistency in solr(contrib)-module-thirdparty dependencies Here is another way: repacking dependent jars into all contrib dist/ jars. I've done an experiment with analysis-extras, and it takes 4 seconds to repack the classes from the dependent jars into apache-solr-analysis-extras-5.0-SNAPSHOT.jar. Add this to solr/contrib/analysis-extras/build.xml: target name="addjars" zip destfile="../../dist/apache-solr-analysis-extras-4.0-SNAPSHOT.jar" update="true" zipfileset src="" class="code-quote">"../../build/contrib/solr-analysis-extras/lucene-libs/lucene-analyzers-icu-4.0-SNAPSHOT.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"../../build/contrib/solr-analysis-extras/lucene-libs/lucene-analyzers-morfologik-4.0-SNAPSHOT.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"../../build/contrib/solr-analysis-extras/lucene-libs/lucene-analyzers-smartcn-4.0-SNAPSHOT.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"../../build/contrib/solr-analysis-extras/lucene-libs/lucene-analyzers-stempel-4.0-SNAPSHOT.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"lib/icu4j-49.1.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"lib/morfologik-fsa-1.5.3.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"lib/morfologik-polish-1.5.3.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"lib/morfologik-stemming-1.5.3.jar" excludes="META-INF/MANIFEST.MF" / /zip /target Run 'ant dist addjars'. The dist jar goes from 20k to 15M. But, it's 15M in one deployable file. I don't know what to do about META-INF files in the absorbed libraries. This approach just preserves the manifest file. This approach needs a little rearranging of the order of the build steps. There is no place visible to the contrib build.xml where the solr/build dist jar is finished, but not yet copied to dist/. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3664) risk of inconsistency in solr(contrib)-module-thirdparty dependencies
Lance Norskog
updated SOLR-3664
risk of inconsistency in solr(contrib)-module-thirdparty dependencies
Change By:
Lance Norskog
(26/Aug/12 11:03)
Comment:
Hereisanotherway:repackingdependentjarsintoallcontribdist/jars.Ivedoneanexperimentwithanalysis-extras,andittakes4secondstorepacktheclassesfromthedependentjarsintoapache-solr-analysis-extras-5.0-SNAPSHOT.jar.Addthistosolr/contrib/analysis-extras/build.xml:{code:xml}targetname=addjarszipdestfile=../../dist/apache-solr-analysis-extras-4.0-SNAPSHOT.jarupdate=true zipfilesetsrc=""> zipfilesetsrc=""> zipfilesetsrc=""> zipfilesetsrc=""> zipfilesetsrc=""> zipfilesetsrc=""> zipfilesetsrc=""> zipfilesetsrc="">/zip/target{code}Runantdistaddjars.Thedistjargoesfrom20kto15M.But,its15Minonedeployablefile.IdontknowwhattodoaboutMETA-INFfilesintheabsorbedlibraries.Thisapproachjustpreservesthemanifestfile.Thisapproachneedsalittlerearrangingoftheorderofthebuildsteps.Thereisnoplacevisibletothecontribbuild.xmlwherethesolr/builddistjarisfinished,butnotyetcopiedtodist/.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-3623) inconsistent treatment of lucene jars third-party deps in analysis-extras uima (in war and in lucene-libs)
Lance Norskog reopened SOLR-3623 inconsistent treatment of lucene jars third-party deps in analysis-extras uima (in war and in lucene-libs) I opened this issue to fix jar arrangements so that the OpenNLP integration could work. analysis-extras, opennlp, and uima share the same problem: they use lucene libraries and third-party dependencies. Fixing license file problems is certainly helpful, but does not make deployment any easer. This issue was essentially hijacked. Here is one way to make it easy to deploy items outside of the solr war file: repack dependent jars into all contrib dist/ jars. Just pack everything about analysis-extras into dist/analysis-extras.jar. Remove the contrib lucene libraries from the war file. Add this to solr/contrib/analysis-extras/build.xml: target name="addjars" zip destfile="../../dist/apache-solr-analysis-extras-4.0-SNAPSHOT.jar" update="true" zipfileset src="" class="code-quote">"../../../lucene/build/analysis/common/lucene-analyzers-common-4.0-SNAPSHOT.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"../../../lucene/build/analysis/icu/lucene-analyzers-icu-4.0-SNAPSHOT.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"../../../lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-4.0-SNAPSHOT.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"../../../lucene/build/analysis/morfologik/lucene-analyzers-morfologik-4.0-SNAPSHOT.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"../../../lucene/build/analysis/phonetic/lucene-analyzers-phonetic-4.0-SNAPSHOT.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"../../../lucene/build/analysis/smartcn/lucene-analyzers-smartcn-4.0-SNAPSHOT.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"../../../lucene/build/analysis/stempel/lucene-analyzers-stempel-4.0-SNAPSHOT.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"lib/icu4j-49.1.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"lib/morfologik-fsa-1.5.3.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"lib/morfologik-polish-1.5.3.jar" excludes="META-INF/MANIFEST.MF" / zipfileset src="" class="code-quote">"lib/morfologik-stemming-1.5.3.jar" excludes="META-INF/MANIFEST.MF" / /zip /target Run 'ant dist addjars'. The dist jar goes from 20k (one file) to 21M (4035 files). But, it is 21M in one deployable file. Everything is in one place! Caveats: This approach needs a little rearranging of the order of the build steps. There is no place visible to the contrib build.xml where the solr/build dist jar is finished, but not yet copied to dist/. I don't know what to do about META-INF files in the absorbed libraries. This approach just preserves the manifest file. Redundant dependencies: analysis-extras and extraction both use icu4j, which is a huge jar. Too bad. dataimporter wants all of extraction. Stick with the current arrangement. This design is appropriate for analysis-extras, uima and opennlp. All of these have lucene libraries and lib/ directories, and the current build arrangement just plain does not work. It is a convenience for clustering, dataimporthandler (-extras), extraction, langid, and velocity. The build.xml file above needs macro-izing, and as mentioned the build sequence needs a point where the contrib build can repack the dist file inside solr/build. Change By: Lance Norskog (26/Aug/12 11:30) Status: Resolved Reopened Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To
[jira] [Commented] (SOLR-2491) spellcheck.maxCollationTries breaks when using FieldCollapsing
Christian Johnsson commented on SOLR-2491 spellcheck.maxCollationTries breaks when using FieldCollapsing Hi, I wonder if this is also a bug: https://issues.apache.org/jira/browse/SOLR-3758 Or if i have missunderstood something. Worked perfectly in 3.5 but not i 4.0 beta. Sorry for hijacking but i think it's kind of rellated This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3758) DirectSolrSpellChecker doesn't work when using group.
Christian Johnsson updated SOLR-3758 DirectSolrSpellChecker doesnt work when using group. Change By: Christian Johnsson (26/Aug/12 13:00) Description: Itseemslikespellcheckerusingsolr.DirectSolrSpellCheckerdoesntworkwhengroupingresults./select?q=mispeledGivesmecorrectspellingsuggestionsbut../select?q=mispeledgroup=truegroup.main=truegroup.field=titledontgiveanysuggestions.Itworkedin3.5withindexbasedspellchecker. Itseemslikeifimispellsomethingthatreturns0resultsidontgetanysuggestions.Ifimisspellsomethingthatgenereatearesultigetsuggestionsonit.Itshouldcomeupwithpropersuggestionseveniftherearenoresultstobedisplayed(Butthereisthingsthatshouldbesuggested).Longstoryshort.Samefunctionalityasin3.5:-) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
about example-DIH
Hello, In solr-trunk/solr/exampleREADME.txt it says java -Dsolr.solr.home=example-DIH but it should be java -Dsolr.solr.home=example-DIH/solr (it is correct in example-DIH/README.txt) When execute full-import on mail core, I get this : ( I am note sure if mail core needs some extra jars) Caused by: java.lang.ClassNotFoundException: org.apache.tika.Tika at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:627) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) Somehow core tika's Dataimport link seems does not working. Weird thing is other cores' works. (tested in firefox and safari) db, rss and solr cores have admin-extra.html while tika and mail don't. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4322) Can we make oal.util.packed.BulkOperation* smaller?
Robert Muir commented on LUCENE-4322 Can we make oal.util.packed.BulkOperation* smaller? based on this, can we just specialize 2, 3, 6, 7, 8 or something like that? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3759) mistakes about example-DIH
Ahmet Arslan created SOLR-3759 mistakes about example-DIH Issue Type: Bug Assignee: Unassigned Components: contrib - DataImportHandler, documentation Created: 26/Aug/12 17:23 Description: mail core's solrconfig.xml lacks lib directive for contrib/extraction/lib. Project: Solr Priority: Minor Reporter: Ahmet Arslan This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3759) mistakes about example-DIH
Ahmet Arslan updated SOLR-3759 mistakes about example-DIH Change By: Ahmet Arslan (26/Aug/12 17:24) Attachment: SOLR-3759.patch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: about example-DIH
In solr-trunk/solr/exampleREADME.txt it says java -Dsolr.solr.home=example-DIH but it should be java -Dsolr.solr.home=example-DIH/solr (it is correct in example-DIH/README.txt) When execute full-import on mail core, I get this : ( I am note sure if mail core needs some extra jars) Caused by: java.lang.ClassNotFoundException: org.apache.tika.Tika at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:627) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) I created SOLR-3759 for these two issues above. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3759) mistakes about example-DIH
Ahmet Arslan updated SOLR-3759 mistakes about example-DIH missing AdminHandlers for tika core and PingRequestHandler for all cores. Change By: Ahmet Arslan (26/Aug/12 17:49) Attachment: SOLR-3759.patch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: about example-DIH
Somehow core tika's Dataimport link seems does not working. Weird thing is other cores' works. (tested in firefox and safari) It seems that requestHandler name=/admin/ class=org.apache.solr.handler.admin.AdminHandlers / is required for UI. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-java7 - Build # 3119 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-java7/3119/ All tests passed Build Log: [...truncated 7775 lines...] [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: /usr/local/openjdk7/jre/bin/java -XX:+UseG1GC -Dtests.prefix=tests -Dtests.seed=6C8D748076FEE7B5 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.lockdir=/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/lucene/build -Dtests.codec=random -Dtests.postingsformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/testlogging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Dfile.encoding=ISO-8859-1 -classpath
Re: [JENKINS] Lucene-Solr-Tests-trunk-java7 - Build # 3119 - Failure
I think we should disable these tests at least on jenkins (by disabling @BadApples?). These are really complex tests and I know Mark has put a lot of effort to stabilize them but they're still causing a lot of noise. I don't think they're easy to fix -- these error code 11 is a JVM-level trap (that results from a resource deadlock, supposedly) -- but I have a suspicion people simply stopped looking at these failures. I really don't want to hurt anybody's feelings but there should be a hard limit of failures after which we consider a test unfixable and it should be excluded from normal jenkins runs. I tried to stabilize those tests myself and failed miserably. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-trunk-java7 - Build # 3119 - Failure
Btw. these JVM exit errors are preceded by a timeout on this test, the main thread hung on parsing HTTP response headers (?): TEST-BasicDistributedZkTest.testDistribSearch-seed#[6C8D748076FEE7B5] ID=991 RUNNABLE (in native code) at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:150) at java.net.SocketInputStream.read(SocketInputStream.java:121) at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:149) at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:111) at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:264) at org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:98) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:252) at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:282) at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:247) at org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:216) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:298) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:647) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:464) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:353) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:182) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:324) at org.apache.solr.cloud.BasicDistributedZkTest.waitForNon404or503(BasicDistributedZkTest.java:513) ... Seems like there should be a Socket.setSoTimeout so that read is interrupted in that loop? D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3759) mistakes about example-DIH
Lance Norskog commented on SOLR-3759 mistakes about example-DIH Cool! This is an illustration of why "one big example" is better: people test it! The convention in solr/ is to add solr.xml and collection1: solr/solr.xml solr/collection1 solr/collection1/conf ... Please change example-DIH/solr to match this. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4327) Use BooleanScorer1 for filter-down-low queries
[ https://issues.apache.org/jira/browse/LUCENE-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442181#comment-13442181 ] Tony Stevenson commented on LUCENE-4327: Faux comment, please ignore. JIRA testing. Use BooleanScorer1 for filter-down-low queries -- Key: LUCENE-4327 URL: https://issues.apache.org/jira/browse/LUCENE-4327 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Fix For: 5.0, 4.0 Attachments: LUCENE-4327.patch, LUCENE-4327.patch, LUCENE-4327.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4327) Use BooleanScorer1 for filter-down-low queries
[ https://issues.apache.org/jira/browse/LUCENE-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442184#comment-13442184 ] Uwe Schindler commented on LUCENE-4327: --- But it is text only now! Use BooleanScorer1 for filter-down-low queries -- Key: LUCENE-4327 URL: https://issues.apache.org/jira/browse/LUCENE-4327 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Fix For: 5.0, 4.0 Attachments: LUCENE-4327.patch, LUCENE-4327.patch, LUCENE-4327.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3760) Build packaging of complex contrib packages just plain does not work
Lance Norskog created SOLR-3760: --- Summary: Build packaging of complex contrib packages just plain does not work Key: SOLR-3760 URL: https://issues.apache.org/jira/browse/SOLR-3760 Project: Solr Issue Type: Improvement Components: Build Reporter: Lance Norskog The build system packages Lucene libraries in the Solr war, but they do not pack libraries required by the Lucene libraries. The UIMA and analysis-extras contrib packages have factories for the Lucene libraries. The net effect is that when solrconfig.xml include lib directives for dist/xxx-contribX-xxx and solr/contrib/contribX/lib, this fails because the lucene analyzer file inside the solr war cannot find the library files in solr/contrib/contribX/lib because the classloader for the war does not find the libraries from the lib directives. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3760) Build packaging of complex contrib packages just plain does not work
[ https://issues.apache.org/jira/browse/SOLR-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lance Norskog updated SOLR-3760: Description: The build system packages Lucene libraries in the Solr war, but they do not pack libraries required by the Lucene libraries. The UIMA and analysis-extras contrib packages have factories for the Lucene libraries. The net effect is that when solrconfig.xml include lib directives for dist/xxx-contribX-xxx.jar and solr/contrib/contribX/lib, this fails because the lucene analyzer file inside the solr war cannot find the library files in solr/contrib/contribX/lib because the classloader for the war does not find the libraries from the lib directives. Two alternative fixes are presented below. was: The build system packages Lucene libraries in the Solr war, but they do not pack libraries required by the Lucene libraries. The UIMA and analysis-extras contrib packages have factories for the Lucene libraries. The net effect is that when solrconfig.xml include lib directives for dist/xxx-contribX-xxx and solr/contrib/contribX/lib, this fails because the lucene analyzer file inside the solr war cannot find the library files in solr/contrib/contribX/lib because the classloader for the war does not find the libraries from the lib directives. Here is the easy way: move the lucene analyzer library from the solr war to a new directory inside solr/contrib/contribX/lucene-lib. The solrconfig.xml then has three lib directives: ../../dist/---contribX---.jar ../../contrib/contribX/lib ../../contrib/contribX/lucene-lib I'm doing this for the OpenNLP patch. Build packaging of complex contrib packages just plain does not work Key: SOLR-3760 URL: https://issues.apache.org/jira/browse/SOLR-3760 Project: Solr Issue Type: Improvement Components: Build Reporter: Lance Norskog The build system packages Lucene libraries in the Solr war, but they do not pack libraries required by the Lucene libraries. The UIMA and analysis-extras contrib packages have factories for the Lucene libraries. The net effect is that when solrconfig.xml include lib directives for dist/xxx-contribX-xxx.jar and solr/contrib/contribX/lib, this fails because the lucene analyzer file inside the solr war cannot find the library files in solr/contrib/contribX/lib because the classloader for the war does not find the libraries from the lib directives. Two alternative fixes are presented below. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3760) Build packaging of complex contrib packages just plain does not work
[
https://issues.apache.org/jira/browse/SOLR-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442193#comment-13442193
]
Lance Norskog commented on SOLR-3760:
-
Here is the hard way: repack dependent jars into all contrib dist/ jars. For
example, pack everything about analysis-extras into dist/*analysis-extras*.jar.
Remove the contrib lucene libraries from the war file.
Add this to solr/contrib/analysis-extras/build.xml:
{code:xml}
target name=addjars
zip destfile=../../dist/apache-solr-analysis-extras-4.0-SNAPSHOT.jar
update=true
zipfileset
src=../../../lucene/build/analysis/common/lucene-analyzers-common-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/icu/lucene-analyzers-icu-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/morfologik/lucene-analyzers-morfologik-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/phonetic/lucene-analyzers-phonetic-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/smartcn/lucene-analyzers-smartcn-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/stempel/lucene-analyzers-stempel-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset src=lib/icu4j-49.1.jar excludes=META-INF/MANIFEST.MF /
zipfileset src=lib/morfologik-fsa-1.5.3.jar
excludes=META-INF/MANIFEST.MF /
zipfileset src=lib/morfologik-polish-1.5.3.jar
excludes=META-INF/MANIFEST.MF /
zipfileset src=lib/morfologik-stemming-1.5.3.jar
excludes=META-INF/MANIFEST.MF /
/zip
/target
{code}
Run 'ant dist addjars'. The dist jar goes from 20k (one file) to 21M (4035
files). But, it is 21M in one deployable file. Everything is in one place! (If
the size bothers you, split the Chinese, Japanese and Polish support into
separate contribs.)
Caveats:
* This approach needs a little rearranging of the order of the build steps.
There is no place visible to the contrib build.xml where the solr/build dist
jar is finished, but not yet copied to dist/. I don't know what to do about
META-INF files in the absorbed libraries. This approach just preserves the
manifest file.
* Redundant dependencies:
** analysis-extras and extraction both use icu4j, which is a huge jar. Too bad.
** dataimporter wants all of extraction. Stick with the current arrangement.
This design is appropriate for analysis-extras, uima and opennlp. All of these
have lucene libraries and lib/ directories, and the current build arrangement
just plain does not work. It is a convenience for clustering, dataimporthandler
(-extras), extraction, langid, and velocity.
The build.xml file above needs macro-izing. As mentioned the build sequence
needs a point where the contrib build can repack the dist file inside
solr/build.
Build packaging of complex contrib packages just plain does not work
Key: SOLR-3760
URL: https://issues.apache.org/jira/browse/SOLR-3760
Project: Solr
Issue Type: Improvement
Components: Build
Reporter: Lance Norskog
The build system packages Lucene libraries in the Solr war, but they do not
pack libraries required by the Lucene libraries. The UIMA and analysis-extras
contrib packages have factories for the Lucene libraries.
The net effect is that when solrconfig.xml include lib directives for
dist/xxx-contribX-xxx.jar and solr/contrib/contribX/lib, this fails because
the lucene analyzer file inside the solr war cannot find the library files in
solr/contrib/contribX/lib because the classloader for the war does not find
the libraries from the lib directives.
Two alternative fixes are presented below.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-3760) Build packaging of complex contrib packages just plain does not work
[
https://issues.apache.org/jira/browse/SOLR-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442188#comment-13442188
]
Lance Norskog edited comment on SOLR-3760 at 8/27/12 8:15 AM:
--
Here is the easy way: move the lucene analyzer library from the solr war to a
new directory inside solr/contrib/contribX/lucene-lib. The solrconfig.xml then
has three lib directives:
../../dist/xxx\-contribX\-xxx.jar
../../contrib/contribX/lib
../../contrib/contribX/lucene-lib
I'm doing this for the OpenNLP patch. It requires adding 'clean' to the ant
targets in solr/contrib. Add {{contrib-crawl target=clean
failonerror=false/}} to solr/build.xml:clean
was (Author: lancenorskog):
Here is the easy way: move the lucene analyzer library from the solr war to
a new directory inside solr/contrib/contribX/lucene-lib. The solrconfig.xml
then has three lib directives:
../../dist/xxx\-contribX\-xxx.jar
../../contrib/contribX/lib
../../contrib/contribX/lucene-lib
I'm doing this for the OpenNLP patch.
Build packaging of complex contrib packages just plain does not work
Key: SOLR-3760
URL: https://issues.apache.org/jira/browse/SOLR-3760
Project: Solr
Issue Type: Improvement
Components: Build
Reporter: Lance Norskog
The build system packages Lucene libraries in the Solr war, but they do not
pack libraries required by the Lucene libraries. The UIMA and analysis-extras
contrib packages have factories for the Lucene libraries.
The net effect is that when solrconfig.xml include lib directives for
dist/xxx-contribX-xxx.jar and solr/contrib/contribX/lib, this fails because
the lucene analyzer file inside the solr war cannot find the library files in
solr/contrib/contribX/lib because the classloader for the war does not find
the libraries from the lib directives.
Two alternative fixes are presented below.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-3760) Build packaging of complex contrib packages just plain does not work
[
https://issues.apache.org/jira/browse/SOLR-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442188#comment-13442188
]
Lance Norskog edited comment on SOLR-3760 at 8/27/12 8:16 AM:
--
Here is the easy way: move the lucene analyzer library from the solr war to a
new directory inside solr/contrib/contribX/lucene-lib. The solrconfig.xml then
has three lib directives:
../../dist/xxx\-contribX\-xxx.jar
../../contrib/contribX/lib
../../contrib/contribX/lucene-lib
I'm doing this for the OpenNLP patch. Since this adds a lucene-lib directory in
solr/contrib, it requires adding 'clean' to the ant targets in solr/contrib.
Add {{contrib-crawl target=clean failonerror=false/}} to
solr/build.xml:target clean
was (Author: lancenorskog):
Here is the easy way: move the lucene analyzer library from the solr war to
a new directory inside solr/contrib/contribX/lucene-lib. The solrconfig.xml
then has three lib directives:
../../dist/xxx\-contribX\-xxx.jar
../../contrib/contribX/lib
../../contrib/contribX/lucene-lib
I'm doing this for the OpenNLP patch. It requires adding 'clean' to the ant
targets in solr/contrib. Add {{contrib-crawl target=clean
failonerror=false/}} to solr/build.xml:clean
Build packaging of complex contrib packages just plain does not work
Key: SOLR-3760
URL: https://issues.apache.org/jira/browse/SOLR-3760
Project: Solr
Issue Type: Improvement
Components: Build
Reporter: Lance Norskog
The build system packages Lucene libraries in the Solr war, but they do not
pack libraries required by the Lucene libraries. The UIMA and analysis-extras
contrib packages have factories for the Lucene libraries.
The net effect is that when solrconfig.xml include lib directives for
dist/xxx-contribX-xxx.jar and solr/contrib/contribX/lib, this fails because
the lucene analyzer file inside the solr war cannot find the library files in
solr/contrib/contribX/lib because the classloader for the war does not find
the libraries from the lib directives.
Two alternative fixes are presented below.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3623) inconsistent treatment of lucene jars third-party deps in analysis-extras uima (in war and in lucene-libs)
[
https://issues.apache.org/jira/browse/SOLR-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lance Norskog updated SOLR-3623:
Comment: was deleted
(was: I opened this issue to fix jar arrangements so that the OpenNLP
integration could work. analysis-extras, opennlp, and uima share the same
problem: they use lucene libraries and third-party dependencies.
Fixing license file problems is certainly helpful, but does not make deployment
any easer. This issue was essentially hijacked.
Here is one way to make it easy to deploy items outside of the solr war file:
repack dependent jars into all contrib dist/ jars. Just pack everything about
analysis-extras into dist/*analysis-extras*.jar. Remove the contrib lucene
libraries from the war file.
Add this to solr/contrib/analysis-extras/build.xml:
{code:xml}
target name=addjars
zip destfile=../../dist/apache-solr-analysis-extras-4.0-SNAPSHOT.jar
update=true
zipfileset
src=../../../lucene/build/analysis/common/lucene-analyzers-common-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/icu/lucene-analyzers-icu-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/morfologik/lucene-analyzers-morfologik-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/phonetic/lucene-analyzers-phonetic-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/smartcn/lucene-analyzers-smartcn-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset
src=../../../lucene/build/analysis/stempel/lucene-analyzers-stempel-4.0-SNAPSHOT.jar
excludes=META-INF/MANIFEST.MF /
zipfileset src=lib/icu4j-49.1.jar excludes=META-INF/MANIFEST.MF /
zipfileset src=lib/morfologik-fsa-1.5.3.jar
excludes=META-INF/MANIFEST.MF /
zipfileset src=lib/morfologik-polish-1.5.3.jar
excludes=META-INF/MANIFEST.MF /
zipfileset src=lib/morfologik-stemming-1.5.3.jar
excludes=META-INF/MANIFEST.MF /
/zip
/target
{code}
Run 'ant dist addjars'. The dist jar goes from 20k (one file) to 21M (4035
files). But, it is 21M in one deployable file. Everything is in one place!
Caveats:
* This approach needs a little rearranging of the order of the build steps.
There is no place visible to the contrib build.xml where the solr/build dist
jar is finished, but not yet copied to dist/. I don't know what to do about
META-INF files in the absorbed libraries. This approach just preserves the
manifest file.
* Redundant dependencies:
** analysis-extras and extraction both use icu4j, which is a huge jar. Too bad.
** dataimporter wants all of extraction. Stick with the current arrangement.
This design is appropriate for analysis-extras, uima and opennlp. All of these
have lucene libraries and lib/ directories, and the current build arrangement
just plain does not work. It is a convenience for clustering, dataimporthandler
(-extras), extraction, langid, and velocity.
The build.xml file above needs macro-izing, and as mentioned the build sequence
needs a point where the contrib build can repack the dist file inside
solr/build.)
inconsistent treatment of lucene jars third-party deps in analysis-extras
uima (in war and in lucene-libs)
--
Key: SOLR-3623
URL: https://issues.apache.org/jira/browse/SOLR-3623
Project: Solr
Issue Type: Bug
Components: Build
Reporter: Lance Norskog
Assignee: Hoss Man
Priority: Minor
Fix For: 4.0-BETA, 5.0
Attachments: SOLR-3623.patch, SOLR-3623.patch
Various dependencies for contrib/analysis-extras are packaged
contrib/analysis-extras/lucene-libs (along with instructions in
contrib/analysis-extras/README.txt that users need to include them
explicitly) even though these jars are already hardcoded into the solr war
file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3623) inconsistent treatment of lucene jars third-party deps in analysis-extras uima (in war and in lucene-libs)
[ https://issues.apache.org/jira/browse/SOLR-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lance Norskog resolved SOLR-3623. - Resolution: Fixed Moving jar deployment problem to [SOLR-3760] because this issue drifted to licensing problems. inconsistent treatment of lucene jars third-party deps in analysis-extras uima (in war and in lucene-libs) -- Key: SOLR-3623 URL: https://issues.apache.org/jira/browse/SOLR-3623 Project: Solr Issue Type: Bug Components: Build Reporter: Lance Norskog Assignee: Hoss Man Priority: Minor Fix For: 5.0, 4.0-BETA Attachments: SOLR-3623.patch, SOLR-3623.patch Various dependencies for contrib/analysis-extras are packaged contrib/analysis-extras/lucene-libs (along with instructions in contrib/analysis-extras/README.txt that users need to include them explicitly) even though these jars are already hardcoded into the solr war file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4322) Can we make oal.util.packed.BulkOperation* smaller?
[ https://issues.apache.org/jira/browse/LUCENE-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442224#comment-13442224 ] Adrien Grand commented on LUCENE-4322: -- These numbers depend on so many factors (docFreq distribution, order in which documents have been indexed, etc.) that it sounds strange to me to only pick a few bits per value we would like to keep specialized based on these benchmarks. I think it would make more sense to specialize a full range? bq. I have concerns that specializing every bpv just means that nothing is even getting JITd and actually makes things worse. I have the same concerns but on the other hand if we pick too few numbers of bits per value, BlockFor might show very disappointing performance with different datasets. Maybe something more conservative would be to specialize the [1-24] range. It would already make the JAR ~350kb smaller (if we removed all specialized impls, the JAR would be ~500kb smaller). Removing all encoder specializations would probably help us save another 50kb. Can we make oal.util.packed.BulkOperation* smaller? --- Key: LUCENE-4322 URL: https://issues.apache.org/jira/browse/LUCENE-4322 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Fix For: 5.0, 4.0 These source files add up to a lot of sources ... it caused problems when compiling under Maven and InteliJ. I committed a change to make separates files, but in aggregate this is still a lot ... EG maybe we don't need to specialize encode? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lance Norskog updated LUCENE-2899: -- Attachment: LUCENE-2899.patch Add OpenNLP Analysis capabilities as a module - Key: LUCENE-2899 URL: https://issues.apache.org/jira/browse/LUCENE-2899 Project: Lucene - Core Issue Type: New Feature Components: modules/analysis Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, opennlp_trunk.patch Now that OpenNLP is an ASF project and has a nice license, it would be nice to have a submodule (under analysis) that exposed capabilities for it. Drew Farris, Tom Morton and I have code that does: * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it would have to change slightly to buffer tokens) * NamedEntity recognition as a TokenFilter We are also planning a Tokenizer/TokenFilter that can put parts of speech as either payloads (PartOfSpeechAttribute?) on a token or at the same position. I'd propose it go under: modules/analysis/opennlp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4329) Lucene and Solr builds
Lance Norskog created LUCENE-4329:
-
Summary: Lucene and Solr builds
Key: LUCENE-4329
URL: https://issues.apache.org/jira/browse/LUCENE-4329
Project: Lucene - Core
Issue Type: Task
Components: general/build
Reporter: Lance Norskog
Priority: Minor
There are a raft of Perl scripts in the Lucene/Solr project. Five are used by
the build, one is an undocumented release manager's tool, three are code
generators that are saved for reference, and 2 appear truly dead.
{noformat}
lucene/benchmark/build.xmlrefers toscripts/shingle.bm2jira.pl
lucene/build.xmlrefers to@{changes.src.dir}/changes2html.pl
OR lucene/site/changes/changes2html.pl
lucene/common-build.xmlrefers to
${dev-tools.scripts.dir}/write.stage.maven.build.xml.pl
OR dev-tools/scripts/write.stage.maven.build.xml.pl
solr/build.xmlrefers to
${common-solr.dir}/dev-tools/stub-analysis-factory-maker.pl
OR solr/dev-tools/stub-analysis-factory-maker.pl
lucene/benchmark/build.xmlrefers toscripts/collation.bm2jira.pl
{noformat}
This is a release manager's tool which is not documented anywhere that
LucidFind crawls: [http://find.searchhub.org/?q=poll-mirrors.pl]. Perhaps it
should be added to the release manager's checklist?
{noformat}
dev-tools/scripts/poll-mirrors.pl
{noformat}
These appear to be standalone scripts that someone may want to run by hand:
{noformat}
lucene/analysis/common/src/test/org/apache/lucene/analysis/core/generateJavaUnicodeWordBreakTest.pl
lucene/benchmark/scripts/compare.collation.benchmark.tables.pl
lucene/benchmark/scripts/compare.shingle.benchmark.tables.pl
{noformat}
These appear to be assistants whose time is past.
{noformat}
dev-tools/scripts/LUCENE-3753.patch.hack.pl dates from 3.4 accd. to the CHANGES
file.
dev-tools/scripts/LUCENE-3753.patch.hack.pl is from February 2012.
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[
https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442250#comment-13442250
]
Lance Norskog commented on LUCENE-2899:
---
Committable except for dev-tools/ and production builds. I've updated
dev-tools/eclipse, I don't have IntelliJ. These dev-tools build files contain
'uima' and so need parallel work for 'opennlp':
{noformat}
dev-tools/maven/lucene/analysis/pom.xml.template
dev-tools/maven/lucene/analysis/uima/pom.xml.template
dev-tools/maven/pom.xml.template
dev-tools/maven/solr/contrib/pom.xml.template
dev-tools/maven/solr/contrib/uima/pom.xml.template
dev-tools/scripts/SOLR-2452.patch.hack.pl
- this one seems to be dead
{noformat}
Add OpenNLP Analysis capabilities as a module
-
Key: LUCENE-2899
URL: https://issues.apache.org/jira/browse/LUCENE-2899
Project: Lucene - Core
Issue Type: New Feature
Components: modules/analysis
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch,
LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, opennlp_trunk.patch
Now that OpenNLP is an ASF project and has a nice license, it would be nice
to have a submodule (under analysis) that exposed capabilities for it. Drew
Farris, Tom Morton and I have code that does:
* Sentence Detection as a Tokenizer (could also be a TokenFilter, although it
would have to change slightly to buffer tokens)
* NamedEntity recognition as a TokenFilter
We are also planning a Tokenizer/TokenFilter that can put parts of speech as
either payloads (PartOfSpeechAttribute?) on a token or at the same position.
I'd propose it go under:
modules/analysis/opennlp
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442251#comment-13442251 ] Lance Norskog commented on LUCENE-2899: --- The latest patch is tested fully and painfully in trunk. I'm sure it works as-is in 4.x, but it is not going into 4.0, so I'm not spending time on that Add OpenNLP Analysis capabilities as a module - Key: LUCENE-2899 URL: https://issues.apache.org/jira/browse/LUCENE-2899 Project: Lucene - Core Issue Type: New Feature Components: modules/analysis Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, opennlp_trunk.patch Now that OpenNLP is an ASF project and has a nice license, it would be nice to have a submodule (under analysis) that exposed capabilities for it. Drew Farris, Tom Morton and I have code that does: * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it would have to change slightly to buffer tokens) * NamedEntity recognition as a TokenFilter We are also planning a Tokenizer/TokenFilter that can put parts of speech as either payloads (PartOfSpeechAttribute?) on a token or at the same position. I'd propose it go under: modules/analysis/opennlp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Problems with ivy resolution
Hi Lance, I don't see any freezing problems at all. icu4j-v49.1 downloads fine for me. I live in New York State in the US. Maybe the trouble your'e having has something to do with your location? (By the way, ant compile under lucene/ doesn't enter analysis/icu/.) Steve -Original Message- From: Lance Norskog [mailto:goks...@gmail.com] Sent: Sunday, August 26, 2012 11:14 PM To: java-dev Subject: Problems with ivy resolution Some library downloads freeze. icu4j-49.1 freezes. If I change the dependency to icu4j-4.8.1.1, the download works. This is from the maven2 repository. To test: move your .ivy2 directory to a backup location (trust me, you want to save it). Start without a .ivy2 directory. run ant compile in lucene/ It will freeze inside the lucene/analysis/icu folder. Change ivy.xml from icu-49.1 to icu-4.8.1.1. ant compile will now work jetty-parent also freezes- this is depended on by other jetty artifacts, so you can't switch the version number. -- Lance Norskog goks...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
