RE: GIT does not support empty directories

2010-04-15 Thread Smiley, David W. 
I've run into this too.  I don't think this needs to be documented, I think it 
needs to be *fixed* -- that is, the relevant ant tasks need to not assume these 
directories exist and create them if not.

~ David Smiley

-Original Message-
From: Lance Norskog [mailto:goks...@gmail.com] 
Sent: Wednesday, April 14, 2010 11:14 PM
To: solr-dev
Subject: GIT does not support empty directories

There are some empty directories in the Solr source tree, both in 1.4
and the trunk.

example/work
example/webapp
example/logs

Git does not support empty directories:

https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty_directories.3F

And so, when you check out from the Apache GIT repository, these empty
directories do not appear and 'ant example' and 'ant run-example'
fail. There is no 'how to use the solr git stuff' wiki page; that
seems like the right place to document this. I'm not git-smart enough
to write that page.
-- 
Lance Norskog
goks...@gmail.com

Re: Eclipse project files...

2010-04-15 Thread Erick Erickson 
Hmmm, now that I look at the rest of the thread (sorry, I just
skim things at work) I see you already did provide the zips.

I wonder if it would suffice to put them on the Wiki and point to
them.

er...@ishouldreadmorethoroughly.com

On Thu, Apr 15, 2010 at 7:48 PM, Erick Erickson wrote:

> Well, there certainly *can* be absolute paths, it depends
> on whether all your jars are relative to the checked-out
> project or whether you had to go exploring your machine.
>
> But that's a nit. I agree it's certainly possible to carefully
> construct the necessary files so that all paths are relative,
> and include all the relevant jars located at those relative
> path locations.
>
> Are you volunteering? If so, feel free to create a JIRA
> and attach any patches, I'm sure one of the committers will
> be happy to make it happen, assuming they approve...
>
> Erick
>
> But you're right
>
>
> On Thu, Apr 15, 2010 at 5:40 PM, Paolo Castagna <
> castagna.li...@googlemail.com> wrote:
>
>> Erick Erickson wrote:
>>
>>> <<>> projects?>>>
>>>
>>> because they're always wrong ...
>>>
>>
>> It is possible to get it right and when it happens users will have a
>> much better experience when they checkout the sources of a project.
>>
>> Just a few examples of things I use:
>>
>>  - https://jena.svn.sourceforge.net/svnroot/jena/TDB/trunk/.classpath
>>  - https://jena.svn.sourceforge.net/svnroot/jena/ARQ/trunk/.classpath
>>  - http://svn.apache.org/repos/asf/hadoop/common/trunk/build.xml
>>
>> With Maven and/or Ant+Ivy it's possible to generate Eclipse .classpath
>> and .project files automatically from your pom.xml file or from your
>> ivy.xml (Hadoop does that).
>>
>>
>>  If I put mine in c:\apache, and you put yours in c:\trunk, our classpath
>>> files will reflect that. And I *really* don't want to update the project
>>> and
>>> get my classpath file overwritten with yours.
>>>
>>> Not to mention that I *actually* work on a mac, where Ant has been
>>> installed in /usr and...
>>>
>>
>> The examples above work on Linux, Windows and should work on Mac OS X as
>> well, there are no absolute paths in the .classpath or .project files.
>>
>>
>>  Not to mention other libraries. And what about plugins?
>>>
>>> That said, one *can* include a sample classpath and, perhaps, project
>>> file,  that can be copied to "the correct place" and changed to reflect
>>> the
>>> local setup as has been done on the Wiki, see:
>>> http://wiki.apache.org/lucene-java/HowToContribute
>>>
>>
>> Eclipse .classpath and .project files can be checked into the source
>> code repository or they can be generated as part of the building system.
>>
>> I'd love to have the same good experience with Lucene and Solr... I am
>> still having problems trying to configure Eclipse to run Solr tests (and
>> yes, I've changed the current directory... but I still have problems).
>>
>> Paolo
>>
>>
>>  Best
>>> Erick
>>>
>>> On Thu, Apr 15, 2010 at 5:04 PM, hkmortensen  wrote:
>>>
>>>  I spend about two days last week to import lucene and solr in eclipse. I
 would not call it easy at all. I took the test sources away completely
 (from
 the source path).

 I would like to help putting some useable project files for eclipse
 together
 (including the test files ;-) ).

 Why are classpath files generally not included in open source projects?
 Would they do any harm? I realise when you get experienced with the
 software
 you want to make it slim to make text search faster. But for new people
 in
 a project it would be a lot nicer, I think.

 Is there any way of distribute work on the solr project? I would not
 like
 to
 do a lot of effort to adapt to eclipse if somebody else does it the same
 time


 --
 View this message in context:
 http://n3.nabble.com/Eclipse-project-files-tp708987p722342.html
 Sent from the Solr - Dev mailing list archive at Nabble.com.


