date:20120406


 [ 
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

This is a quick sketch showing how we can use the SolrInfoMBeanHandler to 
output a speciall 'diff' format that will load (without changes!) in the 
current UI.

Essentially the workflow is:
1. The UI takes a snapshot of a plugins response (needs to be XML string)
2. At some point in the future, you send a post to 
/admin/plugins?diff=truestream.body=XML
3. The handler returns a modified response that only includes changed MBeans 
and makes the differences clear.

For example, the stats response after one request will look like this:
{code:xml}
lst name=stats
long name=handlerStart1333695069323/long
str name=requestsWas: 2, Now: 3, Delta: 1/str
long name=errors0/long
long name=timeouts0/long
str name=totalTimeWas: 3, Now: 4, Delta: 1/str
str name=avgTimePerRequestWas: 1.5, Now: 1.334, Delta: -0.167/str
/lst
{code}



 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


 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] [Updated] (SOLR-3329) Use consistent svn:keywords


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

Ryan McKinley updated SOLR-3329:


Attachment: SOLR-3329-svn-keywords.patch

implements Chris's suggestion and removes Date Author Id Revision from most 
files

 Use consistent svn:keywords
 ---

 Key: SOLR-3329
 URL: https://issues.apache.org/jira/browse/SOLR-3329
 Project: Solr
  Issue Type: Improvement
Reporter: 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] [Resolved] (SOLR-3329) Use consistent svn:keywords

2012-04-06 Thread Ryan McKinley (Resolved) (JIRA)


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

Ryan McKinley resolved SOLR-3329.
-

Resolution: Fixed
  Assignee: Ryan McKinley

committed in #1310219   

 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-3923) fail the build on wrong svn:eol-style

2012-04-06 Thread Ryan McKinley (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248176#comment-13248176
 ] 

Ryan McKinley commented on LUCENE-3923:
---

All the $Id$ and $Revision$ tags have been removed (SOLR-3329)


 fail the build on wrong svn:eol-style
 -

 Key: LUCENE-3923
 URL: https://issues.apache.org/jira/browse/LUCENE-3923
 Project: Lucene - Java
  Issue Type: Task
  Components: general/build
Reporter: Robert Muir

 I'm tired of fixing this before releases. Jenkins should detect and fail on 
 this.

--
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: Implementing SOLR-1093

2012-04-06 Thread Mikhail Khludnev

Hello Karthick,

SOLR-1093 formulated as a batch, but you are talking about something like
fallback query or staged handling. I think it's the best way to have an
optimal trade off between precision and recall. My points are:
 - I don't think that results should be merged, I suppose that the first
non-empty result only should be returned.
 - I did it some time ago as a StagingSearchHandler, which walk through
other handlers, and
 - I rely on configured list of slave handlers, instead of the list of
request/queries
 - Also I iterated through query parsers with the same q=phrase, every of
them parses the same phrase onto more query with the different selectivity,
eg. AND first, OR then, OR with stemming after that, etc.

I haven't had a time to polish and contribute it properly. Does anybody
need it?

Regards


On Thu, Apr 5, 2012 at 6:11 PM, Karthick Duraisamy Soundararaj 
karthick.soundara...@gmail.com wrote:

 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.

 With merge=true and mergeQueries=1,2,3. Would merge(sandwich) the results
 of the queries 1,23.

 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 requests. Any
 suggestions/thoughts/pointers as where to begin looking for will be of
 great help.

 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).

 Thank you,
 Karthick




-- 
Sincerely yours
Mikhail Khludnev
ge...@yandex.ru

http://www.griddynamics.com
 mkhlud...@griddynamics.com

Re: VOTE: Lucene/Solr 3.6

2012-04-06 Thread Christian Moen

Hello again Robert,

I've been doing some end-to-end testing on Kuromoji using the release candidate 
build and things look good to me.

I've also done the testing described on SOLR-3282 earlier using a branch_3x 
build from last week.  That also looks good.

I have one legal question:

