Re: commit requests
On Feb 12, 2007, at 2:48 AM, rubdabadub wrote: On 2/12/07, Erik Hatcher [EMAIL PROTECTED] wrote: I'm in my last ditch procrastinating efforts to get my code4lib pre- conference organized where I'll be teach Solr and Lucene, and guiding a hands-on workshop to help 85 library geeks come up to speed with Solr. Will the transcript/presentation or slides be available afterwards somewhere? Hope so :-) I'll make all zero slides I use for this workshop available to the world, sure! Seriously though, I doubt I'll have much in the way of slides for this workshop, we'll dig right in to firing up Solr and working with it live rather than walking through slides. I am, however, packaging up a binary distribution of Solr, the example application in both source data .xml files and pre-built index, and other sample datasets, such that attendees will be able to jump in regardless of their level of experience with Solr and begin integrating it into their own environments. This preliminary information will appear here: http://code4lib.org/wiki/preconf-docs I will be making slides for my keynote presentation on Solr Flare, and those will certainly be made freely available (and announced here when they are posted). By the way, for many speakers its a classic dilemma to have folks, especially those that didn't attend the event itself, to request slides. The best speakers speak way more than their slides say, so you miss a lot by simply viewing slides. Erik
[jira] Commented: (SOLR-154) Added package tasks for creating Rails plugin and namespaced both the rails and gem packaging
[ https://issues.apache.org/jira/browse/SOLR-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472263 ] Erik Hatcher commented on SOLR-154: --- Jamie's latest patch has been applied. Though I think there is a bit more to come on this. Added package tasks for creating Rails plugin and namespaced both the rails and gem packaging - Key: SOLR-154 URL: https://issues.apache.org/jira/browse/SOLR-154 Project: Solr Issue Type: Improvement Components: clients - ruby - flare Environment: Ruby and Ruby on Rails Reporter: Jamie Orchard-Hays Attachments: Rakefile.diff, Rakefile_2.diff Solrb's (sol.rb's?) rake file has a package:vendor task that is not generating proper rails plugin structure. Rather than just fix this, I've added a PackageTask to package up a proper Rails plugin directory structure and also build distributable packages. Included are the README, LICENSE.txt, and init.rb generated and destroyed on the fly. Also, I've namespaced the Gem PackageTask and the Rails PackageTask, so the commands: rake rails:package (and repackage, clobber, clobber_package) rake gem:package (and the rest...) package their files up and dump them into pkg/rails and pkg/gem, respectively. Their clobber tasks will only remove the sub-directory under pkg/, not pkg/ itself. rake package, rake repackage run both package tasks, while rake clobber and rake clobber_package remove the complete pkg/ directory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: commit requests
By the way, for many speakers its a classic dilemma to have folks, especially those that didn't attend the event itself, to request slides. The best speakers speak way more than their slides say, so you miss a lot by simply viewing slides. I fully agree. But something is better then nothing :-) Beside I am in Asia and all the fun stuff are in US :-( Looking forward to it anyway!
Re: commit requests
: * SOLR-79: to allow launching a common schema/config with various : data directories. +1 : * A newer version of Lucene's JAR: to have *:* syntax. +0 ... i don't really have any opinion about reving Lucene as far as the nbightly builds go ... I think yonik menitoned before that it would be good to make sure Solr 1.2 used a stable version of Lucene, but i don't think it would be bad if nightly builds of Solr (which are by definition supose to be considered developer builds and therefore unstable) used unstable Lucene builds. -Hoss
[jira] Updated: (SOLR-79) [PATCH] Using system properties in Solr configuration
[
https://issues.apache.org/jira/browse/SOLR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-79:
-
Attachment: solr-config-system-property.patch
Here's the patch with default value implemented. ${system.property:default
value} - default value is optional, if omitted, will be used.
[PATCH] Using system properties in Solr configuration
-
Key: SOLR-79
URL: https://issues.apache.org/jira/browse/SOLR-79
Project: Solr
Issue Type: New Feature
Reporter: Alexander Saar
Assigned To: Erik Hatcher
Priority: Minor
Attachments: solr-config-system-property.patch,
solr-config-system-property.patch, solr-config-system-property.patch,
solr-config-system-property.patch, solr-config-system-property.patch
Actually it is not possible to use system properties for configuring the Solr
engine. There should be a way of referencing system properties from
solrconfig.xml, like {$prop.name}.
The attached patch will provide this feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: commit requests
On 2/12/07, Chris Hostetter [EMAIL PROTECTED] wrote: : * A newer version of Lucene's JAR: to have *:* syntax. +0 ... i don't really have any opinion about reving Lucene as far as the nbightly builds go ... I think yonik menitoned before that it would be good to make sure Solr 1.2 used a stable version of Lucene, Specifically, that Solr 1.2 should use Lucene 2.1 (or later). There were so many index format changes in Lucene lately, I wanted some assurances about back-compatibility in the future. but i don't think it would be bad if nightly builds of Solr (which are by definition supose to be considered developer builds and therefore unstable) used unstable Lucene builds. Right. For Solr official releases, we should prefer offlcial Lucene releases, but I wouldn't want to make it a rule. So I'm fine with updating to the latest Lucene nightly build now... It would give us a chance to make sure it works well for us too. Lucene 2.1 shouldn't be too far off... but I'm sick yet again, and it's hard enough writing email in this state that I'm not going to go near any code :-) -Yonik
[jira] Updated: (SOLR-79) [PATCH] Using system properties in Solr configuration
[
https://issues.apache.org/jira/browse/SOLR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-79:
-
Attachment: solr-config-system-property.patch
Updated the patch per Hoss' feedback. Specifically:
i haven't tested Erik's patch, but it reads clean to me.
a couple of minor nits...
1) Javadoc: done.
2) Hoss: if the system properties used were solr.test.sys.prop1, etc. the
patch wouldn't need to modify build.xml ... if we are going to set them
explicitly in build.xml, there shold be a comment explaining which test uses
them. [Erik: I don't understand... are you saying there is a predefined
solr.test.sys.prop1 somewhere? I didn't spot anything like that, so I've kept
with defining a couple of test ones in build.xml
3) ye of little faith! the doc that the Config object holds has been
modified recursively, so all methods querying the doc will see the substituted
values. I've added a test to show the case you mentioned.
4) I added similar tests for .evaluate and .getNode. All is well.
[PATCH] Using system properties in Solr configuration
-
Key: SOLR-79
URL: https://issues.apache.org/jira/browse/SOLR-79
Project: Solr
Issue Type: New Feature
Reporter: Alexander Saar
Assigned To: Erik Hatcher
Priority: Minor
Attachments: solr-config-system-property.patch,
solr-config-system-property.patch, solr-config-system-property.patch,
solr-config-system-property.patch, solr-config-system-property.patch,
solr-config-system-property.patch
Actually it is not possible to use system properties for configuring the Solr
engine. There should be a way of referencing system properties from
solrconfig.xml, like {$prop.name}.
The attached patch will provide this feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: commit requests
On 2/12/07, Erik Hatcher [EMAIL PROTECTED] wrote: ... * SOLR-79: to allow launching a common schema/config with various data directories... +1 ... * A newer version of Lucene's JAR: to have *:* syntax... +0, don't know enough about the issues to comment. -Bertrand