>>>
>

Re: Eclipse project files...

2010-04-15 Thread Erick Erickson 
Well, there certainly *can* be absolute paths, it depends
on whether all your jars are relative to the checked-out
project or whether you had to go exploring your machine.

But that's a nit. I agree it's certainly possible to carefully
construct the necessary files so that all paths are relative,
and include all the relevant jars located at those relative
path locations.

Are you volunteering? If so, feel free to create a JIRA
and attach any patches, I'm sure one of the committers will
be happy to make it happen, assuming they approve...

Erick

But you're right

On Thu, Apr 15, 2010 at 5:40 PM, Paolo Castagna <
castagna.li...@googlemail.com> wrote:

> Erick Erickson wrote:
>
>> <<> projects?>>>
>>
>> because they're always wrong ...
>>
>
> It is possible to get it right and when it happens users will have a
> much better experience when they checkout the sources of a project.
>
> Just a few examples of things I use:
>
>  - https://jena.svn.sourceforge.net/svnroot/jena/TDB/trunk/.classpath
>  - https://jena.svn.sourceforge.net/svnroot/jena/ARQ/trunk/.classpath
>  - http://svn.apache.org/repos/asf/hadoop/common/trunk/build.xml
>
> With Maven and/or Ant+Ivy it's possible to generate Eclipse .classpath
> and .project files automatically from your pom.xml file or from your
> ivy.xml (Hadoop does that).
>
>
>  If I put mine in c:\apache, and you put yours in c:\trunk, our classpath
>> files will reflect that. And I *really* don't want to update the project
>> and
>> get my classpath file overwritten with yours.
>>
>> Not to mention that I *actually* work on a mac, where Ant has been
>> installed in /usr and...
>>
>
> The examples above work on Linux, Windows and should work on Mac OS X as
> well, there are no absolute paths in the .classpath or .project files.
>
>
>  Not to mention other libraries. And what about plugins?
>>
>> That said, one *can* include a sample classpath and, perhaps, project
>> file,  that can be copied to "the correct place" and changed to reflect
>> the
>> local setup as has been done on the Wiki, see:
>> http://wiki.apache.org/lucene-java/HowToContribute
>>
>
> Eclipse .classpath and .project files can be checked into the source
> code repository or they can be generated as part of the building system.
>
> I'd love to have the same good experience with Lucene and Solr... I am
> still having problems trying to configure Eclipse to run Solr tests (and
> yes, I've changed the current directory... but I still have problems).
>
> Paolo
>
>
>  Best
>> Erick
>>
>> On Thu, Apr 15, 2010 at 5:04 PM, hkmortensen  wrote:
>>
>>  I spend about two days last week to import lucene and solr in eclipse. I
>>> would not call it easy at all. I took the test sources away completely
>>> (from
>>> the source path).
>>>
>>> I would like to help putting some useable project files for eclipse
>>> together
>>> (including the test files ;-) ).
>>>
>>> Why are classpath files generally not included in open source projects?
>>> Would they do any harm? I realise when you get experienced with the
>>> software
>>> you want to make it slim to make text search faster. But for new people
>>> in
>>> a project it would be a lot nicer, I think.
>>>
>>> Is there any way of distribute work on the solr project? I would not like
>>> to
>>> do a lot of effort to adapt to eclipse if somebody else does it the same
>>> time
>>>
>>>
>>> --
>>> View this message in context:
>>> http://n3.nabble.com/Eclipse-project-files-tp708987p722342.html
>>> Sent from the Solr - Dev mailing list archive at Nabble.com.
>>>
>>>
>>

