[jira] [Updated] (SOLR-3336) SolrEntityProcessor should substitute params at query time, not startup time
[
https://issues.apache.org/jira/browse/SOLR-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lance Norskog updated SOLR-3336:
Component/s: contrib - DataImportHandler
Description:
The SolrEntityProcessor performs variable substitution at startup, not at query
time. This means that this technique cannot work:
{code}
{code}
The SEP should substitute the new value of SomeField into each query string.
was:
The SolrEntityProcessor performs variable substitution at startup, not at query
time. This means that this technique cannot work:
{code}
{code}
The SEP does not substitute the value of SomeField into each query string.
Affects Version/s: 4.0
3.5
> SolrEntityProcessor should substitute params at query time, not startup time
>
>
> Key: SOLR-3336
> URL: https://issues.apache.org/jira/browse/SOLR-3336
> Project: Solr
> Issue Type: New Feature
> Components: contrib - DataImportHandler
>Affects Versions: 3.5, 4.0
>Reporter: Lance Norskog
>
> The SolrEntityProcessor performs variable substitution at startup, not at
> query time. This means that this technique cannot work:
> {code}
>
>
>
>
> {code}
> The SEP should substitute the new value of SomeField into each query string.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3336) SolrEntityProcessor should substitute params at query time, not startup time
SolrEntityProcessor should substitute params at query time, not startup time
Key: SOLR-3336
URL: https://issues.apache.org/jira/browse/SOLR-3336
Project: Solr
Issue Type: New Feature
Reporter: Lance Norskog
The SolrEntityProcessor performs variable substitution at startup, not at query
time. This means that this technique cannot work:
{code}
{code}
The SEP does not substitute the value of SomeField into each query string.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1310646 - in /lucene/dev/nightly: hudson-lucene-3.x.sh hudson-lusolr-tests-3.x.sh hudson-solr-3.x.sh
heh well you didnt really break it... i just don't know how to disable these jenkins tasks!!! i wanted to quiet it though without backing out any changes. Still, I think its time to disable these 3.x tasks?! On Fri, Apr 6, 2012 at 9:09 PM, Steven A Rowe wrote: > Sorry I broke the build - thanks for fixing Robert! > > -Original Message- > From: rm...@apache.org [mailto:rm...@apache.org] > Sent: Friday, April 06, 2012 8:08 PM > To: comm...@lucene.apache.org > Subject: svn commit: r1310646 - in /lucene/dev/nightly: hudson-lucene-3.x.sh > hudson-lusolr-tests-3.x.sh hudson-solr-3.x.sh > > Author: rmuir > Date: Sat Apr 7 00:07:57 2012 > New Revision: 1310646 > > URL: http://svn.apache.org/viewvc?rev=1310646&view=rev > Log: > try once to unbreak build nicely > > Modified: > lucene/dev/nightly/hudson-lucene-3.x.sh > lucene/dev/nightly/hudson-lusolr-tests-3.x.sh > lucene/dev/nightly/hudson-solr-3.x.sh > > Modified: lucene/dev/nightly/hudson-lucene-3.x.sh > URL: > http://svn.apache.org/viewvc/lucene/dev/nightly/hudson-lucene-3.x.sh?rev=1310646&r1=1310645&r2=1310646&view=diff > == > --- lucene/dev/nightly/hudson-lucene-3.x.sh (original) > +++ lucene/dev/nightly/hudson-lucene-3.x.sh Sat Apr 7 00:07:57 2012 > @@ -1,4 +1,5 @@ > #!/bin/sh > +IGNORE_AUTHOR_TAGS=1 > . $WORKSPACE/nightly/hudson-settings.sh > > #Update the Version # when doing a release > > Modified: lucene/dev/nightly/hudson-lusolr-tests-3.x.sh > URL: > http://svn.apache.org/viewvc/lucene/dev/nightly/hudson-lusolr-tests-3.x.sh?rev=1310646&r1=1310645&r2=1310646&view=diff > == > --- lucene/dev/nightly/hudson-lusolr-tests-3.x.sh (original) > +++ lucene/dev/nightly/hudson-lusolr-tests-3.x.sh Sat Apr 7 00:07:57 2012 > @@ -1,4 +1,5 @@ > #!/bin/sh > +IGNORE_AUTHOR_TAGS=1 > . $WORKSPACE/nightly/hudson-settings.sh > > # temporary: just to look for corner-cases for a bit > > Modified: lucene/dev/nightly/hudson-solr-3.x.sh > URL: > http://svn.apache.org/viewvc/lucene/dev/nightly/hudson-solr-3.x.sh?rev=1310646&r1=1310645&r2=1310646&view=diff > == > --- lucene/dev/nightly/hudson-solr-3.x.sh (original) > +++ lucene/dev/nightly/hudson-solr-3.x.sh Sat Apr 7 00:07:57 2012 > @@ -1,4 +1,5 @@ > #!/bin/sh > +IGNORE_AUTHOR_TAGS=1 > . $WORKSPACE/nightly/hudson-settings.sh > > VERSION=3.6-$BUILD_ID > > -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249110#comment-13249110
]
Steven Rowe commented on LUCENE-3959:
-
bq. I don't know how to disable these 3.x tasks in jenkins completely or i
would.
I think you got it - thanks!
bq. so I think its ok to disable the 3.x tasks and dedicate them towards trunk?
+1
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: svn commit: r1310646 - in /lucene/dev/nightly: hudson-lucene-3.x.sh hudson-lusolr-tests-3.x.sh hudson-solr-3.x.sh
Sorry I broke the build - thanks for fixing Robert! -Original Message- From: rm...@apache.org [mailto:rm...@apache.org] Sent: Friday, April 06, 2012 8:08 PM To: comm...@lucene.apache.org Subject: svn commit: r1310646 - in /lucene/dev/nightly: hudson-lucene-3.x.sh hudson-lusolr-tests-3.x.sh hudson-solr-3.x.sh Author: rmuir Date: Sat Apr 7 00:07:57 2012 New Revision: 1310646 URL: http://svn.apache.org/viewvc?rev=1310646&view=rev Log: try once to unbreak build nicely Modified: lucene/dev/nightly/hudson-lucene-3.x.sh lucene/dev/nightly/hudson-lusolr-tests-3.x.sh lucene/dev/nightly/hudson-solr-3.x.sh Modified: lucene/dev/nightly/hudson-lucene-3.x.sh URL: http://svn.apache.org/viewvc/lucene/dev/nightly/hudson-lucene-3.x.sh?rev=1310646&r1=1310645&r2=1310646&view=diff == --- lucene/dev/nightly/hudson-lucene-3.x.sh (original) +++ lucene/dev/nightly/hudson-lucene-3.x.sh Sat Apr 7 00:07:57 2012 @@ -1,4 +1,5 @@ #!/bin/sh +IGNORE_AUTHOR_TAGS=1 . $WORKSPACE/nightly/hudson-settings.sh #Update the Version # when doing a release Modified: lucene/dev/nightly/hudson-lusolr-tests-3.x.sh URL: http://svn.apache.org/viewvc/lucene/dev/nightly/hudson-lusolr-tests-3.x.sh?rev=1310646&r1=1310645&r2=1310646&view=diff == --- lucene/dev/nightly/hudson-lusolr-tests-3.x.sh (original) +++ lucene/dev/nightly/hudson-lusolr-tests-3.x.sh Sat Apr 7 00:07:57 2012 @@ -1,4 +1,5 @@ #!/bin/sh +IGNORE_AUTHOR_TAGS=1 . $WORKSPACE/nightly/hudson-settings.sh # temporary: just to look for corner-cases for a bit Modified: lucene/dev/nightly/hudson-solr-3.x.sh URL: http://svn.apache.org/viewvc/lucene/dev/nightly/hudson-solr-3.x.sh?rev=1310646&r1=1310645&r2=1310646&view=diff == --- lucene/dev/nightly/hudson-solr-3.x.sh (original) +++ lucene/dev/nightly/hudson-solr-3.x.sh Sat Apr 7 00:07:57 2012 @@ -1,4 +1,5 @@ #!/bin/sh +IGNORE_AUTHOR_TAGS=1 . $WORKSPACE/nightly/hudson-settings.sh VERSION=3.6-$BUILD_ID
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 12981 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12981/ No tests ran. Build Log (for compile errors): [...truncated 58 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249055#comment-13249055
]
Robert Muir commented on LUCENE-3959:
-
I don't know how to disable these 3.x tasks in jenkins completely or i would.
my hudson: http://sierranevada.servebeer.com/ is still running for 3.x and i
will disable when 3.6
is released.
so I think its ok to disable the 3.x tasks and dedicate them towards trunk?
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249051#comment-13249051
]
Chris Male commented on LUCENE-3959:
Ha, beat me too it Robert.
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated LUCENE-3959:
---
Comment: was deleted
(was: Ha, beat me too it Robert.)
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated LUCENE-3959:
---
Comment: was deleted
(was: Hey Steve,
Your @author tag check is now causing the 3x build to break (which demonstrates
it works!). Are you able to backport the @author removals?)
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249050#comment-13249050
]
Chris Male commented on LUCENE-3959:
Hey Steve,
Your @author tag check is now causing the 3x build to break (which demonstrates
it works!). Are you able to backport the @author removals?
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249049#comment-13249049
]
Robert Muir commented on LUCENE-3959:
-
This broke the 3.x hudson task. We should either disable this check for 3.x, or
disable the 3.x hudson <-- best!
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-3.x - Build # 694 - Failure
Build: https://builds.apache.org/job/Lucene-3.x/694/ No tests ran. Build Log (for compile errors): [...truncated 7030 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3335) testDistribSearch failure
[
https://issues.apache.org/jira/browse/SOLR-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249047#comment-13249047
]
Chris Male commented on SOLR-3335:
--
+1 to disabling these tests. They fail often in Jenkins and locally.
> testDistribSearch failure
> -
>
> Key: SOLR-3335
> URL: https://issues.apache.org/jira/browse/SOLR-3335
> Project: Solr
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.0
>
>
> Happened on my test machine. Is there a way to disable these tests if we
> cannot fix them? There are two three tests that fail most of the time and
> that apparently nobody knows how to fix (including me).
> There is also a typo in the error message (I'm away from home for Easter,
> can't do it now).
> {noformat}
> build 06-Apr-2012 16:11:54[junit] Testsuite:
> org.apache.solr.cloud.RecoveryZkTest
> build 06-Apr-2012 16:11:54[junit] Testcase:
> testDistribSearch(org.apache.solr.cloud.RecoveryZkTest): FAILED
> build 06-Apr-2012 16:11:54[junit] There are still nodes recoverying
> build 06-Apr-2012 16:11:54[junit]
> junit.framework.AssertionFailedError: There are still nodes recoverying
> build 06-Apr-2012 16:11:54[junit] at
> org.junit.Assert.fail(Assert.java:93)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:132)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:84)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:670)
> build 06-Apr-2012 16:11:54[junit] at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> build 06-Apr-2012 16:11:54[junit] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> build 06-Apr-2012 16:11:54[junit] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> build 06-Apr-2012 16:11:54[junit] at
> java.lang.reflect.Method.invoke(Method.java:597)
> build 06-Apr-2012 16:11:54[junit] at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> build 06-Apr-2012 16:11:54[junit] at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> build 06-Apr-2012 16:11:54[junit] at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> build 06-Apr-2012 16:11:54[junit] at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> build 06-Apr-2012 16:11:54[junit] at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> build 06-Apr-2012 16:11:54[junit] at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
> build 06-Apr-2012 16:11:54[junit] at
> org.junit.rules.RunRules.evaluate(RunRules.java:18)
> build 06-Apr-2012 16:11:54[junit] at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> build 06-Apr-2012 16:11:54[junit] at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
> build 06-Apr-2012 16:11:54[junit] at
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
> build 06-Apr-2012 16:11:54
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 12980 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12980/ No tests ran. Build Log (for compile errors): [...truncated 59 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249046#comment-13249046
]
Chris Male commented on LUCENE-3965:
+1 to this consolidation effort. I like the latest iteration layout.
I also agree with Steve that we should continue to support sub-modules. The
new layout already has a lot of modules under {{lucene/}} so I think its good
to continue to keep the analysis submodules under {{analysis/}}.
This whole process means we can improve the demo module more, so that it
actually demos all the other modules in some way.
{quote}
Right, i guess if there is something funky about them and we don't think they
belong as a top-level
module, then stuff can always go in the sandbox?
{quote}
+1. We should go over the remaining contribs as we did in the past and make
decisions about whether they're module worthy.
> consolidate all api modules in one place and un!@$# packaging for 4.0
> -
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 2198 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/2198/ No tests ran. Build Log (for compile errors): [...truncated 58 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe resolved LUCENE-3959.
-
Resolution: Fixed
Fix Version/s: 4.0
Assignee: Steven Rowe
Lucene Fields: New,Patch Available (was: New)
Committed to trunk.
Modified {{dev/nightly/hudson-settings.sh}} to check for @author tags right
after checking for no(n)commits in .java files.
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248938#comment-13248938
]
Steven Rowe commented on LUCENE-3959:
-
Hossman's Solr commit removing @author tags in July 2007:
http://svn.apache.org/viewvc?view=revision&revision=555343
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Priority: Trivial
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3543) Add previous versions to maven-metadata.xml files generated by 'ant generate-maven-artifacts'
[
https://issues.apache.org/jira/browse/LUCENE-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe resolved LUCENE-3543.
-
Resolution: Won't Fix
Lucene Fields: (was: New)
Maven artifacts are no longer pushed to repositories from the
internal-repository-structure-on-a-local-filesystem created by {{ant
generate-maven-artifacts}}. Instead:
* snapshot artifacts are uploaded to the ASF snapshot repository by Jenkins
nightly jobs via {{ant generate-maven-artifacts}} with properties
{{m2.repository.id}} and {{m2.repository.url}} defined such that the artifacts
go over the wire instead of being hosted by Jenkins; and
* release artifacts are staged to the ASF release repository via {{ant
stage-maven-artifacts}}: LUCENE-3964.
> Add previous versions to maven-metadata.xml files generated by 'ant
> generate-maven-artifacts'
> -
>
> Key: LUCENE-3543
> URL: https://issues.apache.org/jira/browse/LUCENE-3543
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 3.4, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>
> The {{generate-maven-artifacts}} target generates one {{maven-metadata.xml}}
> file per artifact. In a repository, these files should contain a list of all
> previous releases along with the current release, but because Maven Ant Tasks
> doesn't have access to these versions, it does not include them in the files
> it produces.
> Two possible solutions:
> # download Maven central's versions of the files prior to running
> {{generate-maven-artifacts}} and pre-populate the target local repository; or
> # post-process the files to include the previous versions - this would
> require some form of access to the previously released versions for each
> artifact being published
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: VOTE: Lucene/Solr 3.6 (take two)
+1 to release! Did all my testing again (cannot use smoke - windows, and as all others already did this - I do my own tests with my eyes and personal feeling for the risky parts - I don’t trust tools): Nothing different, except the small issues fixed and the licenses are correct. Sorry for noise today! I also compared package contents and filesizes; all fine! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Friday, April 06, 2012 7:27 PM > To: dev@lucene.apache.org > Subject: VOTE: Lucene/Solr 3.6 (take two) > > Artifacts here: http://s.apache.org/lusolr36rc1 > > I tested with smoketester, (including newly added checks), so here is my +1. > Note: smoketester currently does not support windows (use a linux system) > > -- > lucidimagination.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
[jira] [Commented] (LUCENE-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248887#comment-13248887
]
Robert Muir commented on LUCENE-3965:
-
{quote}
I would be more happy, if e.g. the Solr Tokenizer Factories would be part of
the analysis modules...
{quote}
But how is that related to this proposal?
here I am just talking about consolidating what we currently have on the
filesystem so its less confusing.
Separately, I happen to agree with you, but I can assure you nothing will
happen with regards to that
on this issue, why don't you assign or work on LUCENE-2510?
> consolidate all api modules in one place and un!@$# packaging for 4.0
> -
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248780#comment-13248780 ] Uwe Schindler commented on LUCENE-3965: --- I would be more happy, if e.g. the Solr Tokenizer Factories would be part of the analysis modules... So a equalness between lucene-core and solr would be fine. But on the other hand, factoring out the factories completely from Solr might be a good idea on the way to compoletely dynamic analyzer definitions like in Solr (see Hibernate Search, where you can define your Analyzer using Java Annotations -- that internally usre Solr's factories and import the solr.jar uselessly). Thats just a comment on the side, I just wanted to mention it. So the current solution is fine, given that we remove Factories from Solr and move them to the analysis modules (and add the abstract interface to Lucene core). > consolidate all api modules in one place and un!@$# packaging for 4.0 > - > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248775#comment-13248775 ] Steven Rowe commented on LUCENE-3965: - bq. I don't like the separation between Solr and Lucene, in my opinion, Solr should also be a module and the lucene dir vanished. Solr contribs should also be modules. I agree with Robert: one top-level dir per "product" makes sense to me. > consolidate all api modules in one place and un!@$# packaging for 4.0 > - > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248774#comment-13248774 ] Uwe Schindler commented on LUCENE-3965: --- I don't like the separation between Solr and Lucene, in my opinion, Solr should also be a module and the lucene dir vanished. Solr contribs should also be modules. But, the current solution is also fine, so +1 > consolidate all api modules in one place and un!@$# packaging for 4.0 > - > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3965: Summary: consolidate all api modules in one place and un!@$# packaging for 4.0 (was: Move lucene/core to modules/core, same with test-framework, etc) editing title to be more general... > consolidate all api modules in one place and un!@$# packaging for 4.0 > - > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248763#comment-13248763 ] Steven Rowe commented on LUCENE-3965: - bq. If the products are still going to be lucene/ and solr/ (and i think for simplicity for 4.0, that's really what it should be) +1 > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248761#comment-13248761
]
Robert Muir commented on LUCENE-3965:
-
That would also simplify packaging, as modules' currently go out of their way
to make their
own dist/ directories too: e.g. under analyzers/common:
{noformat}
{noformat}
Same goes with licensing (they have their own LICENSE.txt/NOTICE.txt's). If the
products
are still going to be lucene/ and solr/ (and i think for simplicity for 4.0,
that's really
what it should be) then we don't need this.
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248759#comment-13248759 ] Robert Muir commented on LUCENE-3965: - well we never had one build/ directory right? At least contrib modules build underneath lucene/'s build. The only reasons modules have their own build/'s is because they go out of their way to do this! So I agree with you, lets just nuke that and have one! > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248758#comment-13248758
]
Steven Rowe commented on LUCENE-3965:
-
Do you think we should keep one {{build/}} directory per new-style module? I
rather like the current {{ant clean}} under {{lucene/}} - boom, one directory,
done.
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248752#comment-13248752 ] Robert Muir commented on LUCENE-3965: - That was my concern too. Currently I'm not sure this harms anything, and its well organized. Additionally we have *quite a few* modules underneath analysis now, growing fast actually. So it could cause a mess in the future and i'm not sure any simplicity to the build would actually be worth it. > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248750#comment-13248750
]
Steven Rowe commented on LUCENE-3965:
-
{quote}
another idea: instead of having analysis/ with "submodules" underneath it,
we could flatten that too (like solr-dataimporthandler and
dataimporthandler-extras)
so we would have analysis-common, analysis-kuromoji, analysis-phonetic, etc.
Not sure if this really makes things simpler, but its flat. We don't have to do
it,
but maybe it could simplify the build and such to have this easy flat structure.
{quote}
+0 - while the current analysis sub-module structure only serves to
conceptually group them, rather than provide any technical benefit, I think we
may want sub-modules in the future, perhaps for technical reasons, but also to
get a handle on the [human chunking
limit|http://www.chambers.com.au/glossary/chunking_principle.php]: more than
5-9 or so "things" in one "place" and people's eyes glaze over...
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248747#comment-13248747 ] Robert Muir commented on LUCENE-3965: - So here's the current iteration: * lucene/ ** analysis/ ** benchmark/ ** core/ ** demo/ ** facet/ ** grouping/ ** highlighter/ ** join/ ** queries/ ** queryparser/ ** memory/ ** misc/ ** sandbox/ ** spatial/ ** suggest/ ** test-framework/ ** tools/ > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248741#comment-13248741 ] Robert Muir commented on LUCENE-3965: - i like this better too... quick iteration :) As far as the analyzers being 'nested' or 'flat' we could address that separately, i could go either way. But i think its much simpler to have at least our high level modules all in one place... thats really the point of this issue (title is misleading now) > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248720#comment-13248720
]
Steven Rowe commented on LUCENE-3965:
-
{quote}
bq. Like this? (i.e. everything under modules/, but modules/ under lucene/:
If we put it under lucene/ I would propose we wouldnt move core at all.
* lucene/
** core/
** demo/
** highlighter/
** analyzers/
** grouping/
** test-framework
...
{quote}
+1
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3335) testDistribSearch failure
testDistribSearch failure
-
Key: SOLR-3335
URL: https://issues.apache.org/jira/browse/SOLR-3335
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 4.0
Happened on my test machine. Is there a way to disable these tests if we cannot
fix them? There are two three tests that fail most of the time and that
apparently nobody knows how to fix (including me).
There is also a typo in the error message (I'm away from home for Easter, can't
do it now).
{noformat}
build 06-Apr-2012 16:11:54[junit] Testsuite:
org.apache.solr.cloud.RecoveryZkTest
build 06-Apr-2012 16:11:54[junit] Testcase:
testDistribSearch(org.apache.solr.cloud.RecoveryZkTest): FAILED
build 06-Apr-2012 16:11:54[junit] There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit]
junit.framework.AssertionFailedError: There are still nodes recoverying
build 06-Apr-2012 16:11:54[junit] at
org.junit.Assert.fail(Assert.java:93)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:132)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:84)
build 06-Apr-2012 16:11:54[junit] at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
build 06-Apr-2012 16:11:54[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
build 06-Apr-2012 16:11:54[junit] at
java.lang.reflect.Method.invoke(Method.java:597)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
build 06-Apr-2012 16:11:54[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
build 06-Apr-2012 16:11:54[junit] at
org.junit.rules.RunRules.evaluate(RunRules.java:18)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 06-Apr-2012 16:11:54[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
build 06-Apr-2012 16:11:54[junit] at
org.junit.runners.ParentRunner.access$000(ParentRunne
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248704#comment-13248704
]
Robert Muir commented on LUCENE-3965:
-
{quote}
Like this? (i.e. everything under modules/, but modules/ under lucene/:
{quote}
If we put it under lucene/ I would propose we wouldnt move core at all.
* lucene/
** core/
** demo/
** highlighter/
** analyzers/
** grouping/
** test-framework
...
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248696#comment-13248696 ] Robert Muir commented on LUCENE-3965: - another idea: instead of having analysis/ with "submodules" underneath it, we could flatten that too (like solr-dataimporthandler and dataimporthandler-extras) so we would have analysis-common, analysis-kuromoji, analysis-phonetic, etc. Not sure if this really makes things simpler, but its flat. We don't have to do it, but maybe it could simplify the build and such to have this easy flat structure. > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248688#comment-13248688
]
Steven Rowe commented on LUCENE-3965:
-
bq. an alternative thats still the same basic proposal is to move the current
modules/ underneath lucene/ (maybe thats less confusing? as then you see our
two "products" lucene/ and solr/ from the svn-tree).
Like this? (i.e. everything under {{modules/}}, but {{modules/}} under
{{lucene/}}:
* {{lucene/}}
** {{modules/}}
*** {{core/}}
*** {{sandbox/}}
*** {{test-framework}}
*** ...
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248686#comment-13248686
]
Robert Muir commented on LUCENE-3965:
-
{quote}
I guess it's simpler because instead lucene/ and its denizens (which we already
know and love), as well as modules/ (no packaging clue, thank you very much),
the problem is reduced to the one single great unknown.
{quote}
Well I started thinking about this when you restructured the lucene/ to have
"modules" underneath it
like "core", "test-framework", "tools"... it starts making it painfully obvious
we should combine
this stuff in some simple flattened structure that makes sense.
as far as SVN call it modules/, call it lucene/, I don't care. its our search
API product.
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248683#comment-13248683 ] Robert Muir commented on LUCENE-3965: - an alternative thats still the same basic proposal is to move the current modules/ underneath lucene/ (maybe thats less confusing? as then you see our two "products" lucene/ and solr/ from the svn-tree). > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3330) Show changes in plugin statistics across multiple requests
[ https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3330: Attachment: SOLR-3330-record-changes-ui.patch Here is a first crack at calling this through the UI. It uses blockUI to pause while you run other queris, then will update the UI when you click OK. I have it making all the right calls, but can not figure out how to reload the page with the new response. Stefan, can you take a look? thanks! > Show changes in plugin statistics across multiple requests > -- > > Key: SOLR-3330 > URL: https://issues.apache.org/jira/browse/SOLR-3330 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Ryan McKinley > Fix For: 4.0 > > Attachments: SOLR-3330-pluggins-diff.patch, > SOLR-3330-pluggins-diff.patch, SOLR-3330-record-changes-ui.patch > > > When debugging configuration and performance, I often: > 1. Look at stats values > 2. run some queries > 3. See how the stats values changed > This is fine, but is often a bit clunky and you have to really know what you > are looking for to see any changes. > It would be great if the 'plugins' page had a button that would make this > easier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248681#comment-13248681
]
Steven Rowe commented on LUCENE-3965:
-
bq. btw: I'm just bringing this up as an idea to go towards addressing the 4.0
packaging, in my opinion it makes sense and is simple. There might be other
solutions too though.
I guess it's simpler because instead {{lucene/}} and its denizens (which we
already know and love), as well as {{modules/}} (no packaging clue, thank you
very much), the problem is reduced to the one single great unknown.
bq. But truth be told, now is a GREAT time to figure this out as we look at
putting 3.x in bugfix mode. because we can fix this layout to be organized the
way we want and not pay the price of difficult svn merging.
Yes, if we are going to restructure, we should do it now.
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248680#comment-13248680 ] Robert Muir commented on LUCENE-3965: - some inspiration from ICU: http://source.icu-project.org/repos/icu/icu4j/trunk/main/classes/ They actually combine these all into one mega-jar still as they work towards modularization, but internally this is a similar thing there. > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248677#comment-13248677 ] Robert Muir commented on LUCENE-3965: - btw: I'm just bringing this up as an idea to go towards addressing the 4.0 packaging, in my opinion it makes sense and is simple. There might be other solutions too though. But truth be told, now is a GREAT time to figure this out as we look at putting 3.x in bugfix mode. because we can fix this layout to be organized the way we want and not pay the price of difficult svn merging. > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248672#comment-13248672
]
Robert Muir commented on LUCENE-3965:
-
{quote}
So top-level lucene/ directory would vanish?
{quote}
In my opinion, yes. and contrib/highlighter would sit under there too.
so instead of what you have today (which we dont even know how to package!),
when you unzip lucene.zip
you would see:
* analysis
* benchmark
* core
* demo
* facet
* grouping
* highlighter
* join
* queries
* queryparser
* memory
* misc
* sandbox
* spatial
* suggest
* test-framework
* tools
(i just combined the modules across lucene/, lucene/contrib, modules, and
alpha-sorted so you have an idea of what it looks like)
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248674#comment-13248674 ] Robert Muir commented on LUCENE-3965: - Right, i guess if there is something funky about them and we don't think they belong as a top-level module, then stuff can always go in the sandbox? > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248673#comment-13248673 ] Steven Rowe commented on LUCENE-3965: - and what about lucene contribs? all promoted to be modules? > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248668#comment-13248668
]
Steven Rowe commented on LUCENE-3965:
-
So top-level {{lucene/}} directory would vanish?
Solr would not be affected?
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248661#comment-13248661 ] Robert Muir commented on LUCENE-3965: - i think from release artifacts perspective, this would make a lot of sense: you would unzip and see: * core * analyzers * grouping * demo ... So people wouldnt be confused about where to go find stuff. > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3965) Move lucene/core to modules/core, same with test-framework, etc
Move lucene/core to modules/core, same with test-framework, etc --- Key: LUCENE-3965 URL: https://issues.apache.org/jira/browse/LUCENE-3965 Project: Lucene - Java Issue Type: Task Components: general/build Affects Versions: 4.0 Reporter: Robert Muir I think users get confused about how svn/source is structured, when in fact we are just producing a modular build. I think it would be more clear if the lucene stuff was underneath modules/, thats where our modular API is. we could still package this up as lucene.tar.gz if we want, and even name modules/core lucene-core.jar, but i think this would be a lot better organized than the current: * lucene * lucene/contrib * modules confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3109) Rename FieldsConsumer to InvertedFieldsConsumer
[ https://issues.apache.org/jira/browse/LUCENE-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248604#comment-13248604 ] Michael McCandless commented on LUCENE-3109: Hi Iulius, this patch is great: this rename is badly needed... I was able to apply the patch (resolving a few conflicts since the code has shifted since it was created), but... some things seem to be missing (eg InvertedFieldsProducer rename). How did you generate the patch? > Rename FieldsConsumer to InvertedFieldsConsumer > --- > > Key: LUCENE-3109 > URL: https://issues.apache.org/jira/browse/LUCENE-3109 > Project: Lucene - Java > Issue Type: Task > Components: core/codecs >Affects Versions: 4.0 >Reporter: Simon Willnauer >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3109.patch, LUCENE-3109.patch > > > The name FieldsConsumer is missleading here it really is an > InvertedFieldsConsumer and since we are extending codecs to consume > non-inverted Fields we should be clear here. Same applies to Fields.java as > well as FieldsProducer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3333) Create an option that allows a query to be cached, but not used for warming
[ https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248602#comment-13248602 ] Shawn Heisey commented on SOLR-: I never actually answered your first question. Yes, I do want most entries in the filter cache to be usable for autowarming. Most users have relatively few boolean clauses in their filter queries. Employees are the common exception. We get a few hundred boolean clauses in ours. Plans are being discussed to greatly reduce that, but I'm not sure we'll ever get away from it entirely. > Create an option that allows a query to be cached, but not used for warming > --- > > Key: SOLR- > URL: https://issues.apache.org/jira/browse/SOLR- > Project: Solr > Issue Type: New Feature >Affects Versions: 3.5, 4.0 >Reporter: Shawn Heisey > > The application that uses my Solr install builds complex filter queries for > employees because they have access to everything, whereas most users have > access to a small subset. > Because of this, autowarming on the filterCache can take 30-60 seconds even > though autoWarm is set to just 4 queries. > If we had a way (probably a localparam) to tell Solr to not use those filters > when autowarming, but to go ahead and put them in the filterCache and use > them until there's a new commit, that would eliminate this problem. > Employees might have their queries take longer, but regular users would not > be affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3333) Create an option that allows a query to be cached, but not used for warming
[ https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248579#comment-13248579 ] Shawn Heisey commented on SOLR-: I would like to have our application code tag those nasty employee filters with something that makes them ineligible for autowarming, but still eligible for caching, which would keep them around until the next commit. I am pretty sure our code is capable of knowing that the user is a special user, typically admin or system. An update cycle runs once a minute for the index as a whole, but changes are tracked on a per-shard basis. Commits on each shard are only done if something on that particular shard actually changes. The large shards where this is a problem typically go several minutes between commits, and that might extend to an hour or more. I will talk to our developers about using the cache=false localparam for now, but I am hoping for the ability to use the cache for those nasty filters but not include them for warming. Having recently toyed with the cache code (SOLR-2906), I know this may not be trivial. > Create an option that allows a query to be cached, but not used for warming > --- > > Key: SOLR- > URL: https://issues.apache.org/jira/browse/SOLR- > Project: Solr > Issue Type: New Feature >Affects Versions: 3.5, 4.0 >Reporter: Shawn Heisey > > The application that uses my Solr install builds complex filter queries for > employees because they have access to everything, whereas most users have > access to a small subset. > Because of this, autowarming on the filterCache can take 30-60 seconds even > though autoWarm is set to just 4 queries. > If we had a way (probably a localparam) to tell Solr to not use those filters > when autowarming, but to go ahead and put them in the filterCache and use > them until there's a new commit, that would eliminate this problem. > Employees might have their queries take longer, but regular users would not > be affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3326) Convert plugin documentation links to real links
[
https://issues.apache.org/jira/browse/SOLR-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-3326.
-
Resolution: Fixed
Assignee: Ryan McKinley
real links in #1310532
> Convert plugin documentation links to real links
>
>
> Key: SOLR-3326
> URL: https://issues.apache.org/jira/browse/SOLR-3326
> Project: Solr
> Issue Type: Improvement
> Components: web gui
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: SOLR-3326-convert-links.patch,
> SOLR-3326-convert-links.patch, SOLR-3326-convert-links.patch
>
>
> Right now when we show the plugin info, links are just plaintext. For:
> http://localhost:8983/solr/#/singlecore/plugins/other?entry=org.apache.solr.handler.component.QueryElevationComponent
> we see:
> {code}
> src: $URL:
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/QueryElevationComponent.java
> $
> docs: http://wiki.apache.org/solr/QueryElevationComponent
> {code}
> It would be great if that actually linked to the URLS.
> perhaps using something like:
> https://code.google.com/p/jquery-linkifier/source/browse/jquery.gn.linkifier.js
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3328) executable bits of shellscripts in solr source release
[ https://issues.apache.org/jira/browse/SOLR-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248561#comment-13248561 ] Uwe Schindler edited comment on SOLR-3328 at 4/6/12 6:16 PM: - Yes, it also works for ZIP. I checked Solr's build.xml: It already does what I propose (haveing several tarfilesets and zipfilesets). But it looks like it only sets mode to 755 for example/**.sh, not globally. So the fix is to extend that to include *all* .sh files (just change some properties). I checked both that TGZ and ZIP files for 3.x, too - they have (partly) incorrect attributes (binary tgz is correct, it has +x on example post.sh), so something is wrong with the src filesets (I think they are outdated as they dont respect the root). The files in scripts have no *.sh extension but are still shell scripts. Those have no 755, too. I will look into this and provide patch fro trunk. 3.x is too late. was (Author: thetaphi): Yes, it also works for ZIP. I checked Solr's build.xml: It already does what I propose (haveing several tarfilesets and zipfilesets). But it looks like it only sets mode to 755 for example/**.sh, not globally. So the fix is to extend that to include *all* .sh files (just change some properties). I checked both that TGZ and ZIP files for 3.x, too - they have incorrect attributes, so something is wrong with the filesets (I think they are outdated as they dont respect the root). The files in scripts have no *.sh extension but are still shell scripts. Those have no 755, too. I will look into this and provide patch fro trunk. 3.x is too late. > executable bits of shellscripts in solr source release > -- > > Key: SOLR-3328 > URL: https://issues.apache.org/jira/browse/SOLR-3328 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > HossmanSays: in the solr src releases, some shell scripts are not executable > by default. > I don't know if we can improve this? Maybe its an svn prop? > Maybe something needs to be specified to the tar/zip process? > Currently the 'source release' is really an svn export... > Personally i always do 'sh foo.sh' rather than './foo.sh', > but if it makes it more user-friendly we should figure it out > Just opening the issue since we don't forget about it, I think solr cloud > adds some more shell scripts so we should at least figure out what we want to > do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3328) executable bits of shellscripts in solr source release
[ https://issues.apache.org/jira/browse/SOLR-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248561#comment-13248561 ] Uwe Schindler commented on SOLR-3328: - Yes, it also works for ZIP. I checked Solr's build.xml: It already does what I propose (haveing several tarfilesets and zipfilesets). But it looks like it only sets mode to 755 for example/**.sh, not globally. So the fix is to extend that to include *all* .sh files (just change some properties). I checked both that TGZ and ZIP files for 3.x, too - they have incorrect attributes, so something is wrong with the filesets (I think they are outdated as they dont respect the root). The files in scripts have no *.sh extension but are still shell scripts. Those have no 755, too. I will look into this and provide patch fro trunk. 3.x is too late. > executable bits of shellscripts in solr source release > -- > > Key: SOLR-3328 > URL: https://issues.apache.org/jira/browse/SOLR-3328 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > HossmanSays: in the solr src releases, some shell scripts are not executable > by default. > I don't know if we can improve this? Maybe its an svn prop? > Maybe something needs to be specified to the tar/zip process? > Currently the 'source release' is really an svn export... > Personally i always do 'sh foo.sh' rather than './foo.sh', > but if it makes it more user-friendly we should figure it out > Just opening the issue since we don't forget about it, I think solr cloud > adds some more shell scripts so we should at least figure out what we want to > do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3330) Show changes in plugin statistics across multiple requests
[ https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3330: Attachment: SOLR-3330-pluggins-diff.patch Added a test to show the statistics change across multiple requests. I will commit this soon, and we can continue work on the UI side of things > Show changes in plugin statistics across multiple requests > -- > > Key: SOLR-3330 > URL: https://issues.apache.org/jira/browse/SOLR-3330 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Ryan McKinley > Fix For: 4.0 > > Attachments: SOLR-3330-pluggins-diff.patch, > SOLR-3330-pluggins-diff.patch > > > When debugging configuration and performance, I often: > 1. Look at stats values > 2. run some queries > 3. See how the stats values changed > This is fine, but is often a bit clunky and you have to really know what you > are looking for to see any changes. > It would be great if the 'plugins' page had a button that would make this > easier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3955) smokeTestRelease should test solr example
[ https://issues.apache.org/jira/browse/LUCENE-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248530#comment-13248530 ] Robert Muir commented on LUCENE-3955: - Thanks Mike! This is a great improvement, I've already made use of it. > smokeTestRelease should test solr example > - > > Key: LUCENE-3955 > URL: https://issues.apache.org/jira/browse/LUCENE-3955 > Project: Lucene - Java > Issue Type: Improvement > Components: general/build >Reporter: Robert Muir >Assignee: Michael McCandless > Fix For: 4.0 > > > I think most anyone reviewing the solr artifacts will do this, > so really the RM has to do it manually: > but we can test 'ant example' from the source dist + java -jar start.jar from > solr/example > (or/and 'ant run-example'), and also java -jar start.jar from the binary > distribution. > some basic checks we can do are to run the test_utf8.sh, and to index the > example docs > (post.jar/post.sh the docs in exampledocs) then do a search. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3316) Distributed Grouping fails in some scenarios.
[ https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen updated SOLR-3316: Fix Version/s: 3.6 > Distributed Grouping fails in some scenarios. > - > > Key: SOLR-3316 > URL: https://issues.apache.org/jira/browse/SOLR-3316 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 3.4, 3.5 > Environment: Windows 7, JDK 6u26 >Reporter: Cody Young >Assignee: Martijn van Groningen >Priority: Blocker > Labels: distributed, grouping > Fix For: 3.6, 4.0 > > Attachments: SOLR-3316-3x.patch, SOLR-3316-3x.patch, SOLR-3316.patch, > TestDistributedGrouping.java.patch > > > During a distributed grouping request, if rows is set to 0 a 500 error is > returned. > If groups are unique to a shard and the row count is set to 1, then the > matches number is only the matches from one shard. > I've put together a failing test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3955) smokeTestRelease should test solr example
[ https://issues.apache.org/jira/browse/LUCENE-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-3955. Resolution: Fixed This was fixed w/ SOLR-3331. > smokeTestRelease should test solr example > - > > Key: LUCENE-3955 > URL: https://issues.apache.org/jira/browse/LUCENE-3955 > Project: Lucene - Java > Issue Type: Improvement > Components: general/build >Reporter: Robert Muir >Assignee: Michael McCandless > Fix For: 4.0 > > > I think most anyone reviewing the solr artifacts will do this, > so really the RM has to do it manually: > but we can test 'ant example' from the source dist + java -jar start.jar from > solr/example > (or/and 'ant run-example'), and also java -jar start.jar from the binary > distribution. > some basic checks we can do are to run the test_utf8.sh, and to index the > example docs > (post.jar/post.sh the docs in exampledocs) then do a search. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2358) Distributing Indexing
[ https://issues.apache.org/jira/browse/SOLR-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248516#comment-13248516 ] Michael Garski commented on SOLR-2358: -- I have a use case for shard distribution based on something other than a hash on the document's unique id and was wondering if there are any thoughts as to how such functionality should be implemented? It looks like SOLR-2341 (Shard distribution policy) and SOLR-2592 (pluggable shard lookup mechanism) complement each other for indexing and searching and was wondering if anyone had thoughts as to the approach to take. > Distributing Indexing > - > > Key: SOLR-2358 > URL: https://issues.apache.org/jira/browse/SOLR-2358 > Project: Solr > Issue Type: New Feature > Components: SolrCloud, update >Reporter: William Mayor >Priority: Minor > Fix For: 4.0 > > Attachments: 2shard4server.jpg, SOLR-2358.patch, SOLR-2358.patch, > apache-solr-noggit-r1211150.jar, zookeeper-3.3.4.jar > > > The indexing side of SolrCloud - the goal of this issue is to provide > durable, fault tolerant indexing to an elastic cluster of Solr instances. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
VOTE: Lucene/Solr 3.6 (take two)
Artifacts here: http://s.apache.org/lusolr36rc1 I tested with smoketester, (including newly added checks), so here is my +1. Note: smoketester currently does not support windows (use a linux system) -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2155 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2155/ 2 tests failed. REGRESSION: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch Error Message: java.lang.AssertionError: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane FieldCache usage(s) found expected:<0> but was:<1> Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane FieldCache usage(s) found expected:<0> but was:<1> at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:819) at org.apache.lucene.util.LuceneTestCase.access$900(LuceneTestCase.java:138) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:676) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) Caused by: java.lang.AssertionError: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane FieldCache usage(s) found expected:<0> but was:<1> 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.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:930) at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:809) ... 28 more FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: ERROR: SolrIndexSearcher opens=93 closes=91 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=93 closes=91 at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner$3.addError(JUnitTestRunner.java:974) at junit.framework.TestResult.addError(TestResult.java:38) at junit.framework.JUnit4TestAdapterCache$1.testFailure(JUnit4TestAdapterCache.java:51) at org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100) at org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41) at org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97) at org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26) at org.junit.runners.ParentRunner.run(ParentRunner.java:306) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.
[jira] [Updated] (SOLR-3329) Don't use svn:properties Id or Revision in SolrInfoMBean
[
https://issues.apache.org/jira/browse/SOLR-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-3329:
Priority: Minor (was: Major)
Summary: Don't use svn:properties Id or Revision in SolrInfoMBean (was:
Use consistent svn:keywords)
I'm changing the ticket name so it more accurately reflects the changes.
Robert.. we can look at the HeadURL issue in a different ticket. I think
keeping the URL in the bean is useful -- perhaps we just need to remove the
property from things that are not MBeans?
> Don't use svn:properties Id or Revision in SolrInfoMBean
>
>
> Key: SOLR-3329
> URL: https://issues.apache.org/jira/browse/SOLR-3329
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-3329-svn-keywords.patch
>
>
> In solr, use use svn:keywords haphazardly
> We have lots of places with:
> {code}
> svn propset svn:keywords "Date Author Id Revision HeadURL" *.java
> {code}
> In LUCENE-3923, there is a suggestion to get rid of many of these.
> The MBeans interface often exposes HeadURL, but we likely want to get rid of
> the rest
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3964) Stage Maven release artifacts
[ https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3964: Attachment: LUCENE-3964.patch Patch fixing a bug in the naming of the Solr war's POM. After fixing the POM name problem, I successfully staged Solr 3.6.0 RC0 here: [https://repository.apache.org/content/repositories/orgapachelucene-016/]. I think it's ready to commit, but I'll wait until tomorrow to do so. > Stage Maven release artifacts > - > > Key: LUCENE-3964 > URL: https://issues.apache.org/jira/browse/LUCENE-3964 > Project: Lucene - Java > Issue Type: New Feature > Components: general/build >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe >Priority: Critical > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3964.patch, LUCENE-3964.patch > > > We need a way to stage Maven artifacts to the Apache release repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3316) Distributed Grouping fails in some scenarios.
[ https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved SOLR-3316. --- Resolution: Fixed Assignee: Martijn van Groningen (was: Robert Muir) Thanks Cody! > Distributed Grouping fails in some scenarios. > - > > Key: SOLR-3316 > URL: https://issues.apache.org/jira/browse/SOLR-3316 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 3.4, 3.5 > Environment: Windows 7, JDK 6u26 >Reporter: Cody Young >Assignee: Martijn van Groningen >Priority: Blocker > Labels: distributed, grouping > Fix For: 4.0 > > Attachments: SOLR-3316-3x.patch, SOLR-3316-3x.patch, SOLR-3316.patch, > TestDistributedGrouping.java.patch > > > During a distributed grouping request, if rows is set to 0 a 500 error is > returned. > If groups are unique to a shard and the row count is set to 1, then the > matches number is only the matches from one shard. > I've put together a failing test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3316) Distributed Grouping fails in some scenarios.
[ https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248462#comment-13248462 ] Robert Muir commented on SOLR-3316: --- I'll take the backport. > Distributed Grouping fails in some scenarios. > - > > Key: SOLR-3316 > URL: https://issues.apache.org/jira/browse/SOLR-3316 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 3.4, 3.5 > Environment: Windows 7, JDK 6u26 >Reporter: Cody Young >Assignee: Robert Muir >Priority: Blocker > Labels: distributed, grouping > Fix For: 4.0 > > Attachments: SOLR-3316-3x.patch, SOLR-3316-3x.patch, SOLR-3316.patch, > TestDistributedGrouping.java.patch > > > During a distributed grouping request, if rows is set to 0 a 500 error is > returned. > If groups are unique to a shard and the row count is set to 1, then the > matches number is only the matches from one shard. > I've put together a failing test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3316) Distributed Grouping fails in some scenarios.
[ https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir reassigned SOLR-3316: - Assignee: Robert Muir (was: Martijn van Groningen) > Distributed Grouping fails in some scenarios. > - > > Key: SOLR-3316 > URL: https://issues.apache.org/jira/browse/SOLR-3316 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 3.4, 3.5 > Environment: Windows 7, JDK 6u26 >Reporter: Cody Young >Assignee: Robert Muir >Priority: Blocker > Labels: distributed, grouping > Fix For: 4.0 > > Attachments: SOLR-3316-3x.patch, SOLR-3316-3x.patch, SOLR-3316.patch, > TestDistributedGrouping.java.patch > > > During a distributed grouping request, if rows is set to 0 a 500 error is > returned. > If groups are unique to a shard and the row count is set to 1, then the > matches number is only the matches from one shard. > I've put together a failing test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3964) Stage Maven release artifacts
[ https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248444#comment-13248444 ] Robert Muir commented on LUCENE-3964: - OK cool, my questions are mostly about process (not technicals). As far as adding scripts to deploy to maven, I'm happy with whatever you figure out. I was planning on bailing on this part and leaving it to more capable hands anyway... :) > Stage Maven release artifacts > - > > Key: LUCENE-3964 > URL: https://issues.apache.org/jira/browse/LUCENE-3964 > Project: Lucene - Java > Issue Type: New Feature > Components: general/build >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe >Priority: Critical > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3964.patch > > > We need a way to stage Maven artifacts to the Apache release repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3316) Distributed Grouping fails in some scenarios.
[ https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248442#comment-13248442 ] Robert Muir commented on SOLR-3316: --- Given mike's review, i think this should be committed to 3.x > Distributed Grouping fails in some scenarios. > - > > Key: SOLR-3316 > URL: https://issues.apache.org/jira/browse/SOLR-3316 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 3.4, 3.5 > Environment: Windows 7, JDK 6u26 >Reporter: Cody Young >Assignee: Martijn van Groningen >Priority: Blocker > Labels: distributed, grouping > Fix For: 4.0 > > Attachments: SOLR-3316-3x.patch, SOLR-3316-3x.patch, SOLR-3316.patch, > TestDistributedGrouping.java.patch > > > During a distributed grouping request, if rows is set to 0 a 500 error is > returned. > If groups are unique to a shard and the row count is set to 1, then the > matches number is only the matches from one shard. > I've put together a failing test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3964) Stage Maven release artifacts
[ https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248434#comment-13248434 ] Steven Rowe commented on LUCENE-3964: - bq. Confused about the component: build. Feel free to change it to a more appropriate component (not sure what that would be). bq. I certainily hope the build need not be changed to do this (certainly not for 3.6) No, it does not. As I mentioned in my previous post on this issue, the patch is against trunk, and it works against your 3.6.0 RC0 (Lucene only at this point; Solr still needs to be tested.) bq. I think we should generate an RC like we do now, putting it on p.a.o, vote on it, and this is merely a deployment issue. +1 bq. If there are any scripts involved in this, i think they should go in dev-tools instead, (like other release deployment scripts)? Yup, that's what I've done. This is a work in progress - please review if you're interested! > Stage Maven release artifacts > - > > Key: LUCENE-3964 > URL: https://issues.apache.org/jira/browse/LUCENE-3964 > Project: Lucene - Java > Issue Type: New Feature > Components: general/build >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe >Priority: Critical > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3964.patch > > > We need a way to stage Maven artifacts to the Apache release repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3964) Stage Maven release artifacts
[ https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248438#comment-13248438 ] Steven Rowe commented on LUCENE-3964: - bq. But again: this is for deployment correct? Yes. bq. I don't want to change our release process for 3.6 +1 > Stage Maven release artifacts > - > > Key: LUCENE-3964 > URL: https://issues.apache.org/jira/browse/LUCENE-3964 > Project: Lucene - Java > Issue Type: New Feature > Components: general/build >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe >Priority: Critical > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3964.patch > > > We need a way to stage Maven artifacts to the Apache release repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3964) Stage Maven release artifacts
[ https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248432#comment-13248432 ] Robert Muir commented on LUCENE-3964: - But again: this is for deployment correct? I don't want to change our release process for 3.6 > Stage Maven release artifacts > - > > Key: LUCENE-3964 > URL: https://issues.apache.org/jira/browse/LUCENE-3964 > Project: Lucene - Java > Issue Type: New Feature > Components: general/build >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe >Priority: Critical > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3964.patch > > > We need a way to stage Maven artifacts to the Apache release repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3964) Stage Maven release artifacts
[
https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3964:
Attachment: LUCENE-3964.patch
Trunk patch for a new target {{stage-maven-artifacts}} in
{{lucene/common_build.xml}}, which:
# calls a Perl script in {{dev-tools/scripts/}} to recurse over the Maven dist
directory (specified via property {{maven.dist.dir}}, which has default values
under {{lucene/}} and {{solr/}}) to find Maven artifacts, and then write an Ant
build file (by default {{./build/stage_maven_build.xml}}); and
# invokes the {{stage-maven}} target in the Ant build file produced by the Perl
script to stage each artifact, along with its POM, sources and javadoc jars,
and signatures for each, to the staging repository specified in properties
{{m2.repository.id}} and {{m2.repository.url}}.
Also included in the patch: a shell script to crawl Maven release distribution
artifacts using {{wget}}: {{dev-tools/scripts/crawl.maven.release.dist.sh}}
I have successfully run this target on the Lucene artifacts in Robert's RC0
release candidate, and then "closed" [the resulting staging
repository|https://repository.apache.org/content/repositories/orgapachelucene-014/]
("closing" disallows further uploads to the staging repository, and also does
some quality checks, e.g. valid POMs, valid signatures) using this cmdline:
{noformat}ant clean stage-maven-artifacts -Dmaven.dist.dir=~/temp/lucene
-Dm2.repository.id=apache.releases.https
-Dm2.repository.url=https://repository.apache.org/service/local/staging/deploy/maven2{noformat}
The process took a little less than ten minutes.
Although this patch is against trunk, it will work on any version's release, so
I think it won't be necessary to commit it to branch_3x.
Left to do: test against the RC0 Solr artifacts.
> Stage Maven release artifacts
> -
>
> Key: LUCENE-3964
> URL: https://issues.apache.org/jira/browse/LUCENE-3964
> Project: Lucene - Java
> Issue Type: New Feature
> Components: general/build
>Affects Versions: 3.6, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Critical
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3964.patch
>
>
> We need a way to stage Maven artifacts to the Apache release repository.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Implementing SOLR - 1093
Hi all, I am finding a need to merge the results of multiple queries to accomplish a functionality similar to this https://issues.apache.org/jira/browse/SOLR-1093. The rules are: 1. Make query 1 2. If results returned by query1 is less than a certain threshold, then Make query 2 Extending this idea, I want to be able to create a query chain, i.e, provide a functionality where you could specify n queries and n-1 thresholds in a single url. Start querying in the order from 1 to n until one of them produces results that exceed the threshold. I have got a proof of concept ready where I just modified doFilter function in SolrDispatchFilter.java. I am thinking about writing a MultiSelectHandler that would handle the multiselect functionality. There are three designs that come to my mind. 1. I could add a wrapper in the doFilter that would create muliple SearchHandler's and run them in parallel and merge them into one. 2. I could have a MultiSearch handler that derives from the RequestHandlerBase. MultiSearchHandler would compose the List of SearchHandler objects and execute them. 3. MultiSearchHandler could compose multiple SearchComponents and execute them. PS: These n queries and n threshold are passed on a single url and each of them could use different request handlers and therefore take a different set of parameters. By threshold I mean the count of results returned(hits/NumFound). Also, this new functionality is just a start to many. It would help us execute queries in parallel and come up with various flavours like just send two queries and merge the results of two etc. Thank you, Karthick
[jira] [Commented] (LUCENE-3964) Stage Maven release artifacts
[ https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248408#comment-13248408 ] Robert Muir commented on LUCENE-3964: - Confused about the component: build. I certainily hope the build need not be changed to do this (certainly not for 3.6) I think we should generate an RC like we do now, putting it on p.a.o, vote on it, and this is merely a deployment issue. If there are any scripts involved in this, i think they should go in dev-tools instead, (like other release deployment scripts)? > Stage Maven release artifacts > - > > Key: LUCENE-3964 > URL: https://issues.apache.org/jira/browse/LUCENE-3964 > Project: Lucene - Java > Issue Type: New Feature > Components: general/build >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe >Priority: Critical > Fix For: 3.6, 4.0 > > > We need a way to stage Maven artifacts to the Apache release repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3964) Stage Maven release artifacts
Stage Maven release artifacts - Key: LUCENE-3964 URL: https://issues.apache.org/jira/browse/LUCENE-3964 Project: Lucene - Java Issue Type: New Feature Components: general/build Affects Versions: 3.6, 4.0 Reporter: Steven Rowe Assignee: Steven Rowe Priority: Critical Fix For: 3.6, 4.0 We need a way to stage Maven artifacts to the Apache release repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3319) Improve DataImportHandler status response
[
https://issues.apache.org/jira/browse/SOLR-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248402#comment-13248402
]
Shawn Heisey commented on SOLR-3319:
Here are some general ideas, preliminary because I have not taken a close look
at the code yet. For reference, here is a completed status response on a
full-import from 3.5.0:
{code}
0
0
dih-config.xml
idle
1
11287894
0
2012-04-03 17:38:01
Indexing completed. Added/Updated: 11287894 documents. Deleted 0
documents.
2012-04-03 20:16:32
11287894
2:38:31.314
This response format is experimental. It is likely to
change in the future.
{code}
I was thinking it might be a good idea to have two response sections in
addition to the echoParams section already mentioned - one for a human readable
response and one for a relatively terse machine readable response. The human
readable version would be fairly open to change, and could include extra
verbiage so it's very understandable for a person.
The machine readable version would have more elements, each of which is very
simple, probably just a numeric value or a true/false indicator. A design
decision needs to be made early - do we include all elements in every response
(with the value set to zero, blank, or false), even if they don't apply to the
current status? My first instinct is to include all elements, but maybe that's
wrong.
> Improve DataImportHandler status response
> -
>
> Key: SOLR-3319
> URL: https://issues.apache.org/jira/browse/SOLR-3319
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
>Affects Versions: 3.5, 4.0
>Reporter: Shawn Heisey
>Priority: Minor
> Fix For: 4.0
>
>
> The DataImportHandler has some oddities and inconsistencies in its status
> response that make it difficult to write code that parses DIH status,
> especially if both full-import and delta-import are required. See SOLR-2729.
> I would like to have a discussion where we come up with a well-defined and
> consistent format that can be used programatically as well as be human
> readable, and then I can implement it, or someone else can if they really
> want to. I think it would be very useful if the status response included all
> parameters that went into the import request, like echoParams in the query
> interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3333) Create an option that allows a query to be cached, but not used for warming
[ https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248385#comment-13248385 ] Erick Erickson commented on SOLR-: -- Are there other auto-warming queries you want to have done? Because it almost sounds like you just want to turn off autowarming in the filter cache. Or if they're unlikely to be re-used anyway, would it work to set cache=false on the original fq? > Create an option that allows a query to be cached, but not used for warming > --- > > Key: SOLR- > URL: https://issues.apache.org/jira/browse/SOLR- > Project: Solr > Issue Type: New Feature >Affects Versions: 3.5, 4.0 >Reporter: Shawn Heisey > > The application that uses my Solr install builds complex filter queries for > employees because they have access to everything, whereas most users have > access to a small subset. > Because of this, autowarming on the filterCache can take 30-60 seconds even > though autoWarm is set to just 4 queries. > If we had a way (probably a localparam) to tell Solr to not use those filters > when autowarming, but to go ahead and put them in the filterCache and use > them until there's a new commit, that would eliminate this problem. > Employees might have their queries take longer, but regular users would not > be affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3332) How to index a range of values in solr
[ https://issues.apache.org/jira/browse/SOLR-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-3332. -- Resolution: Not A Problem First, please ask questions like this on the Solr user's list rather than raising a JIRA, JIRAs are intended for code development. But in your case you can index a min_voltage as 10 and a max_voltage as 240. Now you just form queries (or filter queries, fq) like min_voltage:[* TO 110] AND max_voltage:[110 TO *] > How to index a range of values in solr > > > Key: SOLR-3332 > URL: https://issues.apache.org/jira/browse/SOLR-3332 > Project: Solr > Issue Type: Task >Reporter: mohamed badawi > > I have equipments site , need to index equipment specifications > Some of specifications are range of values > for example > i have an equipment , have minimum voltage 10 v and maximum voltage 220 v > i need to index it . so when a user search for equipment with 110 v can find > this one in the results > TY -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3316) Distributed Grouping fails in some scenarios.
[ https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248343#comment-13248343 ] Michael McCandless commented on SOLR-3316: -- Patch looks good! I guess it's OK to make the hard change to the EndResultTransformer interface... (it's marked @experimental). > Distributed Grouping fails in some scenarios. > - > > Key: SOLR-3316 > URL: https://issues.apache.org/jira/browse/SOLR-3316 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 3.4, 3.5 > Environment: Windows 7, JDK 6u26 >Reporter: Cody Young >Assignee: Martijn van Groningen >Priority: Blocker > Labels: distributed, grouping > Fix For: 4.0 > > Attachments: SOLR-3316-3x.patch, SOLR-3316-3x.patch, SOLR-3316.patch, > TestDistributedGrouping.java.patch > > > During a distributed grouping request, if rows is set to 0 a 500 error is > returned. > If groups are unique to a shard and the row count is set to 1, then the > matches number is only the matches from one shard. > I've put together a failing test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: Lucene/Solr 3.6
On Fri, Apr 6, 2012 at 9:15 AM, Walter Underwood wrote: > Other changes to the build have been mentioned in CHANGES.txt. --wunder > Doesn't matter. As release manager I have to be extremely careful about which changes go in and which don't. Licensing/Legal stuff: respin with no questions. Packaging bugs: if its a serious problem, we need it fixed. bugs in the code: case by case basis depending upon severity and risk of the patch Missing documentation: welcome to lucene/solr :). Can't just let any old documentation patch go through, because it itself can create additional documentation bugs. Not to pick on Uwe but see his first patch to the issue he created for this (https://issues.apache.org/jira/browse/LUCENE-3962) Had I not reviewed this, it would have only *added confusion* to the solr release. -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3334) fix NOTICE.txt handling for solr source release
fix NOTICE.txt handling for solr source release --- Key: SOLR-3334 URL: https://issues.apache.org/jira/browse/SOLR-3334 Project: Solr Issue Type: Task Reporter: Robert Muir Priority: Blocker Fix For: 4.0 Followup to SOLR-3331 for 4.0. 4.0 is more complicated because of modules and might need a better solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3963) improve smoketester to work on windows
improve smoketester to work on windows -- Key: LUCENE-3963 URL: https://issues.apache.org/jira/browse/LUCENE-3963 Project: Lucene - Java Issue Type: Task Reporter: Robert Muir After the changes in SOLR-3331, the smoketester won't work on windows (things like path separators of : or ;). Not really critical, people will just have to smoketest on unix-like machines. But it would be more convenient for testers on windows machines if it worked there too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3331) solr NOTICE.txt is missing information
[
https://issues.apache.org/jira/browse/SOLR-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved SOLR-3331.
---
Resolution: Fixed
> solr NOTICE.txt is missing information
> --
>
> Key: SOLR-3331
> URL: https://issues.apache.org/jira/browse/SOLR-3331
> Project: Solr
> Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: SOLR-3331.patch, SOLR-3331.patch
>
>
> Solr depends on some modules from lucene, and is released separately (as a
> source release including lucene),
> thus its NOTICE.txt has a lucene section which includes notices from lucene:
> {noformat}
> =
> == Apache Lucene Notice ==
> =
> {noformat}
> however, its missing the IPADIC (which is required to be there).
> Furthermore, there is no way to check this, except via manual inspection.
> This gets complicated in 4.0 because of modularization, but we need to fix the
> 3.6 situation in order to release (hence, this issue is set to 3.6 only and
> we can open a separate issue for 4.0 and discuss things like modules there,
> its irrelevant here).
> My proposal for *3.6* is:
> 1. add the IPADIC notice
> 2. have smoketester.py look for this specific block of text indicating
>the notices from lucene, and cross check them to ensure everything is
> consistent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3331) solr NOTICE.txt is missing information
[
https://issues.apache.org/jira/browse/SOLR-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248334#comment-13248334
]
Robert Muir commented on SOLR-3331:
---
Thanks also for the smokeTester.py changes.
I'm going to commit this to fix licensing.
Note: the solr example test is going to be broken on windows,
but thats ok, the smoketester is just a tool and is not part of the release
(bugs in it cannot block releases).
> solr NOTICE.txt is missing information
> --
>
> Key: SOLR-3331
> URL: https://issues.apache.org/jira/browse/SOLR-3331
> Project: Solr
> Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: SOLR-3331.patch, SOLR-3331.patch
>
>
> Solr depends on some modules from lucene, and is released separately (as a
> source release including lucene),
> thus its NOTICE.txt has a lucene section which includes notices from lucene:
> {noformat}
> =
> == Apache Lucene Notice ==
> =
> {noformat}
> however, its missing the IPADIC (which is required to be there).
> Furthermore, there is no way to check this, except via manual inspection.
> This gets complicated in 4.0 because of modularization, but we need to fix the
> 3.6 situation in order to release (hence, this issue is set to 3.6 only and
> we can open a separate issue for 4.0 and discuss things like modules there,
> its irrelevant here).
> My proposal for *3.6* is:
> 1. add the IPADIC notice
> 2. have smoketester.py look for this specific block of text indicating
>the notices from lucene, and cross check them to ensure everything is
> consistent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3331) solr NOTICE.txt is missing information
[
https://issues.apache.org/jira/browse/SOLR-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated SOLR-3331:
--
Attachment: SOLR-3331.patch
Mike's patch, for 3.x, with fixed NOTICE.txt and smoketester-checks.
> solr NOTICE.txt is missing information
> --
>
> Key: SOLR-3331
> URL: https://issues.apache.org/jira/browse/SOLR-3331
> Project: Solr
> Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: SOLR-3331.patch, SOLR-3331.patch
>
>
> Solr depends on some modules from lucene, and is released separately (as a
> source release including lucene),
> thus its NOTICE.txt has a lucene section which includes notices from lucene:
> {noformat}
> =
> == Apache Lucene Notice ==
> =
> {noformat}
> however, its missing the IPADIC (which is required to be there).
> Furthermore, there is no way to check this, except via manual inspection.
> This gets complicated in 4.0 because of modularization, but we need to fix the
> 3.6 situation in order to release (hence, this issue is set to 3.6 only and
> we can open a separate issue for 4.0 and discuss things like modules there,
> its irrelevant here).
> My proposal for *3.6* is:
> 1. add the IPADIC notice
> 2. have smoketester.py look for this specific block of text indicating
>the notices from lucene, and cross check them to ensure everything is
> consistent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: Lucene/Solr 3.6
Other changes to the build have been mentioned in CHANGES.txt. --wunder On Apr 6, 2012, at 4:22 AM, Robert Muir wrote: > On Fri, Apr 6, 2012 at 6:55 AM, Uwe Schindler wrote: >> Then please remove the directory refactoring also from CHANGES.txt. >> >> This is still a blocker to me. It should not be *documented* in the >> CHNAGES.txt, I said it should be mentione: >> > > Thats ok that we don't agree here. Fortunately, releases cannot be vetoed. > > -- > lucidimagination.com > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3331) solr NOTICE.txt is missing information
[
https://issues.apache.org/jira/browse/SOLR-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated SOLR-3331:
-
Attachment: SOLR-3331.patch
Patch for smoke tester... it includes NOTICE checking and a bunch of other
additions.. not sure it works yet!
> solr NOTICE.txt is missing information
> --
>
> Key: SOLR-3331
> URL: https://issues.apache.org/jira/browse/SOLR-3331
> Project: Solr
> Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: SOLR-3331.patch
>
>
> Solr depends on some modules from lucene, and is released separately (as a
> source release including lucene),
> thus its NOTICE.txt has a lucene section which includes notices from lucene:
> {noformat}
> =
> == Apache Lucene Notice ==
> =
> {noformat}
> however, its missing the IPADIC (which is required to be there).
> Furthermore, there is no way to check this, except via manual inspection.
> This gets complicated in 4.0 because of modularization, but we need to fix the
> 3.6 situation in order to release (hence, this issue is set to 3.6 only and
> we can open a separate issue for 4.0 and discuss things like modules there,
> its irrelevant here).
> My proposal for *3.6* is:
> 1. add the IPADIC notice
> 2. have smoketester.py look for this specific block of text indicating
>the notices from lucene, and cross check them to ensure everything is
> consistent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3316) Distributed Grouping fails in some scenarios.
[ https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen updated SOLR-3316: Attachment: SOLR-3316-3x.patch Updated patch. > Distributed Grouping fails in some scenarios. > - > > Key: SOLR-3316 > URL: https://issues.apache.org/jira/browse/SOLR-3316 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 3.4, 3.5 > Environment: Windows 7, JDK 6u26 >Reporter: Cody Young >Assignee: Martijn van Groningen >Priority: Blocker > Labels: distributed, grouping > Fix For: 4.0 > > Attachments: SOLR-3316-3x.patch, SOLR-3316-3x.patch, SOLR-3316.patch, > TestDistributedGrouping.java.patch > > > During a distributed grouping request, if rows is set to 0 a 500 error is > returned. > If groups are unique to a shard and the row count is set to 1, then the > matches number is only the matches from one shard. > I've put together a failing test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3333) Create an option that allows a query to be cached, but not used for warming
[ https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248292#comment-13248292 ] Shawn Heisey commented on SOLR-: I don't think I can implement this. My knowledge of Solr internals simply isn't strong enough. > Create an option that allows a query to be cached, but not used for warming > --- > > Key: SOLR- > URL: https://issues.apache.org/jira/browse/SOLR- > Project: Solr > Issue Type: New Feature >Affects Versions: 3.5, 4.0 >Reporter: Shawn Heisey > > The application that uses my Solr install builds complex filter queries for > employees because they have access to everything, whereas most users have > access to a small subset. > Because of this, autowarming on the filterCache can take 30-60 seconds even > though autoWarm is set to just 4 queries. > If we had a way (probably a localparam) to tell Solr to not use those filters > when autowarming, but to go ahead and put them in the filterCache and use > them until there's a new commit, that would eliminate this problem. > Employees might have their queries take longer, but regular users would not > be affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3333) Create an option that allows a query to be cached, but not used for warming
Create an option that allows a query to be cached, but not used for warming --- Key: SOLR- URL: https://issues.apache.org/jira/browse/SOLR- Project: Solr Issue Type: New Feature Affects Versions: 3.5, 4.0 Reporter: Shawn Heisey The application that uses my Solr install builds complex filter queries for employees because they have access to everything, whereas most users have access to a small subset. Because of this, autowarming on the filterCache can take 30-60 seconds even though autoWarm is set to just 4 queries. If we had a way (probably a localparam) to tell Solr to not use those filters when autowarming, but to go ahead and put them in the filterCache and use them until there's a new commit, that would eliminate this problem. Employees might have their queries take longer, but regular users would not be affected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3316) Distributed Grouping fails in some scenarios.
[ https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248286#comment-13248286 ] Martijn van Groningen commented on SOLR-3316: - Committed to trunk. > Distributed Grouping fails in some scenarios. > - > > Key: SOLR-3316 > URL: https://issues.apache.org/jira/browse/SOLR-3316 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 3.4, 3.5 > Environment: Windows 7, JDK 6u26 >Reporter: Cody Young >Assignee: Martijn van Groningen >Priority: Blocker > Labels: distributed, grouping > Fix For: 4.0 > > Attachments: SOLR-3316-3x.patch, SOLR-3316.patch, > TestDistributedGrouping.java.patch > > > During a distributed grouping request, if rows is set to 0 a 500 error is > returned. > If groups are unique to a shard and the row count is set to 1, then the > matches number is only the matches from one shard. > I've put together a failing test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3316) Distributed Grouping fails in some scenarios.
[ https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen updated SOLR-3316: Fix Version/s: 4.0 > Distributed Grouping fails in some scenarios. > - > > Key: SOLR-3316 > URL: https://issues.apache.org/jira/browse/SOLR-3316 > Project: Solr > Issue Type: Bug > Components: SearchComponents - other >Affects Versions: 3.4, 3.5 > Environment: Windows 7, JDK 6u26 >Reporter: Cody Young >Assignee: Martijn van Groningen >Priority: Blocker > Labels: distributed, grouping > Fix For: 4.0 > > Attachments: SOLR-3316-3x.patch, SOLR-3316.patch, > TestDistributedGrouping.java.patch > > > During a distributed grouping request, if rows is set to 0 a 500 error is > returned. > If groups are unique to a shard and the row count is set to 1, then the > matches number is only the matches from one shard. > I've put together a failing test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3962) Fix incorrect/missing CHANGES.txt entries
[ https://issues.apache.org/jira/browse/LUCENE-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-3962. --- Resolution: Fixed Committed trunk revision: 1310303 Committed 3.x revision: 1310304 > Fix incorrect/missing CHANGES.txt entries > - > > Key: LUCENE-3962 > URL: https://issues.apache.org/jira/browse/LUCENE-3962 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Blocker > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3962.patch, LUCENE-3962.patch > > > While reviewing the release artifacts I found several issues with the > CHANGES.txt file sin Lucene and Solr. Attached is an easy patch: > - we no longer JARJAR commons-csv > - Apache Ivy changes were missing in both CHANGES files > - Restructuring of build system by steven was not mentioned by Solr. This is > important as it affects people working with the Solr source code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3329) Use consistent svn:keywords
[
https://issues.apache.org/jira/browse/SOLR-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248284#comment-13248284
]
Robert Muir commented on SOLR-3329:
---
{quote}
keep using $URL$, it doesn't really hurt anything.
{quote}
This still hurts when using ordinary patch/diff tools across different branches.
I frequently do this (I use patch --merge to merge outdated patches, and I use
diff to show changes including svn adds/deletes).
For example, i use the dev-tools/scripts/diffSources.py to review the
differences
between a feature branch and trunk before merging it back.
> Use consistent svn:keywords
> ---
>
> Key: SOLR-3329
> URL: https://issues.apache.org/jira/browse/SOLR-3329
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Fix For: 4.0
>
> Attachments: SOLR-3329-svn-keywords.patch
>
>
> In solr, use use svn:keywords haphazardly
> We have lots of places with:
> {code}
> svn propset svn:keywords "Date Author Id Revision HeadURL" *.java
> {code}
> In LUCENE-3923, there is a suggestion to get rid of many of these.
> The MBeans interface often exposes HeadURL, but we likely want to get rid of
> the rest
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3962) Fix incorrect/missing CHANGES.txt entries
[ https://issues.apache.org/jira/browse/LUCENE-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248270#comment-13248270 ] Uwe Schindler commented on LUCENE-3962: --- OK. I will commit this after making this change. > Fix incorrect/missing CHANGES.txt entries > - > > Key: LUCENE-3962 > URL: https://issues.apache.org/jira/browse/LUCENE-3962 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Blocker > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3962.patch, LUCENE-3962.patch > > > While reviewing the release artifacts I found several issues with the > CHANGES.txt file sin Lucene and Solr. Attached is an easy patch: > - we no longer JARJAR commons-csv > - Apache Ivy changes were missing in both CHANGES files > - Restructuring of build system by steven was not mentioned by Solr. This is > important as it affects people working with the Solr source code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3962) Fix incorrect/missing CHANGES.txt entries
[
https://issues.apache.org/jira/browse/LUCENE-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248269#comment-13248269
]
Robert Muir commented on LUCENE-3962:
-
Solr has no build.txt, but the entry you add to its CHANGES.txt says:
{noformat}
Please review BUILD.txt for instructions.
{noformat}
For Solr, this should say 'Please review *README.txt* for instructions'.
> Fix incorrect/missing CHANGES.txt entries
> -
>
> Key: LUCENE-3962
> URL: https://issues.apache.org/jira/browse/LUCENE-3962
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3962.patch, LUCENE-3962.patch
>
>
> While reviewing the release artifacts I found several issues with the
> CHANGES.txt file sin Lucene and Solr. Attached is an easy patch:
> - we no longer JARJAR commons-csv
> - Apache Ivy changes were missing in both CHANGES files
> - Restructuring of build system by steven was not mentioned by Solr. This is
> important as it affects people working with the Solr source code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3332) How to index a range of values in solr
[ https://issues.apache.org/jira/browse/SOLR-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mohamed badawi updated SOLR-3332: - Summary: How to index a range of values in solr (was: How to index a a range of values in solr ) > How to index a range of values in solr > > > Key: SOLR-3332 > URL: https://issues.apache.org/jira/browse/SOLR-3332 > Project: Solr > Issue Type: Task >Reporter: mohamed badawi > > I have equipments site , need to index equipment specifications > Some of specifications are range of values > for example > i have an equipment , have minimum voltage 10 v and maximum voltage 220 v > i need to index it . so when a user search for equipment with 110 v can find > this one in the results > TY -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