In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find a 
corresponding one in Solr's NOTICE.txt.  Is this fine -- or should this also be 
included as part of the Lucene notice?  (To me it sounds appropriate to also 
include this in Solr's NOTICE.txt.)


Christian Moen
http://www.atilika.com

On Apr 6, 2012, at 12:25 AM, Christian Moen wrote:

 Robert,
 
 Great work getting everything ready and reworking the build system as well.  
 I'll take Kuromoji for a spin and provide feedback tomorrow (Japanese time).
 
 
 Christian
 http://www.atilika.com
 
 On Apr 5, 2012, at 1:45 PM, Robert Muir wrote:
 
 Please vote to release these artifacts: http://s.apache.org/lusolr36rc0
 
 I tested with dev-tools/scripts/smokeTestRelease.py, ran rat-sources
 on both source releases, tested solr example, and reviewed packaging
 contents (http://people.apache.org/~rmuir/36_review/)
 
 Here's my +1.
 
 -- 
 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-3957) Document precision requirements of setBoost calls

2012-04-06 Thread Simon Willnauer (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248215#comment-13248215
 ] 

Simon Willnauer commented on LUCENE-3957:
-

bq. I don't think we should put docs there in those classes:
+1 thats a very long standing impl detail. If it is not on the wiki in the FAQ 
we should add it or maybe add a pitfalls section to the wiki.

 Document precision requirements of setBoost calls
 -

 Key: LUCENE-3957
 URL: https://issues.apache.org/jira/browse/LUCENE-3957
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/javadocs
Affects Versions: 3.5
Reporter: Jordi Salvat i Alabart

 The behaviour of index-time boosts seems pretty erratic (e.g. a boost of 8.0 
 produces the exact same score as a boost of 9.0) until you become aware that 
 these factors end up encoded in a single byte, with a three-bit mantissa. 
 This consumed a whole day of research for us, and I still believe we were 
 lucky to spot it, given how deeply dug into the code  documentation this 
 information is.
 I suggest adding a small note to the JavaDoc of setBoost methods in Document, 
 Fieldable, FieldInvertState, and possibly AbstractField, Field, and 
 NumericField.
 Suggested text:
 Note that all index-time boost values end up encoded using 
 Similarity.encodeNormValue, with a 3-bit mantissa -- so differences in the 
 boost value of less than 25% may easily be rounded away.

--
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

Hi,

I tested Lucene and Solr builds:

- The tgz files unzip fine with Linux/Cygwin tar, but with latest Windows 7-Zip 
Filemanager it says (when opening the inner TAR file): data after end of tar 
file (or like that). As the fixes extract correctly on Linux, I think that 
might be a bug in 7-Zip, but never happened with any releases before.

- URGENT: Our change to IVY is nowhere noted in CHANGES.txt!!! This is a major 
problem, as this is a huge change and people used to building Lucene from 
source only looking into CHANGES.txt will fail to build without inspecting 
BUILD.txt. We have changes entries for the refactoring of the build directory 
structure (by Steven), but not for the Ivy change. Very bad! We must at least 
tell people about that in the release notes, otherwise -1.

- PANGAEA huge index checks: No VInt bugs or similar on checkindex and anywhere 
else (Java 1.7.0_03). Now runs in production, very nice. Not even a need to 
recompile the whole stuff needed, fine backwards!

- JAR files build with JDK 1.5.0_22 - That’s really nice, thanks Robert (and 
important in my opinion, I was missing that in previous releases).

- Binary Javadocs still Geocities-like, it's no problem, but was it not planned 
to use Java 7? - It's of course fine!

- Lucene Source package builds and tests fine.

- Solr Source package builds fine (I only ran the build inside solr/ folder to 
test this actually works)

- Solr tests ran fine on second run, in the first run (Java 5) I hit the famous 
XALAN XSLTC bug with turkish locale in the internal XALAN XSLTC processor fork 
*) -- This is a well-known Java 5 (XALAN XSLTC) bug and Turkish people who use 
XSL script know that this bug is existent, they would have seen the bug without 
Solr, too.

My +0.5 for the release, I would wish we fix CHANGES.txt before release - then 
I would give +1!

Uwe


*) See the bug, we also hit it in Lucene before: 
https://issues.apache.org/jira/browse/LUCENE-2685, 
https://issues.apache.org/jira/browse/XALANJ-2420, 
https://issues.apache.org/bugzilla/show_bug.cgi?id=38787 - In later Java 6 this 
seems fixed (although it still contains XSLTC, but they may use use newer BCEL).
[junit] java.lang.RuntimeException: Instruction unknown: load?nstruction
[junit] at 
com.sun.org.apache.bcel.internal.util.InstructionFinder.mapName(InstructionFinder.java:138)
[junit] at 
com.sun.org.apache.bcel.internal.util.InstructionFinder.compilePattern(InstructionFinder.java:170)
[junit] at 
com.sun.org.apache.bcel.internal.util.InstructionFinder.search(InstructionFinder.java:218)
[junit] at 
com.sun.org.apache.bcel.internal.util.InstructionFinder.search(InstructionFinder.java:264)
[junit] at 
com.sun.org.apache.xalan.internal.xsltc.compiler.Mode.peepHoleOptimization(Mode.java:1444)

