Index, a new generalization super root
--
Key: LUCENE-581
URL: http://issues.apache.org/jira/browse/LUCENE-581
Project: Lucene - Java
Type: New Feature
Components: Index
Versions: 2.0.0
Reporter: Karl Wettin
Pr
[ http://issues.apache.org/jira/browse/LUCENE-581?page=all ]
Karl Wettin updated LUCENE-581:
---
Attachment: index.tar
The required update
> Index, a new generalization super root
> --
>
> Key: LUCENE-581
>
[ http://issues.apache.org/jira/browse/LUCENE-581?page=all ]
Karl Wettin updated LUCENE-581:
---
Attachment: indexbonus.tar
Bonus material
> Index, a new generalization super root
> --
>
> Key: LUCENE-581
>
Will code with 1.5 syntax be committed?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I guess the discussion about switching to 1.5 will startup right now
due to the 2.0 release of lucene.
But I have doubt about 1.5 code will be commited yet.
simon
On 5/27/06, karl wettin <[EMAIL PROTECTED]> wrote:
Will code with 1.5 syntax be committed?
---
1.5 has been out for almost 2 years now and has substantial improvements
over 1.4.x, including generics for example. Isn't it time for Lucene to
adopt 1.5?
Chuck
Simon Willnauer wrote on 05/27/2006 12:47 AM:
> I guess the discussion about switching to 1.5 will startup right now
> due to the 2.0
I fully agree with you. It is defiantly time to use all the new
features 1.5 provides.
It's quiet a funny coincidence that Karl started this discussion, I
would have done it instead.
I'm working on a contrib project under the Google SummerOfCode program.
The project is called GData Server which is
[ http://issues.apache.org/jira/browse/LUCENE-550?page=all ]
Karl Wettin updated LUCENE-550:
---
Attachment: instanciated_20060527.tar
This update makes InstanciatedIndex compatible with Lucene, given that issue
580 and 581 is adopted.
It depends on generic
Please remove all attachment from issue 550 but the following:
4. instanciated_20060527.tar (100 kb)
The images can stay though.
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROT
Hello everyone,
some of you guys might have heard about the Google SummerOfCode
program. (code.google.com/soc/) I'm a student has been accepted to
the the program to build a GData server side implementation developed
as a contrib lucene project.
Like other ASF projects the discussion and the dev
On Samstag 27 Mai 2006 13:18, Chuck Williams wrote:
> 1.5 has been out for almost 2 years now and has substantial improvements
> over 1.4.x, including generics for example. Isn't it time for Lucene to
> adopt 1.5?
Java 1.5 has nice features, sure. But these features are mostly useful
during dev
Lucene running Java 1.5 seems almost 40% faster, and some of the Java 1.5
language features would improve the readability of the Lucene code.
I think it about time for such a "recognized" project to move forward. 1.6
is almost ready to be released...
-Original Message-
From: Daniel Naber
On 5/27/06, Daniel Naber <[EMAIL PROTECTED]> wrote:
If someone wants to add 1.5-dependent modules to
the contrib area that would be okay for me though.
+1
As far as Java1.4 or Java1.5 for Lucene core, I agree that it would
almost be nicer for developers than users. Maybe we should try and
ge
[
http://issues.apache.org/jira/browse/LUCENE-489?page=comments#action_12413587 ]
Eric Jain commented on LUCENE-489:
--
Would be nice if this request could be revisited: For those people who do need
to add support for wildcards at the beginning of terms (and
Don't throw TooManyClauses exception
Key: LUCENE-582
URL: http://issues.apache.org/jira/browse/LUCENE-582
Project: Lucene - Java
Type: Improvement
Components: Search
Versions: 2.0.0
Reporter: Eric Jain
Priorit
On Samstag 27 Mai 2006 18:11, Yonik Seeley wrote:
> I understand legacy situations, but surely anyone doing a major Lucene
> upgrade can upgrade the JVM at the same time (the performance boosts
> alone are worth it.)
You can get the improved performance by running 1.4 code with the 1.5 JVM,
righ
Correct. It is purely a coding issue which can lead to greater productivity
by the developers - which helps out everyone.
-Original Message-
From: Daniel Naber [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 27, 2006 12:09 PM
To: java-dev@lucene.apache.org
Subject: Re: Lucene and Java 1.5
On Sat, 27 May 2006, Yonik Seeley wrote:
On 5/27/06, Daniel Naber <[EMAIL PROTECTED]> wrote:
If someone wants to add 1.5-dependent modules to
the contrib area that would be okay for me though.
+1
As far as Java1.4 or Java1.5 for Lucene core, I agree that it would
almost be nicer for develo
On 5/27/06, Daniel Naber <[EMAIL PROTECTED]> wrote:
On Samstag 27 Mai 2006 18:11, Yonik Seeley wrote:
> I understand legacy situations, but surely anyone doing a major Lucene
> upgrade can upgrade the JVM at the same time (the performance boosts
> alone are worth it.)
You can get the improved p
On 5/27/06, Andi Vajda <[EMAIL PROTECTED]> wrote:
As long as gcj is not implementing the new language features in 1.5, I'm stuck
with 1.4.
Good point Andi... that's a pretty compelling reason to stick with 1.4 for now.
-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search
: Java 1.5 has nice features, sure. But these features are mostly useful
: during development, they are less usefull for existing and proven software
: like Lucene. I think at least the core of Lucene should stay compatible
As I understood it, the long term road map has been that 2.0.* would be t
:
: As long as gcj is not implementing the new language features in 1.5, I'm stuck
: with 1.4. If the Lucene core started using 1.5-only features, I'd have to
: create more and more patches for PyLucene to still build and stay current with
: Java Lucene.
As I understand it (based on nothing more t
I fully agree with you yonik, it won't be a good idea to change to 1.5
within the patch releases of the version 2. But it is generally a good
idea to think about using the 1.5 platform in future development.
What's about using the 1.5 platform as a requirement on new projects
like the contrib GDAT
[ http://issues.apache.org/jira/browse/LUCENE-489?page=all ]
Hoss Man updated LUCENE-489:
Summary: Allow QP subclasses to support Wildcard Queries with leading
"*" (was: Wildcard Queries with leading "*")
Description:
It would be usefull for some u
[ http://issues.apache.org/jira/browse/LUCENE-489?page=all ]
Hoss Man reopened LUCENE-489:
-
> Allow QP subclasses to support Wildcard Queries with leading "*"
>
>
> Key: LUCENE-489
>
: idea to think about using the 1.5 platform in future development. What's
: about using the 1.5 platform as a requirement on new projects like the
: contrib GDATA Server? We gonna have the same problem with the Gdata
someone mentioned the idea that contrib packages should be free to
use/require
[
http://issues.apache.org/jira/browse/LUCENE-582?page=comments#action_12413594 ]
Hoss Man commented on LUCENE-582:
-
If a user costructs a Query instance that rewrites to a BooleanQuery we have to
assume they wanted the scoring factors to come into play --
I agree. Let the caller do this, or use a modified query parser that will
always do it. If you do not need the scoring information, it should be a
constant scoring query to begin with.
-Original Message-
From: Hoss Man (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 27, 2006 2:28 PM
Another issue concerns user contributions of patches and enhancements. I
have a significant body of code that might be contributed, all in 1.5,
to do things that have been requested by others who participate in the
lists. As most of the development community is using 1.5 now, Lucene may
get fewer g
On Sat, 27 May 2006, Chris Hostetter wrote:
:
: As long as gcj is not implementing the new language features in 1.5, I'm stuck
: with 1.4. If the Lucene core started using 1.5-only features, I'd have to
: create more and more patches for PyLucene to still build and stay current with
: Java Luce
ISOLatin1AccentFilter discards position increments of filtered terms
Key: LUCENE-583
URL: http://issues.apache.org/jira/browse/LUCENE-583
Project: Lucene - Java
Type: Bug
Components: Analysis
so far:
pro:
1. Code readability
2. Faster contribs (as many of active developers moved to it allready)
3. "moving forward effect" as sooner or later it will be
the same argument for 1.6, 1.7... good feeling to stay close
4. Some performance boost not only from better hotspot, but from new jvm
On Sat, May 27, 2006 at 02:50:46PM -0400, Yonik Seeley wrote:
> On 5/27/06, Andi Vajda <[EMAIL PROTECTED]> wrote:
> >As long as gcj is not implementing the new language features in 1.5, I'm
> >stuck
> >with 1.4.
> Good point Andi... that's a pretty compelling reason to stick with 1.4 for
> now.
A
[ http://issues.apache.org/jira/browse/LUCENE-489?page=all ]
Daniel Naber updated LUCENE-489:
Attachment: qp.diff
I wrote this patch that let's users enable the leading wildcard using a method
call. It applies to 1.9, but if someone wants to test it and
On Sat, 2006-05-27 at 13:09 -0700, Robin H. Johnson wrote:
>
> As another one that I ran into, until gcj gets 1.5 going, Linux on
> SPARC and Alpha platforms is stuck at the 1.4 level - there are no 1.5
> jdk/jre available. I think some other platforms may be stuck at a
> similar point - possibly
On Sat, May 27, 2006 at 10:50:42PM +0200, karl wettin wrote:
> On Sat, 2006-05-27 at 13:09 -0700, Robin H. Johnson wrote:
> > As another one that I ran into, until gcj gets 1.5 going, Linux on
> > SPARC and Alpha platforms is stuck at the 1.4 level - there are no 1.5
> > jdk/jre available. I think
[
http://issues.apache.org/jira/browse/LUCENE-582?page=comments#action_12413605 ]
Eric Jain commented on LUCENE-582:
--
If you want to be able to "rescue" the query, I believe the catching has to be
done in the rewrite method, which means you need to subclas
I think 2.0 should allow (and use) JDK 1.5 source code. If you need JDK 1.4
compatibility, use Lucene 1.9.
-Original Message-
From: karl wettin [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 27, 2006 4:09 AM
To: java-dev@lucene.apache.org
Subject: Lucene and Java 1.5
Will code with 1.5
Robin H. Johnson wrote on 05/27/2006 11:05 AM:
>> After all, Lucene comes with version numbers.
>>
> Yes it does, I just think the core functionality shouldn't be so quick
> to change away from supporting 1.4.
>
2 years is hardly quick. Performance, contributions from the vast
majority of
On Sat, 2006-05-27 at 14:05 -0700, Robin H. Johnson wrote:
> On Sat, May 27, 2006 at 10:50:42PM +0200, karl wettin wrote:
> > Is that really something Lucene should worry about, how some minority
> > architectures are not up to date with the JMV?
>
> I'm just saying that for some places it may be a
[
http://issues.apache.org/jira/browse/LUCENE-582?page=comments#action_12413606 ]
Yonik Seeley commented on LUCENE-582:
-
Any fallback strategy should attempt to score the same way. If it doesn't it's
brittle and will lead to surprises (e.g. when I add
On Sat, 2006-05-27 at 12:33 -0500, Robert Engels wrote:
> Correct. It is purely a coding issue which can lead to greater
> productivity by the developers - which helps out everyone.
+1
The easier it is to design, code and test,
the better software in shorter time.
---
On 28/05/2006, at 7:25 AM, Chuck Williams wrote:
Robin H. Johnson wrote on 05/27/2006 11:05 AM:
After all, Lucene comes with version numbers.
Yes it does, I just think the core functionality shouldn't be so
quick
to change away from supporting 1.4.
2 years is hardly quick. Performance,
On Sat, 27 May 2006, karl wettin wrote:
How about a binary 1.4-target distribution?
That's a great idea that might solve the problem as long as the
resulting bytecode is compatible with 1.4 and with gcj.
When compiling Java Lucene for PyLucene with gcj I compile from .jar to .o
which gcj
On Sun, 2006-05-28 at 07:59 +1000, Ian Holsman wrote:
>
> OS/X just released their 1.5 version about 2-3 months ago.
I've been running Apple 1.5 on Tiger for... one year?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additio
Greets,
I've been looking over the Hit class, and I notice that there's a
getBoost() method.
/**
* Returns the boost factor for this hit on any field of the
underlying document.
*
* @see Document#getBoost()
*/
public float getBoost() throws IOException {
return getDocum
sorry..
your right.
Rel 1 was released in april 2005, Rel 4 (april 2006) was the one
which made it the default.
On 28/05/2006, at 8:01 AM, karl wettin wrote:
On Sun, 2006-05-28 at 07:59 +1000, Ian Holsman wrote:
OS/X just released their 1.5 version about 2-3 months ago.
I've been runnin
Andi Vajda wrote on 05/27/2006 12:01 PM:
>
> On Sat, 27 May 2006, karl wettin wrote:
>
>> How about a binary 1.4-target distribution?
>
> That's a great idea that might solve the problem as long as the
> resulting bytecode is compatible with 1.4 and with gcj.
>
This would preclude use of the 1.5
: important new facilities. Repeating my earlier question, why should a
: platform that is 2 years behind for java expect to be at the latest and
: greatest level for lucene? I'd propose 2.0 (+ branched patches) be the
: 1.4 release distribution, with 2.1 free to move up to 1.5.
I would ammend tha
On Samstag 27 Mai 2006 05:57, Doug Cutting wrote:
> Release 2.0.0 of Lucene is now available from:
I suggest we also add the news to lucene.apache.org (not only to the java
sub project). Could you do that? I can also do it if you tell me where to
find the files in SVN.
Regards
Daniel
--
htt
For those who haven't heard about the GData project please check
today's mailing list .
The Lucene Indexer is supposed to be used as the search component of
this implementation. As GData is an extension to the Atom/Rss format
including search and a kind of versioning. This project is a server
sid
On Sat, 27 May 2006, Chuck Williams wrote:
Andi Vajda wrote on 05/27/2006 12:01 PM:
On Sat, 27 May 2006, karl wettin wrote:
How about a binary 1.4-target distribution?
That's a great idea that might solve the problem as long as the
resulting bytecode is compatible with 1.4 and with gcj.
Simon,
Storing content in a Lucene index is a common approach and works well.
I use a patch, LUCENE-362, to boost performance. Compress and
decompress the field externally, storing just the byte[] in the Lucene
index. The patch eliminates all copying of the byte[] otherwise done in
lucene, at t
Hi Simon,
The majority of the impact to large stored fields will be on the
indexing side (merging will take a little longer). There will be no
impact to searching, and the impact to retrieving documents shouldn't
matter (assuming you normally want those stored fields when you
retrieve hits).
I'
On Sat, 2006-05-27 at 16:35 -0700, Andi Vajda wrote:
> >>> How about a binary 1.4-target distribution?
> >>
> > This would preclude use of the 1.5 class library, which contains many
> > important new facilities. Repeating my earlier question, why should a
> > platform that is 2 years behind for jav
: I've been looking over the Hit class, and I notice that there's a
: getBoost() method.
That thing is crazy ... how was that ever intended to work?
: Maybe I'm missing something, but unless the user directly manipulates
: the underlying Document object I think this will always return 1.
I don'
On 5/27/06, Daniel Naber <[EMAIL PROTECTED]> wrote:
On Samstag 27 Mai 2006 05:57, Doug Cutting wrote:
> Release 2.0.0 of Lucene is now available from:
I suggest we also add the news to lucene.apache.org (not only to the java
sub project). Could you do that? I can also do it if you tell me where
57 matches
Mail list logo
