Re: Solr Java 1.6 ... was: Re: [jira] Commented: (SOLR-1873) Commit Solr Cloud to trunk
I'm fine with 1.6 as a min requirement... but i imagine others have different opinions :) On Wed, Apr 14, 2010 at 2:53 PM, Yonik Seeley yo...@lucidimagination.com wrote: Yes, it requires that Solr in general is compiled with Java6. We should make our lives easier and make Java6 a Solr requirement. Zookeeper requires Java6, and we also want Java6 for some of the scripting capabilities. -Yonik Apache Lucene Eurocon 2010 18-21 May 2010 | Prague On Wed, Apr 14, 2010 at 2:35 PM, Chris Hostetter hossman_luc...@fucit.org wrote: I haven't been following the Cloud stuff very closely, can someone clarify what exactly the situation is w/Solr Cloud and Java 1.6. Will merging the cloud changes to trunk require that core pieces of Solr be compiled/run with Java 1.6 (ie: a change to our minimum operating requirements) or will it just require that people wanting cloud management features use a 1.6 JVM and include a new solr contrib and appropriate config options at run time (and this contrib is the only thing that needs to be compiled with 1.6) ? As far as hudson and the build system goes ... there's certainly no reason we can't have more then one setup ... one build using JDK 1.5 (with the build.xml files detecting the JDK version and vocally not building the code that can't be compiled (either just the contrib, or all of solr) and a seperate build using JDK 1.6 that builds and test everything. (having this setup in general would be handy if/when other lucene contribs start wanting to incorporate Java 1.6 features) : bq. As I wrap up the remaining work here, one issue looms: We are going : to need to move Hudson to Java 6 before this can be committed. : : In most respects, I think that would be a positive anyway. Java6 is now : the primary production deployment platform for new projects (and it's : new projects that will be using new lucene and/or solr). With respect : to keeping Lucene Java5 compatible, we can always run the tests with : Java5 before commits (that's what I did in the past when Lucene was on : Java1.4) -Hoss
Re: Math Processing for Solr
(perhaps more appropriate on solr-user@) It sounds like you want to make a MathML filter? Check out the analyzer packages... http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters simple example: https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/src/java/org/apache/solr/analysis/LengthFilterFactory.java ryan 2010/4/14 m...@gjgt.sk: Hello everybody, I'm new to all this so I hope this isn't too noob a question and that it isn't very inappropriate here. I'm currently working on a indexing/searching application based on Apache Lucene core, that can process mathematical formulae in MathML format (which is extension to XML) and store it in the index for searching. No troubles here, since I'm making everything above Lucene. But I started to think it would be nice to write this mathematical extension so it could be incorporated into Solr as easy as possible in the future. The thing is I looked into Solr's sources and I'm all confused to be honest and don't know which way to do this. Basic workflow of the whole math processing would be: Check the input document for any math-if found, mathematical unit needs to process it and produce many string-represented formulae with different boosts-put these into index not tokenized furthermore. That's about it. Any ideas? Any help will be appreciated. Thank you Martin
Re: Document level security in Apache Solr
Hi Anders- see comments below... Two weeks ago I created a JIRA issue ( https://issues.apache.org/jira/browse/SOLR-1834) involving document level security in Apache Solr and submitted a patch containing a search component that can be seen as a starting point for making Solr handle document level security. I believe that document security is an essential part of an enterprise search engine and I hope that this contribution can start a discussion about how this should be handled in Solr (possibly in conjunction with the Lucene Connector Framework). Thanks for posting the code -- a quick pass it looks good. I agree some cordination with Lucene Connectors will make sense. On the patch, it looks good, but to get into the the dist, it will probably need some sort of tests. I'm not sure how that would work with windows authentication (I don't' know much about it, but it has been on my long term TODO list for a while!) Perhaps we could have tests that would run on systems that have somethign to test agains, but not fail when running on linux (or something) As this contribution shows I would like to help to develop the security capabilities of Solr together with the community because I believe that it will improve Solr’s appeal to large enterprises. Moreover I think that most of us believe that a transparent security system will in the end give rise to the best security. agree -- the more people to poke holes, the better I hope some of you can take the time to look at the patch, try it out and think about: 1) 1. Should this be a contrib module in Solr? (And if so, what needs to be done to contribute it?) I think a contrib module makes sense. For things to move forward, a committer needs to step up to the plate. I would love to, but don't have much time soon. To make it easier for people to feel comfortable with it, tests and doc help lots. 2) 2. Should document level security be a core feature in Solr? (And if so, what is the best way to integrate it into Solr?) I'm not quite sure what you mean by 'core' -- I think it makes sense to live as a contrib for a while and see how things develop. 3) 3. How can this integrate with connectors like the Lucene Connector Framework? I.e. how do you create a uniform way to talk about Access Control Lists (http://en.wikipedia.org/wiki/Access_control_list). good question! That would be really powerful. P.s (for the nerdy) I have some ideas about putting the security deeper into Solr, perhaps by creating a secure SolrIndexReader and a secure SolrIndexSearcher that are fed user credentials from a search component. What do you think about this? What are you thinking here? To me, it seems like the index would need to contain all data and a SearchComponet would take user credentials and augment the query (group:[a b c] or whatever) The advantage of keeping the same IndexSearch across all users is that it can share a cache where appropriate. As I understand it, currently it’s possible to declare your own SolrIndexReader but not your own SolrIndexSearcher. not sure on this... ryan
Re: Mailing List merge
why not just d...@lucene.apache.org? On Mon, Mar 22, 2010 at 11:44 AM, Grant Ingersoll gsing...@apache.org wrote: Shall we merge the dev mailing lists? This should reduce the cross-posting and can be completely automated (other than you may have to update your client-side filters) and was part of the plan to merge dev efforts. I'd propose it be called lucene-solr-...@l.a.o. I can put in an issue for infra@ to do it. -Grant - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Mailing List merge
Logistically, how would this work? would d...@lucene.apache.org be an alias for java-dev and solr-dev? or a whole new list? Would people need to subscribe to it, or would you already be on the list if you were on java/solr dev? If we are on both lists, do we get two copies of every message? On Mon, Mar 22, 2010 at 11:44 AM, Grant Ingersoll gsing...@apache.org wrote: Shall we merge the dev mailing lists? This should reduce the cross-posting and can be completely automated (other than you may have to update your client-side filters) and was part of the plan to merge dev efforts. I'd propose it be called lucene-solr-...@l.a.o. I can put in an issue for infra@ to do it. -Grant - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Branding Solr+Lucene
I'm confused... what is the need for a new name? The only place where there is a conflict is in the top level svn tree... What about something general like: https://svn.apache.org/repos/asf/lucene/dev or https://svn.apache.org/repos/asf/lucene/project ryan On Mon, Mar 22, 2010 at 2:02 PM, Steven A Rowe sar...@syr.edu wrote: Now that Solr and Lucene live in the same space, there has been an on-going debate about what to call the merged entity. The names being mulled at this point include (variously sized) snippets of both Lucene's and Solr's names, and include LuSolr, Solcene, etc. (my current personal favorites along these lines: Sorlusr :) ). My guess is that Lucene partisans would like to see Solr just become a product (along with the Lucene java library) of the Lucene project. Judging from suggestions coming from Solr partisans, though, I don't think this will fly. So I think an entirely new name is needed for the merged project. Lucene and Solr would remain the product names of this newly named merged project. Along these lines, search.apache.org has been brought up a couple of times recently on the #lucene IRC channel. However (with all due respect to what-happens-on-#lucene-stays-on-#lucene (TM) ), Grant wrote in response to one of these suggestions this morning: prob. is Search is not a brand ASF likes names So in the spirit of a real name (i.e., an abstract symbol), I propose Srrrch (riffing off of Riot Grrrls and Solr's penchant for vowel droppings) Okay, not really. I do have one idea, though: thinking about the icons for Lucene (looks to me like the font used on 50's automobile brand logos) and Solr (a sun): car+sun = convertible = Ragtop. Fun, short, abstract, apolitical. Solr's and Lucene's icons could be easily embedded in a Ragtop logo. Steve - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: rough outline of where Solr's going
I don't see a compelling reason to go to 3.1. It is going to be very confusing for users (when did 3.0 come out? Did I miss it?) At least when MS Word jumped from 2.0 to 6.0 it wasn't to a minor version (i.e. 6.1). 2.0 seems reasonable, as does 1.5. Although 2.0 would be a good reason to get rid of deprecations. I agree. 2.0 or 1.5 makes the most sense. (In the past I suggested we may not be at 2.0 yet... but with all the internal re-jiggering, I now think 2.0 would be best). Locking the solr major number to lucene major number does not make any sense to me. Say there were a major change to solr (for argument sake, perhaps it gets in bed with spring), but there is no major change in lucene... then what?
Re: multiple cores w/same name in solr.xml ???
Is there any reason why CoreContainer shouldn't throw an exception if solr.xml declares a core w/o a name, or two cores with the same name? This makes sense. I think WAY WAY back (in a patch), cores could be initialized by index, but that became moot with the CoreContainer stuff. ryan
Re: LucidWorks for Solr Reference Guide on front page?
On Jan 12, 2010, at 5:45 AM, Erik Hatcher wrote: Hey gang, I'd like to put an image and link to our LucidWorks for Solr Certified Distro Reference Guide on the Solr front page, and wondering if there were any objections. To toss out my only objection with my Apache hat on (yes, I'm really wearing it!), the reference guide isn't strictly about *Apache* Solr, it's about our distro of it. So there is just a little bit more than in the distro (like kstem, tomcat). But then again, the Packt book* has more than what's in Solr 1.4 too (localsolr, field collapsing). Here's a link to our reference guide, that includes the image I'd use too: http://www.lucidimagination.com/Downloads/LucidWorks-for-Solr/Reference-Guide If there are no objections, I'll add it sometime this week. +1, more doc is better then less! ryan
Re: svn commit: r898393 [1/3] - in /lucene/solr/branches/cloud: ./ client/ruby/solr-ruby/solr/conf/ client/ruby/solr-ruby/test/conf/ contrib/clustering/ contrib/clustering/lib/ contrib/clustering/src/
On Jan 12, 2010, at 10:59 AM, markrmil...@apache.org wrote: Author: markrmiller Date: Tue Jan 12 15:59:01 2010 New Revision: 898393 URL: http://svn.apache.org/viewvc?rev=898393view=rev Log: merge up to r898346 dooh, sorry mark -- hope that was not too difficult. thanks ryan
[jira] Commented: (SOLR-1715) Externally Generated Filters
[ https://issues.apache.org/jira/browse/SOLR-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12798797#action_12798797 ] Ryan McKinley commented on SOLR-1715: - this would also be a good way to 'punt' complex geographic queries to some other system. Externally Generated Filters Key: SOLR-1715 URL: https://issues.apache.org/jira/browse/SOLR-1715 Project: Solr Issue Type: New Feature Components: search Reporter: Grant Ingersoll Priority: Minor Fix For: 1.6, 2.0 I'd like to have a way of loading document filters from externally generated sources. For instance, I may have run a clustering task over my corpus and the results may be stored in HDFS (Hadoop). A given cluster will have a centroid and a bunch of points that are in the cluster. The points are labeled by doc id (the Solr doc id) from the index. Another example is I may have an external security system that can provide info on which documents are available to a user. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley reassigned SOLR-1602: --- Assignee: Ryan McKinley (was: Noble Paul) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Assignee: Ryan McKinley Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799059#action_12799059 ] Ryan McKinley commented on SOLR-1602: - I made a few changes to /trunk, but we are still missing: 1. error messages 2. CHANGES.txt 3. FQN seems to be the only thing that worked easily. Need to look into it more to see what we can do with SolrResourceLoader Now that the main changes are in, attaching patces is useful :) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Assignee: Ryan McKinley Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797677#action_12797677 ] Ryan McKinley commented on SOLR-1602: - | .Besides which: even if it's just an example it would be pretty shitty to break that example in the very next release. Agreed -- we will make sure old FQNs work (until the next major release), but moving forward, we should remove FQN from schema.xml so this is less of an issue in the future. Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797678#action_12797678 ] Ryan McKinley commented on SOLR-1602: - Nobel, this issue is assigned to you? Do you want to take care of it? If not I can... Patches won't work well since it will be a few steps in svn to make sure the history is maintained: 1. svn move the files to a new location, update references etc 2. commit 3. add stub files in the location where the old files were 4. commit Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Race condition in org/apache/solr/client/solrj/impl/StreamingUpdateSolrServer
can you submit a patch to JIRA?
On Jan 7, 2010, at 10:23 AM, Attila Babo wrote:
While inserting a large pile of documents using
StreamingUpdateSolrServer I've found a race condition as all Runner
instances stopped while the blocking queue was full. The attached
patch solves the problem, to minify it all indentation has been
removed.
Index: src/solrj/org/apache/solr/client/solrj/impl/
StreamingUpdateSolrServer.java
===
--- src/solrj/org/apache/solr/client/solrj/impl/
StreamingUpdateSolrServer.java (revision
888167)
+++ src/solrj/org/apache/solr/client/solrj/impl/
StreamingUpdateSolrServer.java (working
copy)
@@ -82,6 +82,7 @@
log.info( starting runner: {} , this );
PostMethod method = null;
try {
+do {
RequestEntity request = new RequestEntity() {
// we don't know the length
public long getContentLength() { return -1; }
@@ -142,6 +143,7 @@
msg.append( request: +method.getURI() );
handleError( new Exception( msg.toString() ) );
}
+} while( ! queue.isEmpty());
}
catch (Throwable e) {
handleError( e );
@@ -149,6 +151,7 @@
finally {
try {
// make sure to release the connection
+ if(method != null)
method.releaseConnection();
}
catch( Exception ex ){}
@@ -195,11 +198,11 @@
queue.put( req );
+synchronized( runners ) {
if( runners.isEmpty()
|| (queue.remainingCapacity() queue.size()
runners.size() threadCount) )
{
-synchronized( runners ) {
Runner r = new Runner();
scheduler.execute( r );
runners.add( r );
===
This patch has been tested with millions of document inserted to Solr,
before that I was unable to inject all of our documents as the
following scenario happened. We have a BlockingQueue called runners to
handle requests, at one point the queue was emptied by the Runner
threads, they all stopped processing new items but sent the collected
items to Solr. Solr was busy so that toke a long time, during that the
client filled the queue again. As all worker threads were instantiated
there were no way to create new Runners to handle the queue so it was
growing to upper limit. When the next item was about to put into the
queue it was blocked and the race condition just happened.
Patch 1, 2:
Inside the Runner.run method I've added a do while loop to prevent the
Runner to quit while there are new requests, this handles the problem
of new requests added while Runner is sending the previous batch.
Patch 3
Validity check of method variable is not strictly necessary, just a
code clean up.
Patch 4
The last part of the patch is to move synchronized outside of
conditional to avoid a situation where runners change while evaluating
it.
Your comments and critique are welcome!
Attila
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797227#action_12797227 ] Ryan McKinley commented on SOLR-1602: - Hey Chris- Don't worry about putting up a patch... the real work is just svn move and that does not work well with patches. Lets wait a few days and see if there are no objections, I will do the refactoring (and replacing) on the repos that would get committed. ryan Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
[
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12796280#action_12796280
]
Ryan McKinley commented on SOLR-1568:
-
I'm torn on this also...
The function query syntax (and all local params really) are a bit cryptic.
When I look into it though they are really powerful, and i see an advantage to
having that level of control. (and it works in solr now)
I wonder if there is a simple way to add query rewriting that would convert:
lat=49long=-77radius=10
to:
fq={!sfilt p=49,-77 f=location dist=10}
Perhaps a RequestRewrite component?
I doubt adding something like http://tuckey.org/urlrewrite/ would work
off-the-shelf, but it could go a long way to hide the ugly innards for a simple
case like this, yet still allow the power of the function query syntax.
Implement Spatial Filter
Key: SOLR-1568
URL: https://issues.apache.org/jira/browse/SOLR-1568
Project: Solr
Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 1.5
Attachments: CartesianTierQParserPlugin.java
Given an index with spatial information (either as a geohash,
SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be
able to pass in a filter query that takes in the field name, lat, lon and
distance and produces an appropriate Filter (i.e. one that is aware of the
underlying field type for use by Solr.
The interface _could_ look like:
{code}
fq={!sfilt dist=20}location:49.32,-79.0
{code}
or it could be:
{code}
fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
{code}
or:
{code}
fq={!sfilt p=49.32,-79.0 f=location dist=20}
{code}
or:
{code}
fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12796285#action_12796285 ] Ryan McKinley commented on SOLR-1602: - In an effort to get some resolution here... There are only three options: A. Leave it as is B. Refactor *with* deprecations --C. Refactor without deprecations-- C is out, so A and B are the only options worth discussing. The advantage of B is that the package: o.a.s.response would be clean and organized (but o.a.s.request would still have a bunch of deprecated files) The arguments for A amount to: things are fine as they are, or the confusion of changing is not worth whatever slight gain we would get The strong resistance is to 'C', I suspect wider ambivalence towards 'B' Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
[
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12796352#action_12796352
]
Ryan McKinley commented on SOLR-1568:
-
{quote}
could be written as
{code}
fq={!sfilt f=location}
p=49,-77
d=1000
{code}
{quote}
Jeez -- I had no idea... then I think (most?) cases are taken care of...
With this, a handler could be defined with the default param: 'fq={!sfilt
f=location}' and the 'end user' could simply call:
p=49,-77d=1000
never needing to grock the local-params/function syntax.
Implement Spatial Filter
Key: SOLR-1568
URL: https://issues.apache.org/jira/browse/SOLR-1568
Project: Solr
Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 1.5
Attachments: CartesianTierQParserPlugin.java
Given an index with spatial information (either as a geohash,
SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be
able to pass in a filter query that takes in the field name, lat, lon and
distance and produces an appropriate Filter (i.e. one that is aware of the
underlying field type for use by Solr.
The interface _could_ look like:
{code}
fq={!sfilt dist=20}location:49.32,-79.0
{code}
or it could be:
{code}
fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
{code}
or:
{code}
fq={!sfilt p=49.32,-79.0 f=location dist=20}
{code}
or:
{code}
fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1694) DocFrequencyValueSource
DocFrequencyValueSource --- Key: SOLR-1694 URL: https://issues.apache.org/jira/browse/SOLR-1694 Project: Solr Issue Type: New Feature Components: search Reporter: Ryan McKinley Priority: Minor A ValueSource to expose the document frequency for a given field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1694) DocFrequencyValueSource
[
https://issues.apache.org/jira/browse/SOLR-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1694:
Attachment: SOLR-1694-DocFrequencyValueSource.patch
This is a first draft, it gets the DF with:
{code:java}
public DocValues getValues(Map context, final IndexReader reader) throws
IOException
{
final String[] arr = cache.getStrings(reader, field);
return new DocValues() {
public int intVal(int doc)
{
try {
int v = reader.docFreq( new Term( qfield, arr[doc] ) );
//System.out.println( DF(+arr[doc]+:+v );
return v;
}
catch (IOException e) {
e.printStackTrace();
}
return 0;
}
{code}
You call the function with:
{code}
http://localhost:3456/solr/select?q=*:*sort=df(id,links) desc
{code}
NOTE: right now this only works with string fields
DocFrequencyValueSource
---
Key: SOLR-1694
URL: https://issues.apache.org/jira/browse/SOLR-1694
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Ryan McKinley
Priority: Minor
Attachments: SOLR-1694-DocFrequencyValueSource.patch
A ValueSource to expose the document frequency for a given field.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1694) DocFrequencyValueSource
[ https://issues.apache.org/jira/browse/SOLR-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12796079#action_12796079 ] Ryan McKinley commented on SOLR-1694: - I don't know if folks think this is generally useful... if yes, then I would love feedback and move forward on commiting. If not, i can just use it as a plugin DocFrequencyValueSource --- Key: SOLR-1694 URL: https://issues.apache.org/jira/browse/SOLR-1694 Project: Solr Issue Type: New Feature Components: search Reporter: Ryan McKinley Priority: Minor Attachments: SOLR-1694-DocFrequencyValueSource.patch A ValueSource to expose the document frequency for a given field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer
[
https://issues.apache.org/jira/browse/SOLR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795737#action_12795737
]
Ryan McKinley commented on SOLR-1690:
-
I have been using it to have structured data stored in a single field. Kind of
like a less cryptic version of:
http://wiki.apache.org/solr/UserTagDesign
I'm not sure it belongs in /trunk, but wanted to post it here so that others
could use it if they want...
JSONKeyValueTokenizerFactory -- JSON Tokenizer
--
Key: SOLR-1690
URL: https://issues.apache.org/jira/browse/SOLR-1690
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Reporter: Ryan McKinley
Priority: Minor
Attachments: noggit-1.0-A1.jar,
SOLR-1690-JSONKeyValueTokenizerFactory.patch
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key
values pairs in the json.
{code:xml|title=schema.xml}
!-- JSON Field Type --
fieldtype name=json class=solr.TextField positionIncrementGap=100
omitNorms=true
analyzer type=index
tokenizer class=solr.JSONKeyValueTokenizerFactory keepArray=true
hierarchicalKey=false/
filter class=solr.TrimFilterFactory/
filter class=solr.LowerCaseFilterFactory/
/analyzer
analyzer type=query
tokenizer class=solr.KeywordTokenizerFactory/
filter class=solr.TrimFilterFactory /
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldtype
{code}
Given text:
{code}
{ hello: world, rank:5 }
{code}
indexed as two tokens:
|| term position |1 | 2 |
|| term text |hello:world | rank:5 |
|| term type |word | word |
|| source start,end | 12,17 | 27,28 |
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795341#action_12795341
]
Ryan McKinley commented on SOLR-1602:
-
Sounds fine... except for the back compatibility issues -- especially for
people upgrading with the same solrconfig.xml
When we moved all the handlers to a new package o.a.solr.handler, it left a
bunch of deprecated calsses in o.a.solr.request:
{code:java}
@Deprecated
public class StandardRequestHandler extends
org.apache.solr.handler.StandardRequestHandler {
// Don't use this class
}
{code}
Also, if we make a 'response' package, seems SolrQueryResponse.java should go
there.
Refactor SOLR package structure to include o.a.solr.response and move
QueryResponseWriters in there
---
Key: SOLR-1602
URL: https://issues.apache.org/jira/browse/SOLR-1602
Project: Solr
Issue Type: Improvement
Components: Response Writers
Affects Versions: 1.2, 1.3, 1.4
Environment: independent of environment (code structure)
Reporter: Chris A. Mattmann
Fix For: 1.5
Attachments: SOLR-1602.Mattmann.112509.patch.txt,
SOLR-1602.Mattmann.112509_02.patch.txt
Currently all o.a.solr.request.QueryResponseWriter implementations are
curiously located in the o.a.solr.request package. Not only is this package
getting big (30+ classes), a lot of them are misplaced. There should be a
first-class o.a.solr.response package, and the response related classes
should be given a home there. Patch forthcoming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795352#action_12795352 ] Ryan McKinley commented on SOLR-1602: - | I'm a fan of number 2, and I'd venture to guess the work wouldn't be too bad in this case since most of the ReponseWriters aren't friendly to user extension or sub-classing. +1 but since this is a breaking change -- that would need explicitly called out in CHANGES.txt, we should get pretty wide consensus before moving forward... Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] SOLR-1602 Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
Here's what you're voting on: [ x] Yes, move forward with SOLR-1602 with the plan proposed above [ ] No, don't move forward with SOLR-1602 because... I'll leave the vote open for 72 hours. Votes from SOLR committers are binding, but everyone is welcome to voice your opinion. Not to throw cold water on the formality... but.. when I suggested we get broader approval, i was not thinking about jumping into a formal vote... Seems odd to put a three day window while many people are on vacation :) ryan
[jira] Created: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer
JSONKeyValueTokenizerFactory -- JSON Tokenizer
--
Key: SOLR-1690
URL: https://issues.apache.org/jira/browse/SOLR-1690
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Reporter: Ryan McKinley
Priority: Minor
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key values
pairs in the json.
For example, the text:
{code}
{ hello: world, rank:5 }
{code}
gets indexed as two tokens:
|| term position | 1 | 2 |
|| term text | hello:world | rank:5 |
|| term type | word | word |
|| source start,end | 12,17 | 27,28 |
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer
[
https://issues.apache.org/jira/browse/SOLR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1690:
Attachment: SOLR-1690-JSONKeyValueTokenizerFactory.patch
Here is a simple JSON tokenizer. No tests, but a good place to start if you
are looking to do something similar.
JSONKeyValueTokenizerFactory -- JSON Tokenizer
--
Key: SOLR-1690
URL: https://issues.apache.org/jira/browse/SOLR-1690
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Reporter: Ryan McKinley
Priority: Minor
Attachments: SOLR-1690-JSONKeyValueTokenizerFactory.patch
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key
values pairs in the json.
For example, the text:
{code}
{ hello: world, rank:5 }
{code}
gets indexed as two tokens:
|| term position |1 | 2 |
|| term text |hello:world | rank:5 |
|| term type |word | word |
|| source start,end | 12,17 | 27,28 |
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer
[
https://issues.apache.org/jira/browse/SOLR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1690:
Attachment: noggit-1.0-A1.jar
This tokenizer uses noggit
http://svn.apache.org/repos/asf/labs/noggit/
JSONKeyValueTokenizerFactory -- JSON Tokenizer
--
Key: SOLR-1690
URL: https://issues.apache.org/jira/browse/SOLR-1690
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Reporter: Ryan McKinley
Priority: Minor
Attachments: noggit-1.0-A1.jar,
SOLR-1690-JSONKeyValueTokenizerFactory.patch
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key
values pairs in the json.
For example, the text:
{code}
{ hello: world, rank:5 }
{code}
gets indexed as two tokens:
|| term position |1 | 2 |
|| term text |hello:world | rank:5 |
|| term type |word | word |
|| source start,end | 12,17 | 27,28 |
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1690) JSONKeyValueTokenizerFactory -- JSON Tokenizer
[
https://issues.apache.org/jira/browse/SOLR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1690:
Description:
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key values
pairs in the json.
{code:xml|title=schema.xml}
!-- JSON Field Type --
fieldtype name=json class=solr.TextField positionIncrementGap=100
omitNorms=true
analyzer type=index
tokenizer class=solr.JSONKeyValueTokenizerFactory keepArray=true
hierarchicalKey=false/
filter class=solr.TrimFilterFactory/
filter class=solr.LowerCaseFilterFactory/
/analyzer
analyzer type=query
tokenizer class=solr.KeywordTokenizerFactory/
filter class=solr.TrimFilterFactory /
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldtype
{code}
Given text:
{code}
{ hello: world, rank:5 }
{code}
indexed as two tokens:
|| term position | 1 | 2 |
|| term text | hello:world | rank:5 |
|| term type | word | word |
|| source start,end | 12,17 | 27,28 |
was:
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key values
pairs in the json.
For example, the text:
{code}
{ hello: world, rank:5 }
{code}
gets indexed as two tokens:
|| term position | 1 | 2 |
|| term text | hello:world | rank:5 |
|| term type | word | word |
|| source start,end | 12,17 | 27,28 |
JSONKeyValueTokenizerFactory -- JSON Tokenizer
--
Key: SOLR-1690
URL: https://issues.apache.org/jira/browse/SOLR-1690
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Reporter: Ryan McKinley
Priority: Minor
Attachments: noggit-1.0-A1.jar,
SOLR-1690-JSONKeyValueTokenizerFactory.patch
Sometimes it is nice to group structured data into a single field.
This (rough) patch, takes JSON input and indexes tokens based on the key
values pairs in the json.
{code:xml|title=schema.xml}
!-- JSON Field Type --
fieldtype name=json class=solr.TextField positionIncrementGap=100
omitNorms=true
analyzer type=index
tokenizer class=solr.JSONKeyValueTokenizerFactory keepArray=true
hierarchicalKey=false/
filter class=solr.TrimFilterFactory/
filter class=solr.LowerCaseFilterFactory/
/analyzer
analyzer type=query
tokenizer class=solr.KeywordTokenizerFactory/
filter class=solr.TrimFilterFactory /
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldtype
{code}
Given text:
{code}
{ hello: world, rank:5 }
{code}
indexed as two tokens:
|| term position |1 | 2 |
|| term text |hello:world | rank:5 |
|| term type |word | word |
|| source start,end | 12,17 | 27,28 |
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795428#action_12795428 ] Ryan McKinley commented on SOLR-1602: - | the patch does not apply. iis it not updated to trunk? I've never had good luck with patches for moving files. Even if it applies correctly, if you commit the patch, the svn history does not show that the file was moved. (unless this has been fixed in the last year since i looked) For refactoring like this, whoever commits this will probably need to make the changes directly. Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there --- Key: SOLR-1602 URL: https://issues.apache.org/jira/browse/SOLR-1602 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: independent of environment (code structure) Reporter: Chris A. Mattmann Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt Currently all o.a.solr.request.QueryResponseWriter implementations are curiously located in the o.a.solr.request package. Not only is this package getting big (30+ classes), a lot of them are misplaced. There should be a first-class o.a.solr.response package, and the response related classes should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr 1.5 or 2.0?
On Nov 25, 2009, at 11:30 AM, Chris Hostetter wrote: : The point being: it's all been very informat up to now -- and that's : probably for the best. policies should evolve over time based on real : world situations that come up, and we're still in the process of doing : that. : : Agreed, but now that the elephant has been identified in the room, let's : come up with a policy then. What are your thoughts on my proposal (specified : earlier in this thread)? The elephant has been identified, and he's in the room, but he's in the far corner and he's not bothering anybody. my personal preference (at the moment) is to leave things undefined for now ... i'd rather see us get to a point where we say whoa, here is an actaul in the flesh cross roads where it feels wrong to release w/o bumping the major version and then to try and write down a policy ahead of time anticipating what that cross road is and how we we'll want to deal with it. if it's unspecified, it can be specified later when it actaully becomes an issue -- if it's specified, then people will feel like we are beholden to the specification, even if it doesn't wind up making as much sense in practice. (yonik: you're anarchist ways clearly rubbed off on me at apachecon) I agree with keeping it informal (for now) I agree with Mark that yes, we should do what we can to make the best choices about changes that affect compatibility. For sure. The thing about the 1.5/1.9/2.0 question that makes me uncomfortable is that it is applying the same 'official' rules from lucene to solr. I am not sure how well that maps in practice. What would a 1.9 release mean in solr? (I don't really want an answer, I just don't think it means the same thing in solr vs lucene) Again, i have nothing against calling the next release 2.0 -- I just think that 1.5 is also fine and keeps the door open for 2.0 to be a more fundamental change in solr (that may or may not happen) ryan
[jira] Commented: (SOLR-1589) Make FieldType#toInternal throw explicit Exceptions when Field values don't validate
[ https://issues.apache.org/jira/browse/SOLR-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12781282#action_12781282 ] Ryan McKinley commented on SOLR-1589: - | But SolrException != HttpRequestException, right? More, it's not a ServletContainerException. It's a SolrException +1, I think it would be good to have some more descriptive exceptions then just the HTTP ones. But I think any new exception classes should extend SolrException with a reasonable code. That is, InvalidFieldException extends SolrException( BAD_REQUEST ) or something like that. This way HTTP error codes will get passed correctly, OR the exception can be caught and dealt with. Make FieldType#toInternal throw explicit Exceptions when Field values don't validate Key: SOLR-1589 URL: https://issues.apache.org/jira/browse/SOLR-1589 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Environment: My MacBook pro laptop. Reporter: Chris A. Mattmann Priority: Minor Fix For: 1.5 As discussed on the mailing list: http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200911.mbox/%3c85641490-9e70-41b3-a32e-22935b688...@apache.org%3e I think we can do a better job of having explicit Exceptions when there is a problem creating the internal representation of a Field, as defined by FieldType#toInternal. Instead of throwing obscure RuntimeExceptions, let's create a FieldValidationException explicit type, and make o.a.solr.schema.FieldType#toInternal throw this Exception as part of its signature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr 1.5 or 2.0?
switching back to solr-dev... sorry for spinning off that thread... What is a serious change that would warrant a bump in your opinion? for example: - config overhaul. detangle the XML from the components. perhaps using spring. This is already done. No components read config from xml anymore SOLR-1198 nice work! I had not seen this.
[jira] Commented: (SOLR-1568) Implement Cartesian Tier Filter
[ https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12779726#action_12779726 ] Ryan McKinley commented on SOLR-1568: - | I think the best way is to maintain the code pieces in SOLR, try and flow them back into Lucene (those updates needed there), and then flow back into SOLR as releases in Lucene-ville are made. +1 Implement Cartesian Tier Filter --- Key: SOLR-1568 URL: https://issues.apache.org/jira/browse/SOLR-1568 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: CartesianTierQParserPlugin.java Given an index with cartesian tiers, we should be able to pass in a filter query that takes in the field name, lat, lon and radius and produces an appropriate Filter for use by Solr. Note, contrib/spatial has such a filter, so it may just be that we need to hook in a QParserPlugin to handle it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Functions as Filters
so I don't think any sort of generic cache is needed for geo. Agreed, no generic cache for geo. Was thinking about a generic cache for function calculations. I think even more generally would be good -- an easy way to share calculations between anything in the request cycle: function query, search components, request handlers, response writers. To avoid adding dependencies to stuff that does not need it, perhaps it makes sense to use the 'inform' model we have for SolrCoreAware type things. Perhaps (bad name as i'm just throwing stuff out there) SharedContextAware / inform( SharedContext ) ryan Potentially, we could have the need: sort, filter, facet and boost by function. And that calculation is likely the same over and over within a given request. Of course, if we add the pseudo-fields, then that effectively acts as a cache for the request. -Grant
Re: trunk is now open
And a big thank you to Grant for managing this release! thanks Grant On Nov 10, 2009, at 10:38 AM, Grant Ingersoll wrote: Feel free to move forward on 1.5... Announcement will be sent out shortly on 1.4. Good work everyone! -Grant
Re: [VOTE] 1.4 new RC up
+1 On Nov 6, 2009, at 2:25 PM, Yonik Seeley wrote: +1 for releasing these artifacts: 1cc3783316aa1f95ba5e250a4c1d0451 apache-solr-1.4.0.tgz 8da9395565736499f80542c8d05b3854 apache-solr-1.4.0.zip -Yonik http://www.lucidimagination.com On Fri, Nov 6, 2009 at 1:28 PM, Grant Ingersoll gsing...@apache.org wrote: OK, done. Same place as always. Looks like the Lucene release is finally going through, so let's get this finished up! On Nov 5, 2009, at 6:55 PM, Grant Ingersoll wrote: Sure. I'll do it tonight or first thing tomorrow morning. On Nov 5, 2009, at 6:04 PM, Yonik Seeley wrote: On Thu, Nov 5, 2009 at 7:40 PM, Grant Ingersoll gsing...@apache.org wrote: Hopefully, 4th time is the charm: http://people.apache.org/~gsingers/solr/1.4.0/ Can we respin???!!! https://issues.apache.org/jira/browse/SOLR-1543 -Yonik http://www.lucidimagination.com
Re: [VOTE] Release Solr 1.4.0
+1 On Oct 30, 2009, at 12:40 PM, Grant Ingersoll wrote: OK, take 3: http://people.apache.org/~gsingers/solr/1.4.0/ On Oct 30, 2009, at 8:10 AM, Grant Ingersoll wrote: Got it. Will upload shortly. On Oct 29, 2009, at 8:33 PM, Yonik Seeley wrote: On Thu, Oct 29, 2009 at 7:36 PM, Yonik Seeley yo...@lucidimagination.com wrote: Lucene 2.9.1 respin 3 vote has started... I'm downloading now and will test + check in. Done. You're up Grant! -Yonik http://www.lucidimagination.com
Re: [VOTE] Release Solr 1.4.0
+1 Integrated with my app, and things work well. (windows vista) Ran examples and everything worked as expected. (Mac OSX) On Oct 27, 2009, at 10:07 PM, Grant Ingersoll wrote: OK, new artifacts are up. On Oct 27, 2009, at 9:51 PM, Chris Hostetter wrote: : By other issues, I mean the duplicate libs. I think we can live with them. I agree ... i would have voted +1 already but i figured based on your commit you were in the process of doing a new one. -Hoss
Re: [VOTE] Release Solr 1.4.0
On Oct 28, 2009, at 9:12 PM, Nicholas Letourneau wrote: Not sure who gets a vote, Everyone gets to vote -- officially some votes are 'binding' but in practice this does not really matter. The more feedback there is, the more confidence we have that things are good (or need fixed) and this is my first message to this list, but I wanted to add that I deployed the maven artifacts (along with the lucene 2.9.1 ones) to my in house maven repository and successfully built all my solr dependant projects with dependency groupIdorg.apache.solr/groupId artifactIdsolr-core/artifactId version1.4.0/version /dependency dependency groupIdorg.apache.solr/groupId artifactIdsolr-solrj/artifactId version1.4.0/version /dependency Everything went swimingly and running mvn dependency:tree showed this output: [INFO] +- org.apache.solr:solr-core:jar:1.4.0:compile [INFO] | +- org.apache.lucene:lucene-analyzers:jar:2.9.1:compile [INFO] | | \- org.apache.lucene:lucene-core:jar:2.9.1:compile [INFO] | +- org.apache.lucene:lucene-highlighter:jar:2.9.1:compile [INFO] | +- org.apache.lucene:lucene-queries:jar:2.9.1:compile [INFO] | +- org.apache.lucene:lucene-snowball:jar:2.9.1:compile [INFO] | +- org.apache.lucene:lucene-memory:jar:2.9.1:compile [INFO] | +- org.apache.lucene:lucene-misc:jar:2.9.1:compile [INFO] | +- org.apache.lucene:lucene-spellchecker:jar:2.9.1:compile [INFO] | +- commons-codec:commons-codec:jar:1.3:compile [INFO] | +- commons-fileupload:commons-fileupload:jar:1.2.1:compile [INFO] | +- org.apache.solr:solr-commons-csv:jar:1.4.0:compile [INFO] | +- woodstox:wstx-asl:jar:3.2.7:compile [INFO] | \- org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile [INFO] \- org.apache.solr:solr-solrj:jar:1.4.0:compile [INFO]+- org.slf4j:slf4j-api:jar:1.5.5:compile [INFO]\- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile [INFO] \- stax:stax-api:jar:1.0.1:compile Nicholas Letourneau On 10/27/09 10/27 7:07 PM, Grant Ingersoll gsing...@apache.org wrote: OK, new artifacts are up. On Oct 27, 2009, at 9:51 PM, Chris Hostetter wrote: : By other issues, I mean the duplicate libs. I think we can live with them. I agree ... i would have voted +1 already but i figured based on your commit you were in the process of doing a new one. -Hoss
Re: Another RC
On Oct 26, 2009, at 4:00 PM, Grant Ingersoll wrote: So, just to clarify, here's the plan as I understand it: 1. Put up a 1.4.0 RC today w/ 2.9.1-RC2 2. Commence vote on 1.4.0 3. Once 2.9.1 is finalized, replace in Solr and generate final artifacts We also must make sure the maven pom.xml points to the right place. (currently it still points to 2.9... not the solr specific ones) 4. Release Is that correct? This basically works on the assumption that the only thing that has changed between 2.9.1-RC2 and 2.9.1 final is the name of the jars. If that is the case, I'm fine w/ this process. sounds good. Thanks Grant! -Grant On Oct 19, 2009, at 5:57 PM, Yonik Seeley wrote: OK, so let's do the following: as soon as the Lucene 2.9.1 official RC is put up (the one that will be voted on), I'll update Solr and we can do our vote at the same time, saving 3 or 4 days... this release has really been held up long enough :-) We can re-evaluate what to do if for some reason the Lucene vote doesn't pass (i.e., we won't blindly release Solr if the lucene vote fails). Hopefully everyone has looked at the latest Solr distributions for any potential showstoppers that would cause them to vote -1 during the official vote. -Yonik http://www.lucidimagination.com On Mon, Oct 19, 2009 at 1:35 PM, Walter Underwood wun...@wunderwood.org wrote: Please wait for an official release of Lucene. It makes thing SO much easier when you need to dig into the Lucene code. It is well worth a week delay. wunder On Oct 19, 2009, at 10:27 AM, Yonik Seeley wrote: On Mon, Oct 19, 2009 at 10:59 AM, Grant Ingersoll gsing...@apache.org wrote: Are we ready for a release? +1 I don't think we need to wait for Lucene 2.9.1 - we have all the fixes in our version, and there's little point in pushing things off yet another week. Seems like the next RC should be a *real* one (i.e. no RC label in the version, immediately call a VOTE). -Yonik http://www.lucidimagination.com I got busy at work and haven't been able to address things as much, but it seems like things are progressing. Shall I generate another RC or are we waiting for Lucene 2.9.1? If we go w/ the 2.9.1-dev, then we just need to restore the Maven stuff for them. Hopefully, that stuff was just commented out and not completely removed so as to make it a little easier to restore. -Grant
Re: [VOTE] Release Solr 1.4.0
Also, not sure what the policy is on voting on files where the pom still needs to change.. http://people.apache.org/~gsingers/solr/1.4.0/maven/org/apache/solr/solr-core/1.4.0/solr-core-1.4.0.pom points to: dependency groupIdorg.apache.lucene/groupId artifactIdlucene-analyzers/artifactId version2.9.0/version /dependency But we really want to point to 2.9.1 I guess we can go ahead and change that even though 2.9.1 does not exist in any repository yet? ryan On Oct 26, 2009, at 6:35 PM, Yonik Seeley wrote: Hmmm, weren't you going to update the version numbers to 1.4.1-dev like we just discussed in the other thread? That way if someone changes some of the solr source from the download and recompiles, they don't get a version number of 1.4.0 -Yonik http://www.lucidimagination.com On Mon, Oct 26, 2009 at 6:15 PM, Grant Ingersoll gsing...@apache.org wrote: Tis the season for releases... Please vote on releasing the Solr 1.4.0 artifacts located at http://people.apache.org/~gsingers/solr/1.4.0/ (note, solr.tar and solr-maven.tar are not artifacts to be released) CHANGES are spelled out at https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt Thanks, Grant
Re: Another RC
I've been testing with jetty 7.0.0.v20091005, and everything works good so far.. On Oct 25, 2009, at 3:59 PM, Yonik Seeley wrote: If all goes well in lucene-land 2.9.1 should start a vote on Monday sometime... I've recently tested the latest stable Jetty (6.1.21) ... so we can avoid some duplication, has anyone tested with the latest tomcat, resin, or other popular servlet containers? -Yonik http://www.lucidimagination.com On Mon, Oct 19, 2009 at 5:57 PM, Yonik Seeley yo...@lucidimagination.com wrote: OK, so let's do the following: as soon as the Lucene 2.9.1 official RC is put up (the one that will be voted on), I'll update Solr and we can do our vote at the same time, saving 3 or 4 days... this release has really been held up long enough :-) We can re-evaluate what to do if for some reason the Lucene vote doesn't pass (i.e., we won't blindly release Solr if the lucene vote fails). Hopefully everyone has looked at the latest Solr distributions for any potential showstoppers that would cause them to vote -1 during the official vote. -Yonik http://www.lucidimagination.com On Mon, Oct 19, 2009 at 1:35 PM, Walter Underwood wun...@wunderwood.org wrote: Please wait for an official release of Lucene. It makes thing SO much easier when you need to dig into the Lucene code. It is well worth a week delay. wunder On Oct 19, 2009, at 10:27 AM, Yonik Seeley wrote: On Mon, Oct 19, 2009 at 10:59 AM, Grant Ingersoll gsing...@apache.org wrote: Are we ready for a release? +1 I don't think we need to wait for Lucene 2.9.1 - we have all the fixes in our version, and there's little point in pushing things off yet another week. Seems like the next RC should be a *real* one (i.e. no RC label in the version, immediately call a VOTE). -Yonik http://www.lucidimagination.com I got busy at work and haven't been able to address things as much, but it seems like things are progressing. Shall I generate another RC or are we waiting for Lucene 2.9.1? If we go w/ the 2.9.1-dev, then we just need to restore the Maven stuff for them. Hopefully, that stuff was just commented out and not completely removed so as to make it a little easier to restore. -Grant
minor nit....
I'm looking through a bunch of logs that have:
UpdateRequestProcessor - {add=[aa, bb, cc, dd, ee, ff, gg, hh, ...(142 more)]}
Would it be more reasonable to say: 150 total rather then make you
count the previous 8?
kinda stupid, but i guess this is what drives you nuts while chasing
real problems...
ryan
[jira] Updated: (SOLR-1512) point build.xml to luke 0.9.9
[ https://issues.apache.org/jira/browse/SOLR-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-1512: Attachment: SOLR-1512-luke.patch pointing to luke 0.9.9 point build.xml to luke 0.9.9 - Key: SOLR-1512 URL: https://issues.apache.org/jira/browse/SOLR-1512 Project: Solr Issue Type: Task Reporter: Ryan McKinley Priority: Minor Fix For: 1.4 Attachments: SOLR-1512-luke.patch The luke launcher should point to luke 0.9.9 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1512) point build.xml to luke 0.9.9
[ https://issues.apache.org/jira/browse/SOLR-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-1512. - Resolution: Fixed point build.xml to luke 0.9.9 - Key: SOLR-1512 URL: https://issues.apache.org/jira/browse/SOLR-1512 Project: Solr Issue Type: Task Reporter: Ryan McKinley Priority: Minor Fix For: 1.4 Attachments: SOLR-1512-luke.patch The luke launcher should point to luke 0.9.9 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Outdated luke
thanks for pointing this out. Check: SOLR-1512, now fixed in trunk thanks ryan On Oct 15, 2009, at 10:58 AM, Colin Hynes wrote: I just thought I'd toss a note out that in the main build.xml it's fetching a outdated vesions of luke(0.9.1) and lucene(2.4). For the solr 1.4 release, that should probably change to: luke 0.9.9 lucene 2.9 -Colin Active Media Architects, Inc. World Class Design, Programming Strategy - Since 1998 http://www.activema.com 1-888-392-4567 toll free 1-586-445-1000 local 1-586-445-2247 fax
[jira] Commented: (SOLR-1510) EmbeddedSolrServer should support multiple cores
[ https://issues.apache.org/jira/browse/SOLR-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12765582#action_12765582 ] Ryan McKinley commented on SOLR-1510: - we went back and forth on this one for a while. Originally solrj knew how to handle different cores. What is the advantage of a single EmbeddedSolrServer talking to multiple cores vs an EmbeddedSolrServer for each core? (perhaps in a MapString,EmbeddedSolrServer) IIRC, adding cores to the SolrServer API gets complicated with the HTTP version -- but I don't remember exactly why. EmbeddedSolrServer should support multiple cores Key: SOLR-1510 URL: https://issues.apache.org/jira/browse/SOLR-1510 Project: Solr Issue Type: Improvement Reporter: Noble Paul Assignee: Noble Paul Priority: Minor Fix For: 1.5 currently , EmbeddedSolrServer can be started only with single core. This restriction should be removed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Down to 1
I'm on it! At least it is easy... On Oct 10, 2009, at 3:13 PM, Grant Ingersoll wrote: Down to 1: https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230versionId=12313351showOpenIssuesOnly=true Things are looking good for Monday. I'd encourage everyone to check out trunk and hit it with tests, etc. and post feedback here. -Grant
[jira] Resolved: (SOLR-1497) Remove solrjs from svn -- point docs to AJAX Solr
[ https://issues.apache.org/jira/browse/SOLR-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-1497. - Resolution: Fixed solrjs was removed in rev 824396 This can be pulled from subversion history if necessary Remove solrjs from svn -- point docs to AJAX Solr - Key: SOLR-1497 URL: https://issues.apache.org/jira/browse/SOLR-1497 Project: Solr Issue Type: Task Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 The solrjs version in solr source tree needs some attention, yet progress seems unlikely. Meanwhile, AJAX solr (a solrjs fork) has made good progress and seems that it will be supported moving forward. We should archive solrjs and remove it from the source tree. For discussion, see: http://www.lucidimagination.com/search/document/900bf257f8df4e37/archive_solrjs_and_point_to_ajax_solr#13f6cb2ec40ae1f0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Down to Zero!
Looks like we are down to zero issues: https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230versionId=12313351showOpenIssuesOnly=true
[jira] Created: (SOLR-1497) Remove solrjs from svn -- point docs to AJAX Solr
Remove solrjs from svn -- point docs to AJAX Solr - Key: SOLR-1497 URL: https://issues.apache.org/jira/browse/SOLR-1497 Project: Solr Issue Type: Task Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 The solrjs version in solr source tree needs some attention, yet progress seems unlikely. Meanwhile, AJAX solr (a solrjs fork) has made good progress and seems that it will be supported moving forward. We should archive solrjs and remove it from the source tree. For discussion, see: http://www.lucidimagination.com/search/document/900bf257f8df4e37/archive_solrjs_and_point_to_ajax_solr#13f6cb2ec40ae1f0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1294) SolrJS/Javascript client fails in IE8!
[ https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-1294. - Resolution: Won't Fix With SOLR-1497, solrjs devlopment will move to AJAX solr on github SolrJS/Javascript client fails in IE8! -- Key: SOLR-1294 URL: https://issues.apache.org/jira/browse/SOLR-1294 Project: Solr Issue Type: Bug Affects Versions: 1.4 Reporter: Eric Pugh Assignee: Ryan McKinley Fix For: 1.4 Attachments: jscalendar.tar, SOLR-1294-full.patch, SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch SolrJS seems to fail with 'jQuery.solrjs' is null or not an object errors under IE8. I am continuing to test if this occurs in IE 6 and 7 as well. This happens on both the Sample online site at http://solrjs.solrstuff.org/test/reuters/ as well as the /trunk/contrib/javascript library. Seems to be a show stopper from the standpoint of really using this library! I have posted a screenshot of the error at http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png The error is just a whole bunch of repeated messages in the vein of: Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js Message: 'jQuery.solrjs' is null or not an object Line: 37 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js Message: 'jQuery.solrjs' is null or not an object Line: 27 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1434) Evaluate Including SolrJS
[ https://issues.apache.org/jira/browse/SOLR-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-1434. - Resolution: Fixed Fix Version/s: 1.4 See SOLR-1497 Evaluate Including SolrJS - Key: SOLR-1434 URL: https://issues.apache.org/jira/browse/SOLR-1434 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Priority: Blocker Fix For: 1.4 SolrJS needs to be evaluated for inclusion in the release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1294) SolrJS/Javascript client fails in IE8!
[ https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762848#action_12762848 ] Ryan McKinley commented on SOLR-1294: - Looking over it, it seems interesting... what is the license? I see GPL, Apache, and MIT... is this offered under multiple licenses? While any fork of Apache code can do pretty much do whatever you like, it seems odd to split the community. I would love to adopt/promote the best solution available, but there will always be a need to an Apache style license (LGPL at the minimum) ryan SolrJS/Javascript client fails in IE8! -- Key: SOLR-1294 URL: https://issues.apache.org/jira/browse/SOLR-1294 Project: Solr Issue Type: Bug Affects Versions: 1.4 Reporter: Eric Pugh Assignee: Ryan McKinley Fix For: 1.4 Attachments: jscalendar.tar, SOLR-1294-full.patch, SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch SolrJS seems to fail with 'jQuery.solrjs' is null or not an object errors under IE8. I am continuing to test if this occurs in IE 6 and 7 as well. This happens on both the Sample online site at http://solrjs.solrstuff.org/test/reuters/ as well as the /trunk/contrib/javascript library. Seems to be a show stopper from the standpoint of really using this library! I have posted a screenshot of the error at http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png The error is just a whole bunch of repeated messages in the vein of: Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js Message: 'jQuery.solrjs' is null or not an object Line: 37 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js Message: 'jQuery.solrjs' is null or not an object Line: 27 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1294) SolrJS/Javascript client fails in IE8!
[ https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762860#action_12762860 ] Ryan McKinley commented on SOLR-1294: - sweet. If AJAX-Solr is Apache licensed, then I feel pretty good about archiving solrjs and focusing future attention towards AJAX-Solr. The concern with split the community is that many people in Apache land can not touch GPL code (myself included). With that constraint there would need to be two parallel efforts. Since AJAX-Solr is now Apache/MIT licensed, I see no reason to try to keep solrjs up-to-snuff, and think we can just point to AJAX-Solr. Lets check with solr-dev before dropping solrjs, but I think this is the best route forward. yaay. SolrJS/Javascript client fails in IE8! -- Key: SOLR-1294 URL: https://issues.apache.org/jira/browse/SOLR-1294 Project: Solr Issue Type: Bug Affects Versions: 1.4 Reporter: Eric Pugh Assignee: Ryan McKinley Fix For: 1.4 Attachments: jscalendar.tar, SOLR-1294-full.patch, SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch SolrJS seems to fail with 'jQuery.solrjs' is null or not an object errors under IE8. I am continuing to test if this occurs in IE 6 and 7 as well. This happens on both the Sample online site at http://solrjs.solrstuff.org/test/reuters/ as well as the /trunk/contrib/javascript library. Seems to be a show stopper from the standpoint of really using this library! I have posted a screenshot of the error at http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png The error is just a whole bunch of repeated messages in the vein of: Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js Message: 'jQuery.solrjs' is null or not an object Line: 37 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js Message: 'jQuery.solrjs' is null or not an object Line: 27 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1294) SolrJS/Javascript client fails in IE8!
[ https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762864#action_12762864 ] Ryan McKinley commented on SOLR-1294: - In your 'COPYRIGHT.txt' file, it says: [panel] AJAX Solr includes works under other copyright notices and distributed according to the terms of the GNU General Public License or a compatible license, including: jQuery strftime plugin - Copyright (c) 2008 Emmanuel Benoît [panel] If that is true, the Apache/MIT licenses don't help much... BUT it seems to me that strftime is distributed under the MIT license: http://projects.nocternity.net/index.py/en/jquery-strftime Are there other things in the code that are GPL? (sorry for all the license haggling, it just turns out to be a blocker issue) If strftime is not GPL, can you remove the notice about GPL code? (obviously only if that is true) thanks again SolrJS/Javascript client fails in IE8! -- Key: SOLR-1294 URL: https://issues.apache.org/jira/browse/SOLR-1294 Project: Solr Issue Type: Bug Affects Versions: 1.4 Reporter: Eric Pugh Assignee: Ryan McKinley Fix For: 1.4 Attachments: jscalendar.tar, SOLR-1294-full.patch, SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch SolrJS seems to fail with 'jQuery.solrjs' is null or not an object errors under IE8. I am continuing to test if this occurs in IE 6 and 7 as well. This happens on both the Sample online site at http://solrjs.solrstuff.org/test/reuters/ as well as the /trunk/contrib/javascript library. Seems to be a show stopper from the standpoint of really using this library! I have posted a screenshot of the error at http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png The error is just a whole bunch of repeated messages in the vein of: Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js Message: 'jQuery.solrjs' is null or not an object Line: 37 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js Message: 'jQuery.solrjs' is null or not an object Line: 27 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1294) SolrJS/Javascript client fails in IE8!
[
https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762864#action_12762864
]
Ryan McKinley edited comment on SOLR-1294 at 10/6/09 9:17 PM:
--
In your 'COPYRIGHT.txt' file, it says:
{code}
AJAX Solr includes works under other copyright notices and distributed
according to the terms of the GNU General Public License or a compatible
license, including:
jQuery strftime plugin - Copyright (c) 2008 Emmanuel Benoît
{code}
If that is true, the Apache/MIT licenses don't help much...
BUT it seems to me that strftime is distributed under the MIT license:
http://projects.nocternity.net/index.py/en/jquery-strftime
Are there other things in the code that are GPL? (sorry for all the license
haggling, it just turns out to be a blocker issue) If strftime is not GPL, can
you remove the notice about GPL code? (obviously only if that is true)
thanks again
was (Author: ryantxu):
In your 'COPYRIGHT.txt' file, it says:
[panel]
AJAX Solr includes works under other copyright notices and distributed
according to the terms of the GNU General Public License or a compatible
license, including:
jQuery strftime plugin - Copyright (c) 2008 Emmanuel Benoît
[panel]
If that is true, the Apache/MIT licenses don't help much...
BUT it seems to me that strftime is distributed under the MIT license:
http://projects.nocternity.net/index.py/en/jquery-strftime
Are there other things in the code that are GPL? (sorry for all the license
haggling, it just turns out to be a blocker issue) If strftime is not GPL, can
you remove the notice about GPL code? (obviously only if that is true)
thanks again
SolrJS/Javascript client fails in IE8!
--
Key: SOLR-1294
URL: https://issues.apache.org/jira/browse/SOLR-1294
Project: Solr
Issue Type: Bug
Affects Versions: 1.4
Reporter: Eric Pugh
Assignee: Ryan McKinley
Fix For: 1.4
Attachments: jscalendar.tar, SOLR-1294-full.patch,
SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch
SolrJS seems to fail with 'jQuery.solrjs' is null or not an object errors
under IE8. I am continuing to test if this occurs in IE 6 and 7 as well.
This happens on both the Sample online site at
http://solrjs.solrstuff.org/test/reuters/ as well as the
/trunk/contrib/javascript library. Seems to be a show stopper from the
standpoint of really using this library!
I have posted a screenshot of the error at
http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png
The error is just a whole bunch of repeated messages in the vein of:
Message: 'jQuery.solrjs' is null or not an object
Line: 24
Char: 1
Code: 0
URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js
Message: 'jQuery.solrjs' is null or not an object
Line: 37
Char: 1
Code: 0
URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js
Message: 'jQuery.solrjs' is null or not an object
Line: 24
Char: 1
Code: 0
URI:
file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js
Message: 'jQuery.solrjs' is null or not an object
Line: 27
Char: 1
Code: 0
URI:
file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
archive solrjs and point to AJAX Solr?
I don't think solrjs should hold up the 1.4 release. Since this issue was last discussed, James McKinney has licensed AJAX Solr (a solrjs fork) under Apache MIT http://github.com/evolvingweb/AJAX-Solr/blob/master/COPYRIGHT.txt It seems like this has good support and gets the on-going attention it deserves. I suggest we archive solrjs -- remove it from the 1.4 release -- and point javascript client lovers to AJAX-Solr. If we do archive solrjs, what do you think the best method is? 1. svn copy it to /sandbox? 2. make a zip and place it on an external site, remove it entirely from solr svn I lean towards option 1. thoughts ryan
[jira] Commented: (SOLR-1294) SolrJS/Javascript client fails in IE8!
[ https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762866#action_12762866 ] Ryan McKinley commented on SOLR-1294: - excellent -- thank you SolrJS/Javascript client fails in IE8! -- Key: SOLR-1294 URL: https://issues.apache.org/jira/browse/SOLR-1294 Project: Solr Issue Type: Bug Affects Versions: 1.4 Reporter: Eric Pugh Assignee: Ryan McKinley Fix For: 1.4 Attachments: jscalendar.tar, SOLR-1294-full.patch, SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch SolrJS seems to fail with 'jQuery.solrjs' is null or not an object errors under IE8. I am continuing to test if this occurs in IE 6 and 7 as well. This happens on both the Sample online site at http://solrjs.solrstuff.org/test/reuters/ as well as the /trunk/contrib/javascript library. Seems to be a show stopper from the standpoint of really using this library! I have posted a screenshot of the error at http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png The error is just a whole bunch of repeated messages in the vein of: Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js Message: 'jQuery.solrjs' is null or not an object Line: 37 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js Message: 'jQuery.solrjs' is null or not an object Line: 27 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1472) upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene artifacts
[
https://issues.apache.org/jira/browse/SOLR-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1472:
Attachment: SOLR-1472-maven-cleanup.patch
deleting the solr specific maven files.
I will go ahead and commit this
upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene
artifacts
--
Key: SOLR-1472
URL: https://issues.apache.org/jira/browse/SOLR-1472
Project: Solr
Issue Type: Task
Affects Versions: 1.4
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Blocker
Fix For: 1.4
Attachments: SOLR-1472-maven-cleanup.patch
Currently, the solr pom.xml files reference solr-lucene jar files. Rather
then reference the solr jars, we should reference the real lucene jar files.
Additionally, we need to add a reference to lucene-memory so we avoid:
{code}
java.lang.NoClassDefFoundError: org/apache/lucene/index/memory/MemoryIndex
at
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getReaderForField(WeightedSpanTermExtractor.java:313)
at
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extractWeightedSpanTerms(WeightedSpanTermExtractor.java:239)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1472) upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene artifacts
[
https://issues.apache.org/jira/browse/SOLR-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-1472.
-
Resolution: Fixed
committed in rev819835
When we want to use lucene snapshots again, we can get the template from this
patch or svn history.
upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene
artifacts
--
Key: SOLR-1472
URL: https://issues.apache.org/jira/browse/SOLR-1472
Project: Solr
Issue Type: Task
Affects Versions: 1.4
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Blocker
Fix For: 1.4
Attachments: SOLR-1472-maven-cleanup.patch
Currently, the solr pom.xml files reference solr-lucene jar files. Rather
then reference the solr jars, we should reference the real lucene jar files.
Additionally, we need to add a reference to lucene-memory so we avoid:
{code}
java.lang.NoClassDefFoundError: org/apache/lucene/index/memory/MemoryIndex
at
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getReaderForField(WeightedSpanTermExtractor.java:313)
at
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extractWeightedSpanTerms(WeightedSpanTermExtractor.java:239)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 8 for 1.4
I just discussed this off-line with Matthias. It does not look like he has the time to give this much attention now. (nor do I) We agreed that the best steps forward are to: 1. Support the Drupal guys GPL port 2. Archive the solrjs code to solrstuff.org 3. Yank solrjs from apache svn (and 1.4 release) 4. Add links to the drupal code (GPL) and the solrjs archive (Apache) Does this sound reasonable to everybody? ryan On Mon, Sep 28, 2009 at 1:27 PM, Grant Ingersoll gsing...@apache.org wrote: Forwarded with permission from Peter Wolanin on a private thread. Begin forwarded message: From: Peter Wolanin peter.wola...@acquia.com Date: September 26, 2009 9:43:23 AM EDT To: Grant Ingersoll gsing...@apache.org Subject: Re: 8 for 1.4 I talked to the guys reworking the JS library for Drupal at Drupalcon - they are also having to fork potentially around license as much as anything else, since they'd like to distribute via drupal.org, which means they were hoping to get the original author to re-license the code to them as GPL. -Peter On Fri, Sep 25, 2009 at 4:45 PM, Grant Ingersoll gsing...@apache.org wrote: Argh, this was meant for solr-dev. Begin forwarded message: From: Grant Ingersoll gsing...@apache.org Date: September 25, 2009 1:34:32 PM EDT To: solr-u...@lucene.apache.org Subject: 8 for 1.4 Reply-To: solr-u...@lucene.apache.org Y'all, We're down to 8 open issues: https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230versionId=12313351showOpenIssuesOnly=true 2 are packaging related, one is dependent on the official 2.9 release (so should be taken care of today or tomorrow I suspect) and then we have a few others. The only two somewhat major ones are S-1458, S-1294 (more on this in a mo') and S-1449. On S-1294, the SolrJS patch, I yet again have concerns about even including this, given the lack of activity (from Matthias, the original author and others) and the fact that some in the Drupal community have already forked this to fix the various bugs in it instead of just submitting patches. While I really like the idea of this library (jQuery is awesome), I have yet to see interest in the community to maintain it (unless you count someone forking it and fixing the bugs in the fork as maintenance) and I'll be upfront in admitting I have neither the time nor the patience to debug Javascript across the gazillions of browsers out there (I don't even have IE on my machine unless you count firing up a VM w/ XP on it) in the wild. Given what I know of most of the other committers here, I suspect that is true for others too. At a minimum, I think S-1294 should be pushed to 1.5. Next up, I think we consider pulling SolrJS from the release, but keeping it in trunk and officially releasing it with either 1.5 or 1.4.1, assuming its gotten some love in the meantime. If by then it has no love, I vote we remove it and let the fork maintain it and point people there. -Grant -- Peter M. Wolanin, Ph.D. Momentum Specialist, Acquia. Inc. peter.wola...@acquia.com -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search
Re: 8 for 1.4
can we leave it in svn, but drop it from the release? logistically, what is the best way to do this? Make a branch now, remove it from /trunk, after release copy it from the branch back into /trunk? That seems like the best way to kick the can down the road. I agree an off-the-shelf apache license jquery client is great. ryan On Mon, Sep 28, 2009 at 9:13 PM, Grant Ingersoll gsing...@apache.org wrote: Moving to GPL doesn't seem like a good solution to me, but I don't know what else to propose. Why don't we just hold it from this release, but keep it in trunk and encourage the Drupal guys and others to submit their changes? Perhaps by then Matthias or you or someone else will have stepped up. On Sep 28, 2009, at 7:27 PM, Ryan McKinley wrote: I just discussed this off-line with Matthias. It does not look like he has the time to give this much attention now. (nor do I) We agreed that the best steps forward are to: 1. Support the Drupal guys GPL port 2. Archive the solrjs code to solrstuff.org 3. Yank solrjs from apache svn (and 1.4 release) 4. Add links to the drupal code (GPL) and the solrjs archive (Apache) Does this sound reasonable to everybody? ryan On Mon, Sep 28, 2009 at 1:27 PM, Grant Ingersoll gsing...@apache.org wrote: Forwarded with permission from Peter Wolanin on a private thread. Begin forwarded message: From: Peter Wolanin peter.wola...@acquia.com Date: September 26, 2009 9:43:23 AM EDT To: Grant Ingersoll gsing...@apache.org Subject: Re: 8 for 1.4 I talked to the guys reworking the JS library for Drupal at Drupalcon - they are also having to fork potentially around license as much as anything else, since they'd like to distribute via drupal.org, which means they were hoping to get the original author to re-license the code to them as GPL. -Peter On Fri, Sep 25, 2009 at 4:45 PM, Grant Ingersoll gsing...@apache.org wrote: Argh, this was meant for solr-dev. Begin forwarded message: From: Grant Ingersoll gsing...@apache.org Date: September 25, 2009 1:34:32 PM EDT To: solr-u...@lucene.apache.org Subject: 8 for 1.4 Reply-To: solr-u...@lucene.apache.org Y'all, We're down to 8 open issues: https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230versionId=12313351showOpenIssuesOnly=true 2 are packaging related, one is dependent on the official 2.9 release (so should be taken care of today or tomorrow I suspect) and then we have a few others. The only two somewhat major ones are S-1458, S-1294 (more on this in a mo') and S-1449. On S-1294, the SolrJS patch, I yet again have concerns about even including this, given the lack of activity (from Matthias, the original author and others) and the fact that some in the Drupal community have already forked this to fix the various bugs in it instead of just submitting patches. While I really like the idea of this library (jQuery is awesome), I have yet to see interest in the community to maintain it (unless you count someone forking it and fixing the bugs in the fork as maintenance) and I'll be upfront in admitting I have neither the time nor the patience to debug Javascript across the gazillions of browsers out there (I don't even have IE on my machine unless you count firing up a VM w/ XP on it) in the wild. Given what I know of most of the other committers here, I suspect that is true for others too. At a minimum, I think S-1294 should be pushed to 1.5. Next up, I think we consider pulling SolrJS from the release, but keeping it in trunk and officially releasing it with either 1.5 or 1.4.1, assuming its gotten some love in the meantime. If by then it has no love, I vote we remove it and let the fork maintain it and point people there. -Grant -- Peter M. Wolanin, Ph.D. Momentum Specialist, Acquia. Inc. peter.wola...@acquia.com -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search
[jira] Updated: (SOLR-1472) upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene artifacts
[
https://issues.apache.org/jira/browse/SOLR-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1472:
Summary: upgrade maven poms to reference lucene 2.9 artifacts rather than
solr-lucene artifacts (was: upgrade maven poms to reference lucene 2.9
artifacts rather then solr-lucene artifacts)
upgrade maven poms to reference lucene 2.9 artifacts rather than solr-lucene
artifacts
--
Key: SOLR-1472
URL: https://issues.apache.org/jira/browse/SOLR-1472
Project: Solr
Issue Type: Task
Affects Versions: 1.4
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Blocker
Fix For: 1.4
Currently, the solr pom.xml files reference solr-lucene jar files. Rather
then reference the solr jars, we should reference the real lucene jar files.
Additionally, we need to add a reference to lucene-memory so we avoid:
{code}
java.lang.NoClassDefFoundError: org/apache/lucene/index/memory/MemoryIndex
at
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getReaderForField(WeightedSpanTermExtractor.java:313)
at
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extractWeightedSpanTerms(WeightedSpanTermExtractor.java:239)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1472) upgrade maven poms to reference lucene 2.9 artifacts rather then solr-lucene artifacts
upgrade maven poms to reference lucene 2.9 artifacts rather then solr-lucene
artifacts
--
Key: SOLR-1472
URL: https://issues.apache.org/jira/browse/SOLR-1472
Project: Solr
Issue Type: Task
Affects Versions: 1.4
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Blocker
Fix For: 1.4
Currently, the solr pom.xml files reference solr-lucene jar files. Rather then
reference the solr jars, we should reference the real lucene jar files.
Additionally, we need to add a reference to lucene-memory so we avoid:
{code}
java.lang.NoClassDefFoundError: org/apache/lucene/index/memory/MemoryIndex
at
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getReaderForField(WeightedSpanTermExtractor.java:313)
at
org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extractWeightedSpanTerms(WeightedSpanTermExtractor.java:239)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Solr 1.4 Open Issues Status
: SOLR-1294 SolrJS/Javascript client fails in IE8! Unassigned : : I have concerns about this client library being included at all in Solr, as : I don't see anyone taking it up for maintenance. I raised concerns on the : main issue with no response and likewise with this one. Patch exists. Who : handled the original contribution? Ryan did according to svn. I'm elary of features in core that don'th ave a committer who is actively involved with them, but i'm less concerend for client libraries -- as long as the community is submitting patches that can be tested, it's being maintained. I'd commit this patch, but i can't actualy test that it works (no access to IE) I'll take it... remembering a distant land where I had lots of time and energy for this stuff. alas.
[jira] Assigned: (SOLR-1294) SolrJS/Javascript client fails in IE8!
[ https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley reassigned SOLR-1294: --- Assignee: Ryan McKinley SolrJS/Javascript client fails in IE8! -- Key: SOLR-1294 URL: https://issues.apache.org/jira/browse/SOLR-1294 Project: Solr Issue Type: Bug Affects Versions: 1.4 Reporter: Eric Pugh Assignee: Ryan McKinley Fix For: 1.4 Attachments: SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch SolrJS seems to fail with 'jQuery.solrjs' is null or not an object errors under IE8. I am continuing to test if this occurs in IE 6 and 7 as well. This happens on both the Sample online site at http://solrjs.solrstuff.org/test/reuters/ as well as the /trunk/contrib/javascript library. Seems to be a show stopper from the standpoint of really using this library! I have posted a screenshot of the error at http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png The error is just a whole bunch of repeated messages in the vein of: Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js Message: 'jQuery.solrjs' is null or not an object Line: 37 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js Message: 'jQuery.solrjs' is null or not an object Line: 27 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1424) ant generate-maven-artifacts fails on windows
[
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12754386#action_12754386
]
Ryan McKinley commented on SOLR-1424:
-
no dice. with:
{code}
$ svn diff
Index: common-build.xml
===
--- common-build.xml(revision 814053)
+++ common-build.xml(working copy)
@@ -104,13 +104,12 @@
property name=junit.reports
location=${common.dir}/${dest}/test-results/reports/
!-- Maven properties --
- property name=maven.build.dir value=${basedir}/build/maven/
- property name=maven.dist.dir value=${basedir}/dist/maven/
+ property name=maven.build.dir location=${basedir}/build/maven/
+ property name=maven.dist.dir location=${basedir}/dist/maven/
+ property name=maven.dist.prefix
location=${maven.dist.dir}/org/apache/solr/
- property name=maven.dist.prefix
value=${maven.dist.dir}/org/apache/solr/
-
{code}
I still get:
{code}
generate-maven-artifacts:
[copy] Copying 1 file to
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven
BUILD FAILED
c:\workspace\apache\solr\build.xml:750: The following error occurred while
executing this line:
c:\workspace\apache\solr\common-build.xml:260: Failed to copy
c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template to
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven
\solr-parent-pom.xml.template due to java.io.FileNotFoundException
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template
(The filename, directory name, o
r volume label syntax is incorrect)
Total time: 4 minutes 7 seconds
{code}
looking around at some other options, but don't see anything obvious
ant generate-maven-artifacts fails on windows
-
Key: SOLR-1424
URL: https://issues.apache.org/jira/browse/SOLR-1424
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
From solr-user...
{noformat}
generate-maven-artifacts:
[mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
[mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
[copy] Copying 1 file to
c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
olr_trunk\src\maven
BUILD FAILED
c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
execut
ing this line:
c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
c:\Downloads\solr_t
runk\src\maven\solr-parent-pom.xml.template to
c:\Downloads\solr_trunk\build\mav
en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
java.io
.FileNotFoundException
c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
volu
me label syntax is incorrect)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1424) ant generate-maven-artifacts fails on windows
[
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley reassigned SOLR-1424:
---
Assignee: Ryan McKinley
yup, that does it... I will commit shortly
ant generate-maven-artifacts fails on windows
-
Key: SOLR-1424
URL: https://issues.apache.org/jira/browse/SOLR-1424
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Ryan McKinley
From solr-user...
{noformat}
generate-maven-artifacts:
[mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
[mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
[copy] Copying 1 file to
c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
olr_trunk\src\maven
BUILD FAILED
c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
execut
ing this line:
c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
c:\Downloads\solr_t
runk\src\maven\solr-parent-pom.xml.template to
c:\Downloads\solr_trunk\build\mav
en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
java.io
.FileNotFoundException
c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
volu
me label syntax is incorrect)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1424) ant generate-maven-artifacts fails on windows
[
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1424:
Attachment: SOLR-1424.patch
ant generate-maven-artifacts fails on windows
-
Key: SOLR-1424
URL: https://issues.apache.org/jira/browse/SOLR-1424
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Ryan McKinley
Fix For: 1.4
Attachments: SOLR-1424.patch
From solr-user...
{noformat}
generate-maven-artifacts:
[mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
[mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
[copy] Copying 1 file to
c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
olr_trunk\src\maven
BUILD FAILED
c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
execut
ing this line:
c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
c:\Downloads\solr_t
runk\src\maven\solr-parent-pom.xml.template to
c:\Downloads\solr_trunk\build\mav
en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
java.io
.FileNotFoundException
c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
volu
me label syntax is incorrect)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1424) ant generate-maven-artifacts fails on windows
[
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-1424.
-
Resolution: Fixed
Fix Version/s: 1.4
ant generate-maven-artifacts fails on windows
-
Key: SOLR-1424
URL: https://issues.apache.org/jira/browse/SOLR-1424
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Ryan McKinley
Fix For: 1.4
Attachments: SOLR-1424.patch
From solr-user...
{noformat}
generate-maven-artifacts:
[mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
[mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
[copy] Copying 1 file to
c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
olr_trunk\src\maven
BUILD FAILED
c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
execut
ing this line:
c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
c:\Downloads\solr_t
runk\src\maven\solr-parent-pom.xml.template to
c:\Downloads\solr_trunk\build\mav
en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
java.io
.FileNotFoundException
c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
volu
me label syntax is incorrect)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Lucene RC2
have not tried it yet but we should certainly upgrade. the more testing the better! On Aug 28, 2009, at 2:54 PM, Grant Ingersoll wrote: Anyone tried out the new Lucene RC2 in Solr yet? Should we upgrade to it?
Re: ant generate-maven-artifacts, BUILD FAILED?
I only see the behavior on windows. Works fine in linux/mac (with same maven version) Running with maven 2.2.1 I get the same results... I'll try some more debugging tomorow On Aug 25, 2009, at 11:41 AM, Grant Ingersoll wrote: On Aug 25, 2009, at 11:17 AM, Grant Ingersoll wrote: I'll take a look. Have you tried a diff. version of Maven? On Aug 24, 2009, at 3:09 PM, Ryan McKinley wrote: Anyone else seeing this: $ ant generate-maven-artifacts ... ... BUILD FAILED c:\workspace\apache\solr\build.xml:741: The following error occurred while executing this line: c:\workspace\apache\solr\common-build.xml:261: Failed to copy c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template to c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src \maven\solr-parent-pom.xml.template due to java.io.FileNotFoundException c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src \maven\solr-parent-pom.xml.template (The filename, directory name, or volume label syntax is incorrect) Total time: 3 minutes 37 seconds $ ant -version Apache Ant version 1.7.1 compiled on June 27 2008 $ mvn --version Maven version: 2.0.10 Java version: 1.6.0_13 OS name: windows vista version: 6.0 arch: amd64 Family: windows - - - - - - Obviously this has something to do with: c:\workspace\apache\solr\build\maven\c:\workspace\apache... Hmm, WFM (Works for me) but I'm on a Mac. Does ant -diagnostics show anything weird? You might try echoing out the basedir and the maven.build.dir -Grant
[jira] Commented: (SOLR-1377) Force TokenizerFactory to create a Tokenizer rather then TokenStream
[ https://issues.apache.org/jira/browse/SOLR-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12747012#action_12747012 ] Ryan McKinley commented on SOLR-1377: - Without objection... I will commit this soon Force TokenizerFactory to create a Tokenizer rather then TokenStream - Key: SOLR-1377 URL: https://issues.apache.org/jira/browse/SOLR-1377 Project: Solr Issue Type: New Feature Components: Analysis Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 Attachments: SOLR-1377-Tokenizer.patch, SOLR-1377.patch The new token reuse classes require that they are created with a Tokenizer. The solr TokenizerFactory interface currently makes a TokenStream. Although this is an API breaking change, the alternative is to just document that it needs to be a Tokenizer instance and throw an error when it is not. For more discussion, see: http://www.lucidimagination.com/search/document/272b8c4e6198d887/trunk_classcastexception_with_basetokenizerfactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1377) Force TokenizerFactory to create a Tokenizer rather then TokenStream
[ https://issues.apache.org/jira/browse/SOLR-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-1377. - Resolution: Fixed Force TokenizerFactory to create a Tokenizer rather then TokenStream - Key: SOLR-1377 URL: https://issues.apache.org/jira/browse/SOLR-1377 Project: Solr Issue Type: New Feature Components: Analysis Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 Attachments: SOLR-1377-Tokenizer.patch, SOLR-1377.patch The new token reuse classes require that they are created with a Tokenizer. The solr TokenizerFactory interface currently makes a TokenStream. Although this is an API breaking change, the alternative is to just document that it needs to be a Tokenizer instance and throw an error when it is not. For more discussion, see: http://www.lucidimagination.com/search/document/272b8c4e6198d887/trunk_classcastexception_with_basetokenizerfactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ant generate-maven-artifacts, BUILD FAILED?
Anyone else seeing this: $ ant generate-maven-artifacts ... ... BUILD FAILED c:\workspace\apache\solr\build.xml:741: The following error occurred while executing this line: c:\workspace\apache\solr\common-build.xml:261: Failed to copy c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template to c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template due to java.io.FileNotFoundException c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template (The filename, directory name, or volume label syntax is incorrect) Total time: 3 minutes 37 seconds $ ant -version Apache Ant version 1.7.1 compiled on June 27 2008 $ mvn --version Maven version: 2.0.10 Java version: 1.6.0_13 OS name: windows vista version: 6.0 arch: amd64 Family: windows - - - - - - Obviously this has something to do with: c:\workspace\apache\solr\build\maven\c:\workspace\apache... thanks ryan
Re: /trunk ClassCastException with BaseTokenizerFactory
not sure what you are asking for. The patch in SOLR-1377 (now /trunk) breaks the TokenizerFactory API. You will get an compiler error (or runtime error) with a TokenizerFactory that creates a TokenStream rather then a Tokenizer. I don't see any clean way to do this via deprecation -- if you have ideas, shout them out. ryan On Aug 24, 2009, at 1:49 PM, Lance Norskog wrote: Is it possible to mark out backwards-incompatible changes with deprecation? So at least we get warnings in Eclipse/Netbeans etc? On Fri, Aug 21, 2009 at 9:50 AM, Mark Miller markrmil...@gmail.com wrote: Ryan McKinley wrote: Ahh, I see: Tokenizer extends TokenStream So if this is going to break everything that implements TokenStream rather then Tokenizer, it seems we should change the TokenizerFactory API from: public Tokenizer create( Reader input ) rather then: public TokenStream create( Reader input ); I would WAY rather have my compiler tell me something is wrong then get an error and then find some documentation about the tokenizer. - - - - - Personally, I think lucene/solr just need to fess up and admit that 2.9 is *not* totally back compatible. I don't think anyone contends that Lucene is totally backcompat - and insofarasthatgoes there is no way Solr totally is - . it exposes a lot of Lucene. We admit our breaks in this release in the back compat breaks section. There is no way we will release claiming total back compat. Not even in the realm of possibility. No way is the Multireader change back-compatible! Personally, pure API wise - I think it was. Its a stickier issue on the possible more RAM usage - but too me, thats more of a Runtime change. Certain methods have always changed over time in their resource usage, and I think thats within back compat. This was a steep one to swallow though, I'll admit. Basically we just thought it was way worth it long term. And Hoss came up with some great ideas to help ease the possible pain. ryan On Aug 21, 2009, at 11:39 AM, Yonik Seeley wrote: On Fri, Aug 21, 2009 at 10:13 AM, Ryan McKinleyryan...@gmail.com wrote: I'm fine upgrading, but it seems we should the 'back compatibility' notice more explicit. Yeah... that should be fun for expert-use plugins in general. In Lucene-land, this is the release of the break... I think we've covered the changes reasonably well in our external APIs, but people can always use pretty much the full Lucene API when writing Solr plugins. I think we'll need to document that things in tokenizer tags need to inherit from Tokenizer classes. It is technically a back-compat break, but I assume it will affect very few users? -Yonik http://www.lucidimagination.com -- - Mark http://www.lucidimagination.com -- Lance Norskog goks...@gmail.com
[jira] Updated: (SOLR-1057) PathTokenizerFactory
[
https://issues.apache.org/jira/browse/SOLR-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1057:
Attachment: SOLR-1057-PathTokenizerFactory.patch
updated to use reusable token stuff
PathTokenizerFactory
Key: SOLR-1057
URL: https://issues.apache.org/jira/browse/SOLR-1057
Project: Solr
Issue Type: New Feature
Components: Analysis
Reporter: Ryan McKinley
Priority: Minor
Attachments: SOLR-1057-PathTokenizerFactory.patch,
SOLR-1057-PathTokenizerFactory.patch
This is a Tokenizer that splits the input string into a series of paths. For
example:
{panel}
/aaa/bbb/ccc
{panel}
becomes:
{panel}
/aaa/
/aaa/bbb/
/aaa/bbb/ccc
{panel}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
/trunk ClassCastException with BaseTokenizerFactory
Just updated to /trunk and am now seeing this exception:
Caused by: org.apache.solr.client.solrj.SolrServerException:
java.lang.ClassCastException:
xxx.solr.analysis.JSONKeyValueTokenizerFactory$1 cannot be cast to
org.apache.lucene.analysis.Tokenizer
at
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:141)
... 15 more
Caused by: java.lang.ClassCastException:
xxx.solr.analysis.JSONKeyValueTokenizerFactory$1 cannot be cast to
org.apache.lucene.analysis.Tokenizer
at
org.apache.solr.analysis.TokenizerChain.getStream(TokenizerChain.java:69)
at
org.apache.solr.analysis.SolrAnalyzer.reusableTokenStream(SolrAnalyzer.java:74)
at
org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.reusableTokenStream(IndexSchema.java:364)
at
org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:124)
at
org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:244)
at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:772)
Looks like SolrIndexAnalyzer now assumes everything uses the new
TokenStream API...
I'm fine upgrading, but it seems we should the 'back compatibility'
notice more explicit.
FYI, this is what the TokenizerFactory looks like:
public class JSONKeyValueTokenizerFactory extends BaseTokenizerFactory
{
...
public TokenStream create(Reader input) {
final JSONParser js = new JSONParser( input );
final StackString keystack = new StackString();
return new TokenStream()
{
...
Re: /trunk ClassCastException with BaseTokenizerFactory
Actually I think there may be something wrong here.
BaseTokenizerFactory does not make a Tokenizer, it creates a
TokenStream, so it should never be cast to Tokenizer
My custom TokenizerFactory now looks the same as:
o.a.s.analysis.PatternTokenizerFactory
Not sure what to look at next... ideas?
thanks
ryan
On Fri, Aug 21, 2009 at 10:13 AM, Ryan McKinleyryan...@gmail.com wrote:
Just updated to /trunk and am now seeing this exception:
Caused by: org.apache.solr.client.solrj.SolrServerException:
java.lang.ClassCastException:
xxx.solr.analysis.JSONKeyValueTokenizerFactory$1 cannot be cast to
org.apache.lucene.analysis.Tokenizer
at
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:141)
... 15 more
Caused by: java.lang.ClassCastException:
xxx.solr.analysis.JSONKeyValueTokenizerFactory$1 cannot be cast to
org.apache.lucene.analysis.Tokenizer
at
org.apache.solr.analysis.TokenizerChain.getStream(TokenizerChain.java:69)
at
org.apache.solr.analysis.SolrAnalyzer.reusableTokenStream(SolrAnalyzer.java:74)
at
org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.reusableTokenStream(IndexSchema.java:364)
at
org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:124)
at
org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:244)
at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:772)
Looks like SolrIndexAnalyzer now assumes everything uses the new
TokenStream API...
I'm fine upgrading, but it seems we should the 'back compatibility'
notice more explicit.
FYI, this is what the TokenizerFactory looks like:
public class JSONKeyValueTokenizerFactory extends BaseTokenizerFactory
{
...
public TokenStream create(Reader input) {
final JSONParser js = new JSONParser( input );
final StackString keystack = new StackString();
return new TokenStream()
{
...
Re: /trunk ClassCastException with BaseTokenizerFactory
On Aug 21, 2009, at 10:49 AM, Yonik Seeley wrote: On Fri, Aug 21, 2009 at 10:33 AM, Ryan McKinleyryan...@gmail.com wrote: Actually I think there may be something wrong here. BaseTokenizerFactory does not make a Tokenizer, it creates a TokenStream, so it should never be cast to Tokenizer My custom TokenizerFactory now looks the same as: o.a.s.analysis.PatternTokenizerFactory Urg... looks like there's no end-to-end (index then search) test for PatternTokenizerFactory, so we never caught this. I guess we need to add one :) It seems like when something is specified as a tokenizer in schema.xml it should in fact be a tokenizer - it's the only way tokenstream reuse works. I don't see anything in Solr that creates a Tokenizer. The TokenizerFactory just creates a TokenStream. It seems that TokenizerFactory really needs to be: public Tokenizer create( Reader input ) rather then: public TokenStream create( Reader input ); I don't see any backwards compatible way to make this change! ideas? ryan
Re: /trunk ClassCastException with BaseTokenizerFactory
Ahh, I see: Tokenizer extends TokenStream So if this is going to break everything that implements TokenStream rather then Tokenizer, it seems we should change the TokenizerFactory API from: public Tokenizer create( Reader input ) rather then: public TokenStream create( Reader input ); I would WAY rather have my compiler tell me something is wrong then get an error and then find some documentation about the tokenizer. - - - - - Personally, I think lucene/solr just need to fess up and admit that 2.9 is *not* totally back compatible. No way is the Multireader change back-compatible! ryan On Aug 21, 2009, at 11:39 AM, Yonik Seeley wrote: On Fri, Aug 21, 2009 at 10:13 AM, Ryan McKinleyryan...@gmail.com wrote: I'm fine upgrading, but it seems we should the 'back compatibility' notice more explicit. Yeah... that should be fun for expert-use plugins in general. In Lucene-land, this is the release of the break... I think we've covered the changes reasonably well in our external APIs, but people can always use pretty much the full Lucene API when writing Solr plugins. I think we'll need to document that things in tokenizer tags need to inherit from Tokenizer classes. It is technically a back-compat break, but I assume it will affect very few users? -Yonik http://www.lucidimagination.com
[jira] Created: (SOLR-1377) Force TokenizerFactory to create a Tokenizer rather then TokenStream
Force TokenizerFactory to create a Tokenizer rather then TokenStream - Key: SOLR-1377 URL: https://issues.apache.org/jira/browse/SOLR-1377 Project: Solr Issue Type: New Feature Components: Analysis Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 The new token reuse classes require that they are created with a Tokenizer. The solr TokenizerFactory interface currently makes a TokenStream. Although this is an API breaking change, the alternative is to just document that it needs to be a Tokenizer instance and throw an error when it is not. For more discussion, see: http://www.lucidimagination.com/search/document/272b8c4e6198d887/trunk_classcastexception_with_basetokenizerfactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1377) Force TokenizerFactory to create a Tokenizer rather then TokenStream
[
https://issues.apache.org/jira/browse/SOLR-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1377:
Attachment: SOLR-1377-Tokenizer.patch
Here is a patch that:
1. Changes the TokenizerFactory to return a Tokenizer
2. Updates all TokenizerFactory classes to explicitly return a Tokenizer
3. Changes the PatternTokenizerFactory to return a Tokenizer
4. adds a test that calls PatternTokenizer
- - -
Since this is an API breaking change, I added this to the Upgrading from Solr
1.3 section of CHANGES.txt:
{panel}
The TokenizerFactory API has changed to explicitly return a Tokenizer rather
then
a TokenStream (that may be or may not be a Tokenizer). This change is required
to take advantage of the Token reuse improvements in lucene 2.9. For more
information, see SOLR-1377.
{panel}
I'll wait for two +1 votes on this, since it does break back compatibility
Force TokenizerFactory to create a Tokenizer rather then TokenStream
-
Key: SOLR-1377
URL: https://issues.apache.org/jira/browse/SOLR-1377
Project: Solr
Issue Type: New Feature
Components: Analysis
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Fix For: 1.4
Attachments: SOLR-1377-Tokenizer.patch
The new token reuse classes require that they are created with a Tokenizer.
The solr TokenizerFactory interface currently makes a TokenStream.
Although this is an API breaking change, the alternative is to just document
that it needs to be a Tokenizer instance and throw an error when it is not.
For more discussion, see:
http://www.lucidimagination.com/search/document/272b8c4e6198d887/trunk_classcastexception_with_basetokenizerfactory
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1377) Force TokenizerFactory to create a Tokenizer rather then TokenStream
[
https://issues.apache.org/jira/browse/SOLR-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12746287#action_12746287
]
Ryan McKinley commented on SOLR-1377:
-
Is reset gaurenteed to be called on the same Reader? For the Pattern
implementation, all the tokens are created beforehand and are just passed off
with iter.next(), so if the input changes, the whole thing would need to change.
+ public void reset(Reader input) throws IOException {
+ super.reset(input);
+ init();
+ }
Any reason not to implement reset on: TrieTokenizerFactory?
Force TokenizerFactory to create a Tokenizer rather then TokenStream
-
Key: SOLR-1377
URL: https://issues.apache.org/jira/browse/SOLR-1377
Project: Solr
Issue Type: New Feature
Components: Analysis
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Fix For: 1.4
Attachments: SOLR-1377-Tokenizer.patch, SOLR-1377.patch
The new token reuse classes require that they are created with a Tokenizer.
The solr TokenizerFactory interface currently makes a TokenStream.
Although this is an API breaking change, the alternative is to just document
that it needs to be a Tokenizer instance and throw an error when it is not.
For more discussion, see:
http://www.lucidimagination.com/search/document/272b8c4e6198d887/trunk_classcastexception_with_basetokenizerfactory
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Response Writers and DocLists
On Aug 18, 2009, at 10:01 AM, Grant Ingersoll wrote: On Aug 18, 2009, at 9:49 AM, Ryan McKinley wrote: Also, I'm thinking about having a real simple interface that would allow for, when materializing the Fields, to pass in something like a DocumentModifier, which would basically get the document right before it is to be returned (possibly inside the SolrIndexReader, but maybe this even belongs at the Lucene level similar to the FieldSelector, although it is likely too late for 2.9.) Through this DocModifier, one could easily add fields, etc. Too high level for Lucene I think, and nothing is currently needed for Lucene - a user calls doc() to get the document and then they can modify or add fields however they want. An interface could be useful for Solr... but getting 1.4 out the door is top priority. Agreed... i am wondering if pushing: https://issues.apache.org/jira/browse/SOLR-705 to 1.4 makes sense... It already is marked for 1.4 and has been for a while. dooh, i mean pushing it out of 1.4 (or into 1.5) ryan
[jira] Updated: (SOLR-705) Distributed search should optionally return docID-shard map
[ https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-705: --- Fix Version/s: (was: 1.4) 1.5 Moving this issue to 1.5 so that the details could be worked out with less haste. http://www.lucidimagination.com/search/document/1f2e56f58162679d/response_writers_and_doclists Distributed search should optionally return docID-shard map Key: SOLR-705 URL: https://issues.apache.org/jira/browse/SOLR-705 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Environment: all Reporter: Brian Whitman Assignee: Ryan McKinley Fix For: 1.5 Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, SOLR-705.patch SOLR-303 queries with shards parameters set need to return the dociD-shard mapping in the response. Without it, updating/deleting documents when the # of shards is variable is hard. We currently set this with a special requestHandler that filters /update and inserts the shard as a field in the index but it would be better if the shard location came back in the query response outside of the index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Response Writers and DocLists
Ya, I like this idea. Adding a meta field is OK, but it may just be kicking the can. Also implementation wise, it works well when you have a SolrDocument, but when directly using DocList, it gets a bit messy. https://issues.apache.org/jira/browse/SOLR-705 Also with adding a meta field, I'm not sure I like that it is a double object like: doc.get( _meta_ ).get( distance) It would be nicer if the user does not have any idea if it is a pseudo- field or real field. (by user I mean how you consume the response, not how you construct the URL) The SQL as command comes to mind: SELECT name, count(xxx) as cnt ryan On Aug 17, 2009, at 6:00 PM, Grant Ingersoll wrote: I'm looking a little bit at https://issues.apache.org/jira/browse/SOLR-1298 and some of the other pseudo-field capabilities and am curious how the various Response Writers are handling writing out the Docs. The XMLWriter seems to have a very different approach from the others when it comes to dealing with multi-valued fields (it sorts first, the others don't.) Does anyone know the history here? Also, I'm thinking about having a real simple interface that would allow for, when materializing the Fields, to pass in something like a DocumentModifier, which would basically get the document right before it is to be returned (possibly inside the SolrIndexReader, but maybe this even belongs at the Lucene level similar to the FieldSelector, although it is likely too late for 2.9.) Through this DocModifier, one could easily add fields, etc. Part of what I think needs to be addressed here is that currently, in order to add fields, for instance, LocalSolr does this, one needs to iterate over the DocList (or SolrDocList) multiple times. SolrPluginUtils.docListtoSolrDocList attempts to help, but it still requires a double loop. The tricky part here is that one often needs to have context when modifying the Document that the Response Writer's simply do not have, so you end up writing a SearchComponent to do it and thus iterating multiple times. I know this is a bit stream of conscience, but thought I would get it out there a little bit to see what others thought. -Grant
[jira] Resolved: (SOLR-868) Prepare solrjs trunk to be integrated into contrib
[ https://issues.apache.org/jira/browse/SOLR-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-868. Resolution: Fixed My apologies, this was actually resolved months ago! (and solrjs is now in http://svn.apache.org/repos/asf/lucene/solr/trunk/client/javascript/ ) Prepare solrjs trunk to be integrated into contrib -- Key: SOLR-868 URL: https://issues.apache.org/jira/browse/SOLR-868 Project: Solr Issue Type: Task Affects Versions: 1.4 Reporter: Matthias Epheser Assignee: Ryan McKinley Fix For: 1.4 Attachments: javascript_contrib.zip, reutersimporter.jar, SOLR-868-testdata.patch, solrjs.zip This patch includes a zipfile snapshot of current solrjs trunk. The folder structure is applied to standard solr layout. It can be extracted to contrib/javascript. it includes a build.xml: * ant dist - creates a single js file and a jar that holds velocity templates. * ant docs - creates js docs. test in browser: doc/index.html * ant example-init - (depends ant dist on solr root) copies the current built of solr.war and solr-velocity.jar to example/testsolr/.. * ant example-start - starts the testsolr server on port 8983 * ant example-import - imports 3000 test data rows (requires a started testserver) Point your browser to example/testClientside.html ,example/testServerSide.html or test/reuters/index.html to see it working. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-705) Distributed search should optionally return docID-shard map
[ https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley reassigned SOLR-705: -- Assignee: Ryan McKinley Distributed search should optionally return docID-shard map Key: SOLR-705 URL: https://issues.apache.org/jira/browse/SOLR-705 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Environment: all Reporter: Brian Whitman Assignee: Ryan McKinley Fix For: 1.4 Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, SOLR-705.patch SOLR-303 queries with shards parameters set need to return the dociD-shard mapping in the response. Without it, updating/deleting documents when the # of shards is variable is hard. We currently set this with a special requestHandler that filters /update and inserts the shard as a field in the index but it would be better if the shard location came back in the query response outside of the index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-705) Distributed search should optionally return docID-shard map
[ https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12739076#action_12739076 ] Ryan McKinley commented on SOLR-705: I'll take this one on for 1.4... I incorporate hoss' suggestion and then we can see how we like it. Distributed search should optionally return docID-shard map Key: SOLR-705 URL: https://issues.apache.org/jira/browse/SOLR-705 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Environment: all Reporter: Brian Whitman Assignee: Ryan McKinley Fix For: 1.4 Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, SOLR-705.patch SOLR-303 queries with shards parameters set need to return the dociD-shard mapping in the response. Without it, updating/deleting documents when the # of shards is variable is hard. We currently set this with a special requestHandler that filters /update and inserts the shard as a field in the index but it would be better if the shard location came back in the query response outside of the index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1320) CapitalizationFilterFactory's minWordLength not working properly
[
https://issues.apache.org/jira/browse/SOLR-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12737649#action_12737649
]
Ryan McKinley commented on SOLR-1320:
-
dooh. thanks erik!
CapitalizationFilterFactory's minWordLength not working properly
Key: SOLR-1320
URL: https://issues.apache.org/jira/browse/SOLR-1320
Project: Solr
Issue Type: Bug
Components: Analysis
Affects Versions: 1.4
Reporter: Erik Hatcher
Assignee: Erik Hatcher
To see the problem first hand, add to schema.xml:
{code:xml}
fieldType name=cap class=solr.TextField positionIncrementGap=100
analyzer
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.CapitalizationFilterFactory
minWordLength=2/
/analyzer
/fieldType
{code}
Then in analysis.jsp, analyze a or and. All terms get capitalized.
This has to do with the length calculation being wrong in
CapitalizationFilter#next.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12733900#action_12733900
]
Ryan McKinley commented on SOLR-773:
Wow, this issue just keeps growing! We need to figure the best way to move
forward that will keep things clean and have the flexibility to enable the wide
rage of spatial features we all want. As noted earlier, I hope we can come up
with a simple interface that could support various strategies - including:
trie, cartesian tier, geohash, rtree, jts/geotools etc, etc.
To get things going, it seems the biggest hurdles are getting the solr
framework to support some basic wiring to make these things possible. As Yonik
pointed out before, this comes down to a few core features:
* SOLR-1131 -- FieldType should be able to write multiple fields (consider
WKT - many fields)
* SOLR-1298 -- Add function query calculation to result
* SOLR-705 -- Attach arbitrary metadata (distance) to the results
* A way to sort by a function query
With this, geosearch could be implemented with:
* Custom QParser like: fq={!gbox p=101.2,234.5 f=position, d=1.5}
// a bounding box, centered on 101.2,234.5 including everything within
1.5 miles
* A function query that calculates distances gdist(position,101.2,234.3)
(may need to share data with the Query/Filter)
Incorporate Local Lucene/Solr
-
Key: SOLR-773
URL: https://issues.apache.org/jira/browse/SOLR-773
Project: Solr
Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar,
lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch,
SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch,
SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch,
SOLR-773.patch, spatial-solr.tar.gz
Local Lucene has been donated to the Lucene project. It has some Solr
components, but we should evaluate how best to incorporate it into Solr.
See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1171) dynamic field name with spaces causes error
[
https://issues.apache.org/jira/browse/SOLR-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729462#action_12729462
]
Ryan McKinley commented on SOLR-1171:
-
thanks hoss!
dynamic field name with spaces causes error
---
Key: SOLR-1171
URL: https://issues.apache.org/jira/browse/SOLR-1171
Project: Solr
Issue Type: Bug
Reporter: Ryan McKinley
Assignee: Hoss Man
Fix For: 1.4
Stumbled into this bug. I have a dynamic field meta_set_* When I add the
field: meta_set_NoData Value and try to open luke, I get this exception:
{panel}
May 15, 2009 3:42:06 PM org.apache.solr.common.SolrException log
SEVERE: org.apache.solr.common.SolrException: undefined field Value
at
org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1132)
at
org.apache.solr.schema.IndexSchema.getFieldType(IndexSchema.java:1094)
at
org.apache.solr.search.SolrQueryParser.getRangeQuery(SolrQueryParser.java:121)
at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1514)
at
org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1349)
at
org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1306)
at
org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1266)
at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:172)
at
org.apache.solr.handler.admin.LukeRequestHandler.getIndexedFieldsInfo(LukeRequestHandler.java:310)
at
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:147)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1330)
{panel}
note the field is meta_set_gdal_NoData Value not Value
I think the query parser is grabbing it...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
aaah, using trunk is fun! -- Illegal sort type: 2
Just started getting this error with a recent update: Caused by: java.lang.IllegalStateException: Illegal sort type: 2 at org.apache.lucene.search.SortField.getComparator(SortField.java:492) at org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.init(FieldValueHitQueue.java:80) at org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:190) at org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:851) at org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1082) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:880) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:176) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1290) at org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:139) This only happens when I combine a custom filter with a text search (same custom filter as the last time). Before digging deeply into what solr/lucene rev changed the behavior, I just want to check if this rings a bell with anyone thanks! ryan
Re: aaah, using trunk is fun! -- Illegal sort type: 2
Digging in a little more... this is triggered by a custom search
component that takes some parameters and adds a custom filter to the
mix.
In the component prepare() function, it checks if the there is a sort
defined, if not it defaults to something:
SortSpec sortSpec = builder.getSortSpec();
if( sortSpec.getSort() == null ) {
sortSpec.setSort( new Sort( new SortField[] {
new SortField( afield, true )
}));
}
If I comment this out, I do not get the error (not surprising)
However, if I add the sort field to the original query it works without problem.
Perhaps there has been some changen that now requires me to do something else?
Any ideas?
thanks
ryan
On Wed, Jun 17, 2009 at 7:28 PM, Mark Millermarkrmil...@gmail.com wrote:
Type 2 is auto and its been deprecated in Lucene.
Not sure why you are seeing this issue though. Could be the recent changes
to Solr for LUCENE-1483 - auto now has to be resolved before using the
collector, ie using int autotype = SortField.detectFieldType(reader,
fieldname);
I remember this changing but not the exact details.
Probably Solr is not doing this though.
- Mark
Ryan McKinley wrote:
Just started getting this error with a recent update:
Caused by: java.lang.IllegalStateException: Illegal sort type: 2
at
org.apache.lucene.search.SortField.getComparator(SortField.java:492)
at
org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.init(FieldValueHitQueue.java:80)
at
org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:190)
at
org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:851)
at
org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1082)
at
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:880)
at
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:176)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1290)
at
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:139)
This only happens when I combine a custom filter with a text search
(same custom filter as the last time).
Before digging deeply into what solr/lucene rev changed the behavior,
I just want to check if this rings a bell with anyone
thanks!
ryan
--
- Mark
http://www.lucidimagination.com
[jira] Created: (SOLR-1225) improve LukeRequestHandler docCount calculation
improve LukeRequestHandler docCount calculation --- Key: SOLR-1225 URL: https://issues.apache.org/jira/browse/SOLR-1225 Project: Solr Issue Type: Improvement Components: search Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 Currently the LukeRequestHandler is calling: int docCount = searcher.numDocs( q, matchAllDocs ); followed by: DocList ds = searcher.getDocList( q, (Query)null, (Sort)null, 0, 1 ); to get the doc count (and then the first doc returned) This can be replaced with: TopDocs top = searcher.search( q, 1 ); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