-
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: Thursday, April 05, 2012 6:45 AM
 To: dev@lucene.apache.org
 Subject: VOTE: Lucene/Solr 3.6
 
 Please vote to release these artifacts: http://s.apache.org/lusolr36rc0
 
 I tested with dev-tools/scripts/smokeTestRelease.py, ran rat-sources on both
 source releases, tested solr example, and reviewed packaging contents
 (http://people.apache.org/~rmuir/36_review/)
 
 Here's my +1.
 
 --
 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

Re: VOTE: Lucene/Solr 3.6

On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler u...@thetaphi.de wrote:

 - URGENT: Our change to IVY is nowhere noted in CHANGES.txt!!! This is a 
 major problem, as this is a huge change and people used to building Lucene 
 from source only looking into CHANGES.txt will fail to build without 
 inspecting BUILD.txt. We have changes entries for the refactoring of the 
 build directory structure (by Steven), but not for the Ivy change. Very bad! 
 We must at least tell people about that in the release notes, otherwise -1.


This information is in BUILD.txt, which is where the instructions for
building are.
People building need to look at BUILD.txt, thats what this file exists for.
We don't need to duplicate documentation across *BOTH* build.txt and
changes.txt, thats ridiculous.

-- 
lucidimagination.com

-
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

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:

-
Build 

* LUCENE-: Moved build system to use Apache Ivy for retrival of 3rd party 
JAR files.
   (Robert Muir, Chris Male, Uwe Schindler,...)
-


-
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 12:43 PM
 To: dev@lucene.apache.org
 Subject: Re: VOTE: Lucene/Solr 3.6
 
 On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler u...@thetaphi.de wrote:
 
  - URGENT: Our change to IVY is nowhere noted in CHANGES.txt!!! This is a
 major problem, as this is a huge change and people used to building Lucene
 from source only looking into CHANGES.txt will fail to build without 
 inspecting
 BUILD.txt. We have changes entries for the refactoring of the build directory
 structure (by Steven), but not for the Ivy change. Very bad! We must at least
 tell people about that in the release notes, otherwise -1.
 
 
 This information is in BUILD.txt, which is where the instructions for building
 are.
 People building need to look at BUILD.txt, thats what this file exists for.
 We don't need to duplicate documentation across *BOTH* build.txt and
 changes.txt, thats ridiculous.
 
 --
 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

Re: VOTE: Lucene/Solr 3.6

2012-04-06 Thread Martijn van Groningen (Updated) (JIRA)

On Fri, Apr 6, 2012 at 6:55 AM, Uwe Schindler u...@thetaphi.de 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-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

This issue also occurs in previous 3x releases. Attached a patch that fixes 
that.

 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
  Labels: distributed, grouping
 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.

2012-04-06 Thread Martijn van Groningen (Updated) (JIRA)


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

Martijn van Groningen updated SOLR-3316:


Affects Version/s: (was: 4.0)
   3.4
   3.5
 Assignee: 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: Martijn van Groningen
  Labels: distributed, grouping
 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

Re: VOTE: Lucene/Solr 3.6

On Fri, Apr 6, 2012 at 4:58 AM, Christian Moen c...@atilika.com wrote:

 In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find a 
 corresponding one in Solr's NOTICE.txt.  Is this fine -- or should this also 
 be included as part of the Lucene notice?  (To me it sounds appropriate to 
 also include this in Solr's NOTICE.txt.)


Its a real problem: because this IPADIC license requires you have
certain notifications: PROVIDED that the provisions of Section 3 (NO
WARRANTY) will ALWAYS appear on, or be attached to, the Program,

and the LICENSE.txt/NOTICE.txt needs to be at the root of the source
tree (currently solr just duplicates the lucene entries and its
solr/LICENSE.txt and solr/NOTICE.txt is intentionally placed at the
root of the whole sourcetree).

It needs to be fixed: but the question is how to fix it. patching the
solr NOTICE.txt is not acceptable I think, otherwise this will only
happen again... automation is a must here.

-- 
lucidimagination.com

-
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

Hi Robert,

In the case that you have to fix this one and respin, could you please also fix 
my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, it 
should be mentioned with names in CHANGES.txt.

One more thing: When you extract Solr src package you are at the top-level 
root. In my opinion these license/info/build... files should also be placed 
there (including a BUILD.txt on the root!).

In my opinion, the best would be to place those files only in the root folder 
of SVN and the srz-tgz/bin-tgz/... tasks should add those root-level txt files 
also to the roots of the archives (binary and source).

-
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 1:28 PM
 To: dev@lucene.apache.org
 Subject: Re: VOTE: Lucene/Solr 3.6
 
 On Fri, Apr 6, 2012 at 4:58 AM, Christian Moen c...@atilika.com wrote:
 
  In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find
  a corresponding one in Solr's NOTICE.txt.  Is this fine -- or should
  this also be included as part of the Lucene notice?  (To me it
  sounds appropriate to also include this in Solr's NOTICE.txt.)
 
 
 Its a real problem: because this IPADIC license requires you have certain
 notifications: PROVIDED that the provisions of Section 3 (NO
 WARRANTY) will ALWAYS appear on, or be attached to, the Program,
 
 and the LICENSE.txt/NOTICE.txt needs to be at the root of the source tree
 (currently solr just duplicates the lucene entries and its solr/LICENSE.txt 
 and
 solr/NOTICE.txt is intentionally placed at the root of the whole sourcetree).
 
 It needs to be fixed: but the question is how to fix it. patching the solr
 NOTICE.txt is not acceptable I think, otherwise this will only happen again...
 automation is a must here.
 
 --
 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

Re: VOTE: Lucene/Solr 3.6

On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler u...@thetaphi.de wrote:

 - Binary Javadocs still Geocities-like, it's no problem, but was it not 
 planned to use Java 7? - It's of course fine!


Right: as i proposed originally on the list, this would be something
special I would do for the website *only*.

In my opinion its too risky to do this in the build we ship, because
it would mean i would have to compile with java7 and java5 bootstrap
classpath: of course in theory that shoudl all work, but i feel much
more comfortable building the release with an actual java 5 compiler.

-- 
lucidimagination.com

-
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 7:35 AM, Uwe Schindler u...@thetaphi.de wrote:
 Hi Robert,

 In the case that you have to fix this one and respin, could you please also 
 fix my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, 
 it should be mentioned with names in CHANGES.txt.



 One more thing: When you extract Solr src package you are at the top-level 
 root. In my opinion these license/info/build... files should also be placed 
 there (including a BUILD.txt on the root!).


we aren't doing this.

We put license.txt/notice.txt at the root only because we are legally
required to do so.


-- 
lucidimagination.com

-
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

2012-04-06 Thread Martijn v Groningen

Hi,

A few days ago Cody Young discovered a bug in Solr's distributed grouping
(SOLR-3316). This bug also occurs in the 3x code.
I attached a bug fix in the issue. I think it is an important bug fix. Can
I commit the fix to branch3x or is it already too late?

Martijn

On 6 April 2012 13:35, Robert Muir rcm...@gmail.com wrote:

 On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler u...@thetaphi.de wrote:

  - Binary Javadocs still Geocities-like, it's no problem, but was it not
 planned to use Java 7? - It's of course fine!
 

 Right: as i proposed originally on the list, this would be something
 special I would do for the website *only*.

 In my opinion its too risky to do this in the build we ship, because
 it would mean i would have to compile with java7 and java5 bootstrap
 classpath: of course in theory that shoudl all work, but i feel much
 more comfortable building the release with an actual java 5 compiler.

 --
 lucidimagination.com

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

 --
 Met vriendelijke groet,

 Martijn van Groningen

  dev-h...@lucene.apache.org

RE: VOTE: Lucene/Solr 3.6

I agree. I would have build only the javadocs with java 7, the rest with Java 5.

 -Original Message-
 From: Robert Muir [mailto:rcm...@gmail.com]
 Sent: Friday, April 06, 2012 1:36 PM
 To: dev@lucene.apache.org
 Subject: Re: VOTE: Lucene/Solr 3.6

 On Fri, Apr 6, 2012 at 6:35 AM, Uwe Schindler u...@thetaphi.de wrote:

  - Binary Javadocs still Geocities-like, it's no problem, but was it not 
  planned to
 use Java 7? - It's of course fine!

 Right: as i proposed originally on the list, this would be something special I
 would do for the website *only*.

 In my opinion its too risky to do this in the build we ship, because it would 
 mean
 i would have to compile with java7 and java5 bootstrap
 classpath: of course in theory that shoudl all work, but i feel much more
 comfortable building the release with an actual java 5 compiler.

 --
 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

RE: VOTE: Lucene/Solr 3.6

It was a suggestion, no critisism. Why do you attack me?

-
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 1:37 PM
 To: dev@lucene.apache.org
 Subject: Re: VOTE: Lucene/Solr 3.6
 
 On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler u...@thetaphi.de wrote:
  Hi Robert,
 
  In the case that you have to fix this one and respin, could you please also 
  fix
 my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, it
 should be mentioned with names in CHANGES.txt.
 
 
 
  One more thing: When you extract Solr src package you are at the top-level
 root. In my opinion these license/info/build... files should also be placed 
 there
 (including a BUILD.txt on the root!).
 
 
 we aren't doing this.
 
 We put license.txt/notice.txt at the root only because we are legally 
 required to
 do so.
 
 
 --
 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

Re: VOTE: Lucene/Solr 3.6

On Fri, Apr 6, 2012 at 7:37 AM, Martijn v Groningen
martijn.is.h...@gmail.com wrote:
 Hi,

 A few days ago Cody Young discovered a bug in Solr's distributed grouping
 (SOLR-3316). This bug also occurs in the 3x code.
 I attached a bug fix in the issue. I think it is an important bug fix. Can I
 commit the fix to branch3x or is it already too late?


Hi Martijn, i will have to respin the RC to fix the legal problem that
Christian found anyway, however we shouldnt add any unnecessary
changes at the same time just because i'm respinning, that can
destabilize an otherwise stable release.

On the other hand, if its a blocker bug and the fix is safe, then set
that issue to blocker and we can have more eyes on the patch...


-- 
lucidimagination.com

-
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

The problem is: duplication of documentation is dangerous and only
creates more work for the RM.

if we start duplicating things like build instructions across both
BUILD.txt and CHANGES.txt, or whole text files, then its only a matter
of time before someone says in the next release vote:

XYZ is mentioned in foo/BUILD.txt but this is inconsistent with
foo/CHANGES.txt or XYZ/BUILD.txt is out of date with respect to
/BUILD.txt

On Fri, Apr 6, 2012 at 7:40 AM, Uwe Schindler u...@thetaphi.de wrote:
 It was a suggestion, no critisism. Why do you attack me?

 -
 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 1:37 PM
 To: dev@lucene.apache.org
 Subject: Re: VOTE: Lucene/Solr 3.6

 On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler u...@thetaphi.de wrote:
  Hi Robert,
 
  In the case that you have to fix this one and respin, could you please 
  also fix
 my CHANGES.txt complaint? The Ivy changes were such a huge piece of work, it
 should be mentioned with names in CHANGES.txt.
 


  One more thing: When you extract Solr src package you are at the top-level
 root. In my opinion these license/info/build... files should also be placed 
 there
 (including a BUILD.txt on the root!).
 

 we aren't doing this.

 We put license.txt/notice.txt at the root only because we are legally 
 required to
 do so.


 --
 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




-- 
lucidimagination.com

-
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

Hi Robert,

Read 3 lines below the comment you replied to:
My idea was to place all those text files (BUILD.txt, NOTICE.txt,...) into the 
SVN root (directly under trunk), remove them from Lucene/Solr/modules 
subfolders. Then simply instruct the ZIP/TGZ tasks to add those files as a 
separate fileset to the root of *every* created archive.

Does this sound like a plan? No duplication in the source, but every ZIP/TGZ 
file (if its src or bin doesn’t matter) gets all legal information and build 
instructions (for src only).

Uwe

-
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 1:42 PM
 To: dev@lucene.apache.org
 Subject: Re: VOTE: Lucene/Solr 3.6
 
 The problem is: duplication of documentation is dangerous and only creates
 more work for the RM.
 
 if we start duplicating things like build instructions across both BUILD.txt 
 and
 CHANGES.txt, or whole text files, then its only a matter of time before 
 someone
 says in the next release vote:
 
 XYZ is mentioned in foo/BUILD.txt but this is inconsistent with 
 foo/CHANGES.txt
 or XYZ/BUILD.txt is out of date with respect to /BUILD.txt
 
 On Fri, Apr 6, 2012 at 7:40 AM, Uwe Schindler u...@thetaphi.de wrote:
  It was a suggestion, no critisism. Why do you attack me?
 
  -
  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 1:37 PM
  To: dev@lucene.apache.org
  Subject: Re: VOTE: Lucene/Solr 3.6
 
  On Fri, Apr 6, 2012 at 7:35 AM, Uwe Schindler u...@thetaphi.de wrote:
   Hi Robert,
  
   In the case that you have to fix this one and respin, could you
   please also fix
  my CHANGES.txt complaint? The Ivy changes were such a huge piece of
  work, it should be mentioned with names in CHANGES.txt.
  
 
 
   One more thing: When you extract Solr src package you are at the
   top-level
  root. In my opinion these license/info/build... files should also be
  placed there (including a BUILD.txt on the root!).
  
 
  we aren't doing this.
 
  We put license.txt/notice.txt at the root only because we are legally
  required to do so.
 
 
  --
  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
 
 
 
 
 --
 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

RE: VOTE: Lucene/Solr 3.6

JAJA.

-
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 1:51 PM
 To: dev@lucene.apache.org
 Subject: Re: VOTE: Lucene/Solr 3.6
 
 On Fri, Apr 6, 2012 at 7:47 AM, Uwe Schindler u...@thetaphi.de wrote:
  Hi Robert,
 
  Read 3 lines below the comment you replied to:
  My idea was to place all those text files (BUILD.txt, NOTICE.txt,...) into 
  the
 SVN root (directly under trunk), remove them from Lucene/Solr/modules
 subfolders. Then simply instruct the ZIP/TGZ tasks to add those files as a
 separate fileset to the root of *every* created archive.
 
  Does this sound like a plan? No duplication in the source, but every ZIP/TGZ
 file (if its src or bin doesn’t matter) gets all legal information and build
 instructions (for src only).
 
 Its absolutely not a plan. Because then lucene has shit in its LICENSE.txt and
 NOTICE.txt that don't apply to it.
 
 
 --
 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] (SOLR-3316) Distributed Grouping fails in some scenarios.


[ 
https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248252#comment-13248252
 ] 

Robert Muir commented on SOLR-3316:
---

Some parts of the patch make it difficult to review:
* why does SimpleEndResultTransformer.transform lose its @Override?
* why does GroupedEndResultTransformer/SimpleEndResultTransformer.transform 
gain an {@inheritDoc}? I'm not sure this will really do what you expect, 
because it extends a package-private method (EndResultTransformer.inheritDoc), 
which we don't generate javadocs for (only public, protected).



 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
  Labels: distributed, grouping
 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] [Created] (SOLR-3331) solr NOTICE.txt is missing information

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
Priority: Blocker
 Fix For: 3.6


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

2012-04-06 Thread Martijn van Groningen (Updated) (JIRA)

On Fri, Apr 6, 2012 at 4:58 AM, Christian Moen c...@atilika.com wrote:
 Hello again Robert,

 I've been doing some end-to-end testing on Kuromoji using the release 
 candidate build and things look good to me.

 I've also done the testing described on SOLR-3282 earlier using a branch_3x 
 build from last week.  That also looks good.

 I have one legal question:

 In Lucene's NOTICE.txt we have a MeCab-IPADIC entry, but I can't find a 
 corresponding one in Solr's NOTICE.txt.  Is this fine -- or should this also 
 be included as part of the Lucene notice?  (To me it sounds appropriate to 
 also include this in Solr's NOTICE.txt.)

Thanks again Christian: i created
https://issues.apache.org/jira/browse/SOLR-3331

I think for 3.6 its absolutely necessary the smokeTester check this,
so that its not manual inspection.
Solr has too many dependencies to put this burden on the RM to review
that this stuff is in sync by hand.

we can later extend this to modules in 4.0 if we want, or we can do
something else, thats a separate discussion.

-- 
lucidimagination.com

-
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:

Priority: Blocker (was: Major)

Changed priority to blocker to include this bug fix into the 3.6 release. I
think the changes are safe. I ran the build several times (with java 5). The
javadocs task doesn't throw any errors. I also ran the distributed grouping
test with multiplier of 3:
ant test-core -Dtests.multiplier=3 -Dtestcase=TestDistributedGrouping

If others think the changes aren't safe then the block priority can be removed.

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
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.

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

[JENKINS] Solr-trunk - Build # 1816 - Still Failing

2012-04-06 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Solr-trunk/1816/

1 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.testDistribSearch

Error Message:
Uncaught exception by thread: Thread[Thread-1089,5,]

Stack Trace:
org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread:
 Uncaught exception by thread: Thread[Thread-1089,5,]
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:84)
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.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://localhost:21875/solr
at 
org.apache.solr.TestDistributedSearch$1.run(TestDistributedSearch.java:396)
Caused by: org.apache.solr.client.solrj.SolrServerException: IOException 
occured when talking to server at: http://localhost:21875/solr
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:361)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:209)
at 
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90)
at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:312)
at 
org.apache.solr.TestDistributedSearch$1.run(TestDistributedSearch.java:391)
Caused by: org.apache.http.conn.ConnectTimeoutException: Connect to 
localhost:21875 timed out
at 
org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:125)
at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
at 
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:150)
at 
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:575)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:304)
... 4 more




