[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+168) - Build # 3506 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3506/
Java: 32bit/jdk-9-ea+168 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([37A6569BAF7F78F:885DB6B8FBF15C0B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_131) - Build # 19622 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19622/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.CdcrBootstrapTest

Error Message:
ObjectTracker found 4 object(s) that were not released!!! 
[MockDirectoryWrapper, SolrCore, MockDirectoryWrapper, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:461)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:326) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:415) 
 at 
org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:757)
  at 
org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:712)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1033)  at 
org.apache.solr.core.SolrCore.reload(SolrCore.java:648)  at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1185)  at 
org.apache.solr.handler.IndexFetcher.lambda$reloadCore$0(IndexFetcher.java:877) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:361)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:721)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:948)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:855)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:960)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:895)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:388)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:372)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:316)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) 

[jira] [Created] (SOLR-10683) Add mean Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10683:
-

 Summary: Add mean Stream Evaluator
 Key: SOLR-10683
 URL: https://issues.apache.org/jira/browse/SOLR-10683
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The mean Stream Evaluator will calculate the mean for a vector of numbers.

{code}
m = mean(colA)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10682) Add variance Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10682:
-

 Summary: Add variance Stream Evaluator
 Key: SOLR-10682
 URL: https://issues.apache.org/jira/browse/SOLR-10682
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The variance Stream Evaluator will calculate the variance of a vector of 
numbers.

{code}
v = var(colA)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-master - Build # 1833 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1833/

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
expected:<3> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([C2DAEE053D11AA27:8AAF9AB13B2285B2]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:530)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11486 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 

[jira] [Updated] (SOLR-10680) Add minMaxNormalize Stream Evaluator

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-10680:
--
Summary: Add minMaxNormalize Stream Evaluator  (was: Add minMaxNormalize 
StreamEvaluator)

> Add minMaxNormalize Stream Evaluator
> 
>
> Key: SOLR-10680
> URL: https://issues.apache.org/jira/browse/SOLR-10680
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> The minMaxNormalize Stream Evaluator normalizes an array of numbers within 
> the specified min/max range.
> Syntax:
> {code}
> a = minMaxNormalize(colA, -1, 1)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10681) Add Dynamic Time Warping (DTW) Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10681:
-

 Summary: Add Dynamic Time Warping (DTW) Stream Evaluator
 Key: SOLR-10681
 URL: https://issues.apache.org/jira/browse/SOLR-10681
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


DTW is a temporal distance measurement described:
https://haifengl.github.io/smile/api/java/smile/math/distance/DynamicTimeWarping.html

Implementation will be provided by the above project.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10670) [ref-guide] Various top-bar fixes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008950#comment-16008950
 ] 

ASF subversion and git services commented on SOLR-10670:


Commit 4b93c62d244408902dd91492a797feadf731a3f4 in lucene-solr's branch 
refs/heads/branch_6_6 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4b93c62 ]

SOLR-10670: fix browser bar name; add some padding for DRAFT note; add favicon


> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.hoss.patch, 
> SOLR-10670.patch, SOLR-10670.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10670) [ref-guide] Various top-bar fixes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008948#comment-16008948
 ] 

ASF subversion and git services commented on SOLR-10670:


Commit ee70e1e4c15d3cc5cb0efca4b78a7575d8300ca8 in lucene-solr's branch 
refs/heads/branch_6x from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ee70e1e ]

SOLR-10670: fix browser bar name; add some padding for DRAFT note; add favicon


> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.hoss.patch, 
> SOLR-10670.patch, SOLR-10670.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10670) [ref-guide] Various top-bar fixes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008947#comment-16008947
 ] 

ASF subversion and git services commented on SOLR-10670:


Commit 4f93056ce71912848fabf3e359c5b6e8aa3953b8 in lucene-solr's branch 
refs/heads/master from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4f93056 ]

SOLR-10670: fix browser bar name; add some padding for DRAFT note; add favicon


> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.hoss.patch, 
> SOLR-10670.patch, SOLR-10670.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_131) - Build # 3504 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3504/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([89D9E0BC54A2D763:2FE336D15A47CE7]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[jira] [Commented] (SOLR-10400) refactor "instanceof TrieFooField || instanceof FooPointsField" to use "FooValueFieldType" marker interface

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008912#comment-16008912
 ] 

ASF subversion and git services commented on SOLR-10400:


Commit b3eccb35eaa5fee4d0d6e9470c05f426f8d9035e in lucene-solr's branch 
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b3eccb3 ]

SOLR-10400: Replace (instanceof TrieFooField || instanceof FooPointField) 
constructs with FieldType.getNumberType() or SchemaField.getSortField() where 
appropriate.


> refactor "instanceof TrieFooField || instanceof FooPointsField" to use 
> "FooValueFieldType" marker interface
> ---
>
> Key: SOLR-10400
> URL: https://issues.apache.org/jira/browse/SOLR-10400
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10400.patch, SOLR-10400.patch
>
>
> See previous comment from smiley in SOLR-9994...
> https://issues.apache.org/jira/browse/SOLR-9994?focusedCommentId=15875390=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15875390
> ...we already have the NumericValueFieldType marker interface and children.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10400) refactor "instanceof TrieFooField || instanceof FooPointsField" to use "FooValueFieldType" marker interface

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008911#comment-16008911
 ] 

ASF subversion and git services commented on SOLR-10400:


Commit cbc32130caec4e1d64d1b10dba2a0486b2263418 in lucene-solr's branch 
refs/heads/branch_6x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cbc3213 ]

SOLR-10400: Replace (instanceof TrieFooField || instanceof FooPointField) 
constructs with FieldType.getNumberType() or SchemaField.getSortField() where 
appropriate.

Conflicts:
solr/core/src/java/org/apache/solr/search/CollapsingQParserPlugin.java


> refactor "instanceof TrieFooField || instanceof FooPointsField" to use 
> "FooValueFieldType" marker interface
> ---
>
> Key: SOLR-10400
> URL: https://issues.apache.org/jira/browse/SOLR-10400
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10400.patch, SOLR-10400.patch
>
>
> See previous comment from smiley in SOLR-9994...
> https://issues.apache.org/jira/browse/SOLR-9994?focusedCommentId=15875390=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15875390
> ...we already have the NumericValueFieldType marker interface and children.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-10400) refactor "instanceof TrieFooField || instanceof FooPointsField" to use "FooValueFieldType" marker interface

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe resolved SOLR-10400.
---
   Resolution: Fixed
Fix Version/s: 6.7
   master (7.0)

> refactor "instanceof TrieFooField || instanceof FooPointsField" to use 
> "FooValueFieldType" marker interface
> ---
>
> Key: SOLR-10400
> URL: https://issues.apache.org/jira/browse/SOLR-10400
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10400.patch, SOLR-10400.patch
>
>
> See previous comment from smiley in SOLR-9994...
> https://issues.apache.org/jira/browse/SOLR-9994?focusedCommentId=15875390=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15875390
> ...we already have the NumericValueFieldType marker interface and children.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7505) startup scripts - read-only install dir and other improvements

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-7505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008876#comment-16008876
 ] 

Jan Høydahl commented on SOLR-7505:
---

I think this is fixed, the linux installer by default makes /opt/solr read-only 
to solr user and that's ok as long as you don't try to use that location for 
solr-home, pid or logs

> startup scripts - read-only install dir and other improvements
> --
>
> Key: SOLR-7505
> URL: https://issues.apache.org/jira/browse/SOLR-7505
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
>
> Talking to a user on IRC, I've come across some things we could do better in 
> our startup scripts and the documentation around them.
>  * It's very difficult to make the entire install directory read-only from 
> the point of view of the RUNAS user.
>  ** The war must be extracted, by default this is done to server/solr-webapp.
>  ** Fixing this will require a few changes to the scripts as well as some 
> additions to the documentation.  I'm not suggesting that we make this a 
> default setup, just provide information on how a user can accomplish it.
>  * If SOLR_ENV is pointed at a script that is empty, nonexistent, or only 
> includes minimal user settings, the settings for default max heap and GC 
> tuning are lost, and return to undesirable Java defaults.  I believe that a 
> user env file should *supplement* solr.in.{sh,cmd}, not *replace* it.  The 
> user can always completely override the provided defaults in their env file.
> There were some other ideas I had, will update if I remember them.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-10400) refactor "instanceof TrieFooField || instanceof FooPointsField" to use "FooValueFieldType" marker interface

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe reassigned SOLR-10400:
-

Assignee: Steve Rowe  (was: Hoss Man)

> refactor "instanceof TrieFooField || instanceof FooPointsField" to use 
> "FooValueFieldType" marker interface
> ---
>
> Key: SOLR-10400
> URL: https://issues.apache.org/jira/browse/SOLR-10400
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Attachments: SOLR-10400.patch, SOLR-10400.patch
>
>
> See previous comment from smiley in SOLR-9994...
> https://issues.apache.org/jira/browse/SOLR-9994?focusedCommentId=15875390=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15875390
> ...we already have the NumericValueFieldType marker interface and children.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008844#comment-16008844
 ] 

Hoss Man commented on SOLR-10675:
-

bq. IMHO, the ref guide versions should maybe also in the version.properties 
file. ...

It is _already_ based on the {{version}} in {{versions.properties}} -- there's 
no need for a new distinct version# in there.  Specifying 
{{-Dsolr-guide-version=X.Y}} on the command line when building a guide release 
is _just_ like specifying {{-Dversion=X.Y.Z}} when releasing the code -- the 
only reason for the new/diff prop name on the command line is simply to allow 
us to still read the (existing) {{version}} value from {{versions.properties}} 
on the current branch to correctly identify which major.minor version of *solr* 
we're publishing the guide for.


bq. And by the way, the PDF file on jenkins does not have "-SNAPSHOT" in the 
version number ...

the branch_6_6 and branch_6x jenkins guide jobs both (currently) include 
{{-DRAFT}} in their artifact name as intended.  the master jenkis guide job 
does not -- but that's only because that job last ran *BEFORE* i committed 
these changes.

The choice of "-DRAFT" vs "-SNAPSHOT" was deliberate to be consistent with the 
way we refered to the cwiki content prior to this migration.  If you think we 
should cahnge that please file a new issue.  (Personally i think that while 
SNAPSHOT makes sense for "code builds", the term "DRAFT" will be easier for 
folks to udnerstand in the context of documentation.

> differentiate DRAFT builds of the html/pdf ref-guides vs the official releases
> --
>
> Key: SOLR-10675
> URL: https://issues.apache.org/jira/browse/SOLR-10675
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.6, master (7.0)
>
> Attachments: draft-background.png, SOLR-10675.patch
>
>
> We should tweak the build system for the new ref guide so that it's obvious 
> from the artifacts when they are unofficial "DRAFT" copies (default) vs 
> official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10400) refactor "instanceof TrieFooField || instanceof FooPointsField" to use "FooValueFieldType" marker interface

[Steve Rowe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-10400:
--
Attachment: SOLR-10400.patch

Updated patch to ensure all modified components test points fields.

bq. As things stand, there are a few nocommits in the patch because I'm 
concerned about some edge cases that were ignored in the "instanceof" code that 
should probably throw errors.

The nocommits were all in the expand component, concerning field types that 
weren't handled.  I actually simplified this code to only handle 32-bit numeric 
field types, and not worry about/throw erros for other field types, because the 
collapse qparser, which is required before the expand component runs, already 
validates the fields used; I added a collapse qparser test that explicitly 
tests that using 64-bit numeric fields causes exceptions to be thrown.

I think it's ready to go.  I'll commit once precommit and Solr tests pass.

> refactor "instanceof TrieFooField || instanceof FooPointsField" to use 
> "FooValueFieldType" marker interface
> ---
>
> Key: SOLR-10400
> URL: https://issues.apache.org/jira/browse/SOLR-10400
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-10400.patch, SOLR-10400.patch
>
>
> See previous comment from smiley in SOLR-9994...
> https://issues.apache.org/jira/browse/SOLR-9994?focusedCommentId=15875390=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15875390
> ...we already have the NumericValueFieldType marker interface and children.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10670) [ref-guide] Various top-bar fixes

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008834#comment-16008834
 ] 

Jan Høydahl commented on SOLR-10670:


Nice optimization Hoss. Let's go!

> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.hoss.patch, 
> SOLR-10670.patch, SOLR-10670.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10670) [ref-guide] Various top-bar fixes

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008714#comment-16008714
 ] 

Cassandra Targett commented on SOLR-10670:
--

Yeah, your approach is way simpler and solves all problems initially described.

I'll commit this and we can work on the other changes (moving the footer icon, 
etc.) in another commit.

> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.hoss.patch, 
> SOLR-10670.patch, SOLR-10670.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10678) Clustering can be executed multiple times in distributed mode

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008716#comment-16008716
 ] 

Mike Drob commented on SOLR-10678:
--

> is there any other way to determine whether it's a distributed request or not
If you need different behaviours, I think that's what using the different 
methods {{process}} and {{distributedProcess}} is intended to do for you.

You should also be able to check {{SolrParams.getBool("distrib")}} - true for 
top level, false for sub-requests.

> Clustering can be executed multiple times in distributed mode
> -
>
> Key: SOLR-10678
> URL: https://issues.apache.org/jira/browse/SOLR-10678
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
>
> As reported on SO: 
> http://stackoverflow.com/questions/43877284/how-does-solr-clustering-component-work/43937064#43937064



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10651) Streaming Expressions statistical functions library

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-10651:
--
Fix Version/s: master (7.0)

> Streaming Expressions statistical functions library
> ---
>
> Key: SOLR-10651
> URL: https://issues.apache.org/jira/browse/SOLR-10651
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
>
> This is a ticket for organizing the new statistical programming features of 
> Streaming Expressions. It's also a place for the community to discuss what 
> functions are needed to support statistical programming. This ticket will be 
> updated shortly to show the existing syntax and functions with links to 
> existing jira tickets.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10680) Add minMaxNormalize StreamEvaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10680:
-

 Summary: Add minMaxNormalize StreamEvaluator
 Key: SOLR-10680
 URL: https://issues.apache.org/jira/browse/SOLR-10680
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The minMaxNormalize Stream Evaluator normalizes an array of numbers within the 
specified min/max range.

Syntax:

{code}
a = minMaxNormalize(colA, -1, 1)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7827) disable "textgrams" when minPrefixChars=0 AnalyzingInfixSuggester

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated LUCENE-7827:
-
Attachment: LUCENE-7827.patch