[jira] Updated: (SOLR-1703) Sorting by function problems on multicore (more than one core)

2010-04-15 Thread Yonik Seeley (JIRA) 

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

Yonik Seeley updated SOLR-1703:
---

Fix Version/s: 3.1

> Sorting by function problems on multicore (more than one core)
> --
>
> Key: SOLR-1703
> URL: https://issues.apache.org/jira/browse/SOLR-1703
> Project: Solr
>  Issue Type: Bug
>  Components: multicore, search
>Affects Versions: 1.5
> Environment: Linux (debian, ubuntu), 64bits
>Reporter: Rafał Kuć
> Fix For: 3.1
>
>
> When using sort by function (for example dist function) with multicore with 
> more than one core (on multicore with one core, ie. the example deployment 
> the problem doesn`t exist) there is a problem with not using the right 
> schema. I think there is a problem with this portion of code:
> QueryParsing.java:
> {code}
> public static FunctionQuery parseFunction(String func, IndexSchema schema) 
> throws ParseException {
> SolrCore core = SolrCore.getSolrCore();
> return (FunctionQuery) (QParser.getParser(func, "func", new 
> LocalSolrQueryRequest(core, new HashMap())).parse());
> // return new FunctionQuery(parseValSource(new StrParser(func), schema));
> }
> {code}
> Code above uses deprecated method to get the core sometimes getting the wrong 
> core effecting in impossibility to find the right fields in index. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (SOLR-1703) Sorting by function problems on multicore (more than one core)

2010-04-15 Thread Billy Morgan (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857573#action_12857573
 ] 

Billy Morgan commented on SOLR-1703:


Just an updated to my previous post...

 It appears that the sort function tries to run against whichever core was last 
reloaded. I know this won't be much help to anyone else but luckily this gives 
me a hacky yet workable fix to my problem, as only one of my cores uses sort 
functions I just need to make sure it is always reloaded last.

> Sorting by function problems on multicore (more than one core)
> --
>
> Key: SOLR-1703
> URL: https://issues.apache.org/jira/browse/SOLR-1703
> Project: Solr
>  Issue Type: Bug
>  Components: multicore, search
>Affects Versions: 1.5
> Environment: Linux (debian, ubuntu), 64bits
>Reporter: Rafał Kuć
>
> When using sort by function (for example dist function) with multicore with 
> more than one core (on multicore with one core, ie. the example deployment 
> the problem doesn`t exist) there is a problem with not using the right 
> schema. I think there is a problem with this portion of code:
> QueryParsing.java:
> {code}
> public static FunctionQuery parseFunction(String func, IndexSchema schema) 
> throws ParseException {
> SolrCore core = SolrCore.getSolrCore();
> return (FunctionQuery) (QParser.getParser(func, "func", new 
> LocalSolrQueryRequest(core, new HashMap())).parse());
> // return new FunctionQuery(parseValSource(new StrParser(func), schema));
> }
> {code}
> Code above uses deprecated method to get the core sometimes getting the wrong 
> core effecting in impossibility to find the right fields in index. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (SOLR-1703) Sorting by function problems on multicore (more than one core)

2010-04-15 Thread Billy Morgan (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857568#action_12857568
 ] 

Billy Morgan commented on SOLR-1703:


I believe this to be the cause of the problem I  am experiencing..

I start tomcat and everything works as normal. I then trigger a process which 
updates our synonym files and tells each of the cores affected to reload to 
pickup the changes. Once reloaded the fields used by the sort functions can no 
longer be found.

Restarting tomcat fixes the problem but isn't an option on our production 
servers. Any idea when this bug will be ironed out or a possible work around 
for my situation in the meantime?