Build Log (for compile errors):
[...truncated 11011 lines...]



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

[jira] [Created] (SOLR-3332) How to index a arange of values in solr

2012-04-06 Thread mohamed badawi (Created) (JIRA)

How to index a arange 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.

2012-04-06 Thread Martijn van Groningen (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248262#comment-13248262
]

Robert Muir commented on SOLR-3316:
---

{quote}
I can change that back. My personal preference is to use @inheritDoc instead of
@Override for method that implements from an interface.
{quote}

Thats ok: for 3.6 we cannot have this @Override here anyway.

{quote}
EndResultTransformer is an interface. The default is visibility public for
methods, so we want to keep the javadoc, right?
{quote}

I think i recommend just doing 'ant javadocs' and inspecting build/docs/... and
ensuring the javadocs read as you would like.

If you are satisfied, please commit to trunk only first and others can review
while hudson chews on it in trunk: or does this somehow not affect 4.0?!

Distributed Grouping fails in some scenarios.
-

-
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

2012-04-06 Thread Michael McCandless (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248263#comment-13248263
]

Michael McCandless commented on SOLR-3331:
--

I'll fix smoke tester...

I already have a bunch of mods to add other checks to it...

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

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.

-
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-tabpanelfocusedCommentId=13248266#comment-13248266
]

