headers
Paul Elschot | 1 May 2005 16:34
Picon
Picon
Favicon

Re: svn commit: r165500 - in /lucene/java/trunk/docs: images/asf-logo.gif lucene-sandbox/index.html

On Sunday 01 May 2005 15:09, dnaber <at> apache.org wrote:
> Author: dnaber
> Date: Sun May  1 06:09:36 2005
> New Revision: 165500
> 
> URL: http://svn.apache.org/viewcvs?rev=165500&view=rev
> Log:
> forgot to commit these files

In another project, this helps me to check for files not under version control
of svn:

http://www.mail-archive.com/user <at> ant.apache.org/msg18369.html

In that project it is the final stage of the main test build target.

It is useful only for a working copy that should precisely reflect the next
version of the svn repository. For a working copy that just follows
the svn repository I don't use it.

Regards,
Paul Elschot
Permalink | Reply | 0 comments |
headers
bugzilla | 1 May 2005 20:48
Picon
Favicon

DO NOT REPLY [Bug 34673] - ConstantScoreRangeQuery - fixes "too many clauses" exception

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34673>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34673

------- Additional Comments From paul.elschot <at> xs4all.nl  2005-05-01 20:48 -------
The ConstantScoreQuery requires java 1.4 for its skipTo() implementation, 
so this will have to wait until java 1.4 is a minimum requirement for 
Lucene. 
Some time ago there was a bit of discussion on mixed boolean and 
scored queries, and I think the ConstantScoreQuery is a wellcome 
addition for such mixed queries. 
One problem with the current score is that it is not really bound 
to a maximum, so it is difficult to choose a good constant score 
value in a mix. 
Perhaps that aspect of scoring should be tackled in the future. 

Regards, 
Paul Elschot 

--

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
Guillermo Payet | 1 May 2005 22:14
Favicon

geographical searches

Hi,

I started implementing geographical searches yesterday, using BBN's QuadTree
implementaion as the spacial index.  I first implemented a new "GeoFilter" 
class to filter queries to "all items within a rectangle".  That was pretty 
easy and it's now working beautifuly, and very fast too.  See below force 
source code.

BTW:  I'm creating the QuadTree in memory right now during Lucene index 
creation, but not storing it in the disk yet.  I'll add something like
a couple of "GeoIndexReader" and "GeoIndexWriter" classes later.

I'm now having a hell of a time figuring out how to implement a "GeoQuery" 
class though.  Just figuring out how the whole Query mechanism works 
by reading the source code is proving to be quite a challenge.

Question:  Is there any article or document that explains this?  Also:
Any tips as to what the right approach would be here?

    --G

----------------------------------------------------------------------------
package com.oceangroup.projects.localharvest.search;

import java.util.BitSet;
import java.util.Vector;
import java.io.IOException;

import org.apache.lucene.search.*;
import org.apache.lucene.index.IndexReader;
(Continue reading)

Permalink | Reply | 6 comments |
headers
Daniel Naber | 1 May 2005 21:06
Picon
Favicon

Re: too many classes visible with "ant javadocs"

On Wednesday 27 April 2005 02:53, Erik Hatcher wrote:

> By all means feel free
> to take over the build process refactorings if you'd like.

I think you as the ant expert can do that much better, and my mail wasn't 
meant as a complaint that things don't progress fast enough.

One small thing: "ant test" complains that JUnit isn't found if it's not in 
classpath. As we have junit.jar in CVS, couldn't that be used 
automatically?

Regards
 Daniel

--

-- 
http://www.danielnaber.de
Permalink | Reply | 3 comments |
headers
Guillermo Payet | 1 May 2005 22:56
Favicon

Re: geographical searches

A thought....

I don't really need any geographical scoring.  I just need to be able 
to show all items within a region.  Since a lot of the complexity of
"Query" has to do with scoring, would it be better to just use the
GeoFilter, and to search for *?   Are there any performance issues 
with this?

    --G

On Sun, May 01, 2005 at 01:14:25PM -0700, Guillermo Payet wrote:
> Hi,
> 
> I started implementing geographical searches yesterday, using BBN's QuadTree
> implementaion as the spacial index.  I first implemented a new "GeoFilter" 
> class to filter queries to "all items within a rectangle".  That was pretty 
> easy and it's now working beautifuly, and very fast too.  See below force 
> source code.
> 
> BTW:  I'm creating the QuadTree in memory right now during Lucene index 
> creation, but not storing it in the disk yet.  I'll add something like
> a couple of "GeoIndexReader" and "GeoIndexWriter" classes later.
> 
> I'm now having a hell of a time figuring out how to implement a "GeoQuery" 
> class though.  Just figuring out how the whole Query mechanism works 
> by reading the source code is proving to be quite a challenge.
> 
> Question:  Is there any article or document that explains this?  Also:
> Any tips as to what the right approach would be here?
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Guillermo Payet | 1 May 2005 23:22
Favicon

Re: geographical searches

I guess the solution is to forget about using IndexSearcher and
Query at all and to write a simple "GeoSearcher" that opens the 
regular index, plus the QuadTree, and uses the same approach I used 
in GeoFilter to generate a group of hits.  Like this:

  GeoQuery geoSearcher = new GeoSearcher("path_to_index_file", quadTree);
  hits = geoQuery.search(rect,filter);

Would that be right?

    --G

