[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846244#action_12846244
]
Mark Miller commented on SOLR-1817:
---
U - I'm sorry - I'm being confusing - it wasn't t
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846242#action_12846242
]
Mark Miller commented on SOLR-1817:
---
bq. That is the issue where that possible NPE is - ge
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846240#action_12846240
]
Mark Miller commented on SOLR-1817:
---
bq. In either case: why do we need to specificly test
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846237#action_12846237
]
Hoss Man commented on SOLR-1817:
bq. That is the issue where that possible NPE is - getting
[
https://issues.apache.org/jira/browse/SOLR-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846235#action_12846235
]
Hoss Man commented on SOLR-1824:
Can someone point me to a method name and/or line number? .
On Tue, Mar 16, 2010 at 2:25 PM, Chris Hostetter
wrote:
>
> : We try not to do that then. Things make a lot more sense when one
> : starts thinking of them as a single project, w/o multiple downloads.
> :
> : If major modules were to be pulled from Solr and put into Lucene, and
> : Solr wanted to
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846230#action_12846230
]
Hoss Man commented on SOLR-1817:
Ugh... lots of "cross talk", sorry still procesisng some of
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846227#action_12846227
]
Hoss Man commented on SOLR-1817:
bq. this is part of the big open issue I think is left here
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846225#action_12846225
]
Mark Miller commented on SOLR-1817:
---
bq. why is "admin" suddenly a magic alias for "" in S
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846219#action_12846219
]
Mark Miller commented on SOLR-1817:
---
bq. two of the places you removed "adds" to SolrConfi
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846217#action_12846217
]
Hoss Man commented on SOLR-1817:
Some rore comments now that i've read things a little more
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846208#action_12846208
]
Mark Miller commented on SOLR-1817:
---
1 and 2) I agree - this is part of the big open issue
I'm reviewing SOLR-1817 and noticing that when CoreContainer parses
solr.xml, it asserts that at most one core has a "name" matching the
"defaultCoreName" ... but there is currently no assertion that every core
have a name, or that the names be unique before the SolrCore is
constructed ... it
On Tue, Mar 16, 2010 at 3:46 PM, Chris Hostetter
wrote:
> : Otis, yes, I think so, eventually. But that's gonna take much more
> discussion.
> :
> : I don't think this initial cutover should try to "solve" how modules
> : will be organized, yet... we'll get there, eventually.
>
> But we should at
On 03/16/2010 06:46 PM, Chris Hostetter wrote:
Here's my concrete suggestion that could be done today
+1
--
- Mark
http://www.lucidimagination.com
: Otis, yes, I think so, eventually. But that's gonna take much more
discussion.
:
: I don't think this initial cutover should try to "solve" how modules
: will be organized, yet... we'll get there, eventually.
But we should at least consider it, and not move in a direction that's
distinct fro
[
https://issues.apache.org/jira/browse/SOLR-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846166#action_12846166
]
Ted Dunning commented on SOLR-1375:
---
Sorry to comment late here, but when indexing in hado
On Tue, Mar 16, 2010 at 02:57:33PM -0700, Otis Gospodnetic wrote:
> Check out the dir structure mentioned here:
> http://markmail.org/message/gwpmaevw7tavqqge
>
> Isn't that what we want?
I think the downside of that hierarchy is that you will need the "modules"
directory if you're working on Luc
[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846160#action_12846160
]
Dan Bentson commented on SOLR-773:
--
I'm trying to test spatial search out in 1.5 going by th
On Tue, Mar 16, 2010 at 2:57 PM, Otis Gospodnetic <
otis_gospodne...@yahoo.com> wrote:
> Hi,
>
> Check out the dir structure mentioned here:
> http://markmail.org/message/gwpmaevw7tavqqge
>
> Isn't that what we want?
>
I'm totally down with this structure, personally. Not that I matter. :)
-j
Otis, yes, I think so, eventually. But that's gonna take much more discussion.
I don't think this initial cutover should try to "solve" how modules
will be organized, yet... we'll get there, eventually.
Mike
On Tue, Mar 16, 2010 at 4:57 PM, Otis Gospodnetic
wrote:
> Hi,
>
> Check out the dir s
Hi,
Check out the dir structure mentioned here:
http://markmail.org/message/gwpmaevw7tavqqge
Isn't that what we want?
Otis
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
Hadoop ecosystem search :: http://search-hadoop.com/
- Original Message
> From: Mark Miller
> T
[
https://issues.apache.org/jira/browse/SOLR-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846139#action_12846139
]
Otis Gospodnetic commented on SOLR-1375:
Heh, with the Lucene/Solr merge taking plac
[
https://issues.apache.org/jira/browse/SOLR-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bell updated SOLR-1828:
Description:
We would like to configure the DIH handler for a SLAVE connection for FULL
imports, and a MAST
DIH Handler separate connection for delta and full index
Key: SOLR-1828
URL: https://issues.apache.org/jira/browse/SOLR-1828
Project: Solr
Issue Type: Bug
Components: contrib
[
https://issues.apache.org/jira/browse/SOLR-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846099#action_12846099
]
Otis Gospodnetic commented on SOLR-1822:
When Solr starts, doesn't it create the ind
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846061#action_12846061
]
Hoss Man commented on SOLR-1817:
Hey mark: i've only had a chance to skim your patch so far,
: We try not to do that then. Things make a lot more sense when one
: starts thinking of them as a single project, w/o multiple downloads.
:
: If major modules were to be pulled from Solr and put into Lucene, and
: Solr wanted to make some big changes for a major version number bump?
: How could
On Tue, Mar 16, 2010 at 1:47 PM, Chris Hostetter
wrote:
> even if we get Lucene-Java and Solr onto the same
> scheme now, we could easily find ourselves in a situation where
> we're ready to release lucene-3.3 (ie: a minor release that is
> back-compat with lucene-3.2 and addss some new features)
The key word here is "end-user".
On Tue, Mar 16, 2010 at 10:57 AM, Kevin Osborn wrote:
> I definitely agree with Chris here. Although Lucene and Solr are highly
> related, the version numbering should communicate whether Solr has changed
> in a significant or minor way to the end-user. A minor c
[
https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-1743.
Resolution: Fixed
Committed revision 923909.
NOTE: since this bug was introduced after 1.4, and since i exp
I definitely agree with Chris here. Although Lucene and Solr are highly
related, the version numbering should communicate whether Solr has changed in a
significant or minor way to the end-user. A minor change in Lucene could cause
major changes in Solr. And vice-versa, a major change in Lucene c
: - since lucene is on a new major version, the next solr release
: containing that sould have a new major version number
This rationale concerns me less then making sure the version change
adequately communicates the significance of "upgrading' to users ... ie:
if most/many users will need to
+1 on moving to Java 6 since Java 5 has been EOL'ed.
Bill
On Tue, Mar 16, 2010 at 12:00 PM, Yonik Seeley wrote:
> One more addition:
> - Consider a different wiki... our current style will serve us poorly
> across major version bumps esp. We need versioning. A different
> option could inclu
One more addition:
- Consider a different wiki... our current style will serve us poorly
across major version bumps esp. We need versioning. A different
option could include moving more documentation onto the website, where
it would be versioned. Getting something easy to edit/change would be
On Tue, Mar 16, 2010 at 10:45 AM, Grant Ingersoll wrote:
>
> On Mar 16, 2010, at 11:00 AM, Yonik Seeley wrote:
>
>> Here is a very rough list of what makes sense to me:
>> - since lucene is on a new major version, the next solr release
>> containing that sould have a new major version number
>> -
On Mar 16, 2010, at 11:00 AM, Yonik Seeley wrote:
> Here is a very rough list of what makes sense to me:
> - since lucene is on a new major version, the next solr release
> containing that sould have a new major version number
> - this does not preclude further releases on 1.x
> - for simplicit
RunExecutableListener should be able to optionally capture the Error and Output
Streams
---
Key: SOLR-1827
URL: https://issues.apache.org/jira/browse/SOLR-1827
Projec
another minor addition:
- move to Junti4 for new tests... and some old tests might be
migrated (for speed issues)
I already have a SolrTestCaseJ4 that extends LuceneTestCase4J that
avoids spinning up a solr core for each test method... but I need to
be able to reference LuceneTestCase4J from the
[
https://issues.apache.org/jira/browse/SOLR-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Oestreicher updated SOLR-1826:
-
Attachment: SOLR-1826.txt
updated the patch because I borked the indentation
> highlighti
Here is a very rough list of what makes sense to me:
- since lucene is on a new major version, the next solr release
containing that sould have a new major version number
- this does not preclude further releases on 1.x
- for simplicity, and the "single dev" model, we should just sync
with luce
[
https://issues.apache.org/jira/browse/SOLR-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Oestreicher updated SOLR-1826:
-
Attachment: SOLR-1826.txt
I just realised that the field type definition in my patch is un
[
https://issues.apache.org/jira/browse/SOLR-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Oestreicher updated SOLR-1826:
-
Attachment: SOLR-1826.txt
attached patch demonstrates the problem
> highlighting breaks w
highlighting breaks when using WordDelimiterFilter and setting termOffsets=true
---
Key: SOLR-1826
URL: https://issues.apache.org/jira/browse/SOLR-1826
Project: Solr
SolrQuery.addFacetQuery should call setFacet(true)
--
Key: SOLR-1825
URL: https://issues.apache.org/jira/browse/SOLR-1825
Project: Solr
Issue Type: Bug
Components: clients - java
On Tue, Mar 16, 2010 at 3:43 AM, Simon Willnauer
wrote:
> One more thing which I wonder about even more is that this whole
> merging happens so quickly for reasons I don't see right now. I don't
> want to keep anybody from making progress but it appears like a rush
> to me.
By the way, the seri
46 matches
Mail list logo