> disable "textgrams" when minPrefixChars=0 AnalyzingInfixSuggester 
> --
>
> Key: LUCENE-7827
> URL: https://issues.apache.org/jira/browse/LUCENE-7827
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: LUCENE-7827.patch
>
>
> The current code allows to set minPrefixChars=0, but it creates an 
> unnecessary {{textgrams}} field, and might bring significant footprint.  
> Bypassing it keeps existing tests green.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+168) - Build # 19619 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19619/
Java: 64bit/jdk-9-ea+168 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.SegmentsInfoRequestHandlerTest.testSegmentInfosVersion

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([B106BDE228A7BBC6:49D8280A50CB6A95]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:898)
at 
org.apache.solr.handler.admin.SegmentsInfoRequestHandlerTest.testSegmentInfosVersion(SegmentsInfoRequestHandlerTest.java:70)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=2=count(//lst[@name='segments']/lst/str[@name='version'][.='7.0.0'])
xml response was: 

[jira] [Created] (LUCENE-7827) disable "textgrams" when minPrefixChars=0 AnalyzingInfixSuggester

[Mikhail Khludnev (JIRA)]

Mikhail Khludnev created LUCENE-7827:


 Summary: disable "textgrams" when minPrefixChars=0 
AnalyzingInfixSuggester 
 Key: LUCENE-7827
 URL: https://issues.apache.org/jira/browse/LUCENE-7827
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Mikhail Khludnev
Priority: Minor


The current code allows to set minPrefixChars=0, but it creates an unnecessary 
{{textgrams}} field, and might bring significant footprint.  Bypassing it keeps 
existing tests green.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1298 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1298/

1 tests failed.
FAILED:  
org.apache.solr.core.HdfsDirectoryFactoryTest.testInitArgsOrSysPropConfig

Error Message:
The max direct memory is likely too low.  Either increase it (by adding 
-XX:MaxDirectMemorySize=g -XX:+UseLargePages to your containers startup 
args) or disable direct allocation using 
solr.hdfs.blockcache.direct.memory.allocation=false in solrconfig.xml. If you 
are putting the block cache on the heap, your java heap size might not be large 
enough. Failed allocating ~134.217728 MB.

Stack Trace:
java.lang.RuntimeException: The max direct memory is likely too low.  Either 
increase it (by adding -XX:MaxDirectMemorySize=g -XX:+UseLargePages to 
your containers startup args) or disable direct allocation using 
solr.hdfs.blockcache.direct.memory.allocation=false in solrconfig.xml. If you 
are putting the block cache on the heap, your java heap size might not be large 
enough. Failed allocating ~134.217728 MB.
at 
__randomizedtesting.SeedInfo.seed([B9436D789A6A2D90:4EECA45367E3C7BB]:0)
at 
org.apache.solr.core.HdfsDirectoryFactory.createBlockCache(HdfsDirectoryFactory.java:311)
at 
org.apache.solr.core.HdfsDirectoryFactory.getBlockDirectoryCache(HdfsDirectoryFactory.java:287)
at 
org.apache.solr.core.HdfsDirectoryFactory.create(HdfsDirectoryFactory.java:227)
at 
org.apache.solr.core.HdfsDirectoryFactoryTest.testInitArgsOrSysPropConfig(HdfsDirectoryFactoryTest.java:111)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008629#comment-16008629
 ] 

Uwe Schindler commented on SOLR-10675:
--

IMHO, the ref guide versions should maybe also in the version.properties file. 
And by the way, the PDF file on jenkins does not have "-SNAPSHOT" in the 
version number. So maybe just copy the approach from the normal builds, but use 
a different "pair" of properties for it.

> differentiate DRAFT builds of the html/pdf ref-guides vs the official releases
> --
>
> Key: SOLR-10675
> URL: https://issues.apache.org/jira/browse/SOLR-10675
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.6, master (7.0)
>
> Attachments: draft-background.png, SOLR-10675.patch
>
>
> We should tweak the build system for the new ref guide so that it's obvious 
> from the artifacts when they are unofficial "DRAFT" copies (default) vs 
> official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10670) [ref-guide] Various top-bar fixes

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008627#comment-16008627
 ] 

Uwe Schindler commented on SOLR-10670:
--

IMHO, the ref guide versions should maybe also in the version.properties file. 
And by the way, the PDF file on jenkins does not have "-SNAPSHOT" in the 
version number. So maybe just copy the approach from the normal builds, but use 
a different "pair" of properties for it.

> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.hoss.patch, 
> SOLR-10670.patch, SOLR-10670.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Issue Comment Deleted] (SOLR-10670) [ref-guide] Various top-bar fixes

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated SOLR-10670:
-
Comment: was deleted

(was: IMHO, the ref guide versions should maybe also in the version.properties 
file. And by the way, the PDF file on jenkins does not have "-SNAPSHOT" in the 
version number. So maybe just copy the approach from the normal builds, but use 
a different "pair" of properties for it.)

> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.hoss.patch, 
> SOLR-10670.patch, SOLR-10670.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008620#comment-16008620
 ] 

Steve Rowe commented on SOLR-10568:
---

Chris Lambertus offered to help troubleshoot the 6.6 job issue on INFRA-14143, 
but declined to provide me access to those general (non-project-specific) build 
slaves.  I manually kicked off the 6.6 job and it succeeded!  Maybe there was 
something weird about the squash merge commit or something?

FYI because of changes Uwe instigated, the HTML format is no longer under 
latest successful build artifacts, but are instead available from the 
"Document" link from the job's landing page, pointing to a ".../javadocs/" 
page, e.g. for the 6.6 job: 
[https://builds.apache.org/job/Solr-reference-guide-6.6/javadoc/].

> Automate HTML builds via Jenkins to occur with each commit
> --
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so 
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are 
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to 
> verify the presentation of the information is as expected.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10617) JDBCStream: support more data types

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008614#comment-16008614
 ] 

ASF subversion and git services commented on SOLR-10617:


Commit 6e68e9ea8d94232d7e3aef8f7d33c1bcf058f4cc in lucene-solr's branch 
refs/heads/master from jdyer1
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6e68e9e ]

SOLR-10617: run "ant jar-checksums" to correct the hsqldb.jar.sha1 file


> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 6.7
>
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10617) JDBCStream: support more data types

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008615#comment-16008615
 ] 

ASF subversion and git services commented on SOLR-10617:


Commit 6de364045bae5f90c05b9e7680186fdac0ad3d79 in lucene-solr's branch 
refs/heads/branch_6x from jdyer1
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6de3640 ]

SOLR-10617: run "ant jar-checksums" to correct the hsqldb.jar.sha1 file


> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 6.7
>
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10670) [ref-guide] Various top-bar fixes

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-10670:

Attachment: SOLR-10670.hoss.patch

I feel like maybe you guys are overcomplicating things :)

Personally, i don't see any advantage in having "Home" in the title tag (or 
anywhere else in the guide) so why not keep things simple?

Attaching a patch with my own personal strawman...

* fix the topnav links as jan suggested
* fix the favicon path (although we actaully need to copy it still, not in 
patch)
* make the template ignore the page name if the page.shortname == "index"

so for the index.html the title is "Apache Solr Reference Guide X.Y" for every 
other page it's "Page Name | Apache Solr Reference Guide X.Y" and we don't have 
to have any special variables/title in index.adoc, we can change it's 
page.title anytime we want.

i would suggest discussions about sidebar changes be punted to their own issue?

> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.hoss.patch, 
> SOLR-10670.patch, SOLR-10670.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10678) Clustering can be executed multiple times in distributed mode

[Dawid Weiss (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008598#comment-16008598
 ] 

Dawid Weiss commented on SOLR-10678:


Clustering should run when the search results are collected. In normal mode, 
this happens in {{process}} (as the tests show), but in distributed mode (as I 
assume and partially confirmed by running the distrib. tests) the search 
request is routed to collect the results, each shard calls {{process}} and then 
everything is collected in {{finishStage}}. Since we don't need to run 
clustering on each shard, only once the results are collected, I think we can 
skip clustering in {{process}} if we're sure it's part of a distributed request 
that will eventually be finalized in {{finishStage}}.

But all the above is based on my vague understanding of how it works 
internally, so I'd like to get some confirmation that it's actually correct 
before I try to change the code.

> Clustering can be executed multiple times in distributed mode
> -
>
> Key: SOLR-10678
> URL: https://issues.apache.org/jira/browse/SOLR-10678
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
>
> As reported on SO: 
> http://stackoverflow.com/questions/43877284/how-does-solr-clustering-component-work/43937064#43937064



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7821) Classic, flexible, and Solr's standard/"lucene" query parsers: range queries should require " TO ", and accept TO as range endpoints

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008583#comment-16008583
 ] 

Steve Rowe commented on LUCENE-7821:


If there are no objections, I'll commit this tomorrow, including to 6.6.

> Classic, flexible, and Solr's standard/"lucene" query parsers: range queries 
> should require " TO ", and accept TO as range endpoints
> 
>
> Key: LUCENE-7821
> URL: https://issues.apache.org/jira/browse/LUCENE-7821
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Attachments: LUCENE-7821.patch, LUCENE-7821.patch
>
>
> A post on the solr-user mailing list drew my attention to the fact that this 
> is apparently a valid range query under the QueryParser.jj grammer (both for 
> the classic parser and the solr variant -- i didn't check flexible)...
> {noformat}
> [x z]   // parsed the same as [x TO z]
> {noformat}
> it's parsed as a valid range query even though there is no {{ TO }} -- even 
> though there is nothing in the docs to suggest that the {{ TO }} is intended 
> to be optional.
> Furthermore, in my experimenting i realized that how the grammer looks for 
> the {{ TO }} keyword seems to be a bit sloppy, making some range queries that 
> should be easy to validate (because they are unambiguous) fail to parse...
> {noformat}
> [TO TO z] // fails
> [a TO TO] // fails
> [a TO "TO"]   // works, but why should quoting be neccessary here?
> {noformat}
> 
> If the "sloppy" parsing behavior is intentional, then the docs should reflect 
> that the {{ TO }} is optional -- but it seems like in general we should make 
> these other unambiguous cases parse cleanly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008578#comment-16008578
 ] 

Hoss Man commented on SOLR-10675:
-

[~thetaphi] it does in fact work very similar, and if you note in the 
patch/commits both the "guide version" and "solr version" defaults come from 
the existing {{version.properties}} file -- but please note my comments when i 
attached the patch...

bq. This will typically be the same - but now if we want to do a "bug fix 
release" of the guide itself, we can – and if we do so, the bug fix number for 
the doc doesn't need to be tied to any particular code bug fix that has/has not 
yet happened on the same branch_X_Y

We specifically can *NOT* depend on the guide version matching the 
{{version.base}} to know if it's a "release" because the {{version.base}} on 
the release branch will be incremented immediately after the code releases, but 
the solr guide may be released after that.  likewise, we may want to do a 
"guide bugfix" release (to fix some egregious formatting mistake or missleading 
content) independent of if/when there was a "code bugfix" release on the same 
branch.

hence the introduction of the new {{solr-guide-version}} sys property.

> differentiate DRAFT builds of the html/pdf ref-guides vs the official releases
> --
>
> Key: SOLR-10675
> URL: https://issues.apache.org/jira/browse/SOLR-10675
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.6, master (7.0)
>
> Attachments: draft-background.png, SOLR-10675.patch
>
>
> We should tweak the build system for the new ref guide so that it's obvious 
> from the artifacts when they are unofficial "DRAFT" copies (default) vs 
> official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+168) - Build # 3502 - Still Failing!

[Uwe Schindler]

"ant jar-checksums" from root folder. After that commit changes to checksum 
files an commit. Precommit does not catch this because it's special check done 
only by Jenkins. Whenever you change dependencies you must recalculate 
checksums. Be sure to remove files deleted by this task from git!

Uwe

Am 12. Mai 2017 21:02:05 MESZ schrieb "Dyer, James" 
:
>I committed the updated hsqldb jar today, along with its sha1. 
>Pre-commit passes for me.  Does anyone know why Jenkins is complaining
>and if there is anything I must do to fix this?
>
>James Dyer
>Ingram Content Group
>
>-Original Message-
>From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] 
>Sent: Friday, May 12, 2017 1:33 PM
>To: dev@lucene.apache.org
>Subject: [JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+168) -
>Build # 3502 - Still Failing!
>Importance: Low
>
>Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3502/
>Java: 32bit/jdk-9-ea+168 -client -XX:+UseG1GC
>
>All tests passed
>
>Build Log:
>[...truncated 49636 lines...]
>BUILD FAILED
>/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:775: The
>following error occurred while executing this line:
>/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:655: The
>following error occurred while executing this line:
>/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:643: Source
>checkout is modified!!! Offending files:
>* solr/licenses/hsqldb-2.4.0.jar.sha1
>
>Total time: 63 minutes 5 seconds
>Build step 'Invoke Ant' marked build as failure
>Archiving artifacts
>[WARNINGS] Skipping publisher since build result is FAILURE
>Recording test results
>Email was triggered for: Failure - Any
>Sending email for trigger: Failure - Any
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

RE: [JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+168) - Build # 3502 - Still Failing!

[Dyer, James]

I committed the updated hsqldb jar today, along with its sha1.  Pre-commit 
passes for me.  Does anyone know why Jenkins is complaining and if there is 
anything I must do to fix this?

James Dyer
Ingram Content Group

-Original Message-
From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] 
Sent: Friday, May 12, 2017 1:33 PM
To: dev@lucene.apache.org
Subject: [JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+168) - Build # 3502 
- Still Failing!
Importance: Low

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3502/
Java: 32bit/jdk-9-ea+168 -client -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 49636 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:655: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:643: Source checkout is 
modified!!! Offending files:
* solr/licenses/hsqldb-2.4.0.jar.sha1

Total time: 63 minutes 5 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+168) - Build # 3502 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3502/
Java: 32bit/jdk-9-ea+168 -client -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 49636 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:655: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:643: Source checkout is 
modified!!! Offending files:
* solr/licenses/hsqldb-2.4.0.jar.sha1

Total time: 63 minutes 5 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10679) Solr CDCR cannot be configured to use Aliases for replication

[Webster Homer (JIRA)]

Webster Homer created SOLR-10679:


 Summary: Solr CDCR cannot be configured to use Aliases for 
replication
 Key: SOLR-10679
 URL: https://issues.apache.org/jira/browse/SOLR-10679
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: CDCR
Affects Versions: 6.2
Reporter: Webster Homer


My company uses Solr aliases to limit the configuration changes that we need to 
support.
The CDCR configuration seems to accept an alias for either the source or target 
collections, and no errors show up in the log, but no data is replicated if the 
source or target is an alias and not an actual collection.

I see that aliases are not even mentioned in the CDCR documentation. It seems 
to me this should either work or throw an error.
It should be documented one way or another



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008532#comment-16008532
 ] 

Uwe Schindler commented on SOLR-10675:
--

It can do the decission in the same way like the remaining build system. It is 
a release build if version property equals version.base property. See the 
common build files how to do this. There are many examples e.g. in define 
javadoc url targets of solr.

> differentiate DRAFT builds of the html/pdf ref-guides vs the official releases
> --
>
> Key: SOLR-10675
> URL: https://issues.apache.org/jira/browse/SOLR-10675
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.6, master (7.0)
>
> Attachments: draft-background.png, SOLR-10675.patch
>
>
> We should tweak the build system for the new ref guide so that it's obvious 
> from the artifacts when they are unofficial "DRAFT" copies (default) vs 
> official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008523#comment-16008523
 ] 

Hoss Man commented on SOLR-10675:
-

bq. I think this is good. I'm not totally sold on the DRAFT watermark, but it 
does get the point across and it doesn't obscure any text ...

exactly, and if we decide it's not subtle enough, we can always tweak the image.

Personally i love the watermark -- no one can ever again claim they didn't 
realize something wasn't the "official" guide.  I was hoping we could include 
it in the PDF too, but aparently it doesn't work with asciidoctorJ...
* 
https://github.com/asciidoctor/asciidoctor-pdf/blob/master/docs/theming-guide.adoc
* 
http://discuss.asciidoctor.org/Asciidoctor-YAML-style-file-for-PDF-and-maven-td3849.html

> differentiate DRAFT builds of the html/pdf ref-guides vs the official releases
> --
>
> Key: SOLR-10675
> URL: https://issues.apache.org/jira/browse/SOLR-10675
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
> Fix For: 6.6, master (7.0)
>
> Attachments: draft-background.png, SOLR-10675.patch
>
>
> We should tweak the build system for the new ref guide so that it's obvious 
> from the artifacts when they are unofficial "DRAFT" copies (default) vs 
> official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man resolved SOLR-10675.
-
   Resolution: Fixed
 Assignee: Hoss Man
Fix Version/s: master (7.0)
   6.6

> differentiate DRAFT builds of the html/pdf ref-guides vs the official releases
> --
>
> Key: SOLR-10675
> URL: https://issues.apache.org/jira/browse/SOLR-10675
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.6, master (7.0)
>
> Attachments: draft-background.png, SOLR-10675.patch
>
>
> We should tweak the build system for the new ref guide so that it's obvious 
> from the artifacts when they are unofficial "DRAFT" copies (default) vs 
> official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008516#comment-16008516
 ] 