Martijn van Groningen commented on SOLR-3316:
-

bq. If you are satisfied, please commit to trunk only first and others can
review while hudson chews on it in trunk: or does this somehow not affect 4.0?!
It does affect trunk. I only did use 4.0 as affect version, since it isn't
released. I'll commit to trunk first and see if Hudson likes this change.

Distributed Grouping fails in some scenarios.
-

-
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-tabpanelfocusedCommentId=13248265#comment-13248265
 ] 

Robert Muir commented on SOLR-3331:
---

Thanks Mike for helping with the python: i think we can fix the 
smoketester first (so we add the test), and then fix this NOTICE.txt until its 
happy :)


 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


 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] [Created] (LUCENE-3962) Fix incorrect/missing CHANGES.txt entries

2012-04-06 Thread Uwe Schindler (Created) (JIRA)

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


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] (LUCENE-3962) Fix incorrect/missing CHANGES.txt entries

2012-04-06 Thread Uwe Schindler (Updated) (JIRA)


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

Uwe Schindler updated LUCENE-3962:
--

Attachment: LUCENE-3962.patch

 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


 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

2012-04-06 Thread Uwe Schindler (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248267#comment-13248267
 ] 

Uwe Schindler commented on LUCENE-3962:
---

Path for trunk to be backported.

 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


 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] (LUCENE-3962) Fix incorrect/missing CHANGES.txt entries

