Re: Solr CWIKI ready for experimenting
On Sun, 2007-12-23 at 00:19 -0800, Chris Hostetter wrote: ... If you are a Solr committer and/or have a CLA on file with the ASF and want ot help with Solr documentation, please reply to this thread when you make an account (with the account name please), and i'll add you to the appropriate groups. If possible to have an account with write access I would like one (never know when I will write some lines of docu). ;) Login: thorsten salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: [jira] Resolved: (SOLR-441) example app comes up with some bad links
Mike Klaas wrote: On 27-Dec-07, at 5:26 PM, Ryan McKinley wrote: Seems like that would be the best solution. Me (and, I think, many others), would be unlikely to used the multiple core functionality of Solr at all. Avoiding lengthening the log messages in this case would be nice. check rev 607151 -- this removes the [name] bit for things where the name is null Looks great, thanks. I haven't really followed the multicore discussion very closely (so ignore this if it doesn't compute), but might it make sense for the core-specific log object to automatically prepend the corename to the log message (cursorily, it looks like current it is necessary for each logging call to prepend the corename (.getLogId()) if the log message is to be core-specific)? Sounds like a good idea, but how would you do it? Right now it calls log.info( logId + message... ) everywhere. Is there a way to change the underlying log format for each core? (log is currently a static Logger log = Logger.getLogger(...); ryan
Re: Solr CWIKI ready for experimenting
erik: someone already handled your account mike, thorsten: added to appropriate groups. -Yonik
[jira] Commented: (SOLR-434) interfaces should support 2B docs
[ https://issues.apache.org/jira/browse/SOLR-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554844 ] Yonik Seeley commented on SOLR-434: --- I think we can safely change all integers to long without problem. So you mean, when SolrJ encounters a int100/int it will create a new Long(100)? That wouldn't really be backward compatible with SolrJ users, but we haven't had a SolrJ release yet. I don't think the external api int makes an contract to say the value will fit within the java int range. The only issue is that there is a long tag... I don't think Solr currently uses Long objects for serialization, but long field types currently use the long tag. interfaces should support 2B docs -- Key: SOLR-434 URL: https://issues.apache.org/jira/browse/SOLR-434 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Priority: Minor Fix For: 1.3 External interfaces that deal with numbers of documents should eventually be able to deal with 2B documents (that means long instead of int). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (SOLR-441) example app comes up with some bad links
On 28-Dec-07, at 7:31 AM, Ryan McKinley wrote: Mike Klaas wrote: Looks great, thanks. I haven't really followed the multicore discussion very closely (so ignore this if it doesn't compute), but might it make sense for the core-specific log object to automatically prepend the corename to the log message (cursorily, it looks like current it is necessary for each logging call to prepend the corename (.getLogId()) if the log message is to be core-specific)? Sounds like a good idea, but how would you do it? Right now it calls log.info( logId + message... ) everywhere. Is there a way to change the underlying log format for each core? (log is currently a static Logger log = Logger.getLogger(...); I'm not too familiar with jdk logging, but I think that it should be possible to assign each SolrCore its own Logger (using getLogger (classname +'.'+ corename)), then modifying the config of the logger (this might be useful for other reasons too, such as making each core's logfile output to a different file). The simplest configuration might be to assign a custom java.util.logging.Formatter which calls .setMessage() on the LogRecord to prepend the corename before passing to the SimpleFormatter superclass. The world of java logging and associated configuration is a bit of a sordid beast, so I'm not sure if this is kosher with all the possible custom configurations and such. -Mike
Re: maven + solr
Hello! Hope you all are having nice holidays. let me lob another idea out there and see if you think I'm crazy... How do you all feel about changing the directory layout so it plays nicely with maven? While we are at it, how do you feel about switching to maven for the primary build system? My reasons to suggest this are: 1. working with maven artifacts makes plugin/app development loads easier. 2. maintaining multiple build systems simultaneously seems like a pain (I can't quite figure out how the lucene maven stuff works... it seems overly complicated though) 3. For SOLR-303, solr-core needs to depend on solrj -- we can do this with a simple change to build.xml, but it leaves us with a directory structure that does not reflect the real dependencies. It seems like a restructuring is called for regardless of the build system. 4. Using maven, we can quickly add other nice build features like clover, pmd, eclipse, and idea support. 5. Assuming we stick with cwiki for the the site release, we need to figure out how to include the auto-export in our distribution. The concerns I have heard about maven are: 1. past experience was awful, lets not go there 2. solr sometimes depends on snapshot builds #1, I can't really argue with - My past experience with maven (a long time ago) was terrible too. All my recent work with maven2 has been incredibly smooth. #2, with maven, we can still put in hand built jar files, it is just not the best practice. Currently, the only dependency that we can't pull from a standard repository is: commons-csv-0.1-SNAPSHOT.jar In SOLR-19, I just uploaded a proof of concept layout/pom structure with 4 artifacts: 1. solr-common (jar) 2. solr-client (jar) 3. solr-core (jar) 4. solr-server (war) The one thing that is strange about our dependency graph is that many of the tests for 'solr-client' depend on 'solr-server' and 'solr-core', so they would probably be in that package. Is this something worth pursuing? Would we rather stick with ant and either have maven build unofficial artifacts or jump through lucene style hoops? My input on this... * Providing a Maven2 build would be useful for us. Currently when we modify Solr, we do an Ant build and then manually push the resulting jar to our in-house Maven repo, which works but isn't all that clean. * So I'd be in favor of changing the directory layout, but only for my own selfish reasons :) * I wouldn't be in favor of changing the build to rely on Maven2. We use Maven internally at Krugle, and sometimes it works well, and other times it's a royal pain in the butt. So having it as an option would be nice, and handy for me personally, but I'd hate to foist Maven on everybody else. -- Ken -- Ken Krugler Krugle, Inc. +1 530-210-6378 If you can't find it, you can't fix it
Re: maven + solr
On Dec 28, 2007, at 5:50 PM, Ken Krugler wrote: Hello! Hope you all are having nice holidays. let me lob another idea out there and see if you think I'm crazy... How do you all feel about changing the directory layout so it plays nicely with maven? While we are at it, how do you feel about switching to maven for the primary build system? My reasons to suggest this are: 1. working with maven artifacts makes plugin/app development loads easier. 2. maintaining multiple build systems simultaneously seems like a pain (I can't quite figure out how the lucene maven stuff works... it seems overly complicated though) 3. For SOLR-303, solr-core needs to depend on solrj -- we can do this with a simple change to build.xml, but it leaves us with a directory structure that does not reflect the real dependencies. It seems like a restructuring is called for regardless of the build system. 4. Using maven, we can quickly add other nice build features like clover, pmd, eclipse, and idea support. 5. Assuming we stick with cwiki for the the site release, we need to figure out how to include the auto-export in our distribution. The concerns I have heard about maven are: 1. past experience was awful, lets not go there 2. solr sometimes depends on snapshot builds #1, I can't really argue with - My past experience with maven (a long time ago) was terrible too. All my recent work with maven2 has been incredibly smooth. #2, with maven, we can still put in hand built jar files, it is just not the best practice. Currently, the only dependency that we can't pull from a standard repository is: commons-csv-0.1- SNAPSHOT.jar In SOLR-19, I just uploaded a proof of concept layout/pom structure with 4 artifacts: 1. solr-common (jar) 2. solr-client (jar) 3. solr-core (jar) 4. solr-server (war) The one thing that is strange about our dependency graph is that many of the tests for 'solr-client' depend on 'solr-server' and 'solr-core', so they would probably be in that package. Is this something worth pursuing? Would we rather stick with ant and either have maven build unofficial artifacts or jump through lucene style hoops? My input on this... * Providing a Maven2 build would be useful for us. Currently when we modify Solr, we do an Ant build and then manually push the resulting jar to our in-house Maven repo, which works but isn't all that clean. +1 I like the M2 repository and M2 conventions, but am less enamored w/ M2 as a tool to actually execute targets/goals, and I have used it fairly extensively. I tend to favor how Lucene does it these days. * So I'd be in favor of changing the directory layout, but only for my own selfish reasons :) +1. I do like the way the M2 standardizes directories. * I wouldn't be in favor of changing the build to rely on Maven2. We use Maven internally at Krugle, and sometimes it works well, and other times it's a royal pain in the butt. So having it as an option would be nice, and handy for me personally, but I'd hate to foist Maven on everybody else. Again, +1. If it ain't broke, don't fix it. Keep the ANT build and publish the Jars on the Maven repo is my vote.