On Sun, May 01, 2005 at 01:14:25PM -0700, Guillermo Payet wrote:
> Hi,
> 
> I started implementing geographical searches yesterday, using BBN's QuadTree
> implementaion as the spacial index.  I first implemented a new "GeoFilter" 
> class to filter queries to "all items within a rectangle".  That was pretty 
> easy and it's now working beautifuly, and very fast too.  See below force 
> source code.
> 
> BTW:  I'm creating the QuadTree in memory right now during Lucene index 
> creation, but not storing it in the disk yet.  I'll add something like
> a couple of "GeoIndexReader" and "GeoIndexWriter" classes later.
> 
> I'm now having a hell of a time figuring out how to implement a "GeoQuery" 
> class though.  Just figuring out how the whole Query mechanism works 
> by reading the source code is proving to be quite a challenge.
> 
> Question:  Is there any article or document that explains this?  Also:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Hatcher | 2 May 2005 00:09
Favicon

Re: too many classes visible with "ant javadocs"


On May 1, 2005, at 3:06 PM, Daniel Naber wrote:
> On Wednesday 27 April 2005 02:53, Erik Hatcher wrote:
>
>> By all means feel free
>> to take over the build process refactorings if you'd like.
>
> I think you as the ant expert can do that much better, and my mail 
> wasn't
> meant as a complaint that things don't progress fast enough.

I've spent some time today refactoring the build process to unify the 
main build to also build the contrib libraries, yet still allowing them 
to be built by themselves.  I will check in my effort later tonight.

> One small thing: "ant test" complains that JUnit isn't found if it's 
> not in
> classpath. As we have junit.jar in CVS, couldn't that be used
> automatically?

junit.jar really ought to be removed from our repository.  Due to 
classloader issues, <junit> doesn't work with junit.jar anywhere but in 
the classpath that launches Ant.  The Ant best practice is to put 
junit.jar in ANT_HOME/lib anyway.  I have adjusted the build file that 
I'll check in later to account for this.

	Erik
Permalink | Reply | 2 comments |
headers
Erik Hatcher | 2 May 2005 03:27
Favicon

build process changes

I have done some extensive rearranging of the build system to 
facilitate the inclusion of the contrib pieces into future source and 
binary distributions.  I'll describe it in more detail below.

First - if you have any problems with the Lucene build process as it 
currently stands in Subversion, let me know.  All existing targets 
should still work as it did before.  Just typing "ant" will build the 
Lucene JAR file as it has done.

The building of the contrib components individually still needs some 
adjustments, but the pieces do build successfully for me.  To build all 
the contrib pieces now, run "ant build-contrib" at the top-level.  
Running "dist-all" target incorporates the contrib pieces into the 
source and binary .zip/.tar.gz files.

Please provide feedback on what, if anything, needs to be changed to 
make it viable for a 1.9 release.  I will continue to tinker with the 
odds and ends.  Some known issues are that only JAR files build by the 
contrib projects are put into the distribution, which means 
contrib/javascript is not distributed currently.  Javadoc documentation 
is built into the main documentation, but any other documentation 
within a contrib project is not incorporated (though there isn't much 
documentation to distribute on these pieces anyway, unfortunately).  
Running unit tests of all the contrib components as part of the main 
build is not done.

I believe it was Doug that had proposed the following:
  ---
  "ant dist" will create something like:
(Continue reading)

Permalink | Reply | 6 comments |
headers
Brian Goetz | 2 May 2005 03:32

Re: too many classes visible with "ant javadocs"

> junit.jar really ought to be removed from our repository.  Due to 
> classloader issues, <junit> doesn't work with junit.jar anywhere but in 
> the classpath that launches Ant.  The Ant best practice is to put 
> junit.jar in ANT_HOME/lib anyway.  I have adjusted the build file that 
> I'll check in later to account for this.

I disagree that this is a "best practice."  At best, it is a horrible
workaround for two tools that ought to work better together, but don't,
for reasons that no one has been able to explain compellingly.  

What if you have different projects which use the same version of ANT
but use different versions of JUnit?  You're screwed.  

What we've taken to doing is to "neuter" ANT by removing optional.jar,
and add optional.jar to the lib/ directory of every project, along with
junit.  While this is not really a great practice either, it does 
provide more flexibility.
Permalink | Reply | 1 comment |
headers
Wolfgang Hoschek | 2 May 2005 04:20
Favicon

Re: [Performance] Streaming main memory indexing of single strings

I've uploaded code that now runs against the current SVN, plus junit 
test cases, plus some minor internal updates to the functionality 
itself. For details see 
http://issues.apache.org/bugzilla/show_bug.cgi?id=34585

Be prepared for the testcases to take some minutes to complete - don't 
hit CTRL-C :-)
Erik, if nobody objects, can you please put this into a contrib area, 
e.g. module "memory" in org.apache.lucene.index.memory, or similar?
Thanks,
Wolfgang.

On Apr 27, 2005, at 10:30 AM, Erik Hatcher wrote:

> On Apr 27, 2005, at 12:22 PM, Doug Cutting wrote:
>> Erik Hatcher wrote:
>>> I'm not quite sure  where to put MemoryIndex - maybe it deserves to 
>>> stand on its own in a  new contrib area?
>>
>> That sounds good to me.
>
> Ok... once Wolfgang gives me one last round up updates (JUnit tests 
> instead of main() and upgrade it to work with trunk) I'll do that.  I 
> had put it in miscellaneous but will create its only sub-contrib area 
> instead.
>
>>
>>> Or does it make sense to put this into misc (still  in 
>>> sandbox/misc)?  Or where?
>>
(Continue reading)

Permalink | Reply | 12 comments |

Gmane