2012-04-06 Thread Uwe Schindler (Updated) (JIRA)


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

Uwe Schindler updated LUCENE-3962:
--

Attachment: LUCENE-3962.patch

I missed to add Chris Male to the Commons-CSV issue (he finally moved the code).

 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 a range of values in solr

2012-04-06 Thread mohamed badawi (Updated) (JIRA)


 [ 
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 a range of values in solr   (was: How to index a 
arange of values in solr )

 How to index a 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] [Updated] (SOLR-3332) How to index a range of values in solr

2012-04-06 Thread mohamed badawi (Updated) (JIRA)


 [ 
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

[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-tabpanelfocusedCommentId=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] [Commented] (LUCENE-3962) Fix incorrect/missing CHANGES.txt entries

2012-04-06 Thread Uwe Schindler (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (SOLR-3329) Use consistent svn:keywords

2012-04-06 Thread Martijn van Groningen (Updated) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Resolved] (LUCENE-3962) Fix incorrect/missing CHANGES.txt entries

2012-04-06 Thread Uwe Schindler (Resolved) (JIRA)


 [ 
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] [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] [Commented] (SOLR-3316) Distributed Grouping fails in some scenarios.

2012-04-06 Thread Martijn van Groningen (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Created] (SOLR-3333) Create an option that allows a query to be cached, but not used for warming

2012-04-06 Thread Shawn Heisey (Created) (JIRA)

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

2012-04-06 Thread Martijn van Groningen (Updated) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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] [Updated] (SOLR-3331) solr NOTICE.txt is missing information