ASF subversion and git services commented on SOLR-10675:


Commit b552127ea36bd54f70014bab67738d3f156b505a in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b552127 ]

SOLR-10675: differentiate DRAFT builds of the html/pdf ref-guides vs the 
official releases


> differentiate DRAFT builds of the html/pdf ref-guides vs the official releases
> --
>
> Key: SOLR-10675
> URL: https://issues.apache.org/jira/browse/SOLR-10675
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
> Attachments: draft-background.png, SOLR-10675.patch
>
>
> We should tweak the build system for the new ref guide so that it's obvious 
> from the artifacts when they are unofficial "DRAFT" copies (default) vs 
> official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008514#comment-16008514
 ] 

ASF subversion and git services commented on SOLR-10675:


Commit 0c2330bea082a8936e60aa61fea0e7a1a54f2300 in lucene-solr's branch 
refs/heads/branch_6_6 from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0c2330b ]

SOLR-10675: differentiate DRAFT builds of the html/pdf ref-guides vs the 
official releases

(cherry picked from commit b552127ea36bd54f70014bab67738d3f156b505a)


> differentiate DRAFT builds of the html/pdf ref-guides vs the official releases
> --
>
> Key: SOLR-10675
> URL: https://issues.apache.org/jira/browse/SOLR-10675
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
> Attachments: draft-background.png, SOLR-10675.patch
>
>
> We should tweak the build system for the new ref guide so that it's obvious 
> from the artifacts when they are unofficial "DRAFT" copies (default) vs 
> official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008515#comment-16008515
 ] 

ASF subversion and git services commented on SOLR-10675:


Commit 977b17bca4194cb43942b7af741f8da6a8b72bf6 in lucene-solr's branch 
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=977b17b ]

SOLR-10675: differentiate DRAFT builds of the html/pdf ref-guides vs the 
official releases

(cherry picked from commit b552127ea36bd54f70014bab67738d3f156b505a)


> differentiate DRAFT builds of the html/pdf ref-guides vs the official releases
> --
>
> Key: SOLR-10675
> URL: https://issues.apache.org/jira/browse/SOLR-10675
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
> Attachments: draft-background.png, SOLR-10675.patch
>
>
> We should tweak the build system for the new ref guide so that it's obvious 
> from the artifacts when they are unofficial "DRAFT" copies (default) vs 
> official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008486#comment-16008486
 ] 

Cassandra Targett commented on SOLR-10675:
--

I think this is good. I'm not totally sold on the DRAFT watermark, but it does 
get the point across and it doesn't obscure any text (code blocks go over it, 
which is nice). I definitely like the version being printed at the bottom of 
each page (in html and pdf) and the fact it includes "-DRAFT".

Unless you have any other ideas today, I think we could work with this.

> differentiate DRAFT builds of the html/pdf ref-guides vs the official releases
> --
>
> Key: SOLR-10675
> URL: https://issues.apache.org/jira/browse/SOLR-10675
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
> Attachments: draft-background.png, SOLR-10675.patch
>
>
> We should tweak the build system for the new ref guide so that it's obvious 
> from the artifacts when they are unofficial "DRAFT" copies (default) vs 
> official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10572) (from 7.0.0 onwards) remove three no-longer-supported warnings in SolrIndexConfig

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008485#comment-16008485
 ] 

Hoss Man commented on SOLR-10572:
-

Oh man ... I'm sorry -- i totally missed the distinction. (and the fact that 
this line ends with {{true);}} ... not sure why it was ever written that way?)

bq. ... it is clearest to leave the code-as, hence the reverted commit.

I'm going to stop assuming I know what i'm talking about and trust you on this 
-- but i have to ask: isn't {{...}} 
already deprecated though?  Shouldn't this (effectively) automatic failure if 
{{myclass}} is found be telling people to use 
{{mergePolicyFactory}} ?