> Sorting by function problems on multicore (more than one core)
> --
>
> Key: SOLR-1703
> URL: https://issues.apache.org/jira/browse/SOLR-1703
> Project: Solr
>  Issue Type: Bug
>  Components: multicore, search
>Affects Versions: 1.5
> Environment: Linux (debian, ubuntu), 64bits
>Reporter: Rafał Kuć
>
> When using sort by function (for example dist function) with multicore with 
> more than one core (on multicore with one core, ie. the example deployment 
> the problem doesn`t exist) there is a problem with not using the right 
> schema. I think there is a problem with this portion of code:
> QueryParsing.java:
> {code}
> public static FunctionQuery parseFunction(String func, IndexSchema schema) 
> throws ParseException {
> SolrCore core = SolrCore.getSolrCore();
> return (FunctionQuery) (QParser.getParser(func, "func", new 
> LocalSolrQueryRequest(core, new HashMap())).parse());
> // return new FunctionQuery(parseValSource(new StrParser(func), schema));
> }
> {code}
> Code above uses deprecated method to get the core sometimes getting the wrong 
> core effecting in impossibility to find the right fields in index. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Eclipse project files...

2010-04-15 Thread Paolo Castagna 

hkmortensen wrote:

I spend about two days last week to import lucene and solr in eclipse. I
would not call it easy at all. I took the test sources away completely (from
the source path).


I share and understand your pain.


I would like to help putting some useable project files for eclipse together
(including the test files ;-) ). 


Why are classpath files generally not included in open source projects?


I do not have a good answer...

I cannot think any good reason why a .classpath and .project file for
Eclipse cannot be checked into the repository together with the sources.

However, if the project team is using a diverse variety of IDEs, it
makes less sense. But, these days, it's possible to generate IDE
configuration files via Maven and/or Ant+Ivy.

It would be interesting to know what the Lucene and Solr committers
normally use: Eclipse? IDEA? Emacs? Vi? ...?


Would they do any harm? I realise when you get experienced with the software
you want to make it slim to make text search faster. But for new people in 
a project it would be a lot nicer, I think.


+1


Is there any way of distribute work on the solr project? I would not like to
do a lot of effort to adapt to eclipse if somebody else does it the same
time


Paolo

Re: Eclipse project files...

2010-04-15 Thread Paolo Castagna 



Robert Muir wrote:

On Mon, Apr 12, 2010 at 5:15 AM, Paolo Castagna <
castagna.li...@googlemail.com> wrote:


For Lucene, I needed two more jars from Ant project:

 - ant-1.7.1.jar
 - ant-junit-1.7.1.jar



Paolo, I put these in the lib directory now, to hopefully make IDE
configuration easier.


Thanks, I appreciate.


By the way, thanks for your ideas here. I think its worth our time to try to
make Lucene/Solr as easy as possible for someone to bring up in their IDE,
or we scare people away...


Indeed. :-)

Paolo

Re: Eclipse project files...

2010-04-15 Thread Paolo Castagna 

Erick Erickson wrote:

<<>>

because they're always wrong ...


It is possible to get it right and when it happens users will have a
much better experience when they checkout the sources of a project.

Just a few examples of things I use:

 - https://jena.svn.sourceforge.net/svnroot/jena/TDB/trunk/.classpath
 - https://jena.svn.sourceforge.net/svnroot/jena/ARQ/trunk/.classpath
 - http://svn.apache.org/repos/asf/hadoop/common/trunk/build.xml

With Maven and/or Ant+Ivy it's possible to generate Eclipse .classpath
and .project files automatically from your pom.xml file or from your
ivy.xml (Hadoop does that).


If I put mine in c:\apache, and you put yours in c:\trunk, our classpath
files will reflect that. And I *really* don't want to update the project and
get my classpath file overwritten with yours.

Not to mention that I *actually* work on a mac, where Ant has been
installed in /usr and...


The examples above work on Linux, Windows and should work on Mac OS X as
well, there are no absolute paths in the .classpath or .project files.


Not to mention other libraries. And what about plugins?

That said, one *can* include a sample classpath and, perhaps, project
file,  that can be copied to "the correct place" and changed to reflect the
local setup as has been done on the Wiki, see:
http://wiki.apache.org/lucene-java/HowToContribute


Eclipse .classpath and .project files can be checked into the source
code repository or they can be generated as part of the building system.

I'd love to have the same good experience with Lucene and Solr... I am
still having problems trying to configure Eclipse to run Solr tests (and
yes, I've changed the current directory... but I still have problems).

Paolo


Best
Erick

On Thu, Apr 15, 2010 at 5:04 PM, hkmortensen  wrote:


I spend about two days last week to import lucene and solr in eclipse. I
would not call it easy at all. I took the test sources away completely
(from
the source path).

I would like to help putting some useable project files for eclipse
together
(including the test files ;-) ).

Why are classpath files generally not included in open source projects?
Would they do any harm? I realise when you get experienced with the
software
you want to make it slim to make text search faster. But for new people in
a project it would be a lot nicer, I think.

Is there any way of distribute work on the solr project? I would not like
to
do a lot of effort to adapt to eclipse if somebody else does it the same
time


--
View this message in context:
http://n3.nabble.com/Eclipse-project-files-tp708987p722342.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Re: Eclipse project files...

2010-04-15 Thread Erick Erickson 
<<>>

because they're always wrong ...

If I put mine in c:\apache, and you put yours in c:\trunk, our classpath
files will reflect that. And I *really* don't want to update the project and
get my classpath file overwritten with yours.

Not to mention that I *actually* work on a mac, where Ant has been
installed in /usr and...

Not to mention other libraries. And what about plugins?

That said, one *can* include a sample classpath and, perhaps, project
file,  that can be copied to "the correct place" and changed to reflect the
local setup as has been done on the Wiki, see:
http://wiki.apache.org/lucene-java/HowToContribute

Best
Erick

On Thu, Apr 15, 2010 at 5:04 PM, hkmortensen  wrote:

>
> I spend about two days last week to import lucene and solr in eclipse. I
> would not call it easy at all. I took the test sources away completely
> (from
> the source path).
>
> I would like to help putting some useable project files for eclipse
> together
> (including the test files ;-) ).
>
> Why are classpath files generally not included in open source projects?
> Would they do any harm? I realise when you get experienced with the
> software
> you want to make it slim to make text search faster. But for new people in
> a project it would be a lot nicer, I think.
>
> Is there any way of distribute work on the solr project? I would not like
> to
> do a lot of effort to adapt to eclipse if somebody else does it the same
> time
>
>
> --
> View this message in context:
> http://n3.nabble.com/Eclipse-project-files-tp708987p722342.html
> Sent from the Solr - Dev mailing list archive at Nabble.com.
>

Re: Eclipse project files...

2010-04-15 Thread hkmortensen 

I spend about two days last week to import lucene and solr in eclipse. I
would not call it easy at all. I took the test sources away completely (from
the source path).

I would like to help putting some useable project files for eclipse together
(including the test files ;-) ). 

Why are classpath files generally not included in open source projects?
Would they do any harm? I realise when you get experienced with the software
you want to make it slim to make text search faster. But for new people in 
a project it would be a lot nicer, I think.

Is there any way of distribute work on the solr project? I would not like to
do a lot of effort to adapt to eclipse if somebody else does it the same
time


-- 
View this message in context: 
http://n3.nabble.com/Eclipse-project-files-tp708987p722342.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Re: Math Processing for Solr

2010-04-15 Thread mato 
Thanks for the replies.

I think I will leave this thing for now because I don't have much time and
it doesn't look very easy to me at the moment. Maybe I'll save it to the
future.

Martin

> Payloads are used to set boosts for tokens.  Have a look at the
> PayloadTermQuery.  There is a patch for support in Solr, but it isn't
> committed yet.
>
> -Grant
>
> On Apr 15, 2010, at 8:46 AM, m...@gjgt.sk wrote:
>
>> Yes, I considered creating own analyzer with a set of filters. Trouble
>> is,
>> that I wouldn't be able to set different boosts for the tokens created
>> by
>> the filters(filters need to create additional token to the input one and
>> set a lower boost for it), which is kind of crucial funcionality. Even
>> the
>> tokenizer at the beginning of the process needs to set different boosts
>> to
>> different tokens produced. As far as I know, it is possible to set
>> boosts
>> only to Fields though.
>> This is now more of a discussion for the Lucene lists, I guess.
>>
>> Thanks for the replies anyway.
>>
>> Martin
>>
>>> (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  :
 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


>>>
>>
>>
>
> --
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem using Solr/Lucene:
> http://www.lucidimagination.com/search
>

Re: Solr & Java 1.6 ... was: Re: [jira] Commented: (SOLR-1873) Commit Solr Cloud to trunk

2010-04-15 Thread Jason Rutherglen 
I'm planning on using Solr Cloud, kind of waiting for the commit to
trunk so lets do it (ie, Java6).

On Wed, Apr 14, 2010 at 11:32 PM, Ryan McKinley  wrote:
> 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
>  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
>>  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
>>>
>>>
>>
>

[jira] Closed: (SOLR-1884) Documentation on how to get Apache Solr running on Windows?

2010-04-15 Thread Erik Hatcher (JIRA) 

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

Erik Hatcher closed SOLR-1884.
--

Resolution: Not A Problem

Please ask user questions on the solr-user list.

Briefly, though, you'll need Tomcat or Jetty or some Java web container to run 
Solr.   solrsharp is purely a Solr client, not a .NET version of Solr.  Solr is 
purely Java.

> Documentation on how to get Apache Solr running on Windows?
> ---
>
> Key: SOLR-1884
> URL: https://issues.apache.org/jira/browse/SOLR-1884
> Project: Solr
>  Issue Type: Wish
>  Components: documentation
>Affects Versions: 1.4
> Environment: Windows
> IIS7+
>Reporter: Simon Rijnders
>
> Looking for documentation how to get Apache Solr running on Windows.
> I'm looking to run my .NET website on a Windows machine combined with Apache 
> Solr (this may be solrsharp or the regular Apache Solr).
> And can anyone advise me on what hosting configuration is needed? My wish is 
> to stay as close to an MS configuration as possible.
> So I definately need:
> IIS
> .NET framework
> But do I need:
> Tomcat?
> Apache webserver?
> JDK?
> Anything else?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Math Processing for Solr

2010-04-15 Thread Grant Ingersoll 
Payloads are used to set boosts for tokens.  Have a look at the 
PayloadTermQuery.  There is a patch for support in Solr, but it isn't committed 
yet.

-Grant

On Apr 15, 2010, at 8:46 AM, m...@gjgt.sk wrote:

> Yes, I considered creating own analyzer with a set of filters. Trouble is,
> that I wouldn't be able to set different boosts for the tokens created by
> the filters(filters need to create additional token to the input one and
> set a lower boost for it), which is kind of crucial funcionality. Even the
> tokenizer at the beginning of the process needs to set different boosts to
> different tokens produced. As far as I know, it is possible to set boosts
> only to Fields though.
> This is now more of a discussion for the Lucene lists, I guess.
> 
> Thanks for the replies anyway.
> 
> Martin
> 
>> (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  :
>>> 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
>>> 
>>> 
>> 
> 
> 

--
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem using Solr/Lucene: 
http://www.lucidimagination.com/search

Re: Math Processing for Solr

2010-04-15 Thread mato 
Yes, I considered creating own analyzer with a set of filters. Trouble is,
that I wouldn't be able to set different boosts for the tokens created by
the filters(filters need to create additional token to the input one and
set a lower boost for it), which is kind of crucial funcionality. Even the
tokenizer at the beginning of the process needs to set different boosts to
different tokens produced. As far as I know, it is possible to set boosts
only to Fields though.
This is now more of a discussion for the Lucene lists, I guess.

Thanks for the replies anyway.

Martin

> (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  :
>> 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: Eclipse project files...

2010-04-15 Thread Grant Ingersoll 
AFAICT, those are just coding styles.  It would be nice to have the project 
files setup somehow too.  

On Apr 14, 2010, at 2:40 PM, Chris Hostetter wrote:

> 
> : I think it would be good to put these up on the Wiki.
> 
> We have Eclipse and IDEA configs on the wiki, we just need users of 
> those IDEs to be proactive about making sure they work well...
> 
>  http://wiki.apache.org/solr/HowToContribute#Helpful_Resources
> 
> 
> -Hoss
>

Re: Math Processing for Solr

2010-04-15 Thread Grant Ingersoll 
Another option would be a Tika handler that converted the MathML to a Solr 
document.

On Apr 15, 2010, at 2:38 AM, Ryan McKinley wrote:

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

--
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem using Solr/Lucene: 
http://www.lucidimagination.com/search

[jira] Created: (SOLR-1884) Documentation on how to get Apache Solr running on Windows?

2010-04-15 Thread Simon Rijnders (JIRA) 
Documentation on how to get Apache Solr running on Windows?
---

 Key: SOLR-1884
 URL: https://issues.apache.org/jira/browse/SOLR-1884
 Project: Solr
  Issue Type: Wish
  Components: documentation
Affects Versions: 1.4
 Environment: Windows
IIS7+
Reporter: Simon Rijnders


Looking for documentation how to get Apache Solr running on Windows.

I'm looking to run my .NET website on a Windows machine combined with Apache 
Solr (this may be solrsharp or the regular Apache Solr).

And can anyone advise me on what hosting configuration is needed? My wish is to 
stay as close to an MS configuration as possible.

So I definately need:
IIS
.NET framework

But do I need:
Tomcat?
Apache webserver?
JDK?
Anything else?


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (SOLR-1794) Dataimport of CLOB fields fails when getCharacterStream() is defined in a superclass

2010-04-15 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/SOLR-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857267#action_12857267
 ] 

Stein Kåre Skytteren edited comment on SOLR-1794 at 4/15/10 6:50 AM:
-

A fixed version of  org.apache.solr.handler.dataimport.FieldReaderDataSource 
Change line 89 and 110 to use getMethod instead of getDeclaredMethod.

This works for us on Weblogic 10.3.2.

Since I cannot commit to the repository I hope that someone will update the 
file so we may upgrade without deploying our own version of this class.

  was (Author: skytteren):
A fixed version of  
org.apache.solr.handler.dataimport.FieldReaderDataSource 
Change line 89 and 110 to use getMethod instead of getDeclaredMethod.

This works for us on Weblogic 10.3.2.
  
> Dataimport of CLOB fields fails when getCharacterStream() is defined in a 
> superclass
> 
>
> Key: SOLR-1794
> URL: https://issues.apache.org/jira/browse/SOLR-1794
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4
> Environment: Oracle WebLogic 10.3.2
>Reporter: Gunnar Gauslaa Bergem
> Attachments: FieldReaderDataSource.java
>
>
> When running Solr on WebLogic application server 10.3.2, the dataimport for 
> CLOB fields are failing. Line 109 in FieldReaderDataSource.java illustrates 
> the problem:
> Method m = clob.getClass().getDeclaredMethod("getCharacterStream");
> Since getDeclaredMethod instead of getMethod is used, the 
> getCharacterStream() method will not be found if it is defined in a 
> superclass of clob. This is exactly what
> happens in e.g. WebLogic 10.3.2, since the object returned is a dynamically 
> created wrapper class called Clob_oracle_sql_CLOB. This class does not define
> getCharacterStream(), but it inherits from another class that does. This 
> problem will also occur in other places where getDeclaredMethod used in 
> conjunction with the CLOB
> or BLOB datatypes.
> Stacktrace:
> org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to get 
> reader from clob Processing Document # 1
> at 
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:72)
> at 
> org.apache.solr.handler.dataimport.FieldReaderDataSource.readCharStream(FieldReaderDataSource.java:118)
> at 
> org.apache.solr.handler.dataimport.ClobTransformer.readFromClob(ClobTransformer.java:69)
> at 
> org.apache.solr.handler.dataimport.ClobTransformer.transformRow(ClobTransformer.java:61)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.applyTransformer(EntityProcessorWrapper.java:195)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:241)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:357)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:383)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:242)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:180)
> at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:331)
> at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:389)
> at 
> org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:370)
> Caused by: java.lang.NoSuchMethodException: 
> weblogic.jdbc.wrapper.Clob_oracle_sql_CLOB.getCharacterStream()
> at java.lang.Class.getDeclaredMethod(Class.java:1937)
> at 
> org.apache.solr.handler.dataimport.FieldReaderDataSource.readCharStream(FieldReaderDataSource.java:109)
> ... 11 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (SOLR-1794) Dataimport of CLOB fields fails when getCharacterStream() is defined in a superclass

2010-04-15 Thread JIRA 

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

Stein Kåre Skytteren updated SOLR-1794:
---

Attachment: FieldReaderDataSource.java

A fixed version of  org.apache.solr.handler.dataimport.FieldReaderDataSource 
Change line 89 and 110 to use getMethod instead of getDeclaredMethod.

This works for us on Weblogic 10.3.2.

> Dataimport of CLOB fields fails when getCharacterStream() is defined in a 
> superclass
> 
>
> Key: SOLR-1794
> URL: https://issues.apache.org/jira/browse/SOLR-1794
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4
> Environment: Oracle WebLogic 10.3.2
>Reporter: Gunnar Gauslaa Bergem
> Attachments: FieldReaderDataSource.java
>
>
> When running Solr on WebLogic application server 10.3.2, the dataimport for 
> CLOB fields are failing. Line 109 in FieldReaderDataSource.java illustrates 
> the problem:
> Method m = clob.getClass().getDeclaredMethod("getCharacterStream");
> Since getDeclaredMethod instead of getMethod is used, the 
> getCharacterStream() method will not be found if it is defined in a 
> superclass of clob. This is exactly what
> happens in e.g. WebLogic 10.3.2, since the object returned is a dynamically 
> created wrapper class called Clob_oracle_sql_CLOB. This class does not define
> getCharacterStream(), but it inherits from another class that does. This 
> problem will also occur in other places where getDeclaredMethod used in 
> conjunction with the CLOB
> or BLOB datatypes.
> Stacktrace:
> org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to get 
> reader from clob Processing Document # 1
> at 
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:72)
> at 
> org.apache.solr.handler.dataimport.FieldReaderDataSource.readCharStream(FieldReaderDataSource.java:118)
> at 
> org.apache.solr.handler.dataimport.ClobTransformer.readFromClob(ClobTransformer.java:69)
> at 
> org.apache.solr.handler.dataimport.ClobTransformer.transformRow(ClobTransformer.java:61)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.applyTransformer(EntityProcessorWrapper.java:195)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:241)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:357)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:383)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:242)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:180)
> at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:331)
> at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:389)
> at 
> org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:370)
> Caused by: java.lang.NoSuchMethodException: 
> weblogic.jdbc.wrapper.Clob_oracle_sql_CLOB.getCharacterStream()
> at java.lang.Class.getDeclaredMethod(Class.java:1937)
> at 
> org.apache.solr.handler.dataimport.FieldReaderDataSource.readCharStream(FieldReaderDataSource.java:109)
> ... 11 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Merging the Mailing Lists

2010-04-15 Thread Grant Ingersoll 
Looks like we are ready to go to merge the Lucene and Solr dev mailing lists.  
The new list will be d...@lucene.apache.org.  All existing subscribers will 
automatically be subscribed to the new list.  For more info, see 
https://issues.apache.org/jira/browse/INFRA-2567.

-Grant

Hudson build is back to normal : Solr-trunk #1118

2010-04-15 Thread Apache Hudson Server 
See