2012-04-06 Thread Michael McCandless (Updated) (JIRA)


 [ 
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

Re: VOTE: Lucene/Solr 3.6

2012-04-06 Thread Walter Underwood

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 u...@thetaphi.de 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

2012-04-06 Thread Robert Muir (Updated) (JIRA)


 [ 
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

[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-tabpanelfocusedCommentId=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] [Resolved] (SOLR-3331) solr NOTICE.txt is missing information

2012-04-06 Thread Robert Muir (Resolved) (JIRA)


 [ 
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] [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] [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

Re: VOTE: Lucene/Solr 3.6

On Fri, Apr 6, 2012 at 9:15 AM, Walter Underwood wun...@wunderwood.org 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] [Commented] (SOLR-3316) Distributed Grouping fails in some scenarios.

2012-04-06 Thread Michael McCandless (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

[jira] [Resolved] (SOLR-3332) How to index a range of values in solr

2012-04-06 Thread Erick Erickson (Resolved) (JIRA)


 [ 
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-3333) Create an option that allows a query to be cached, but not used for warming

2012-04-06 Thread Erick Erickson (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (SOLR-3319) Improve DataImportHandler status response


[ 
https://issues.apache.org/jira/browse/SOLR-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
?xml version=1.0 encoding=UTF-8?
response

lst name=responseHeader
  int name=status0/int
  int name=QTime0/int
/lst
lst name=initArgs
  lst name=defaults
str name=configdih-config.xml/str
  /lst
/lst
str name=statusidle/str
str name=importResponse/
lst name=statusMessages
  str name=Total Requests made to DataSource1/str
  str name=Total Rows Fetched11287894/str
  str name=Total Documents Skipped0/str
  str name=Full Dump Started2012-04-03 17:38:01/str
  str name=Indexing completed. Added/Updated: 11287894 documents. Deleted 0 
documents./str
  str name=Committed2012-04-03 20:16:32/str
  str name=Total Documents Processed11287894/str
  str name=Time taken 2:38:31.314/str
/lst
str name=WARNINGThis response format is experimental.  It is likely to 
change in the future./str
/response
{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] [Created] (LUCENE-3964) Stage Maven release artifacts

2012-04-06 Thread Steven Rowe (Created) (JIRA)

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] (LUCENE-3964) Stage Maven release artifacts


[ 
https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

Implementing SOLR - 1093

2012-04-06 Thread Karthick Duraisamy Soundararaj

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] [Updated] (LUCENE-3964) Stage Maven release artifacts

2012-04-06 Thread Steven Rowe (Updated) (JIRA)


 [ 
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

[jira] [Commented] (LUCENE-3964) Stage Maven release artifacts


[ 
https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (LUCENE-3964) Stage Maven release artifacts


[ 
https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] (SOLR-3316) Distributed Grouping fails in some scenarios.


[ 
https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] [Assigned] (SOLR-3316) Distributed Grouping fails in some scenarios.

2012-04-06 Thread Robert Muir (Assigned) (JIRA)


 [ 
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] (SOLR-3316) Distributed Grouping fails in some scenarios.


[ 
https://issues.apache.org/jira/browse/SOLR-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Resolved] (SOLR-3316) Distributed Grouping fails in some scenarios.

2012-04-06 Thread Robert Muir (Resolved) (JIRA)


 [ 
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] [Updated] (LUCENE-3964) Stage Maven release artifacts

2012-04-06 Thread Steven Rowe (Updated) (JIRA)


 [ 
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] [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

[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2155 - Failure

2012-04-06 Thread Apache Jenkins Server

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.java:911)

VOTE: Lucene/Solr 3.6 (take two)

2012-04-06 Thread Martijn van Groningen (Updated) (JIRA)

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

[jira] [Commented] (SOLR-2358) Distributing Indexing

2012-04-06 Thread Michael Garski (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

[jira] [Resolved] (LUCENE-3955) smokeTestRelease should test solr example

2012-04-06 Thread Michael McCandless (Resolved) (JIRA)


 [ 
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] [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] [Commented] (LUCENE-3955) smokeTestRelease should test solr example


[ 
https://issues.apache.org/jira/browse/LUCENE-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-3330) Show changes in plugin statistics across multiple requests

2012-04-06 Thread Uwe Schindler (Issue Comment Edited) (JIRA)


 [ 
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] (SOLR-3328) executable bits of shellscripts in solr source release

2012-04-06 Thread Uwe Schindler (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

-
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-tabpanelfocusedCommentId=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 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

-
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

2012-04-06 Thread Ryan McKinley (Resolved) (JIRA)


 [ 
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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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.

-
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

2012-04-06 Thread Michael McCandless (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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-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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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