> (from 7.0.0 onwards) remove three no-longer-supported warnings in 
> SolrIndexConfig
> -
>
> Key: SOLR-10572
> URL: https://issues.apache.org/jira/browse/SOLR-10572
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10572.patch
>
>
> The mergeScheduler, mergePolicy and luceneAutoCommit [no-longer-supported 
> warnings|https://github.com/apache/lucene-solr/blame/48ca9fc3f4f8d95293cee7bb59eff61247ede181/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L130-L140]
>  date back to 
> [2012|https://github.com/apache/lucene-solr/commit/058179d177208450850c5e3e3103710cadd3b53e].
>  Let's remove them from 7.0.0 onwards for clarity. This caught my attention 
> as part of SOLR-8668's mergePolicy support removal.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008475#comment-16008475
 ] 

Steve Rowe commented on SOLR-10568:
---

bq. Once this is in branch_6x, I hope you will help us again by setting up a 
job for that too

Done: https://builds.apache.org/job/Solr-reference-guide-6.x/

I tried to make a branch_6_6 version of the job 
([https://builds.apache.org/job/Solr-reference-guide-6.6/]) but it is refusing 
to checkout the latest commit on the branch.  I created a JIRA to gain access 
to the VM where the job runs to see if I can figure out what's going on: 
[https://issues.apache.org/jira/browse/INFRA-14143].  In the meantime, I've 
disabled the job.

> Automate HTML builds via Jenkins to occur with each commit
> --
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so 
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are 
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to 
> verify the presentation of the information is as expected.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+168) - Build # 19618 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19618/
Java: 64bit/jdk-9-ea+168 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 13227 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/temp/junit4-J0-20170512_165517_64515610166793122128075.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-master-Linux/heapdumps/java_pid17349.hprof 
...
   [junit4] Heap dump file created [204852557 bytes in 1.216 secs]
   [junit4] <<< JVM J0: EOF 

[...truncated 7465 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:727: Some of the 
tests produced a heap dump, but did not fail. Maybe a suppressed 
OutOfMemoryError? Dumps created:
* java_pid17349.hprof

Total time: 56 minutes 27 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Solr-reference-guide-6.6 - Build # 3 - Still Failing

[Steve Rowe]

I made a JIRA for me and Uwe to gain access: 
.  (On HipChat, Daniel Gruno 
said that Gavin and pono, the two who are best equipped to deal with this, are 
traveling for Apachecon right now.)

For now I’ll disable the 6.6 job.

--
Steve
www.lucidworks.com

> On May 12, 2017, at 12:41 PM, Steve Rowe  wrote:
> 
> Thanks Uwe, I’ll make that change on the 6.x job.
> 
> I deleted the branch_6_6 job and re-cloned from the master job (including 
> your changes), but it still checks out an old commit.
> 
> I’ll ask Infra on hipchat about getting ‘sudo jenkins’ access on H19 and H20 
> (the nodes where ‘git-websites’ label jobs are built).
> 
> --
> Steve
> www.lucidworks.com
> 
>> On May 12, 2017, at 12:18 PM, Uwe Schindler  wrote:
>> 
>> Hi,
>> 
>> I edited the master build a bit (see my other mail). In addition, you should 
>> add the extra "additional behaviour" git option" "clean before checkout". 
>> This brings the checkout into a pristine state and reverts any changes. I 
>> did this for master, too.
>> 
>> Uwe
>> 
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>> 
>>> -Original Message-
>>> From: Steve Rowe [mailto:sar...@gmail.com]
>>> Sent: Friday, May 12, 2017 5:46 PM
>>> To: Lucene Dev 
>>> Subject: Re: [JENKINS] Solr-reference-guide-6.6 - Build # 3 - Still Failing
>>> 
>>> For some reason the checked-out commit is the one just before Cassandra
>>> cherry-picked the ref guide squash merge onto branch_6_6, so the solr/solr-
>>> ref-guide/ directory isn’t present.  I don’t see anything in the job config 
>>> that
>>> would cause this.
>>> 
>>> Thinking the issue was maybe timing, I manually restarted the job a couple
>>> times, but there’s no change.
>>> 
>>> Next I’ll try deleting the job and re-cloning.
>>> 
>>> --
>>> Steve
>>> www.lucidworks.com
>>> 
 On May 12, 2017, at 11:42 AM, Apache Jenkins Server
>>>  wrote:
 
 Build: https://builds.apache.org/job/Solr-reference-guide-6.6/3/
 
 Log:
 Started by user sarowe
 [EnvInject] - Loading node environment variables.
 Building remotely on H19 (git-websites) in workspace
>>> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6
> git rev-parse --is-inside-work-tree # timeout=10
 Fetching changes from the remote Git repository
> git config remote.origin.url git://git.apache.org/lucene-solr.git #
>>> timeout=10
 Fetching upstream changes from git://git.apache.org/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress git://git.apache.org/lucene-solr.git
>>> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} #
>>> timeout=10
 Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479
>>> (refs/remotes/origin/branch_6_6)
> git config core.sparsecheckout # timeout=10
> git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
> git rev-list 506485c4403bce29cc06272f3341c6afc2f1d479 # timeout=10
 No emails were triggered.
 [Solr-reference-guide-6.6] $ /bin/bash -xe
>>> /tmp/hudson7016357499441274446.sh
 + echo 'Set ruby path to avoid writing to /usr directory'
 Set ruby path to avoid writing to /usr directory
 + export RUBY_PATH=/home/jenkins/shared/.rvm
 + RUBY_PATH=/home/jenkins/shared/.rvm
 + export GEM_HOME=/home/jenkins/shared/.rvm/gems
 + GEM_HOME=/home/jenkins/shared/.rvm/gems
 + curl -sSL https://get.rvm.io
 + bash -s -- --path /home/jenkins/shared/.rvm
 Downloading https://github.com/rvm/rvm/archive/master.tar.gz
 
 Upgrading the RVM installation in /home/jenkins/shared/.rvm/
  RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile
>>> /home/jenkins/.bashrc /home/jenkins/.zshrc.
  RVM sourcing line found in /home/jenkins/.profile
>>> /home/jenkins/.bash_profile /home/jenkins/.zlogin.
 Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
 
 # jenkins,
 #
 #   Thank you for using RVM!
 #   We sincerely hope that RVM helps to make your life easier and more
>>> enjoyable!!!
 #
 # ~Wayne, Michal & team.
 
 In case of problems: https://rvm.io/help and https://twitter.com/rvm_io
 
 Upgrade Notes:
 
 * It looks like some old stuff is laying around RVM, you can cleanup with:
>>> rvm cleanup all
 
 * No new notes to display.
 
 + mkdir -p /home/jenkins/shared/.rvm/gems/gems
 + gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll jekyll-
>>> asciidoc pygments.rb
 Successfully installed jekyll-3.4.3
 Successfully installed jekyll-asciidoc-2.0.1
 Successfully installed pygments.rb-1.1.2
 3 gems installed
 + export
>>> 

[jira] [Commented] (SOLR-10307) Provide SSL/TLS keystore password a more secure way

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008423#comment-16008423
 ] 

Mark Miller commented on SOLR-10307:


I have it ready locally but am on vacation and prefer to commit after as I 
won't pay attention to any Jenkins issues if I'm lucky. 

> Provide SSL/TLS keystore password a more secure way
> ---
>
> Key: SOLR-10307
> URL: https://issues.apache.org/jira/browse/SOLR-10307
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Attachments: SOLR-10307.patch, SOLR-10307.patch, SOLR-10307.patch
>
>
> Currently the only way to pass server and client side SSL keytstore and 
> truststore passwords is to set specific environment variables that will be 
> passed as system properties, through command line parameter.
> First option is to pass passwords through environment variables which gives a 
> better level of protection. Second option would be to use hadoop credential 
> provider interface to access credential store.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10572) (from 7.0.0 onwards) remove three no-longer-supported warnings in SolrIndexConfig

[Christine Poerschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008419#comment-16008419
 ] 

Christine Poerschke commented on SOLR-10572:


Thanks for the detailed explanation!

At the risk of confusing things further and from just looking at this again 
now, the code that I was trying to get rid of was
{code}
assertWarnOrFail("The myclass syntax is no longer 
supported in solrconfig.xml. Please use syntax  
instead.", 
!((solrConfig.getNode(prefix + "/mergePolicy", false) != null) && 
(solrConfig.get(prefix + "/mergePolicy/@class", null) == null)), 
true); 
{code}
which is actually for functionality already no longer supported.

However since {{...}} is still 
supported at present and since the difference between {{class="myclass"}} 
attribute and {{myclass}} element is very subtle 
then it is clearest to leave the code-as, hence the reverted commit.

> (from 7.0.0 onwards) remove three no-longer-supported warnings in 
> SolrIndexConfig
> -
>
> Key: SOLR-10572
> URL: https://issues.apache.org/jira/browse/SOLR-10572
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10572.patch
>
>
> The mergeScheduler, mergePolicy and luceneAutoCommit [no-longer-supported 
> warnings|https://github.com/apache/lucene-solr/blame/48ca9fc3f4f8d95293cee7bb59eff61247ede181/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L130-L140]
>  date back to 
> [2012|https://github.com/apache/lucene-solr/commit/058179d177208450850c5e3e3103710cadd3b53e].
>  Let's remove them from 7.0.0 onwards for clarity. This caught my attention 
> as part of SOLR-8668's mergePolicy support removal.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Release 6.6

[jim ferenczi]

Ok thanks Ishan.

Le 12 mai 2017 18:44, "Ishan Chattopadhyaya"  a
écrit :

Sure, Jim. Please go ahead!

On Fri, May 12, 2017 at 10:01 PM, jim ferenczi 
wrote:

> Hi,
> Would be great to have https://issues.apache.org/jira/browse/LUCENE-7824
> included for 6.6. Can I merge the fix this week end Ishan ?
>
> 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya  >:
>
>> Done, Adrien. Thanks!
>>
>> On Thu, May 11, 2017 at 7:34 PM, Adrien Grand  wrote:
>>
>>> Ishan, wdyt about running addVersion on the branch_6x/master as well? I
>>> think it would help realize that the 6.6 branch has been cut when looking
>>> at the CHANGES.txt file and not forget about backporting?
>>>
>>> Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> a écrit :
>>>
 I've cut the branch for 6.6. (branch_6_6). Please feel free to add
 bugfixes to the branch, if needed.
 Planning to build the first RC on 15 May. Please let me know if there
 are any objections.

 Thanks,
 Ishan

 On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com> wrote:

> Planning to cut the release branch in another 10-12 hours.
>
> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty 
> wrote:
>
>> i was wondering if there was a specific test for
>> SpanPayloadCheckQuery method
>>
>> matches = payloadToMatch.get(upto).bytesEquals(payload);
>>
>>
>> the only implementation i could locate was in collectLeaf of
>> SpanPayloadCheckQuery
>>
>>
>> I will submit JIRA with Patch
>>
>>
>> as a CS *dinosaur* I am more familiar with LISP for dissecting
>> sentence fragments (what we called phenomes) than current SEO
>> implementations
>>
>>
>> Can you suggest a book to read to better understand Lucenes pattern
>> dissection and match algorithms?
>>
>>
>> Many Thanks for helpful guidance
>> Martin
>> __
>>
>>
>>
>>
>> --
>> *From:* Erik Hatcher 
>> *Sent:* Sunday, April 30, 2017 2:06 PM
>>
>> *To:* dev@lucene.apache.org
>> *Subject:* Re: Release 6.6
>>
>> Martin -
>>
>> I have to admit to still being unsure what the gist is here - is
>> there a bug?   Apologies for not catching what you’re saying/showing 
>> here.
>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>> now.
>>
>> I’m going to focus purely on SOLR-1485 this week to get it committed
>> for 6.6.  If there is an issue to address with your work would you please
>> open a JIRA and include your patch there?
>>
>> Thanks,
>> Erik
>>
>>
>> On Apr 30, 2017, at 7:47 AM, Martin Gainty 
>> wrote:
>>
>> Mornin' Erik
>>
>> there is a collectLeaf  override in org.apache.lucene
>> .queries.payloads.TestPayloadSpans ..but its never called:
>>
>> static class VerifyingCollector implements SpanCollector {
>> List payloads = new ArrayList<>();
>> @Override
>> public void collectLeaf(PostingsEnum postings, int position, Term
>> term) throws IOException {
>>  
>>  }
>> }
>>
>>
>> the modification in org.apache.lucene.queries.payl
>> oads.TestPayloadCheckQuery tests collectLeaf for query
>>
>> //initialise term
>>
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>> before term1=new org.apache.lucene.index.Term('
>> field','withPayload')");
>> org.apache.lucene.index.Term term1=new 
>> org.apache.lucene.index.Term("field",
>> "withPayload");
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>> term1="+term1);
>>
>> //assume position is 5
>> int position=5;
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>> position="+position);
>>
>> BytesRef pay = new BytesRef("pos: " + position);
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>> pay="+pay);
>>
>> //build spanQuery with term parameter
>> org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>> SpanTermQuery(term1);
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>> spanQuery1="+spanQuery1);
>>
>> //add BytesRef to payloadToMatch list
>> java.util.List
>> payloadToMatch=new java.util.ArrayList> .lucene.util.BytesRef>();
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>> payloadToMatch="+payloadToMatch);
>> payloadToMatch.add(pay);
>>
>> //build SpanPayloadCheckQuery
>>
>> query=new 

Re: Release 6.6

[Ishan Chattopadhyaya]

Sure, Jim. Please go ahead!

On Fri, May 12, 2017 at 10:01 PM, jim ferenczi 
wrote:

> Hi,
> Would be great to have https://issues.apache.org/jira/browse/LUCENE-7824
> included for 6.6. Can I merge the fix this week end Ishan ?
>
> 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya  >:
>
>> Done, Adrien. Thanks!
>>
>> On Thu, May 11, 2017 at 7:34 PM, Adrien Grand  wrote:
>>
>>> Ishan, wdyt about running addVersion on the branch_6x/master as well? I
>>> think it would help realize that the 6.6 branch has been cut when looking
>>> at the CHANGES.txt file and not forget about backporting?
>>>
>>> Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> a écrit :
>>>
 I've cut the branch for 6.6. (branch_6_6). Please feel free to add
 bugfixes to the branch, if needed.
 Planning to build the first RC on 15 May. Please let me know if there
 are any objections.

 Thanks,
 Ishan

 On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com> wrote:

> Planning to cut the release branch in another 10-12 hours.
>
> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty 
> wrote:
>
>> i was wondering if there was a specific test for
>> SpanPayloadCheckQuery method
>>
>> matches = payloadToMatch.get(upto).bytesEquals(payload);
>>
>>
>> the only implementation i could locate was in collectLeaf of
>> SpanPayloadCheckQuery
>>
>>
>> I will submit JIRA with Patch
>>
>>
>> as a CS *dinosaur* I am more familiar with LISP for dissecting
>> sentence fragments (what we called phenomes) than current SEO
>> implementations
>>
>>
>> Can you suggest a book to read to better understand Lucenes pattern
>> dissection and match algorithms?
>>
>>
>> Many Thanks for helpful guidance
>> Martin
>> __
>>
>>
>>
>>
>> --
>> *From:* Erik Hatcher 
>> *Sent:* Sunday, April 30, 2017 2:06 PM
>>
>> *To:* dev@lucene.apache.org
>> *Subject:* Re: Release 6.6
>>
>> Martin -
>>
>> I have to admit to still being unsure what the gist is here - is
>> there a bug?   Apologies for not catching what you’re saying/showing 
>> here.
>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>> now.
>>
>> I’m going to focus purely on SOLR-1485 this week to get it committed
>> for 6.6.  If there is an issue to address with your work would you please
>> open a JIRA and include your patch there?
>>
>> Thanks,
>> Erik
>>
>>
>> On Apr 30, 2017, at 7:47 AM, Martin Gainty 
>> wrote:
>>
>> Mornin' Erik
>>
>> there is a collectLeaf  override in org.apache.lucene
>> .queries.payloads.TestPayloadSpans ..but its never called:
>>
>> static class VerifyingCollector implements SpanCollector {
>> List payloads = new ArrayList<>();
>> @Override
>> public void collectLeaf(PostingsEnum postings, int position, Term
>> term) throws IOException {
>>  
>>  }
>> }
>>
>>
>> the modification in org.apache.lucene.queries.payl
>> oads.TestPayloadCheckQuery tests collectLeaf for query
>>
>> //initialise term
>>
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>> before term1=new org.apache.lucene.index.Term('
>> field','withPayload')");
>> org.apache.lucene.index.Term term1=new 
>> org.apache.lucene.index.Term("field",
>> "withPayload");
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>> term1="+term1);
>>
>> //assume position is 5
>> int position=5;
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>> position="+position);
>>
>> BytesRef pay = new BytesRef("pos: " + position);
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>> pay="+pay);
>>
>> //build spanQuery with term parameter
>> org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>> SpanTermQuery(term1);
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>> spanQuery1="+spanQuery1);
>>
>> //add BytesRef to payloadToMatch list
>> java.util.List
>> payloadToMatch=new java.util.ArrayList> .lucene.util.BytesRef>();
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>> payloadToMatch="+payloadToMatch);
>> payloadToMatch.add(pay);
>>
>> //build SpanPayloadCheckQuery
>>
>> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>> (org.apache.lucene.search.spans.SpanQuery)query,
>> 

RE: [JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing

[Uwe Schindler]

It has a stable URL - we do this for all release builds already in the same 
way. This URL is also listed on the Job's homepage.

https://builds.apache.org/job/Solr-reference-guide-master/javadoc/

In addition, if you go to the Job's homepage, you will see a huge 
"Documentation" button (that points to this stable URL). In addition, because 
the number of artifacts is small (1 in this case), it shows the PDF next to the 
other links. So basically this is like it should be: PDF is artifact, HTML is 
ready-to view documenattion. We keep it the same way for all builds, so its 
also consistent:

https://builds.apache.org/job/Solr-reference-guide-master/

So from the Solr homepage you can easily add a link to the "latest build" 
homepage, or alternatively to the docs in HTML form directly.

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Steve Rowe [mailto:sar...@gmail.com]
> Sent: Friday, May 12, 2017 6:15 PM
> To: dev@lucene.apache.org
> Subject: Re: [JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing
> 
> Uwe,
> 
> > On May 12, 2017, at 12:00 PM, Uwe Schindler  wrote:
> >
> > Ah by the way: I changed the master job a bit. Instead of "archiving" the
> HTML docs as "artifact", I used the "publish javadocs" post-build step to
> publish it as conventional Javadocs. This makes it show as "Documentation"
> link on the Jenkins base page. Also browsing is faster, as it does not need to
> do additional stuff on jenkins, its just a simple static HTML view.
> 
> Unfortunately, this causes the HTML format not to be accessible from the
> “last successful build artifacts” view, e.g.
>  master/lastSuccessfulBuild/artifact/>, which AFAICT means we can’t have a
> stable URL for the HTML format.  I think this is bad.
> 
> --
> Steve
> www.lucidworks.com
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Solr-reference-guide-6.6 - Build # 3 - Still Failing

[Steve Rowe]

Thanks Uwe, I’ll make that change on the 6.x job.

I deleted the branch_6_6 job and re-cloned from the master job (including your 
changes), but it still checks out an old commit.

I’ll ask Infra on hipchat about getting ‘sudo jenkins’ access on H19 and H20 
(the nodes where ‘git-websites’ label jobs are built).

--
Steve
www.lucidworks.com

> On May 12, 2017, at 12:18 PM, Uwe Schindler  wrote:
> 
> Hi,
> 
> I edited the master build a bit (see my other mail). In addition, you should 
> add the extra "additional behaviour" git option" "clean before checkout". 
> This brings the checkout into a pristine state and reverts any changes. I did 
> this for master, too.
> 
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
>> -Original Message-
>> From: Steve Rowe [mailto:sar...@gmail.com]
>> Sent: Friday, May 12, 2017 5:46 PM
>> To: Lucene Dev 
>> Subject: Re: [JENKINS] Solr-reference-guide-6.6 - Build # 3 - Still Failing
>> 
>> For some reason the checked-out commit is the one just before Cassandra
>> cherry-picked the ref guide squash merge onto branch_6_6, so the solr/solr-
>> ref-guide/ directory isn’t present.  I don’t see anything in the job config 
>> that
>> would cause this.
>> 
>> Thinking the issue was maybe timing, I manually restarted the job a couple
>> times, but there’s no change.
>> 
>> Next I’ll try deleting the job and re-cloning.
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On May 12, 2017, at 11:42 AM, Apache Jenkins Server
>>  wrote:
>>> 
>>> Build: https://builds.apache.org/job/Solr-reference-guide-6.6/3/
>>> 
>>> Log:
>>> Started by user sarowe
>>> [EnvInject] - Loading node environment variables.
>>> Building remotely on H19 (git-websites) in workspace
>> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6
 git rev-parse --is-inside-work-tree # timeout=10
>>> Fetching changes from the remote Git repository
 git config remote.origin.url git://git.apache.org/lucene-solr.git #
>> timeout=10
>>> Fetching upstream changes from git://git.apache.org/lucene-solr.git
 git --version # timeout=10
 git fetch --tags --progress git://git.apache.org/lucene-solr.git
>> +refs/heads/*:refs/remotes/origin/*
 git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
 git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} #
>> timeout=10
>>> Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479
>> (refs/remotes/origin/branch_6_6)
 git config core.sparsecheckout # timeout=10
 git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
 git rev-list 506485c4403bce29cc06272f3341c6afc2f1d479 # timeout=10
>>> No emails were triggered.
>>> [Solr-reference-guide-6.6] $ /bin/bash -xe
>> /tmp/hudson7016357499441274446.sh
>>> + echo 'Set ruby path to avoid writing to /usr directory'
>>> Set ruby path to avoid writing to /usr directory
>>> + export RUBY_PATH=/home/jenkins/shared/.rvm
>>> + RUBY_PATH=/home/jenkins/shared/.rvm
>>> + export GEM_HOME=/home/jenkins/shared/.rvm/gems
>>> + GEM_HOME=/home/jenkins/shared/.rvm/gems
>>> + curl -sSL https://get.rvm.io
>>> + bash -s -- --path /home/jenkins/shared/.rvm
>>> Downloading https://github.com/rvm/rvm/archive/master.tar.gz
>>> 
>>> Upgrading the RVM installation in /home/jenkins/shared/.rvm/
>>>   RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile
>> /home/jenkins/.bashrc /home/jenkins/.zshrc.
>>>   RVM sourcing line found in /home/jenkins/.profile
>> /home/jenkins/.bash_profile /home/jenkins/.zlogin.
>>> Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
>>> 
>>> # jenkins,
>>> #
>>> #   Thank you for using RVM!
>>> #   We sincerely hope that RVM helps to make your life easier and more
>> enjoyable!!!
>>> #
>>> # ~Wayne, Michal & team.
>>> 
>>> In case of problems: https://rvm.io/help and https://twitter.com/rvm_io
>>> 
>>> Upgrade Notes:
>>> 
>>> * It looks like some old stuff is laying around RVM, you can cleanup with:
>> rvm cleanup all
>>> 
>>> * No new notes to display.
>>> 
>>> + mkdir -p /home/jenkins/shared/.rvm/gems/gems
>>> + gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll jekyll-
>> asciidoc pygments.rb
>>> Successfully installed jekyll-3.4.3
>>> Successfully installed jekyll-asciidoc-2.0.1
>>> Successfully installed pygments.rb-1.1.2
>>> 3 gems installed
>>> + export
>> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/late
>> st1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ga
>> mes:/usr/local/games
>>> +
>> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/late
>> st1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ga
>> mes:/usr/local/games
>>> + cd solr/solr-ref-guide
>>> /tmp/hudson7016357499441274446.sh: line 10: cd: solr/solr-ref-guide: No
>> such file or directory
>>> Build step 'Execute shell' marked build as failure

[JENKINS] Solr-reference-guide-6.6 - Build # 2 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-6.6/2/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H19 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} # timeout=10
Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479 
(refs/remotes/origin/branch_6_6)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
 > git rev-list 506485c4403bce29cc06272f3341c6afc2f1d479 # timeout=10
No emails were triggered.
[Solr-reference-guide-6.6] $ /bin/bash -xe /tmp/hudson6293175119916860417.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s -- --path /home/jenkins/shared/.rvm
Downloading https://github.com/rvm/rvm/archive/master.tar.gz

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

# jenkins,
#
#   Thank you for using RVM!
#   We sincerely hope that RVM helps to make your life easier and more 
enjoyable!!!
#
# ~Wayne, Michal & team.

In case of problems: https://rvm.io/help and https://twitter.com/rvm_io

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

+ mkdir -p /home/jenkins/shared/.rvm/gems/gems
+ gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll 
jekyll-asciidoc pygments.rb
Successfully installed jekyll-3.4.3
Successfully installed jekyll-asciidoc-2.0.1
Successfully installed pygments.rb-1.1.2
3 gems installed
+ export 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ cd solr/solr-ref-guide
/tmp/hudson6293175119916860417.sh: line 10: cd: solr/solr-ref-guide: No such 
file or directory
Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing

[Steve Rowe]

Hmm, there is a stable URL for the javadoc plugin output: 
 (at least 
after the first build anyway).  Seems okay, though the URL sucks (HTML format 
ref guide is not “javadoc”; I checked and there is no configuration option for 
the URL).  Also, with this change we now have to provide two separate URLs for 
each branch, one for each format.  On balance, I guess I'm okay with leaving it 
this way.

--
Steve
www.lucidworks.com

> On May 12, 2017, at 12:15 PM, Steve Rowe  wrote:
> 
> Uwe,
> 
>> On May 12, 2017, at 12:00 PM, Uwe Schindler  wrote:
>> 
>> Ah by the way: I changed the master job a bit. Instead of "archiving" the 
>> HTML docs as "artifact", I used the "publish javadocs" post-build step to 
>> publish it as conventional Javadocs. This makes it show as "Documentation" 
>> link on the Jenkins base page. Also browsing is faster, as it does not need 
>> to do additional stuff on jenkins, its just a simple static HTML view.
> 
> Unfortunately, this causes the HTML format not to be accessible from the 
> “last successful build artifacts” view, e.g. 
> ,
>  which AFAICT means we can’t have a stable URL for the HTML format.  I think 
> this is bad.
> 
> --
> Steve
> www.lucidworks.com


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+168) - Build # 3501 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3501/
Java: 64bit/jdk-9-ea+168 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 49622 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:655: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:643: Source checkout is 
modified!!! Offending files:
* solr/licenses/hsqldb-2.4.0.jar.sha1

Total time: 56 minutes 24 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Release 6.6

[jim ferenczi]

Hi,
Would be great to have https://issues.apache.org/jira/browse/LUCENE-7824
included for 6.6. Can I merge the fix this week end Ishan ?

2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya :

> Done, Adrien. Thanks!
>
> On Thu, May 11, 2017 at 7:34 PM, Adrien Grand  wrote:
>
>> Ishan, wdyt about running addVersion on the branch_6x/master as well? I
>> think it would help realize that the 6.6 branch has been cut when looking
>> at the CHANGES.txt file and not forget about backporting?
>>
>> Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> a écrit :
>>
>>> I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>>> bugfixes to the branch, if needed.
>>> Planning to build the first RC on 15 May. Please let me know if there
>>> are any objections.
>>>
>>> Thanks,
>>> Ishan
>>>
>>> On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
 Planning to cut the release branch in another 10-12 hours.

 On Mon, May 1, 2017 at 4:00 PM, Martin Gainty 
 wrote:

> i was wondering if there was a specific test for SpanPayloadCheckQuery
> method
>
> matches = payloadToMatch.get(upto).bytesEquals(payload);
>
>
> the only implementation i could locate was in collectLeaf of
> SpanPayloadCheckQuery
>
>
> I will submit JIRA with Patch
>
>
> as a CS *dinosaur* I am more familiar with LISP for dissecting
> sentence fragments (what we called phenomes) than current SEO
> implementations
>
>
> Can you suggest a book to read to better understand Lucenes pattern
> dissection and match algorithms?
>
>
> Many Thanks for helpful guidance
> Martin
> __
>
>
>
>
> --
> *From:* Erik Hatcher 
> *Sent:* Sunday, April 30, 2017 2:06 PM
>
> *To:* dev@lucene.apache.org
> *Subject:* Re: Release 6.6
>
> Martin -
>
> I have to admit to still being unsure what the gist is here - is there
> a bug?   Apologies for not catching what you’re saying/showing here.
> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
> now.
>
> I’m going to focus purely on SOLR-1485 this week to get it committed
> for 6.6.  If there is an issue to address with your work would you please
> open a JIRA and include your patch there?
>
> Thanks,
> Erik
>
>
> On Apr 30, 2017, at 7:47 AM, Martin Gainty 
> wrote:
>
> Mornin' Erik
>
> there is a collectLeaf  override in org.apache.lucene
> .queries.payloads.TestPayloadSpans ..but its never called:
>
> static class VerifyingCollector implements SpanCollector {
> List payloads = new ArrayList<>();
> @Override
> public void collectLeaf(PostingsEnum postings, int position, Term
> term) throws IOException {
>  
>  }
> }
>
>
> the modification in org.apache.lucene.queries.payl
> oads.TestPayloadCheckQuery tests collectLeaf for query
>
> //initialise term
>
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
> before term1=new org.apache.lucene.index.Term('
> field','withPayload')");
> org.apache.lucene.index.Term term1=new 
> org.apache.lucene.index.Term("field",
> "withPayload");
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
> term1="+term1);
>
> //assume position is 5
> int position=5;
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
> position="+position);
>
> BytesRef pay = new BytesRef("pos: " + position);
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
> pay="+pay);
>
> //build spanQuery with term parameter
> org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
> SpanTermQuery(term1);
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
> spanQuery1="+spanQuery1);
>
> //add BytesRef to payloadToMatch list
> java.util.List
> payloadToMatch=new java.util.ArrayList .lucene.util.BytesRef>();
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
> payloadToMatch="+payloadToMatch);
> payloadToMatch.add(pay);
>
> //build SpanPayloadCheckQuery
>
> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
> (org.apache.lucene.search.spans.SpanQuery)query,
> (java.util.List)payloadToMatch);
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
> query="+query);
>
> //build lucene Directory (TODO: we should use an existing directory
> with REAL test-data)
> org.apache.lucene.store.Directory ram = 

Re: JIRA Status - Finding Patch Submissions

[Hrishikesh Gadre]

>>For current patches, I think we could really benefit from a Patch
Available JIRA state. It would be a bright big flag for committers, instead
of making contributors have to hound us periodically to look. Additionally,
we could use that to start running precommit checks on Jenkins whenever a
new patch is put up. See Apache Yetus for how this might work.

+1. We should also consider running unit tests as part of the process.


On Thu, May 11, 2017 at 1:54 PM, Mike Drob  wrote:

> Wanted to follow up on this, since I've been steadily working away at old
> JIRA issues when I have some time for them. I think read through 100s of
> issues and closed about 20 as either duplicates or already committed, which
> is a tiny drop in the ocean of what we have open. In an attempt to cut the
> task to a more manageable size, I only looked at Solr issues.
>
> I'd like to adjust my earlier statement that most of the attachments are
> patches. Most of the really old attachments are patches, the mid-age ones
> are bug reports (indices, screen captures, logs) and the recent ones being
> actively worked are patches again. So, the situation isn't as bad as I
> imagined it at first. For a lot of these old issues, there's not much to be
> done going forward. I don't expect to have much traction asking
> contributors to rebase their patches from 1.x, 3.x or even 4.x onto the
> current code line, and without that many of them are just unworkable.
>
> For current patches, I think we could really benefit from a Patch
> Available JIRA state. It would be a bright big flag for committers, instead
> of making contributors have to hound us periodically to look. Additionally,
> we could use that to start running precommit checks on Jenkins whenever a
> new patch is put up. See Apache Yetus for how this might work.
>
> Is there interest in the community for this path? I'm personally a big fan
> of enabling static analysis and always like to explore ways to improve in
> that area.
>
> Mike
>
> On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey  wrote:
>
>> On 4/28/2017 9:42 AM, Mike Drob wrote:
>> > Thanks for this hint, Alex.
>> >
>> > I ran the following JQL to get some idea of our current status:
>> > project in (lucene, solr) and "Attachment count" > 0 and status =
>> Open
>> >
>> > There were 1500 results.
>> >
>> > 1500. I couldn't believe it. This is a huge number of patches that are
>> > out there.
>> >
>> > I did a spot check, thinking that a lot of these might be bug reports
>> > with error logs or screen shots attached, but nope. These are mostly
>> > patches. I'm going to try starting with the oldest ones to see if they
>> > can be rebase, have already been committed, or generally try to triage
>> > them. Would appreciate any volunteers that want to help.
>>
>> This doesn't surprise me at all.  Many users submit patches for issues
>> they encounter, but for one reason or another, no committer action ever
>> happens.  There are many possible reasons.
>>
>> 1) The patch has bugs or some other problem that makes it unacceptable.
>> 2) When the issue/patch is reviewed, one of these situations exists:
>>  a) Committers don't think it's worth pursuing.
>>  b) The code is behaving as designed.
>>  c) The committer cannot reproduce the problem.
>>  d) The committer doesn't understand the problem.
>>  e) The committer doesn't think it's actually a problem.
>>  f) A workaround exists that is just as effective as the patch.
>> 3) Nobody has had time to review the issue/patch.
>>
>> In some of these situations, the reviewing committer should probably
>> close the issue with an appropriate reason ... but issue triage is a
>> difficult and unrewarding job.  Sometimes it just doesn't happen.
>>
>> Thanks,
>> Shawn
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

[jira] [Updated] (LUCENE-7824) Multi-word synonyms rule with common terms at the same position are buggy

[Jim Ferenczi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jim Ferenczi updated LUCENE-7824:
-
Affects Version/s: master (7.0)
   6.5.1

> Multi-word synonyms rule with common terms at the same position are buggy
> -
>
> Key: LUCENE-7824
> URL: https://issues.apache.org/jira/browse/LUCENE-7824
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master (7.0), 6.5.1
>Reporter: Jim Ferenczi
> Attachments: LUCENE-7824.patch
>
>
> The automaton built from the graph token stream tries to pack common terms in 
> multi word synonyms that appear at the same position. This means that some 
> states inside a multi word synonym can have multiple transitions.
> As a result the intersection point of the graph are not computed correctly.
> For example the synonym rule: "ny, new york city, new york" is not applied 
> correctly to the query "ny police".
> In this case "police" is detected as part of the multi synonyms path and we 
> create the disjunction between:
>  "ny police", "new york police", ...
> I pushed a patch that removes this optim (and creates a single transition 
> from each state) in order to ensure that the intersection points of the graph 
> always showed up at the end of the multi synonym paths.
> [~mattweber] can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Solr-reference-guide-6.6 - Build # 1 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-6.6/1/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H19 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} # timeout=10
Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479 
(refs/remotes/origin/branch_6_6)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
First time build. Skipping changelog.
No emails were triggered.
[Solr-reference-guide-6.6] $ /bin/bash -xe /tmp/hudson8214595670161299839.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s -- --path /home/jenkins/shared/.rvm
Downloading https://github.com/rvm/rvm/archive/master.tar.gz

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

# jenkins,
#
#   Thank you for using RVM!
#   We sincerely hope that RVM helps to make your life easier and more 
enjoyable!!!
#
# ~Wayne, Michal & team.

In case of problems: https://rvm.io/help and https://twitter.com/rvm_io

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

+ mkdir -p /home/jenkins/shared/.rvm/gems/gems
+ gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll 
jekyll-asciidoc pygments.rb
Successfully installed jekyll-3.4.3
Successfully installed jekyll-asciidoc-2.0.1
Successfully installed pygments.rb-1.1.2
3 gems installed
+ export 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ cd solr/solr-ref-guide
/tmp/hudson8214595670161299839.sh: line 10: cd: solr/solr-ref-guide: No such 
file or directory
Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10572) (from 7.0.0 onwards) remove three no-longer-supported warnings in SolrIndexConfig

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008340#comment-16008340
 ] 

Hoss Man commented on SOLR-10572:
-

bq. The removal of the  warning would be included in the SOLR-8668 
effort then instead, right? And the other two warnings would stay for now.

[~cpoerschke]: I haven't looked closely at the other two to know when they are 
safe to remove -- i just noticed that removingthe mergePolicy warning was weird 
since hte functionality itself doesn't seem to have been removed.

to be clear: the call to {{assertWarnOrFail}} should be removed many versions 
_AFTER_ the functionality is removed -- the only change should be in the final 
argument to the call, so that instead of logging a warning "don't do X use Y 
instead" it triggers a hard failure with the message "don't do X use Y instead"



The method was designed so that the final boolean "failCondition" could be 
something conditional -- like comparing some constant with the Version.LATEST 
(of the luceneMatchVersion from the users config) -- so that you could write a 
single line of code on master, backport it to a stable branch, and get a "fail" 
on master but a "warn" on older branches (or better: a warn if their 
luceneMatchVersion < X, but when they edit or replace their config and use a 
newer luceneMatchVersion the warning becomes a fail) ... then we don't have to 
go out of our way to remember when it's safe to remove an {{assertWarnOrFail}} 
method call -- we just remove it completley once whatever Version constants it 
refers to are removed (ie: 6.6 removed in 8.0)



> (from 7.0.0 onwards) remove three no-longer-supported warnings in 
> SolrIndexConfig
> -
>
> Key: SOLR-10572
> URL: https://issues.apache.org/jira/browse/SOLR-10572
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10572.patch
>
>
> The mergeScheduler, mergePolicy and luceneAutoCommit [no-longer-supported 
> warnings|https://github.com/apache/lucene-solr/blame/48ca9fc3f4f8d95293cee7bb59eff61247ede181/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L130-L140]
>  date back to 
> [2012|https://github.com/apache/lucene-solr/commit/058179d177208450850c5e3e3103710cadd3b53e].
>  Let's remove them from 7.0.0 onwards for clarity. This caught my attention 
> as part of SOLR-8668's mergePolicy support removal.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [JENKINS] Solr-reference-guide-6.6 - Build # 3 - Still Failing

[Uwe Schindler]

Hi,

I edited the master build a bit (see my other mail). In addition, you should 
add the extra "additional behaviour" git option" "clean before checkout". This 
brings the checkout into a pristine state and reverts any changes. I did this 
for master, too.

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Steve Rowe [mailto:sar...@gmail.com]
> Sent: Friday, May 12, 2017 5:46 PM
> To: Lucene Dev 
> Subject: Re: [JENKINS] Solr-reference-guide-6.6 - Build # 3 - Still Failing
> 
> For some reason the checked-out commit is the one just before Cassandra
> cherry-picked the ref guide squash merge onto branch_6_6, so the solr/solr-
> ref-guide/ directory isn’t present.  I don’t see anything in the job config 
> that
> would cause this.
> 
> Thinking the issue was maybe timing, I manually restarted the job a couple
> times, but there’s no change.
> 
> Next I’ll try deleting the job and re-cloning.
> 
> --
> Steve
> www.lucidworks.com
> 
> > On May 12, 2017, at 11:42 AM, Apache Jenkins Server
>  wrote:
> >
> > Build: https://builds.apache.org/job/Solr-reference-guide-6.6/3/
> >
> > Log:
> > Started by user sarowe
> > [EnvInject] - Loading node environment variables.
> > Building remotely on H19 (git-websites) in workspace
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6
> >> git rev-parse --is-inside-work-tree # timeout=10
> > Fetching changes from the remote Git repository
> >> git config remote.origin.url git://git.apache.org/lucene-solr.git #
> timeout=10
> > Fetching upstream changes from git://git.apache.org/lucene-solr.git
> >> git --version # timeout=10
> >> git fetch --tags --progress git://git.apache.org/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> >> git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
> >> git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} #
> timeout=10
> > Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479
> (refs/remotes/origin/branch_6_6)
> >> git config core.sparsecheckout # timeout=10
> >> git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
> >> git rev-list 506485c4403bce29cc06272f3341c6afc2f1d479 # timeout=10
> > No emails were triggered.
> > [Solr-reference-guide-6.6] $ /bin/bash -xe
> /tmp/hudson7016357499441274446.sh
> > + echo 'Set ruby path to avoid writing to /usr directory'
> > Set ruby path to avoid writing to /usr directory
> > + export RUBY_PATH=/home/jenkins/shared/.rvm
> > + RUBY_PATH=/home/jenkins/shared/.rvm
> > + export GEM_HOME=/home/jenkins/shared/.rvm/gems
> > + GEM_HOME=/home/jenkins/shared/.rvm/gems
> > + curl -sSL https://get.rvm.io
> > + bash -s -- --path /home/jenkins/shared/.rvm
> > Downloading https://github.com/rvm/rvm/archive/master.tar.gz
> >
> > Upgrading the RVM installation in /home/jenkins/shared/.rvm/
> >RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile
> /home/jenkins/.bashrc /home/jenkins/.zshrc.
> >RVM sourcing line found in /home/jenkins/.profile
> /home/jenkins/.bash_profile /home/jenkins/.zlogin.
> > Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
> >
> > # jenkins,
> > #
> > #   Thank you for using RVM!
> > #   We sincerely hope that RVM helps to make your life easier and more
> enjoyable!!!
> > #
> > # ~Wayne, Michal & team.
> >
> > In case of problems: https://rvm.io/help and https://twitter.com/rvm_io
> >
> > Upgrade Notes:
> >
> >  * It looks like some old stuff is laying around RVM, you can cleanup with:
> rvm cleanup all
> >
> >  * No new notes to display.
> >
> > + mkdir -p /home/jenkins/shared/.rvm/gems/gems
> > + gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll jekyll-
> asciidoc pygments.rb
> > Successfully installed jekyll-3.4.3
> > Successfully installed jekyll-asciidoc-2.0.1
> > Successfully installed pygments.rb-1.1.2
> > 3 gems installed
> > + export
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/late
> st1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ga
> mes:/usr/local/games
> > +
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/late
> st1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ga
> mes:/usr/local/games
> > + cd solr/solr-ref-guide
> > /tmp/hudson7016357499441274446.sh: line 10: cd: solr/solr-ref-guide: No
> such file or directory
> > Build step 'Execute shell' marked build as failure
> > Archiving artifacts
> > Email was triggered for: Failure - Any
> > Sending email for trigger: Failure - Any
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: 

Re: [JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing

[Steve Rowe]

Uwe,

> On May 12, 2017, at 12:00 PM, Uwe Schindler  wrote:
> 
> Ah by the way: I changed the master job a bit. Instead of "archiving" the 
> HTML docs as "artifact", I used the "publish javadocs" post-build step to 
> publish it as conventional Javadocs. This makes it show as "Documentation" 
> link on the Jenkins base page. Also browsing is faster, as it does not need 
> to do additional stuff on jenkins, its just a simple static HTML view.

Unfortunately, this causes the HTML format not to be accessible from the “last 
successful build artifacts” view, e.g. 
,
 which AFAICT means we can’t have a stable URL for the HTML format.  I think 
this is bad.

--
Steve
www.lucidworks.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7824) Multi-word synonyms rule with common terms at the same position are buggy

[Matt Weber (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008311#comment-16008311
 ] 

Matt Weber commented on LUCENE-7824:


Sure, looks good then!

> Multi-word synonyms rule with common terms at the same position are buggy
> -
>
> Key: LUCENE-7824
> URL: https://issues.apache.org/jira/browse/LUCENE-7824
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jim Ferenczi
> Attachments: LUCENE-7824.patch
>
>
> The automaton built from the graph token stream tries to pack common terms in 
> multi word synonyms that appear at the same position. This means that some 
> states inside a multi word synonym can have multiple transitions.
> As a result the intersection point of the graph are not computed correctly.
> For example the synonym rule: "ny, new york city, new york" is not applied 
> correctly to the query "ny police".
> In this case "police" is detected as part of the multi synonyms path and we 
> create the disjunction between:
>  "ny police", "new york police", ...
> I pushed a patch that removes this optim (and creates a single transition 
> from each state) in order to ensure that the intersection points of the graph 
> always showed up at the end of the multi synonym paths.
> [~mattweber] can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing

[Steve Rowe]

Can you be more specific Uwe?  I looked at 
 and I don’t 
see anywhere I can specify where to checkout relative to the workspace root.

Aso, I cloned the branch_6x job to create the branch_6_6, and the branch_6x job 
is working fine.

--
Steve
www.lucidworks.com

> On May 12, 2017, at 11:51 AM, Uwe Schindler  wrote:
> 
> Are you sure you checked out to the workspace root? In Jenkins you have to 
> explicitly say this (see other jobs).
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
>> -Original Message-
>> From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
>> Sent: Friday, May 12, 2017 5:48 PM
>> To: dev@lucene.apache.org
>> Subject: [JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing
>> 
>> Build: https://builds.apache.org/job/Solr-reference-guide-6.6/4/
>> 
>> Log:
>> Started by user sarowe
>> [EnvInject] - Loading node environment variables.
>> Building remotely on H19 (git-websites) in workspace /home/jenkins/jenkins-
>> slave/workspace/Solr-reference-guide-6.6
>> Cloning the remote Git repository
>> Cloning repository git://git.apache.org/lucene-solr.git
>>> git init /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6 #
>> timeout=10
>> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>>> git --version # timeout=10
>>> git fetch --tags --progress git://git.apache.org/lucene-solr.git
>> +refs/heads/*:refs/remotes/origin/*
>>> git config remote.origin.url git://git.apache.org/lucene-solr.git #
>> timeout=10
>>> git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* #
>> timeout=10
>>> git config remote.origin.url git://git.apache.org/lucene-solr.git #
>> timeout=10
>> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>>> git fetch --tags --progress git://git.apache.org/lucene-solr.git
>> +refs/heads/*:refs/remotes/origin/*
>>> git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
>>> git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} #
>> timeout=10
>> Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479
>> (refs/remotes/origin/branch_6_6)
>>> git config core.sparsecheckout # timeout=10
>>> git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
>>> git rev-list 506485c4403bce29cc06272f3341c6afc2f1d479 # timeout=10
>> No emails were triggered.
>> [Solr-reference-guide-6.6] $ /bin/bash -xe
>> /tmp/hudson1875946413917847668.sh
>> + echo 'Set ruby path to avoid writing to /usr directory'
>> Set ruby path to avoid writing to /usr directory
>> + export RUBY_PATH=/home/jenkins/shared/.rvm
>> + RUBY_PATH=/home/jenkins/shared/.rvm
>> + export GEM_HOME=/home/jenkins/shared/.rvm/gems
>> + GEM_HOME=/home/jenkins/shared/.rvm/gems
>> + curl -sSL https://get.rvm.io
>> + bash -s -- --path /home/jenkins/shared/.rvm
>> Downloading https://github.com/rvm/rvm/archive/master.tar.gz
>> 
>> Upgrading the RVM installation in /home/jenkins/shared/.rvm/
>>RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile
>> /home/jenkins/.bashrc /home/jenkins/.zshrc.
>>RVM sourcing line found in /home/jenkins/.profile
>> /home/jenkins/.bash_profile /home/jenkins/.zlogin.
>> Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
>> 
>> # jenkins,
>> #
>> #   Thank you for using RVM!
>> #   We sincerely hope that RVM helps to make your life easier and more
>> enjoyable!!!
>> #
>> # ~Wayne, Michal & team.
>> 
>> In case of problems: https://rvm.io/help and https://twitter.com/rvm_io
>> 
>> Upgrade Notes:
>> 
>>  * It looks like some old stuff is laying around RVM, you can cleanup with:
>> rvm cleanup all
>> 
>>  * No new notes to display.
>> 
>> + mkdir -p /home/jenkins/shared/.rvm/gems/gems
>> + gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll jekyll-
>> asciidoc pygments.rb
>> Successfully installed jekyll-3.4.3
>> Successfully installed jekyll-asciidoc-2.0.1
>> Successfully installed pygments.rb-1.1.2
>> 3 gems installed
>> + export
>> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/late
>> st1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ga
>> mes:/usr/local/games
>> +
>> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/late
>> st1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ga
>> mes:/usr/local/games
>> + cd solr/solr-ref-guide
>> /tmp/hudson1875946413917847668.sh: line 10: cd: solr/solr-ref-guide: No
>> such file or directory
>> Build step 'Execute shell' marked build as failure
>> Archiving artifacts
>> Email was triggered for: Failure - Any
>> Sending email for trigger: Failure - Any
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[jira] [Commented] (LUCENE-7824) Multi-word synonyms rule with common terms at the same position are buggy

[Jim Ferenczi (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008305#comment-16008305
 ] 

Jim Ferenczi commented on LUCENE-7824:
--

I don't think we should try to optimize here. The number of terms should be 
small in a query so I would prefer to keep it simple and just create a new 
entry for each token like the cached token stream does.

> Multi-word synonyms rule with common terms at the same position are buggy
> -
>
> Key: LUCENE-7824
> URL: https://issues.apache.org/jira/browse/LUCENE-7824
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jim Ferenczi
> Attachments: LUCENE-7824.patch
>
>
> The automaton built from the graph token stream tries to pack common terms in 
> multi word synonyms that appear at the same position. This means that some 
> states inside a multi word synonym can have multiple transitions.
> As a result the intersection point of the graph are not computed correctly.
> For example the synonym rule: "ny, new york city, new york" is not applied 
> correctly to the query "ny police".
> In this case "police" is detected as part of the multi synonyms path and we 
> create the disjunction between:
>  "ny police", "new york police", ...
> I pushed a patch that removes this optim (and creates a single transition 
> from each state) in order to ensure that the intersection points of the graph 
> always showed up at the end of the multi synonym paths.
> [~mattweber] can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing

[Uwe Schindler]

Ah by the way: I changed the master job a bit. Instead of "archiving" the HTML 
docs as "artifact", I used the "publish javadocs" post-build step to publish it 
as conventional Javadocs. This makes it show as "Documentation" link on the 
Jenkins base page. Also browsing is faster, as it does not need to do 
additional stuff on jenkins, its just a simple static HTML view.

It just releases the PDF as an artifact. 

I am in a train, if you like this, do it in the same way for the other jobs. I 
have no idea why the 6.6 one fails. Did you remove the workspace?

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Friday, May 12, 2017 5:51 PM
> To: dev@lucene.apache.org
> Subject: RE: [JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing
> 
> Are you sure you checked out to the workspace root? In Jenkins you have to
> explicitly say this (see other jobs).
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> > -Original Message-
> > From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
> > Sent: Friday, May 12, 2017 5:48 PM
> > To: dev@lucene.apache.org
> > Subject: [JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing
> >
> > Build: https://builds.apache.org/job/Solr-reference-guide-6.6/4/
> >
> > Log:
> > Started by user sarowe
> > [EnvInject] - Loading node environment variables.
> > Building remotely on H19 (git-websites) in workspace
> /home/jenkins/jenkins-
> > slave/workspace/Solr-reference-guide-6.6
> > Cloning the remote Git repository
> > Cloning repository git://git.apache.org/lucene-solr.git
> >  > git init /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6
> #
> > timeout=10
> > Fetching upstream changes from git://git.apache.org/lucene-solr.git
> >  > git --version # timeout=10
> >  > git fetch --tags --progress git://git.apache.org/lucene-solr.git
> > +refs/heads/*:refs/remotes/origin/*
> >  > git config remote.origin.url git://git.apache.org/lucene-solr.git #
> > timeout=10
> >  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
> #
> > timeout=10
> >  > git config remote.origin.url git://git.apache.org/lucene-solr.git #
> > timeout=10
> > Fetching upstream changes from git://git.apache.org/lucene-solr.git
> >  > git fetch --tags --progress git://git.apache.org/lucene-solr.git
> > +refs/heads/*:refs/remotes/origin/*
> >  > git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
> >  > git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} #
> > timeout=10
> > Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479
> > (refs/remotes/origin/branch_6_6)
> >  > git config core.sparsecheckout # timeout=10
> >  > git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
> >  > git rev-list 506485c4403bce29cc06272f3341c6afc2f1d479 # timeout=10
> > No emails were triggered.
> > [Solr-reference-guide-6.6] $ /bin/bash -xe
> > /tmp/hudson1875946413917847668.sh
> > + echo 'Set ruby path to avoid writing to /usr directory'
> > Set ruby path to avoid writing to /usr directory
> > + export RUBY_PATH=/home/jenkins/shared/.rvm
> > + RUBY_PATH=/home/jenkins/shared/.rvm
> > + export GEM_HOME=/home/jenkins/shared/.rvm/gems
> > + GEM_HOME=/home/jenkins/shared/.rvm/gems
> > + curl -sSL https://get.rvm.io
> > + bash -s -- --path /home/jenkins/shared/.rvm
> > Downloading https://github.com/rvm/rvm/archive/master.tar.gz
> >
> > Upgrading the RVM installation in /home/jenkins/shared/.rvm/
> > RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile
> > /home/jenkins/.bashrc /home/jenkins/.zshrc.
> > RVM sourcing line found in /home/jenkins/.profile
> > /home/jenkins/.bash_profile /home/jenkins/.zlogin.
> > Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
> >
> > # jenkins,
> > #
> > #   Thank you for using RVM!
> > #   We sincerely hope that RVM helps to make your life easier and more
> > enjoyable!!!
> > #
> > # ~Wayne, Michal & team.
> >
> > In case of problems: https://rvm.io/help and https://twitter.com/rvm_io
> >
> > Upgrade Notes:
> >
> >   * It looks like some old stuff is laying around RVM, you can cleanup with:
> > rvm cleanup all
> >
> >   * No new notes to display.
> >
> > + mkdir -p /home/jenkins/shared/.rvm/gems/gems
> > + gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll jekyll-
> > asciidoc pygments.rb
> > Successfully installed jekyll-3.4.3
> > Successfully installed jekyll-asciidoc-2.0.1
> > Successfully installed pygments.rb-1.1.2
> > 3 gems installed
> > + export
> >
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/late
> >
> st1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ga
> > mes:/usr/local/games
> > +
> >
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/late
> >
> 

RE: [JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing

[Uwe Schindler]

Are you sure you checked out to the workspace root? In Jenkins you have to 
explicitly say this (see other jobs).

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
> Sent: Friday, May 12, 2017 5:48 PM
> To: dev@lucene.apache.org
> Subject: [JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing
> 
> Build: https://builds.apache.org/job/Solr-reference-guide-6.6/4/
> 
> Log:
> Started by user sarowe
> [EnvInject] - Loading node environment variables.
> Building remotely on H19 (git-websites) in workspace /home/jenkins/jenkins-
> slave/workspace/Solr-reference-guide-6.6
> Cloning the remote Git repository
> Cloning repository git://git.apache.org/lucene-solr.git
>  > git init /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6 #
> timeout=10
> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>  > git --version # timeout=10
>  > git fetch --tags --progress git://git.apache.org/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
>  > git config remote.origin.url git://git.apache.org/lucene-solr.git #
> timeout=10
>  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* #
> timeout=10
>  > git config remote.origin.url git://git.apache.org/lucene-solr.git #
> timeout=10
> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>  > git fetch --tags --progress git://git.apache.org/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
>  > git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
>  > git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} #
> timeout=10
> Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479
> (refs/remotes/origin/branch_6_6)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
>  > git rev-list 506485c4403bce29cc06272f3341c6afc2f1d479 # timeout=10
> No emails were triggered.
> [Solr-reference-guide-6.6] $ /bin/bash -xe
> /tmp/hudson1875946413917847668.sh
> + echo 'Set ruby path to avoid writing to /usr directory'
> Set ruby path to avoid writing to /usr directory
> + export RUBY_PATH=/home/jenkins/shared/.rvm
> + RUBY_PATH=/home/jenkins/shared/.rvm
> + export GEM_HOME=/home/jenkins/shared/.rvm/gems
> + GEM_HOME=/home/jenkins/shared/.rvm/gems
> + curl -sSL https://get.rvm.io
> + bash -s -- --path /home/jenkins/shared/.rvm
> Downloading https://github.com/rvm/rvm/archive/master.tar.gz
> 
> Upgrading the RVM installation in /home/jenkins/shared/.rvm/
> RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile
> /home/jenkins/.bashrc /home/jenkins/.zshrc.
> RVM sourcing line found in /home/jenkins/.profile
> /home/jenkins/.bash_profile /home/jenkins/.zlogin.
> Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
> 
> # jenkins,
> #
> #   Thank you for using RVM!
> #   We sincerely hope that RVM helps to make your life easier and more
> enjoyable!!!
> #
> # ~Wayne, Michal & team.
> 
> In case of problems: https://rvm.io/help and https://twitter.com/rvm_io
> 
> Upgrade Notes:
> 
>   * It looks like some old stuff is laying around RVM, you can cleanup with:
> rvm cleanup all
> 
>   * No new notes to display.
> 
> + mkdir -p /home/jenkins/shared/.rvm/gems/gems
> + gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll jekyll-
> asciidoc pygments.rb
> Successfully installed jekyll-3.4.3
> Successfully installed jekyll-asciidoc-2.0.1
> Successfully installed pygments.rb-1.1.2
> 3 gems installed
> + export
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/late
> st1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ga
> mes:/usr/local/games
> +
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/late
> st1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ga
> mes:/usr/local/games
> + cd solr/solr-ref-guide
> /tmp/hudson1875946413917847668.sh: line 10: cd: solr/solr-ref-guide: No
> such file or directory
> Build step 'Execute shell' marked build as failure
> Archiving artifacts
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Solr-reference-guide-6.6 - Build # 4 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-6.6/4/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H19 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6
Cloning the remote Git repository
Cloning repository git://git.apache.org/lucene-solr.git
 > git init /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6 # 
 > timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} # timeout=10
Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479 
(refs/remotes/origin/branch_6_6)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
 > git rev-list 506485c4403bce29cc06272f3341c6afc2f1d479 # timeout=10
No emails were triggered.
[Solr-reference-guide-6.6] $ /bin/bash -xe /tmp/hudson1875946413917847668.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s -- --path /home/jenkins/shared/.rvm
Downloading https://github.com/rvm/rvm/archive/master.tar.gz

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

# jenkins,
#
#   Thank you for using RVM!
#   We sincerely hope that RVM helps to make your life easier and more 
enjoyable!!!
#
# ~Wayne, Michal & team.

In case of problems: https://rvm.io/help and https://twitter.com/rvm_io

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

+ mkdir -p /home/jenkins/shared/.rvm/gems/gems
+ gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll 
jekyll-asciidoc pygments.rb
Successfully installed jekyll-3.4.3
Successfully installed jekyll-asciidoc-2.0.1
Successfully installed pygments.rb-1.1.2
3 gems installed
+ export 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ cd solr/solr-ref-guide
/tmp/hudson1875946413917847668.sh: line 10: cd: solr/solr-ref-guide: No such 
file or directory
Build step 'Execute shell' marked build as failure
Archiving artifacts
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Solr-reference-guide-6.6 - Build # 3 - Still Failing

[Steve Rowe]

For some reason the checked-out commit is the one just before Cassandra 
cherry-picked the ref guide squash merge onto branch_6_6, so the 
solr/solr-ref-guide/ directory isn’t present.  I don’t see anything in the job 
config that would cause this.

Thinking the issue was maybe timing, I manually restarted the job a couple 
times, but there’s no change.

Next I’ll try deleting the job and re-cloning.

--
Steve
www.lucidworks.com

> On May 12, 2017, at 11:42 AM, Apache Jenkins Server 
>  wrote:
> 
> Build: https://builds.apache.org/job/Solr-reference-guide-6.6/3/
> 
> Log: 
> Started by user sarowe
> [EnvInject] - Loading node environment variables.
> Building remotely on H19 (git-websites) in workspace 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6
>> git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>> git config remote.origin.url git://git.apache.org/lucene-solr.git # 
>> timeout=10
> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>> git --version # timeout=10
>> git fetch --tags --progress git://git.apache.org/lucene-solr.git 
>> +refs/heads/*:refs/remotes/origin/*
>> git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
>> git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} # timeout=10
> Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479 
> (refs/remotes/origin/branch_6_6)
>> git config core.sparsecheckout # timeout=10
>> git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
>> git rev-list 506485c4403bce29cc06272f3341c6afc2f1d479 # timeout=10
> No emails were triggered.
> [Solr-reference-guide-6.6] $ /bin/bash -xe /tmp/hudson7016357499441274446.sh
> + echo 'Set ruby path to avoid writing to /usr directory'
> Set ruby path to avoid writing to /usr directory
> + export RUBY_PATH=/home/jenkins/shared/.rvm
> + RUBY_PATH=/home/jenkins/shared/.rvm
> + export GEM_HOME=/home/jenkins/shared/.rvm/gems
> + GEM_HOME=/home/jenkins/shared/.rvm/gems
> + curl -sSL https://get.rvm.io
> + bash -s -- --path /home/jenkins/shared/.rvm
> Downloading https://github.com/rvm/rvm/archive/master.tar.gz
> 
> Upgrading the RVM installation in /home/jenkins/shared/.rvm/
>RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
> /home/jenkins/.bashrc /home/jenkins/.zshrc.
>RVM sourcing line found in /home/jenkins/.profile 
> /home/jenkins/.bash_profile /home/jenkins/.zlogin.
> Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
> 
> # jenkins,
> #
> #   Thank you for using RVM!
> #   We sincerely hope that RVM helps to make your life easier and more 
> enjoyable!!!
> #
> # ~Wayne, Michal & team.
> 
> In case of problems: https://rvm.io/help and https://twitter.com/rvm_io
> 
> Upgrade Notes:
> 
>  * It looks like some old stuff is laying around RVM, you can cleanup with: 
> rvm cleanup all
> 
>  * No new notes to display.
> 
> + mkdir -p /home/jenkins/shared/.rvm/gems/gems
> + gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll 
> jekyll-asciidoc pygments.rb
> Successfully installed jekyll-3.4.3
> Successfully installed jekyll-asciidoc-2.0.1
> Successfully installed pygments.rb-1.1.2
> 3 gems installed
> + export 
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
> + 
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
> + cd solr/solr-ref-guide
> /tmp/hudson7016357499441274446.sh: line 10: cd: solr/solr-ref-guide: No such 
> file or directory
> Build step 'Execute shell' marked build as failure
> Archiving artifacts
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Solr-reference-guide-6.6 - Build # 3 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-6.6/3/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H19 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} # timeout=10
Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479 
(refs/remotes/origin/branch_6_6)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
 > git rev-list 506485c4403bce29cc06272f3341c6afc2f1d479 # timeout=10
No emails were triggered.
[Solr-reference-guide-6.6] $ /bin/bash -xe /tmp/hudson7016357499441274446.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s -- --path /home/jenkins/shared/.rvm
Downloading https://github.com/rvm/rvm/archive/master.tar.gz

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

# jenkins,
#
#   Thank you for using RVM!
#   We sincerely hope that RVM helps to make your life easier and more 
enjoyable!!!
#
# ~Wayne, Michal & team.

In case of problems: https://rvm.io/help and https://twitter.com/rvm_io

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

+ mkdir -p /home/jenkins/shared/.rvm/gems/gems
+ gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll 
jekyll-asciidoc pygments.rb
Successfully installed jekyll-3.4.3
Successfully installed jekyll-asciidoc-2.0.1
Successfully installed pygments.rb-1.1.2
3 gems installed
+ export 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ cd solr/solr-ref-guide
/tmp/hudson7016357499441274446.sh: line 10: cd: solr/solr-ref-guide: No such 
file or directory
Build step 'Execute shell' marked build as failure
Archiving artifacts
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+168) - Build # 19617 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19617/
Java: 32bit/jdk-9-ea+168 -client -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 13231 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/temp/junit4-J0-20170512_145943_5313255031430695800181.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-master-Linux/heapdumps/java_pid27225.hprof 
...
   [junit4] Heap dump file created [59176189 bytes in 0.543 secs]
   [junit4] <<< JVM J0: EOF 

[...truncated 7466 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:727: Some of the 
tests produced a heap dump, but did not fail. Maybe a suppressed 
OutOfMemoryError? Dumps created:
* java_pid27225.hprof

Total time: 62 minutes 22 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Solr-reference-guide-6.6 - Build # 2 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-6.6/2/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H19 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6
Cloning the remote Git repository
Cloning repository git://git.apache.org/lucene-solr.git
 > git init /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6 # 
 > timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} # timeout=10
Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479 
(refs/remotes/origin/branch_6_6)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
 > git rev-list 506485c4403bce29cc06272f3341c6afc2f1d479 # timeout=10
No emails were triggered.
[Solr-reference-guide-6.6] $ /bin/bash -xe /tmp/hudson7357700613985192295.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s -- --path /home/jenkins/shared/.rvm
Downloading https://github.com/rvm/rvm/archive/master.tar.gz

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

# jenkins,
#
#   Thank you for using RVM!
#   We sincerely hope that RVM helps to make your life easier and more 
enjoyable!!!
#
# ~Wayne, Michal & team.

In case of problems: https://rvm.io/help and https://twitter.com/rvm_io

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

+ mkdir -p /home/jenkins/shared/.rvm/gems/gems
+ gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll 
jekyll-asciidoc pygments.rb
Successfully installed jekyll-3.4.3
Successfully installed jekyll-asciidoc-2.0.1
Successfully installed pygments.rb-1.1.2
3 gems installed
+ export 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ cd solr/solr-ref-guide
/tmp/hudson7357700613985192295.sh: line 10: cd: solr/solr-ref-guide: No such 
file or directory
Build step 'Execute shell' marked build as failure
Archiving artifacts
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Solr-reference-guide-6.6 - Build # 1 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-6.6/1/

Log: 
Started by user sarowe
[EnvInject] - Loading node environment variables.
Building remotely on H20 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6
Cloning the remote Git repository
Cloning repository git://git.apache.org/lucene-solr.git
 > git init /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-6.6 # 
 > timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_6_6^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_6_6^{commit} # timeout=10
Checking out Revision 506485c4403bce29cc06272f3341c6afc2f1d479 
(refs/remotes/origin/branch_6_6)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 506485c4403bce29cc06272f3341c6afc2f1d479
First time build. Skipping changelog.
No emails were triggered.
[Solr-reference-guide-6.6] $ /bin/bash -xe /tmp/hudson302336181407443888.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s -- --path /home/jenkins/shared/.rvm
Downloading https://github.com/rvm/rvm/archive/master.tar.gz

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

# jenkins,
#
#   Thank you for using RVM!
#   We sincerely hope that RVM helps to make your life easier and more 
enjoyable!!!
#
# ~Wayne, Michal & team.

In case of problems: https://rvm.io/help and https://twitter.com/rvm_io

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

+ mkdir -p /home/jenkins/shared/.rvm/gems/gems
+ gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll 
jekyll-asciidoc pygments.rb
Successfully installed public_suffix-2.0.5
Successfully installed addressable-2.5.1
Successfully installed colorator-1.1.0
Successfully installed sass-3.4.23
Successfully installed jekyll-sass-converter-1.5.0
Successfully installed rb-fsevent-0.9.8
Building native extensions.  This could take a while...
Successfully installed ffi-1.9.18
Successfully installed rb-inotify-0.9.8
Successfully installed listen-3.0.8
Successfully installed jekyll-watch-1.5.0
Successfully installed kramdown-1.13.2
Successfully installed liquid-3.0.6
Successfully installed mercenary-0.3.6
Successfully installed forwardable-extended-2.6.0
Successfully installed pathutil-0.14.0
Successfully installed rouge-1.11.1
Successfully installed safe_yaml-1.0.4
Successfully installed jekyll-3.4.3
Successfully installed asciidoctor-1.5.5
Successfully installed jekyll-asciidoc-2.0.1
Successfully installed multi_json-1.12.1
Successfully installed pygments.rb-1.1.2
22 gems installed
+ export 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ cd solr/solr-ref-guide
/tmp/hudson302336181407443888.sh: line 10: cd: solr/solr-ref-guide: No such 
file or directory
Build step 'Execute shell' marked build as failure
Archiving artifacts
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 866 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/866/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

7 tests failed.
FAILED:  org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest

Error Message:
Could not find collection : delLiveColl

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : delLiveColl
at 
__randomizedtesting.SeedInfo.seed([12AD24191CFFCBC8:BFCD901201C063BD]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:245)
at 
org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest(DeleteReplicaTest.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest

Error Message:
java.io.IOException: Couldn't instantiate 

[jira] [Commented] (SOLR-10290) New Publication Model for Solr Reference Guide

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008237#comment-16008237
 ] 

Cassandra Targett commented on SOLR-10290:
--

Cherrypicked to branch_6x: 
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=ccbc93b80929e942d20cd4782e3a3f4c77d73932

Cherrypicked to branch_6_6: 
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=c8c2aab8dbb1174bf9fd38fdb9dea53e16307f3a

> New Publication Model for Solr Reference Guide
> --
>
> Key: SOLR-10290
> URL: https://issues.apache.org/jira/browse/SOLR-10290
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>
> The current Solr Ref Guide is hosted at cwiki.apache.org, a Confluence 
> installation. There are numerous reasons to be dissatisfied with the current 
> setup, a few of which are:
> * Confluence as a product is no longer designed for our use case and our type 
> of content. 
> * The writing/editing experience is painful and a barrier for all users, who 
> need to learn a lot of Confluence-specific syntax just to help out with some 
> content. 
> * Non-committers can't really help improve documentation except to point out 
> problems and hope someone else fixes them.
> * We really can't maintain online documentation for different versions. Users 
> on versions other than the one that hasn't been released yet are only given a 
> PDF to work with.
> I made a proposal in Aug 2016 ([email 
> link|http://mail-archives.apache.org/mod_mbox/lucene-dev/201608.mbox/%3CCAKrJsP%3DqMLVZhb8xR2C27mfNFfEJ6b%3DPcjxPz4f3fq7G371B_g%40mail.gmail.com%3E])
>  to move the Ref Guide from Confluence to a new system that relies on 
> asciidoc-formatted text files integrated with the Solr source code. 
> This is an umbrella issue for the sub-tasks and related decisions to make 
> that proposal a reality. A lot of work has already been done as part of a 
> proof-of-concept, but there are many things left to do. Some of the items to 
> be completed include:
> * Creation of a branch and moving the early POC work I've done to the project
> * Conversion the content and clean up of unavoidable post-conversion issues
> * Decisions about location of source files, branching strategy and hosting 
> for online versions
> * Meta-documentation for publication process, beginner tips, etc. (whatever 
> else people need or want)
> * Integration of build processes with the broader project
> For reference, a demo of what the new ref guide might look like is currently 
> online at http://people.apache.org/~ctargett/RefGuidePOC/.
> Creation of sub-tasks to follow shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9910) Allow setting of additional jetty options in bin/solr and bin/solr.cmd

[Mano Kovacs (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008220#comment-16008220
 ] 

Mano Kovacs commented on SOLR-9910:
---

[~markrmil...@gmail.com], is there anything I can do related to this jira?

> Allow setting of additional jetty options in bin/solr and bin/solr.cmd
> --
>
> Key: SOLR-9910
> URL: https://issues.apache.org/jira/browse/SOLR-9910
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mano Kovacs
> Attachments: SOLR-9910.patch, SOLR-9910.patch
>
>
> Command line tools allow the option {{-a}} to add JVM options to start 
> command. Proposing to add {{-j}} option to add additional config for jetty 
> (the part after {{start.jar}}).
> Motivation: jetty can be configured with start.ini in server directory. 
> Running multiple Solr instances, however, requires the configuration per 
> instance that cannot share the start.ini with other instances.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7822) IllegalArgumentException thrown instead of a CorruptIndexException

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008219#comment-16008219
 ] 

Michael McCandless commented on LUCENE-7822:


bq. For such a small file, maybe we should call eg. 
CodecUtil.checksumEntireFile before starting to read it. This would give a 
clearer error message?

+1

> IllegalArgumentException thrown instead of a CorruptIndexException
> --
>
> Key: LUCENE-7822
> URL: https://issues.apache.org/jira/browse/LUCENE-7822
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.5.1
>Reporter: Martin Amirault
>Priority: Minor
>
> Similarly to LUCENE-7592 , When an {{*.si}} file is corrupted on very 
> specific part an IllegalArgumentException is thrown instead of a 
> CorruptIndexException.
> StackTrace (Lucene 6.5.1):
> {code}
> java.lang.IllegalArgumentException: Illegal minor version: 12517381
>   at 
> __randomizedtesting.SeedInfo.seed([1FEB5987CFA44BE:B8755B5574F9F3BF]:0)
>   at org.apache.lucene.util.Version.(Version.java:385)
>   at org.apache.lucene.util.Version.(Version.java:371)
>   at org.apache.lucene.util.Version.fromBits(Version.java:353)
>   at 
> org.apache.lucene.codecs.lucene62.Lucene62SegmentInfoFormat.read(Lucene62SegmentInfoFormat.java:97)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:357)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:288)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:448)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:445)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:692)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:644)
>   at 
> org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:450)
>   at 
> org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.java:260)
> {code}
> Simple fix would be to add IllegalArgumentException to the catch list at 
> {{org/apache/lucene/index/SegmentInfos.java:289}}
> Other variations for the stacktraces:
> {code}
> java.lang.IllegalArgumentException: invalid codec filename '_�.cfs', must 
> match: _[a-z0-9]+(_.*)?\..*
>   at 
> __randomizedtesting.SeedInfo.seed([8B3FDE317B8D634A:A8EE07E5EB4B0B13]:0)
>   at 
> org.apache.lucene.index.SegmentInfo.checkFileNames(SegmentInfo.java:270)
>   at org.apache.lucene.index.SegmentInfo.addFiles(SegmentInfo.java:252)
>   at org.apache.lucene.index.SegmentInfo.setFiles(SegmentInfo.java:246)
>   at 
> org.apache.lucene.codecs.lucene62.Lucene62SegmentInfoFormat.read(Lucene62SegmentInfoFormat.java:248)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:357)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:288)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:448)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:445)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:692)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:644)
>   at 
> org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:450)
>   at 
> org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.java:260)
> {code}
> {code}
> java.lang.IllegalArgumentException: An SPI class of type 
> org.apache.lucene.codecs.Codec with name 'LucenI62' does not exist.  You need 
> to add the corresponding JAR file supporting this SPI to your classpath.  The 
> current classpath supports the following names: [Lucene62, Lucene50, 
> Lucene53, Lucene54, Lucene60]
>   at 
> __randomizedtesting.SeedInfo.seed([925DE160F7260F99:B026EB9373CB6368]:0)
>   at org.apache.lucene.util.NamedSPILoader.lookup(NamedSPILoader.java:116)
>   at org.apache.lucene.codecs.Codec.forName(Codec.java:116)
>   at org.apache.lucene.index.SegmentInfos.readCodec(SegmentInfos.java:424)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:356)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:288)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:448)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:445)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:692)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:644)
>   at 
> org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:450)
>   at 
> org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.java:260)
> {code}

[jira] [Commented] (LUCENE-7810) false positive equality: distinctly diff join queries return equals()==true

[Martijn van Groningen (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008212#comment-16008212
 ] 

Martijn van Groningen commented on LUCENE-7810:
---

Good catch [~hossman]! If nobody is working on this then I can fix this bug. So 
far only the {{TermsQuery}} seems to not take into account the join field.

bq. you mean the from query, correct?

I think this is what [~jpountz] means, because equality checking the collected 
terms would be too expensive. 

I think the {{TermsIncludingScoreQuery}}, {{TermsQuery}}, 
{{PointInSetIncludingScoreQuery}} and {{PointInSetQuery}} should also take 
index reader context id into like the {{GlobalOrdinalsQuery}} is doing. 
Otherwise the fromQuery + join field key can still be invalid. (mainly when 
docs on the from side added) 

> false positive equality: distinctly diff join queries return equals()==true
> ---
>
> Key: LUCENE-7810
> URL: https://issues.apache.org/jira/browse/LUCENE-7810
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: LUCENE-7810.patch
>
>
> While working on SOLR-10583 I was getting some odd test failures that seemed 
> to suggest we were getting false cache hits for Join queries that should have 
> been unique.
> tracing thorugh the code, the problem seems to be the way {{TermsQuery}} 
> implements {{equals(Object)}}.  This class takes in the {{fromQuery}} (used 
> to identify set of documents we "join from") and uses it in the equals 
> calculation -- but the information about the join _field_ is never passed 
> directly to {{TermsQuery}} and the BytesRefs that are passed in can't be 
> compared efficiently (AFAICT), so 2 completely diff calls to 
> {{JoinUtils.createJoinQuery(...)}} can result in Query objects that think 
> they are {{equal()}} even when they most certainly are not.
> At a brief glance, it appears that similar bugs exist in 
> {{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}}, 
> but i didn't look into that class at all)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7826) Support to unload FST's .tip into memory,make load or unload configuable!.

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008210#comment-16008210
 ] 

Michael McCandless commented on LUCENE-7826:


You could do this in your own custom codec, but I don't think we should expose 
this behavior in Lucene's default codec.  Typically the RAM usage for .tip is 
manageable.

Can you describe the 10s of billions of documents that you are indexing?  You 
need to use sharding for that (a single Lucene index can index at most ~2.1 
billion documents).  What is the total unique term account?

Another thing you could do is increase the block size of the on-disk terms (see 
the {{minTermBlockSize}} and {{maxTermBlockSize}} params to 
{{Lucene50PostingsFormat}}.  These are easy knobs to turn to decrease heap 
needed by .tip, but increase term lookup cost (since more scanning will be 
needed).

> Support to unload FST's .tip into memory,make load or unload configuable!.
> --
>
> Key: LUCENE-7826
> URL: https://issues.apache.org/jira/browse/LUCENE-7826
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/FSTs, core/store
>Reporter: Xibao
>Priority: Minor
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> in real case,we use lucene index many documents. But some machine have not 
> much memory.,once documents reach up to tens of billion,lucene can not start 
> because of no enough memory. Most of the memry cost is FST;s .tip content.
> So I want to pull my change on lucene core to make load FST's .tip into 
> memory become configurable!
> What do you think?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7824) Multi-word synonyms rule with common terms at the same position are buggy

[Matt Weber (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008209#comment-16008209
 ] 

Matt Weber commented on LUCENE-7824:


[~jim.ferenczi] Maybe use a {{BytesRefHash}} and maintain a id-to-hash map so 
we still only have single copy of common term in memory and still have a unique 
id?

> Multi-word synonyms rule with common terms at the same position are buggy
> -
>
> Key: LUCENE-7824
> URL: https://issues.apache.org/jira/browse/LUCENE-7824
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jim Ferenczi
> Attachments: LUCENE-7824.patch
>
>
> The automaton built from the graph token stream tries to pack common terms in 
> multi word synonyms that appear at the same position. This means that some 
> states inside a multi word synonym can have multiple transitions.
> As a result the intersection point of the graph are not computed correctly.
> For example the synonym rule: "ny, new york city, new york" is not applied 
> correctly to the query "ny police".
> In this case "police" is detected as part of the multi synonyms path and we 
> create the disjunction between:
>  "ny police", "new york police", ...
> I pushed a patch that removes this optim (and creates a single transition 
> from each state) in order to ensure that the intersection points of the graph 
> always showed up at the end of the multi synonym paths.
> [~mattweber] can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-8668) Remove support for (in favour of )

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke updated SOLR-8668:
--
Attachment: SOLR-8668-part1.patch

Attaching very slightly revised patch (ready for review) to account for the 
SOLR-10572 revert. Hoping to commit this later this month in good time for the 
branch_7x branch cutting.

> Remove support for  (in favour of )
> 
>
> Key: SOLR-8668
> URL: https://issues.apache.org/jira/browse/SOLR-8668
> Project: Solr
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Christine Poerschke
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-8668-part1.patch, SOLR-8668-part1.patch
>
>
> Following SOLR-8621, we should remove support for {{}} (and 
> related {{}} and {{}}) in trunk/6x.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10307) Provide SSL/TLS keystore password a more secure way

[Mano Kovacs (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008186#comment-16008186
 ] 

Mano Kovacs commented on SOLR-10307:


[~markrmil...@gmail.com], is there anything I can help to get this jira 
resolved?

> Provide SSL/TLS keystore password a more secure way
> ---
>
> Key: SOLR-10307
> URL: https://issues.apache.org/jira/browse/SOLR-10307
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Attachments: SOLR-10307.patch, SOLR-10307.patch, SOLR-10307.patch
>
>
> Currently the only way to pass server and client side SSL keytstore and 
> truststore passwords is to set specific environment variables that will be 
> passed as system properties, through command line parameter.
> First option is to pass passwords through environment variables which gives a 
> better level of protection. Second option would be to use hadoop credential 
> provider interface to access credential store.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-10572) (from 7.0.0 onwards) remove three no-longer-supported warnings in SolrIndexConfig

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke resolved SOLR-10572.

   Resolution: Won't Do
Fix Version/s: (was: master (7.0))

Won't do, the warnings are not yet remove-able.

> (from 7.0.0 onwards) remove three no-longer-supported warnings in 
> SolrIndexConfig
> -
>
> Key: SOLR-10572
> URL: https://issues.apache.org/jira/browse/SOLR-10572
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10572.patch
>
>
> The mergeScheduler, mergePolicy and luceneAutoCommit [no-longer-supported 
> warnings|https://github.com/apache/lucene-solr/blame/48ca9fc3f4f8d95293cee7bb59eff61247ede181/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L130-L140]
>  date back to 
> [2012|https://github.com/apache/lucene-solr/commit/058179d177208450850c5e3e3103710cadd3b53e].
>  Let's remove them from 7.0.0 onwards for clarity. This caught my attention 
> as part of SOLR-8668's mergePolicy support removal.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10572) (from 7.0.0 onwards) remove three no-longer-supported warnings in SolrIndexConfig

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008162#comment-16008162
 ] 

ASF subversion and git services commented on SOLR-10572:


Commit 6d74a9e858d464fbfa6fc9e0fc90abf437565c3b in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6d74a9e ]

Revert "SOLR-10572: Removed three "no longer supported in solrconfig.xml" 
asserts."

This reverts commit a96f39449b48c7c2b4f2a82c808a97fb0c60ffc5.

Resolved Conflicts:
solr/CHANGES.txt


> (from 7.0.0 onwards) remove three no-longer-supported warnings in 
> SolrIndexConfig
> -
>
> Key: SOLR-10572
> URL: https://issues.apache.org/jira/browse/SOLR-10572
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10572.patch
>
>
> The mergeScheduler, mergePolicy and luceneAutoCommit [no-longer-supported 
> warnings|https://github.com/apache/lucene-solr/blame/48ca9fc3f4f8d95293cee7bb59eff61247ede181/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L130-L140]
>  date back to 
> [2012|https://github.com/apache/lucene-solr/commit/058179d177208450850c5e3e3103710cadd3b53e].
>  Let's remove them from 7.0.0 onwards for clarity. This caught my attention 
> as part of SOLR-8668's mergePolicy support removal.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10617) JDBCStream: support more data types

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008149#comment-16008149
 ] 

ASF subversion and git services commented on SOLR-10617:


Commit 7fe57aded128a60f64d8482ec13a56ad8d00feac in lucene-solr's branch 
refs/heads/branch_6x from jdyer1
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7fe57ad ]

SOLR-10617: JDBCStream to support additional types, minor refactoring to 
separate out CalciteJDBCStream, upgrade hsqldb for JDBCStream & DIH tests.


> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 6.7
>
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-10617) JDBCStream: support more data types

[James Dyer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Dyer resolved SOLR-10617.
---
Resolution: Fixed

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 6.7
>
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10617) JDBCStream: support more data types

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008141#comment-16008141
 ] 

ASF subversion and git services commented on SOLR-10617:


Commit e61b5b34bf14b9addd98eeafdad43b92e6208d5f in lucene-solr's branch 
refs/heads/master from jdyer1
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e61b5b3 ]

SOLR-10617: JDBCStream to support additional types, minor refactoring to 
separate out CalciteJDBCStream, upgrade hsqldb for JDBCStream & DIH tests.


> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 6.7
>
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10617) JDBCStream: support more data types

[James Dyer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Dyer updated SOLR-10617:
--
Fix Version/s: 6.7

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 6.7
>
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-10670) [ref-guide] Various top-bar fixes

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008103#comment-16008103
 ] 

Cassandra Targett edited comment on SOLR-10670 at 5/12/17 1:23 PM:
---

bq. Now the "Home" on top of sidebar will be highlighted on the frontpage, and 
when another page is selected, the "Home" will remain on top with a grey 
background, clickable as any other sidebar element. 

I don't think this works well - it looks like the title of the sidebar, and I 
wouldn't think it was supposed to be clickable if I didn't know it was from 
reading this ticket.

It could be like it was - "Apache Solr Reference Guide", which we could hard 
code into that spot  - but another option is to use some of what you've done to 
integrate it into the sidebar but change it to be a title for the sidebar that 
reads something like "Topics Covered" or similar heading. Personally I'd prefer 
to just make it a bit of white space - a sidebar doesn't need a title, and the 
action of getting home is  already accomplished by the "Solr Ref Guide" link in 
the top navigation. We really don't need another clickable avenue right below 
it, IMO.

_edit_: I meant I don't think it works well - missed the "don't"


was (Author: ctargett):
bq. Now the "Home" on top of sidebar will be highlighted on the frontpage, and 
when another page is selected, the "Home" will remain on top with a grey 
background, clickable as any other sidebar element. 

I think this works well - it looks like the title of the sidebar, and I 
wouldn't think it was supposed to be clickable if I didn't know it was from 
reading this ticket.

It could be like it was - "Apache Solr Reference Guide", which we could hard 
code into that spot  - but another option is to use some of what you've done to 
integrate it into the sidebar but change it to be a title for the sidebar that 
reads something like "Topics Covered" or similar heading. Personally I'd prefer 
to just make it a bit of white space - a sidebar doesn't need a title, and the 
action of getting home is  already accomplished by the "Solr Ref Guide" link in 
the top navigation. We really don't need another clickable avenue right below 
it, IMO.

> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.patch, 
> SOLR-10670.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4004 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4004/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter

Error Message:
Collection not found: withShardField

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: withShardField
at 
__randomizedtesting.SeedInfo.seed([C0E1DDC6CA6224D9:95B13554669BEB29]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1416)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1099)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1074)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter(CustomCollectionTest.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   

[jira] [Commented] (SOLR-10670) [ref-guide] Various top-bar fixes

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008103#comment-16008103
 ] 

Cassandra Targett commented on SOLR-10670:
--

bq. Now the "Home" on top of sidebar will be highlighted on the frontpage, and 
when another page is selected, the "Home" will remain on top with a grey 
background, clickable as any other sidebar element. 

I think this works well - it looks like the title of the sidebar, and I 
wouldn't think it was supposed to be clickable if I didn't know it was from 
reading this ticket.

It could be like it was - "Apache Solr Reference Guide", which we could hard 
code into that spot  - but another option is to use some of what you've done to 
integrate it into the sidebar but change it to be a title for the sidebar that 
reads something like "Topics Covered" or similar heading. Personally I'd prefer 
to just make it a bit of white space - a sidebar doesn't need a title, and the 
action of getting home is  already accomplished by the "Solr Ref Guide" link in 
the top navigation. We really don't need another clickable avenue right below 
it, IMO.

> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.patch, 
> SOLR-10670.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10651) Streaming Expressions statistical functions library

[manohar kanuri (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008085#comment-16008085
 ] 

manohar kanuri commented on SOLR-10651:
---

Nice. I started with Solr and moved on to R.  I'd be interested to see how 
extensive your planned functionalities are. Consistent syntax is invaluable to 
have. 

> Streaming Expressions statistical functions library
> ---
>
> Key: SOLR-10651
> URL: https://issues.apache.org/jira/browse/SOLR-10651
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> This is a ticket for organizing the new statistical programming features of 
> Streaming Expressions. It's also a place for the community to discuss what 
> functions are needed to support statistical programming. This ticket will be 
> updated shortly to show the existing syntax and functions with links to 
> existing jira tickets.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10644) solr.in.sh installed by install script should be writable by solr user

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SOLR-10644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl updated SOLR-10644:
---
Attachment: SOLR-10644-reopen.patch

Attaching proposed patch {{SOLR-10644-reopen.patch}}

* solr.in.sh will be owned by root, readable by SOLR_USER but not by world
* tested on Ubuntu, CentOS and OpenSuse
* For OpenSuse, user-group was not created by default, so modified useradd 
command to create user-group {{-U}} and to place home-dir in /var/solr 
  {{useradd --system -U -m --home-dir "$SOLR_VAR_DIR" "$SOLR_USER"}}
* Did the same modifications for RedHat (tested on CentOS) for completeness

> solr.in.sh installed by install script should be writable by solr user
> --
>
> Key: SOLR-10644
> URL: https://issues.apache.org/jira/browse/SOLR-10644
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10644.patch, SOLR-10644-reopen.patch
>
>
> Spinoff from SOLR-8440
> {{install_solr_service.sh}} installs {{solr.in.sh}} as world-readable but not 
> solr user writable:
> {noformat}
> -rw-r--r-- 1 root root 5968 Feb 15 14:55 /etc/default/solr.in.sh
> {noformat}
> For better security, and ease for scripts to update solr.in.sh, this should 
> change to:
> {noformat}
> -rw-rw 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16008059#comment-16008059
 ] 

Cassandra Targett commented on SOLR-10568:
--

Awesome, thanks Steve. Once this is in branch_6x, I hope you will help us again 
by setting up a job for that too :-)

> Automate HTML builds via Jenkins to occur with each commit
> --
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so 
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are 
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to 
> verify the presentation of the information is as expected.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org