RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
: From: Robert Engels : The "lazy" refers to the ability/desire of the 1.4 "users & developers" to : devote their resources to back-porting the code to the 2.0.X release. Rather : than having the 1.5 developers having to waste their time "thinking" in 1.4 : when their work is predominately being performed using 1.5 : features/compilers/tools. There is NOTHING stopping the 1.4 community from : doing this, except their "laziness" in wanting to (especially given their : common assessment that 1.5 is nothing more than syntactic sugar). At the start of this brew-ha, I was very much in favor of 2.1.x allowing java1.5 features ... but comments like this make me question that opionion, because they suggest (in this case explicitly) the existence of a "1.4 community" that can backport things if "they" want to ... perhaps it's idealistic of me, but I'd like to think there is one big happy Lucene community that helps eachother, and I'd hate to knowingly and willfully take steps to fracture that community in half (more then this discussion already has). The whole is certainly greater then the sum of it's parts. : From: DM Smith : Can I stick with 2.0.x? Certainly. However, I'd rather not. I keep reading : about refactoring providing a significant, incremental improvement, and I'd : like to provide that, especially for those older machines! And here is where the other half of my brain chimes in -- The reason I initially supported the idea of using java1.5 for the 2.1.x release is because there is no doubt in my mind that being able to use 1.5 language features (specificly generics and concurrency utils) will make refactoring and cleaning up the core Lucene APIs easier, faster, and safer then if we constrain ourselves to java1.4. -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Robert Engels wrote: People making these arguments against 1.5 sound really ill-informed, or lazy. Neither of which is good for open-source development. Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. I have some applications that I have written in 1.5 - and yes - it is nice. But I also have other applications (that use Lucene) that are written to be 1.4 compatible. And they need to stay that way for quite some time to come. Why? Many reasons. The first - because they implement an official HL7 specification - and the specification says that the implementation needs to support Java 1.4. Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gracious enough to fix for me). Lucene is a low level library that is used to build many great applications. If you make the jump to 1.5 today - you are going to be leaving people behind. And judging by the poll, you are going to be leaving a fairly significant number of people behind. Lucene has great policy on not breaking backwards compatibility in their API - why should this be looked at any differently? > Rather than having the 1.5 developers having to waste their time > "thinking" in 1.4 when their work is predominately being performed > using 1.5 features/compilers/tools. I don't think that the caliber of developers that are working on the Lucene core are going to be slowed down any by using 1.4 syntax over 1.5. (It actually takes longer to type in all of those generics :) All of my tools - Eclipse and Java 1.5 - have a check box that will cause them to generate 1.4 compatible code. Its really _not_ a big deal to write 1.4 code even if you are used to 1.5. This particular argument just isn't compelling to me. My personal opinion for the path that Lucene should take: Core bugs fixes must be 1.4 compatible. Core improvements must be 1.4 compatible. Contrib / sandbox can be 1.5 or 1.6. Of course, at some point - Lucene Core does need to advance. But I don't just don't feel that syntactic sugar in 1.5 is enough of a reason to break backwards compatibility. I haven't followed 1.6 - I don't know what the new features are there. Assuming that there are great new features in 1.6 - that would improve the lucene core if they were used - I think that that is when this issue gets revisited. This isn't the type of question that should be decided by a poll. This should be decided by thoughtfully looking at the consequences of each choice. For me - the negative consequences of choosing 1.5 - leaving behind a lot of users - is much worse than the negative consequences of staying at 1.4 - making a couple dozen highly skilled developers check an extra box in their lucene development environments? If any developers have actually read this far (sorry - it got kind of long) - thanks again for all of your great work - Lucene is a great tool - and a great community. Dan -- Daniel Armbrust Biomedical Informatics Mayo Clinic Rochester daniel.armbrust(at)mayo.edu http://informatics.mayo.edu/ ---
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
To set the record straight, I think the Lucene product and community are fantastic. Period. I was also not the one who starting in with what could be termed 'aggressive' language. Our company does not fully support 1.5. I was the loudest voice against the move to 1.5. After almost 2 years I now back the move. Why? Several reasons: 1. Sun is very slow, if at all to fix bugs in 1.4 (of which there are many). For example, the current problems in Lucene regarding ThreadLocals. Although this is not a bug per se, it is probably not intuitive or desired behavior. The Lucene developers have been forced to both diagnose and create workarounds "problems" already fixed in 1.5. The licensing of Java does not allow for the easy fix bugs by non-Sun developers. 2. The type safe collections are far more efficient to program/debug with. 3. The standardized concurrent facilities can be of great benefit to multithreaded programs. 4. It is what students graduating from college understand and use. 5. It is what the currently available books explain and use. It just seems that many people believe that if there is ONE person (or a minority) that can't switch, then Lucene cannot switch. It seems that Bob is in this category of never being able to switch (I am fairly certain 1.5 will probably never be released for OS 9) - does that mean that Lucene developers can never use 1.5 features? What about the argument I made of using alternative algorithms that may not be as useable on older, slower machines. We have users that cannot upgrade to the latest release of our software because of inadequate hardware (or unwillingness to change). They have 3 choices. Stick with the old, upgrade their machines, or move to a competitor. The last of which we surely do not want, but that is their choice. At the same time, if we did not continue to grow and evolve our software, we would lose far more of our customers to competitors. This is open-source software. A clear majority has voted. Why can't we listen to them and move forward??? -Original Message- From: Dan Armbrust [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 8:42 AM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) Robert Engels wrote: > > People making these arguments against 1.5 sound really ill-informed, > or lazy. Neither of which is good for open-source development. > Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. I have some applications that I have written in 1.5 - and yes - it is nice. But I also have other applications (that use Lucene) that are written to be 1.4 compatible. And they need to stay that way for quite some time to come. Why? Many reasons. The first - because they implement an official HL7 specification - and the specification says that the implementation needs to support Java 1.4. Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gracious enough to fix for me). Lucene is a low level library that is used to build many great applications. If you make the jump to 1.5 today - you are going to be leaving people behind. And judging by the poll, you are going
lucene in combination with pattern recognition...
hi... i'm looking at a problem and i can't figure out how to "easily" solve it... basically, i'm trying to figure out if there's a way to use lucene/nutch with some form of pattern matching to extract course information from a College/Registrar's course section... Assume I can point to a Regiatrar's section of a College site. Assume I can then crawl through the section, and capture all the underlying information, including the Course information... Is there a way to somehow use pattern matching/recognition to somehow interpret the DOM to pull out the class schedule information. I'm pretty sure there's no vanilla approach, so I'd even consider some kind of solution where I might have to intially evaluate/analyze the site, to tell it what DOM elements are "important"... anyone done any work/projects like this... any research/papers/sample apps i could look at... any thoughts/comments/etc i could brute force this by writing a bunch of perl scripts, with each script tied to a given registrar site, but i'd like a more generalizable solution if one exists.. thanks -bruce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I have another idea. Why don't we just let the voted committers decide amongst themselves. Since they are principally charged with maintaining the code quality and feature set, they are in the best position to make the decision. -Original Message- From: Dan Armbrust [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 8:42 AM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) Robert Engels wrote: > > People making these arguments against 1.5 sound really ill-informed, > or lazy. Neither of which is good for open-source development. > Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. I have some applications that I have written in 1.5 - and yes - it is nice. But I also have other applications (that use Lucene) that are written to be 1.4 compatible. And they need to stay that way for quite some time to come. Why? Many reasons. The first - because they implement an official HL7 specification - and the specification says that the implementation needs to support Java 1.4. Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gracious enough to fix for me). Lucene is a low level library that is used to build many great applications. If you make the jump to 1.5 today - you are going to be leaving people behind. And judging by the poll, you are going to be leaving a fairly significant number of people behind. Lucene has great policy on not breaking backwards compatibility in their API - why should this be looked at any differently? > Rather than having the 1.5 developers having to waste their time > "thinking" in 1.4 when their work is predominately being performed > using 1.5 features/compilers/tools. I don't think that the caliber of developers that are working on the Lucene core are going to be slowed down any by using 1.4 syntax over 1.5. (It actually takes longer to type in all of those generics :) All of my tools - Eclipse and Java 1.5 - have a check box that will cause them to generate 1.4 compatible code. Its really _not_ a big deal to write 1.4 code even if you are used to 1.5. This particular argument just isn't compelling to me. My personal opinion for the path that Lucene should take: Core bugs fixes must be 1.4 compatible. Core improvements must be 1.4 compatible. Contrib / sandbox can be 1.5 or 1.6. Of course, at some point - Lucene Core does need to advance. But I don't just don't feel that syntactic sugar in 1.5 is enough of a reason to break backwards compatibility. I haven't followed 1.6 - I don't know what the new features are there. Assuming that there are great new features in 1.6 - that would improve the lucene core if they were used - I think that that is when this issue gets revisited. This isn't the type of question that should be decided by a poll. This should be decided by thoughtfully looking at the consequences of each choice. For me - the negative consequences of choosing 1.5 - leaving behind a lot of users - is much worse than the negative consequences of staying at 1.4 - making a couple dozen highly skilled developers check an extra box in their lucene development
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Robert Engels wrote: To set the record straight, I think the Lucene product and community are fantastic. Period. Ditto. [snip] After almost 2 years I now back the move. Why? Several reasons: 1. Sun is very slow, if at all to fix bugs in 1.4 (of which there are many). For example, the current problems in Lucene regarding ThreadLocals. Although this is not a bug per se, it is probably not intuitive or desired behavior. The Lucene developers have been forced to both diagnose and create workarounds "problems" already fixed in 1.5. The licensing of Java does not allow for the easy fix bugs by non-Sun developers. 2. The type safe collections are far more efficient to program/debug with. 3. The standardized concurrent facilities can be of great benefit to multithreaded programs. 4. It is what students graduating from college understand and use. 5. It is what the currently available books explain and use. For my money (2) is the most important reason for moving to 1.5. My early years (!) involved a lot of work with programming languages and finally having type-safe collections and the syntactic conventions that go along with those immediately struck me as a good step forward. That first impression was borne out when I converted some of my java code to use the 1.5 type-safe constructs. Not only was the code shorter and more understandable (aka more maintainable) but it brought to light some bugs that had lain their dormant for quite a while. Lucene is well-tested and stable and written by better people better at writing Java than me so it's unlikely that there'll be any bugs like that lurking in dark corners. On the other hand, new code stands a better chance of being bug free precisely because of the improvements in the language and the improved type-safety. (3) comes second for me though -- I'm a big fan of Doug Lea's util.concurrent classes and having them well integrated in Java 1.5 makes them even better, but that's the operating system personality talking. jch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Sorry, for some reason my Yahoo email doesn't prepend ">" on replies, so I'll use "OG" for my lines. - Original Message From: Dan Armbrust <[EMAIL PROTECTED]> Robert Engels wrote: > > People making these arguments against 1.5 sound really ill-informed, or > lazy. Neither of which is good for open-source development. > Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. OG: I think you are missing or misinterpreting things here. Lucene contributors tend to be people who write nice extensions to Lucene, and want to give them back to Lucene. Typically those extensions come out of their day jobs, or at least that is my impression. When they use 1.5 there, their contribution will be 1.5. External contributors already spend extra time and effort to do this. Requiring them to modify their code not to use 1.5 would mean they will be less likely to contribute. I wouldn't bother, if I had to take extra time and effort to contribute, and even "go backwards" with my code, when what I really want is for my piece of code to become a part of Lucene, so I can just use that code instead of maintaining my own variation of it. OG: My main concern is losing those contributions. We already have a TON of good patches in JIRA that we didn't integrate, and lots of them are lost, because patches no longer apply. I hate treating kind contributors like that. I feel ungrateful. OG: So, instead of only thinking how if Lucene 2.1 goes the 1.5 route you won't be able to use the latest and greatest, one can also think about losing the latest and greatest contributions because they are written with 1.5 in mind. And this is not a loss only to those who are already on 1.5. This is a loss for _everyone_ in the long run. Those running 1.4 now, will be running 1.5 one day, but they won't be getting Lucene with contributions that were rejected, because in the second half of 2006 we were forced to reject all 1.5 contributions. I have some applications that I have written in 1.5 - and yes - it is nice. But I also have other applications (that use Lucene) that are written to be 1.4 compatible. And they need to stay that way for quite some time to come. OG: Exactly. There will ALWAYS be people who have to stay with 1.4 or older Java. At some point you have to decide not support the older versions, just like at some point we decided to stop supporting 1.3. Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. OG: Again, exactly. If this is an environment where upgrades are very carefully planned and thus probably rare, why does this environment care SO much to have the cutting edge Lucene, when at the same time they are ok with a old version of Java? Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? OG: It is NOT syntactic sugar only. This is FUD! :) Really. I just found a bug in my code that was hidden for several weeks because I was using a List instead of List, for instance! Also, this "entire ecosystem of potential users" seems a bit exaggerated. :) They certainly didn't seem to take part in that survey. I think J2ME on mobile devices might even be 1.2 Java, not sure. While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gra
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
> A clear majority has voted. Why can't we > listen to them and move forward??? Just to be clear: a (badly designed) poll was taken. No one "voted". Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-569) NearSpans skipTo bug
[ http://issues.apache.org/jira/browse/LUCENE-569?page=comments#action_12416949 ] paul.elschot commented on LUCENE-569: - TestSpanExplanations (latest) with the SpanScorer.explain.testcase.patch passes here, but my intermediate version of NearSpansOrdered.java does not pass TestSpans yet. > NearSpans skipTo bug > > > Key: LUCENE-569 > URL: http://issues.apache.org/jira/browse/LUCENE-569 > Project: Lucene - Java > Type: Bug > Components: Search > Reporter: Hoss Man > Attachments: SpanScorer.explain.testcase.patch, TestNearSpans.java > > NearSpans appears to have a bug in skipTo that causes it to skip over some > matching documents completely. I discovered this bug while investigating > problems with SpanWeight.explain, but as far as I can tell the Bug is not > specific to Explanations ... it seems like it could potentially result in > incorrect matching in some situations where a SpanNearQuery is nested in > another query such thatskipTo will be used ... I tried to create a high level > test case to exploit the bug when searching, but i could not. TestCase > exploiting the class using NearSpan and SpanScorer will follow... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I would like to suggest that a central core Lucene be identified and
that core be maintained as compatible for Java 1.4.
It has also been stated that J2ME compatibility is a future goal. It
would be nice to consider that in defining a central core. (BTW, there
are two J2ME standards, one is a subset of Java 1.3 and the newer is a
subset of Java 1.4, but it is not widely implemented on target devices.
Since Lucene does not support J2ME today, perhaps the 1.4 version is
appropriate.)
Outside of that central core, I think Java 5, even Java 6 is just fine.
And probably this is where most of the contributions will be.
As I said earlier, I am not a Lucene developer, but a Lucene user.
Here is an example of what I use (very trivial):
For indexing:
IndexWriter writer = new IndexWriter(tempPath.getCanonicalPath(), new
SimpleAnalyzer(), true)
loop over all (verseReference,verseText) pairs
Document doc = new Document();
doc.add(new Field(FIELD_NAME, verseReference, Field.Store.YES,
Field.Index.NO));
doc.add(new Field(FIELD_BODY, new StringReader(verseText)));
writer.addDocument(doc);
end loop
writer.optimize();
writer.close();
And for searching:
IndexSearcher searcher = new IndexSearcher(path);
Analyzer analyzer = new SimpleAnalyzer();
QueryParser parser = new QueryParser(LuceneIndex.FIELD_BODY, analyzer);
Query query = parser.parse(search);
Hits hits = searcher.search(query);
for (int i = 0; i < hits.length(); i++)
{
Verse verse =
VerseFactory.fromString(hits.doc(i).get(LuceneIndex.FIELD_NAME));
// PassageTally understands a score of 0 as the verse not participating
int score = (int) (hits.score(i) * 100 + 1);
tally.add(verse, score);
}
I just don't see why Java 5 needs to be behind this kind of usage.
See below for more responses.
Robert Engels wrote:
To set the record straight, I think the Lucene product and community are
fantastic. Period.
I was also not the one who starting in with what could be termed
'aggressive' language.
Our company does not fully support 1.5. I was the loudest voice against the
move to 1.5.
After almost 2 years I now back the move. Why? Several reasons:
1. Sun is very slow, if at all to fix bugs in 1.4 (of which there are many).
For example, the current problems in Lucene regarding ThreadLocals. Although
this is not a bug per se, it is probably not intuitive or desired behavior.
The Lucene developers have been forced to both diagnose and create
workarounds "problems" already fixed in 1.5. The licensing of Java does not
allow for the easy fix bugs by non-Sun developers.
I'm not certain, but IIRC earlier messages in the first Java 5 thread,
this was not a change that prevented compiling under Java 5 for a Java
1.4 target.
I think that this is an example of where we need to be clear about
runtime compatibility. Java 1.4 programs compiled with a Java 1.4
compiler run better under Java 5. Programs that don't use Java 5
features can be compiled with Java 1.4 compatibility using the Java 5
compiler.
As long as the bugs are fixed in Java 5 and it can be cross-compiled for
Java 1.4, the fix becomes available under a Java 1.4 jre.
2. The type safe collections are far more efficient to program/debug with.
I personally find this to be the case, but it does not change "business
requirements" of a target application.
3. The standardized concurrent facilities can be of great benefit to
multithreaded programs.
These can be used without going to Java 5. I have been using them since
Java 1.3. Granted it would be a dependency and a first for Lucene. The
license clearly places the cpj code in the public domain. This means
that it can be distributed within the Lucene jar.
4. It is what students graduating from college understand and use.
5. It is what the currently available books explain and use.
True, but they are still taught the "old" way. Anyone needing to
maintain or enhance existing pre Java 5 code will have to know the old
way. Given the caliper of developers here and those that provide
patches, I doubt that there is anyone that would have any difficulty
writing Java 1.4 code.
It just seems that many people believe that if there is ONE person (or a
minority) that can't switch, then Lucene cannot switch. It seems that Bob is
in this category of never being able to switch (I am fairly certain 1.5 will
probably never be released for OS 9) - does that mean that Lucene developers
can never use 1.5 features? What about the argument I made of using
alternative algorithms that may not be as useable on older, slower machines.
Java 5 will never be released for MacOS 10.3. This OS is still current,
supported and widely used.
I mentioned MacOS 9, because it is a business requirement for me. And
yes, it will be many year before we will drop support for it. And during
those years, I would like to have the benefit of bug fixes, performance
enhancements and new features (such as leading wild card searches, if
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I think Otis put things perfectly and would like to second everything he's said. This is about facilitating more contributions from the majority vs. creating a version that the minority can use. To answer Otis's question, "How small does the percentage of 1.4 users need to be, before we can have 1.5 in Lucene?", I think there are some other factors that need to be considered. How many contributors to Lucene are generating contributions out of work they are doing for their companies or other vocations, submitting these to Lucene to achieve the benefits of community usage/maintenance/enhancement, and using 1.5 as their daily environment? My suspicion is that while the user ratio may be 2:1 1.5:1.4 that the contributor ratio is even more skewed in favor of 1.5. One of the reasons I suspect this is that the 1.4 users who have spoken up thus far do not seem to fully appreciate the volunteer-contribution model of the Lucene community (e.g., see the thread below). I think it is safe to assume that potential contributors will be less motivated if they are forced to back port their code. If Lucene makes the 1.5 decision, about 1/3 of the Lucene user base today will not be able to build off the head, although they will have a fully supported 2.0.x. The 1/3 portion will decline continually, but this is still a substantial problem. I'm sure the Lucene pmc/committers do not want to leave so many users behind. If Lucene makes the 1.4 decision, it will get fewer contributions. As one example, I will only submit bug fixes. I'm waiting to see how this turns out to decide whether or not to contribute some new features that are all coded in 1.5. The question is how many contributors are in a similar situation? If this number is say greater than 80%, rather than the 67% indicated in the usage poll, then making the 1.4 decision is also a substantial problem for Lucene's future. Chuck Otis Gospodnetic wrote on 06/20/2006 09:33 AM: > Sorry, for some reason my Yahoo email doesn't prepend ">" on replies, so I'll > use "OG" for my lines. > > - Original Message > From: Dan Armbrust <[EMAIL PROTECTED]> > Robert Engels wrote: > > >> People making these arguments against 1.5 sound really ill-informed, or >> lazy. Neither of which is good for open-source development. >> >> > > Preface - I'm not a lucene developer - just an interested user. > > I don't know - it seems to me that it is the 1.5 crowd that is making > the lazy argument. You are in effect, saying, that the highly skilled > developers who would be making lucene contributions are unable or > unwilling to write 1.4 java code? Come on... it really not that hard. > Which set is being lazy? I'll stop the name calling now, and try to > make a better point. > > OG: I think you are missing or misinterpreting things here. Lucene > contributors tend to be people who write nice extensions to Lucene, and want > to give them back to Lucene. Typically those extensions come out of their > day jobs, or at least that is my impression. When they use 1.5 there, their > contribution will be 1.5. External contributors already spend extra time and > effort to do this. Requiring them to modify their code not to use 1.5 would > mean they will be less likely to contribute. I wouldn't bother, if I had to > take extra time and effort to contribute, and even "go backwards" with my > code, when what I really want is for my piece of code to become a part of > Lucene, so I can just use that code instead of maintaining my own variation > of it. > > OG: My main concern is losing those contributions. We already have a TON of > good patches in JIRA that we didn't integrate, and lots of them are lost, > because patches no longer apply. I hate treating kind contributors like > that. I feel ungrateful. > > OG: So, instead of only thinking how if Lucene 2.1 goes the 1.5 route you > won't be able to use the latest and greatest, one can also think about losing > the latest and greatest contributions because they are written with 1.5 in > mind. And this is not a loss only to those who are already on 1.5. This is > a loss for _everyone_ in the long run. Those running 1.4 now, will be > running 1.5 one day, but they won't be getting Lucene with contributions that > were rejected, because in the second half of 2006 we were forced to reject > all 1.5 contributions. > > I have some applications that I have written in 1.5 - and yes - it is > nice. But I also have other applications (that use Lucene) that are > written to be 1.4 compatible. And they need to stay that way for quite > some time to come. > > OG: Exactly. There will ALWAYS be people who have to stay with 1.4 or older > Java. At some point you have to decide not support the older versions, just > like at some point we decided to stop supporting 1.3. > > Also, at my place of employment we have about 40,000 desktop computers > that are all centrally managed - down to every point
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Robert Engels wrote: I have another idea. Why don't we just let the voted committers decide amongst themselves. If push comes to shove, this decision will be made by consensus of the Lucene PMC. Any member of the PMC can veto any change to the code. http://www.apache.org/foundation/voting.html As a member of the PMC, I presently find the arguments of those who'd like to keep the Lucene core in 1.4 more compelling, although I don't know yet whether I'd use my veto power. In the history of Lucene we've rarely had to even resort to voting to make code decisions, and I don't think anyone has ever vetoed anything. It would be best if we could come to an agreement here without alienating anyone and without resorting to vetoes. For this to happen, we all need to try hard to understand the concerns of others. Some folks reasonably want to use the latest features of Lucene but also have constraints about what Java version their users can use. Developers whose users are not so constrained want to be able to use the latest features of Java. I think the inconvenience to the former (lack of user access to new Lucene features) affects more folks than that to the latter (lack of developer access to new Java features). In the end, we develop Lucene for users, no? We obviously can't always please all of them, but this isn't a user-versus-user issue, but rather a user-versus-developer issue, where we, the developers, have all the power. We have the power to be kind and thoughtful, or to be selfish. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I think your statement "do not seem to fully appreciate the volunteer-contribution model" hits the nail on the head. There is a minority that wants everything for free, wants it work exactly as they want, and then have the audacity to tell the others they should do more even work to make them happy - all without contributing a single hour of work to the product (maybe via testing...). -Original Message- From: Chuck Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 1:15 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) I think Otis put things perfectly and would like to second everything he's said. This is about facilitating more contributions from the majority vs. creating a version that the minority can use. To answer Otis's question, "How small does the percentage of 1.4 users need to be, before we can have 1.5 in Lucene?", I think there are some other factors that need to be considered. How many contributors to Lucene are generating contributions out of work they are doing for their companies or other vocations, submitting these to Lucene to achieve the benefits of community usage/maintenance/enhancement, and using 1.5 as their daily environment? My suspicion is that while the user ratio may be 2:1 1.5:1.4 that the contributor ratio is even more skewed in favor of 1.5. One of the reasons I suspect this is that the 1.4 users who have spoken up thus far do not seem to fully appreciate the volunteer-contribution model of the Lucene community (e.g., see the thread below). I think it is safe to assume that potential contributors will be less motivated if they are forced to back port their code. If Lucene makes the 1.5 decision, about 1/3 of the Lucene user base today will not be able to build off the head, although they will have a fully supported 2.0.x. The 1/3 portion will decline continually, but this is still a substantial problem. I'm sure the Lucene pmc/committers do not want to leave so many users behind. If Lucene makes the 1.4 decision, it will get fewer contributions. As one example, I will only submit bug fixes. I'm waiting to see how this turns out to decide whether or not to contribute some new features that are all coded in 1.5. The question is how many contributors are in a similar situation? If this number is say greater than 80%, rather than the 67% indicated in the usage poll, then making the 1.4 decision is also a substantial problem for Lucene's future. Chuck Otis Gospodnetic wrote on 06/20/2006 09:33 AM: > Sorry, for some reason my Yahoo email doesn't prepend ">" on replies, so I'll use "OG" for my lines. > > - Original Message > From: Dan Armbrust <[EMAIL PROTECTED]> Robert Engels > wrote: > > >> People making these arguments against 1.5 sound really ill-informed, >> or lazy. Neither of which is good for open-source development. >> >> > > Preface - I'm not a lucene developer - just an interested user. > > I don't know - it seems to me that it is the 1.5 crowd that is making > the lazy argument. You are in effect, saying, that the highly skilled > developers who would be making lucene contributions are unable or > unwilling to write 1.4 java code? Come on... it really not that hard. > Which set is being lazy? I'll stop the name calling now, and try to > make a better point. > > OG: I think you are missing or misinterpreting things here. Lucene contributors tend to be people who write nice extensions to Lucene, and want to give them back to Lucene. Typically those extensions come out of their day jobs, or at least that is my impression. When they use 1.5 there, their contribution will be 1.5. External contributors already spend extra time and effort to do this. Requiring them to modify their code not to use 1.5 would mean they will be less likely to contribute. I wouldn't bother, if I had to take extra time and effort to contribute, and even "go backwards" with my code, when what I really want is for my piece of code to become a part of Lucene, so I can just use that code instead of maintaining my own variation of it. > > OG: My main concern is losing those contributions. We already have a TON of good patches in JIRA that we didn't integrate, and lots of them are lost, because patches no longer apply. I hate treating kind contributors like that. I feel ungrateful. > > OG: So, instead of only thinking how if Lucene 2.1 goes the 1.5 route you won't be able to use the latest and greatest, one can also think about losing the latest and greatest contributions because they are written with 1.5 in mind. And this is not a loss only to those who are already on 1.5. This is a loss for _everyone_ in the long run. Those running 1.4 now, will be running 1.5 one day, but they won't be getting Lucene with contributions that were rejected, because in the second half of 2006 we were forced to reject all 1.5 contributions. > > I have some applications that I have written in 1.5 - a
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Could someone shed light on how the decision to transition from Java 1.3 to Java 1.4 unfolded? Any lessons learned or applicable here? Mike "Robert Engels" <[EMAIL PROTECTED]> 06/20/2006 02:24 PM Please respond to java-dev@lucene.apache.org To cc Subject RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) I think your statement "do not seem to fully appreciate the volunteer-contribution model" hits the nail on the head. There is a minority that wants everything for free, wants it work exactly as they want, and then have the audacity to tell the others they should do more even work to make them happy - all without contributing a single hour of work to the product (maybe via testing...). -Original Message- From: Chuck Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 1:15 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) I think Otis put things perfectly and would like to second everything he's said. This is about facilitating more contributions from the majority vs. creating a version that the minority can use. To answer Otis's question, "How small does the percentage of 1.4 users need to be, before we can have 1.5 in Lucene?", I think there are some other factors that need to be considered. How many contributors to Lucene are generating contributions out of work they are doing for their companies or other vocations, submitting these to Lucene to achieve the benefits of community usage/maintenance/enhancement, and using 1.5 as their daily environment? My suspicion is that while the user ratio may be 2:1 1.5:1.4 that the contributor ratio is even more skewed in favor of 1.5. One of the reasons I suspect this is that the 1.4 users who have spoken up thus far do not seem to fully appreciate the volunteer-contribution model of the Lucene community (e.g., see the thread below). I think it is safe to assume that potential contributors will be less motivated if they are forced to back port their code. If Lucene makes the 1.5 decision, about 1/3 of the Lucene user base today will not be able to build off the head, although they will have a fully supported 2.0.x. The 1/3 portion will decline continually, but this is still a substantial problem. I'm sure the Lucene pmc/committers do not want to leave so many users behind. If Lucene makes the 1.4 decision, it will get fewer contributions. As one example, I will only submit bug fixes. I'm waiting to see how this turns out to decide whether or not to contribute some new features that are all coded in 1.5. The question is how many contributors are in a similar situation? If this number is say greater than 80%, rather than the 67% indicated in the usage poll, then making the 1.4 decision is also a substantial problem for Lucene's future. Chuck Otis Gospodnetic wrote on 06/20/2006 09:33 AM: > Sorry, for some reason my Yahoo email doesn't prepend ">" on replies, so I'll use "OG" for my lines. > > - Original Message > From: Dan Armbrust <[EMAIL PROTECTED]> Robert Engels > wrote: > > >> People making these arguments against 1.5 sound really ill-informed, >> or lazy. Neither of which is good for open-source development. >> >> > > Preface - I'm not a lucene developer - just an interested user. > > I don't know - it seems to me that it is the 1.5 crowd that is making > the lazy argument. You are in effect, saying, that the highly skilled > developers who would be making lucene contributions are unable or > unwilling to write 1.4 java code? Come on... it really not that hard. > Which set is being lazy? I'll stop the name calling now, and try to > make a better point. > > OG: I think you are missing or misinterpreting things here. Lucene contributors tend to be people who write nice extensions to Lucene, and want to give them back to Lucene. Typically those extensions come out of their day jobs, or at least that is my impression. When they use 1.5 there, their contribution will be 1.5. External contributors already spend extra time and effort to do this. Requiring them to modify their code not to use 1.5 would mean they will be less likely to contribute. I wouldn't bother, if I had to take extra time and effort to contribute, and even "go backwards" with my code, when what I really want is for my piece of code to become a part of Lucene, so I can just use that code instead of maintaining my own variation of it. > > OG: My main concern is losing those contributions. We already have a TON of good patches in JIRA that we didn't integrate, and lots of them are lost, because patches no longer apply. I hate treating kind contributors like that. I feel ungrateful. > > OG: So, instead of only thinking how if Lucene 2.1 goes the 1.5 route you won't be able to use the latest and greatest, one can also think about losing the latest and greatest contributions because they are written with 1.5 in mind. And this is not a loss only to those who ar
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/20/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: Sorry, for some reason my Yahoo email doesn't prepend ">" on replies, so I'll use "OG" for my lines. - Original Message From: Dan Armbrust <[EMAIL PROTECTED]> Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. OG: Again, exactly. If this is an environment where upgrades are very carefully planned and thus probably rare, why does this environment care SO much to have the cutting edge Lucene, when at the same time they are ok with a old version of Java? In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? OG: It is NOT syntactic sugar only. This is FUD! :) Really. I just found a bug in my code that was hidden for several weeks because I was using a List instead of List, for instance! I think I was the first to suggest that some of Java 5's features were syntatic sugar. In saying this, I had no intention of spreading "Fear", "Uncertainty" or "Doubt". That strong type checking is valuable is certainly beyond a doubt. It is a syntax addition to the language that's really sweet! However, one can carefully write correct code without it. The other features such as autoboxing have a runtime cost that probably would be best to avoid. But boy is it easier to write code when you don't have to convert an integer to an Integer! Using the new iterator construct is simple and much more straightforward, but it does not add much to the code. While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gracious enough to fix for me). OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. One can get the performance gains just by using the Java 5 jre. I don't think that the caliber of developers that are working on the Lucene core are going to be slowed down any by using 1.4 syntax over 1.5. (It actually takes longer to type in all of those generics :) All of my tools - Eclipse and Java 1.5 - have a check box that will cause them to generate 1.4 compatible code. Its really _not_ a big deal to write 1.4 code even if you are used to 1.5. This particular argument just isn't compelling to me. OG: Please read what I wrote all the way up. In my mind, it is not so much about core Lucene developers, as it is about external contributions. Core developer will know what we agreed on and will write the code to suit our agreement. External contributor will contribute code she/he wrote for work. As the poll shows, more people use 1.5 at work, thus... My personal opinion for the path that Lucene should take: Core bugs fixes must be 1.4 compatible. Core improvements must be 1.4 compatible. Contrib / sandbox can be 1.5 or 1.6. How many external contributions are to the "core" Lucene? If the "core" Lucene contribution can be applied and then "downgraded" to Java 1.4 easily, what harm is in that?
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Doug Cutting wrote: [T]his isn't a user-versus-user issue, but rather a user-versus-developer issue, where we, the developers, have all the power. The poll[1] seems to indicate that a large minority of users are using Lucene with Java 1.4, and it has been asserted (without contention) that most Lucene developers (committers and contributors) are using Java 1.5. Could not tools like Retrotranslator[2] or Retroweaver[3] be used to satisfy both camps? That is, the Lucene source base could move to Java 1.5, while the Lucene project could continue to provide Java-1.4-JVM-compatible binaries. Steve [1] http://www.quimble.com/poll/view/2156 [2] http://retrotranslator.sourceforge.net/ [3] http://retroweaver.sourceforge.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
To me, I am just as likely to make contributions in 1.4 as I am 1.5 and I am running 1.5 in my daily life. I just don't find it all that hard to do 1.4 for Lucene since IntelliJ allows me to set my compiler version for the Lucene project and then forget about it, going about creating my patches. This is, after all, what we have been doing up until now. Sure there are a lot of benefits to 1.5 for coding, but I still plan on helping out even if we decide not to go to 1.5. Having said that, I think the versioning argument that Otis and others have made makes a lot of sense. I think stating that 2.0.x is the last 1.4 release is reasonable and that if there are people interested in maintaining branches then we should work to get them commit rights on those branches (is that even possible) so that they can backport changes to 1.4 if they want. And of course the code is always available such that one can maintain their own copy for their company. This is something I have had to do from time to time as I waited for patches to be applied and it is not the end of the world. As has been stressed a number of times 2.1 is not likely for some time (at least based on our previous release history). In the meantime people can prepare for the switch. After all, how many 1.4 users are actually using the Trunk of Lucene versus some know release? My two cents, Grant Chuck Williams wrote: I think Otis put things perfectly and would like to second everything he's said. This is about facilitating more contributions from the majority vs. creating a version that the minority can use. To answer Otis's question, "How small does the percentage of 1.4 users need to be, before we can have 1.5 in Lucene?", I think there are some other factors that need to be considered. How many contributors to Lucene are generating contributions out of work they are doing for their companies or other vocations, submitting these to Lucene to achieve the benefits of community usage/maintenance/enhancement, and using 1.5 as their daily environment? My suspicion is that while the user ratio may be 2:1 1.5:1.4 that the contributor ratio is even more skewed in favor of 1.5. One of the reasons I suspect this is that the 1.4 users who have spoken up thus far do not seem to fully appreciate the volunteer-contribution model of the Lucene community (e.g., see the thread below). I think it is safe to assume that potential contributors will be less motivated if they are forced to back port their code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
This poll does not indicate anything about Lucene. It is open to anyone who goes to quimble and searches on Java. On 6/16/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: It looks like I would have won a beer had anyone wagered me. 1.5 IS the Java version that the majority Lucene users use, not 1.4! Does this mean we can now start accepting 1.5 code? Otis - Original Message From: Otis Gospodnetic <[EMAIL PROTECTED]> To: java-user@lucene.apache.org Sent: Friday, June 16, 2006 11:48:15 AM Subject: Survey: Lucene and Java 1.4 vs. 1.5 Hello everyone, If you have 15 seconds to spare, please let us (Lucene developers) know which version of Java you are using with Lucene: 1.4 or 1.5 All it takes is 1 click on one of the two choices: http://www.quimble.com/poll/view/2156 No cheating, please. Thanks! Otis
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I agree with most of the points Otis makes. As a developer I would prefer to develop in Java5. As I do all my Solr development in Java5, it would be nice to be able to move some common stuff to Lucene more easily. Now I have to plan ahead of time if I think it has a decent probability of being wanted by the Lucene community, and avoid any Java5 features. A couple of points: - "syntactic sugar" is a rather broad categorization, including some very useful things. It is not synonymous with "irrelevant" or "should not be seriously considered", although it has that connotation. I'd recommend avoiding that phrase. - I disagree with many of the arguments 1.4 proponents are making about the Java5 language/library improvements themselves. The real compelling argument is that moving to Java5 now will inconvenience a fair number of people. I'd personally be more comfortable moving to Java5 if at least GCJ had support (which it looks like it's getting!) -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-398) ParallelReader crashes when trying to merge into a new index
On a side note, please feel free to vote for bugs to get the attention
of a committer. Opening a duplicate bug just makes it harder to
straighten out things in the long run and fills JIRA with cruft.
I fully intend to start working on popular issues (hence the need for
votes) after my move in a few weeks. Doing some Lucene work will be a
welcome relief from packing boxes and lugging furniture.
-Grant
Chuck Williams (JIRA) wrote:
[ http://issues.apache.org/jira/browse/LUCENE-398?page=comments#action_12416837 ]
Chuck Williams commented on LUCENE-398:
---
Christian,
I'm going to open a new issue on this in order to rename it, post a revised
patch, and hopefully get the attention of a committer.
Chuck
ParallelReader crashes when trying to merge into a new index
Key: LUCENE-398
URL: http://issues.apache.org/jira/browse/LUCENE-398
Project: Lucene - Java
Type: Bug
Components: Index
Versions: unspecified
Environment: Operating System: All
Platform: All
Reporter: Sebastian Kirsch
Assignee: Lucene Developers
Attachments: ParallelReader.diff, ParallelReaderTest1.java,
parallelreader.diff, patch-next.diff
ParallelReader causes a NullPointerException in
org.apache.lucene.index.ParallelReader$ParallelTermPositions.seek(ParallelReader.java:318)
when trying to merge into a new index.
See test case and sample output:
$ svn diff
Index: src/test/org/apache/lucene/index/TestParallelReader.java
===
--- src/test/org/apache/lucene/index/TestParallelReader.java(revision
179785)
+++ src/test/org/apache/lucene/index/TestParallelReader.java(working copy)
@@ -57,6 +57,13 @@
}
+ public void testMerge() throws Exception {
+Directory dir = new RAMDirectory();
+IndexWriter w = new IndexWriter(dir, new StandardAnalyzer(), true);
+w.addIndexes(new IndexReader[] { ((IndexSearcher)
parallel).getIndexReader() });
+w.close();
+ }
+
private void queryTest(Query query) throws IOException {
Hits parallelHits = parallel.search(query);
Hits singleHits = single.search(query);
$ ant -Dtestcase=TestParallelReader test
Buildfile: build.xml
[...]
test:
[mkdir] Created dir:
/Users/skirsch/text/lectures/da/thirdparty/lucene-trunk/build/test
[junit] Testsuite: org.apache.lucene.index.TestParallelReader
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 1.993 sec
[junit] Testcase: testMerge(org.apache.lucene.index.TestParallelReader):
Caused an ERROR
[junit] null
[junit] java.lang.NullPointerException
[junit] at
org.apache.lucene.index.ParallelReader$ParallelTermPositions.seek(ParallelReader.java:318)
[junit] at
org.apache.lucene.index.ParallelReader$ParallelTermDocs.seek(ParallelReader.java:294)
[junit] at
org.apache.lucene.index.SegmentMerger.appendPostings(SegmentMerger.java:325)
[junit] at
org.apache.lucene.index.SegmentMerger.mergeTermInfo(SegmentMerger.java:296)
[junit] at
org.apache.lucene.index.SegmentMerger.mergeTermInfos(SegmentMerger.java:270)
[junit] at
org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:234)
[junit] at
org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:96)
[junit] at
org.apache.lucene.index.IndexWriter.addIndexes(IndexWriter.java:596)
[junit] at
org.apache.lucene.index.TestParallelReader.testMerge(TestParallelReader.java:63)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] Test org.apache.lucene.index.TestParallelReader FAILED
BUILD FAILED
/Users/skirsch/text/lectures/da/thirdparty/lucene-trunk/common-build.xml:188:
Tests failed!
Total time: 16 seconds
$
--
Grant Ingersoll
Sr. Software Engineer
Center for Natural Language Processing
Syracuse University
School of Information Studies
335 Hinds Hall
Syracuse, NY 13244
http://www.cnlp.org
Voice: 315-443-5484
Fax: 315-443-6886
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/20/06, Steven Rowe <[EMAIL PROTECTED]> wrote: Could not tools like Retrotranslator[2] or Retroweaver[3] be used to satisfy both camps? That's an interesting option Steven... Retrotranslator certainly looks like they handle almost everything! If we ended up taking that route, we have enough 1.4 users that I think it would be nice to have - a 1.4 compatible jar included in the distributions along with the 1.5 jar - an easy way to run all the unit tests against the 1.4 compatible jar -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I think retrotranslator only work on the syntax, but not on the 1.5 specific libraries (for obvious reasons). A real use case was written up by a Java 5 web mvc framework at http://stripes.mc4j.org/confluence/display/stripes/Java+1.4+and+Stripes Once again, so long we stay away from non-1.4 compatible language features of 1.5, we can always compile to 1.4 code anyways. I don't know exactly what everyone is saying that makes it convinient for them to develop in 1.5. But I believe majority of it are in basic syntax improvements of 1.5 which are (should) fully compatible to be compiled into 1.4 bytecode (although i could see a use of the concurrent package?) Looking at hibernate and spring, do we see them rushing into 1.5? They do have great support for users using both 1.4 and 1.5. Surely it's on a different scale, different user base, and different type of libraries. But the point is they have a good compromise between the 2, and there is no branching, but incremental versions that adds 1.5 extensions on top of what they already have. I think to avoid branching, it can come down to what 1.5 language features are we willing to accept in the core, and anything-goes in the contributions. We do realize that not every feature needs to be in the core, right? ray, On 6/20/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: On 6/20/06, Steven Rowe <[EMAIL PROTECTED]> wrote: > Could not tools like Retrotranslator[2] or Retroweaver[3] be used to > satisfy both camps? That's an interesting option Steven... Retrotranslator certainly looks like they handle almost everything! If we ended up taking that route, we have enough 1.4 users that I think it would be nice to have - a 1.4 compatible jar included in the distributions along with the 1.5 jar - an easy way to run all the unit tests against the 1.4 compatible jar -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I don't know much about those tools, but it wouldn't seem feasible to supply 1.5 compatible libraries (otherwise the stupid classpath project would have been abandoned long ago). I think the bug fixing that has gone into 1.5 libraries is just as important as the language changes. -Original Message- From: Yonik Seeley [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 2:31 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On 6/20/06, Steven Rowe <[EMAIL PROTECTED]> wrote: > Could not tools like Retrotranslator[2] or Retroweaver[3] be used to > satisfy both camps? That's an interesting option Steven... Retrotranslator certainly looks like they handle almost everything! If we ended up taking that route, we have enough 1.4 users that I think it would be nice to have - a 1.4 compatible jar included in the distributions along with the 1.5 jar - an easy way to run all the unit tests against the 1.4 compatible jar -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-608) deprecate Document.fields(), add getFields()
deprecate Document.fields(), add getFields() Key: LUCENE-608 URL: http://issues.apache.org/jira/browse/LUCENE-608 Project: Lucene - Java Type: Improvement Components: Other Versions: 2.0.0 Reporter: Daniel Naber Fix For: 2.1 Attachments: document.diff A simple API improvement that I'm going to commit if nobody objects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-608) deprecate Document.fields(), add getFields()
[ http://issues.apache.org/jira/browse/LUCENE-608?page=all ] Daniel Naber updated LUCENE-608: Attachment: document.diff > deprecate Document.fields(), add getFields() > > > Key: LUCENE-608 > URL: http://issues.apache.org/jira/browse/LUCENE-608 > Project: Lucene - Java > Type: Improvement > Components: Other > Versions: 2.0.0 > Reporter: Daniel Naber > Fix For: 2.1 > Attachments: document.diff > > A simple API improvement that I'm going to commit if nobody objects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/20/06, Ray Tsang <[EMAIL PROTECTED]> wrote: I think retrotranslator only work on the syntax, but not on the 1.5 specific libraries (for obvious reasons). I was going by the link provided: http://retrotranslator.sourceforge.net/ What Java 5.0 features are supported? * Generics (generic types) * Annotations (metadata) * Reflection on generics and annotations * Typesafe enums (enumerated types) * Autoboxing/unboxing * Enhanced for loop (for-each loop) * Varargs (variable arguments) * Covariant return types * Static import * Concurrency utilities * Collections framework enhancements It looks like there are some runtime components. In any case, there is still GCJ too. If GCJ supported 1.5, and we could make a 1.4 library with Retrotranslator, that should cover most users, right? Then there is the question of if it's worth the effort to support 1.4 via Retrotranslator over just coding Lucene stuff in 1.4 or backporting... -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-607) ParallelTermEnum is BROKEN
[ http://issues.apache.org/jira/browse/LUCENE-607?page=all ] Yonik Seeley resolved LUCENE-607: - Fix Version: 2.0.1 Resolution: Fixed Assign To: Yonik Seeley Looks fine to me, (committed.) Thanks for another high-quality patch Chuck! > ParallelTermEnum is BROKEN > -- > > Key: LUCENE-607 > URL: http://issues.apache.org/jira/browse/LUCENE-607 > Project: Lucene - Java > Type: Bug > Components: Index > Versions: 2.0.0 > Reporter: Chuck Williams > Assignee: Yonik Seeley > Priority: Critical > Fix For: 2.0.1 > Attachments: ParallelTermEnum.patch > > ParallelTermEnum.next() fails to advance properly to new fields. This is a > serious bug. > Christian Kohlschuetter diagnosed this as the root problem underlying > LUCENE-398 and posted a first patch there. > I've addressed a couple issues in the patch (close skipped field TermEnum's, > generate field iterator only once, integrated Christian's test case as a > Lucene test) and packaged in all the revised patch here. > All Lucene tests pass, and I've further tested in this in my app, which makes > extensive use of ParallelReader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-398) ParallelReader crashes when trying to merge into a new index
[ http://issues.apache.org/jira/browse/LUCENE-398?page=all ]
Yonik Seeley resolved LUCENE-398:
-
Fix Version: 2.0.1
Resolution: Fixed
Assign To: Yonik Seeley (was: Lucene Developers)
Thanks for tracking this down Christian!
I've committed Chuck's version of your patch in LUCENE-607
> ParallelReader crashes when trying to merge into a new index
>
>
> Key: LUCENE-398
> URL: http://issues.apache.org/jira/browse/LUCENE-398
> Project: Lucene - Java
> Type: Bug
> Components: Index
> Versions: unspecified
> Environment: Operating System: All
> Platform: All
> Reporter: Sebastian Kirsch
> Assignee: Yonik Seeley
> Fix For: 2.0.1
> Attachments: ParallelReader.diff, ParallelReaderTest1.java,
> parallelreader.diff, patch-next.diff
>
> ParallelReader causes a NullPointerException in
> org.apache.lucene.index.ParallelReader$ParallelTermPositions.seek(ParallelReader.java:318)
> when trying to merge into a new index.
> See test case and sample output:
> $ svn diff
> Index: src/test/org/apache/lucene/index/TestParallelReader.java
> ===
> --- src/test/org/apache/lucene/index/TestParallelReader.java(revision
> 179785)
> +++ src/test/org/apache/lucene/index/TestParallelReader.java(working copy)
> @@ -57,6 +57,13 @@
>
>}
>
> + public void testMerge() throws Exception {
> +Directory dir = new RAMDirectory();
> +IndexWriter w = new IndexWriter(dir, new StandardAnalyzer(), true);
> +w.addIndexes(new IndexReader[] { ((IndexSearcher)
> parallel).getIndexReader() });
> +w.close();
> + }
> +
>private void queryTest(Query query) throws IOException {
> Hits parallelHits = parallel.search(query);
> Hits singleHits = single.search(query);
> $ ant -Dtestcase=TestParallelReader test
> Buildfile: build.xml
> [...]
> test:
> [mkdir] Created dir:
> /Users/skirsch/text/lectures/da/thirdparty/lucene-trunk/build/test
> [junit] Testsuite: org.apache.lucene.index.TestParallelReader
> [junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 1.993 sec
> [junit] Testcase: testMerge(org.apache.lucene.index.TestParallelReader):
> Caused an ERROR
> [junit] null
> [junit] java.lang.NullPointerException
> [junit] at
> org.apache.lucene.index.ParallelReader$ParallelTermPositions.seek(ParallelReader.java:318)
> [junit] at
> org.apache.lucene.index.ParallelReader$ParallelTermDocs.seek(ParallelReader.java:294)
> [junit] at
> org.apache.lucene.index.SegmentMerger.appendPostings(SegmentMerger.java:325)
> [junit] at
> org.apache.lucene.index.SegmentMerger.mergeTermInfo(SegmentMerger.java:296)
> [junit] at
> org.apache.lucene.index.SegmentMerger.mergeTermInfos(SegmentMerger.java:270)
> [junit] at
> org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:234)
> [junit] at
> org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:96)
> [junit] at
> org.apache.lucene.index.IndexWriter.addIndexes(IndexWriter.java:596)
> [junit] at
> org.apache.lucene.index.TestParallelReader.testMerge(TestParallelReader.java:63)
> [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [junit] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [junit] Test org.apache.lucene.index.TestParallelReader FAILED
> BUILD FAILED
> /Users/skirsch/text/lectures/da/thirdparty/lucene-trunk/common-build.xml:188:
> Tests failed!
> Total time: 16 seconds
> $
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/20/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: In any case, there is still GCJ too. If GCJ supported 1.5, and we could make a 1.4 library with Retrotranslator, that should cover most users, right? I just took a look at GCJ again. If I am not mistaken: future support for 1.5 in gcj is ambiguous and/or will be incomplete. GCJ uses Classpath to provide open implementations of Java. It's stated goal is to be Java 1.2 compliant by the time it gets to a 1.0 release. It is largely 1.4 compliant. Significant for me, the swing classes don't support all the Look and Feels I support, e.g. no MacOS LaF. And while it says that there is some support for some Java 5 classes, I could not find an enumeration of them. I would speculate that incorporating the concurrency classes will be relatively easy since the cpj, on which Sun's implementation is based, is public domain. However, I would also speculate that all bets are off on the other classes as to when they will show up. GCJ will be using Eclipse's java compiler as its new compiler. When this happens it will have the support for the new language features. Interestingly this is dependent upon the GPLv3 which is stated as being a year away from being finalized (I don't know when the page was written, so it could be some time soon) and I don't know if it needs to be finalized before the compiler is released.
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I think the decision was made among developers without asking for much user input. I think that made a huge difference. Otis - Original Message From: Michael McCandless <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Cc: java-dev@lucene.apache.org Sent: Tuesday, June 20, 2006 2:30:36 PM Subject: RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) Could someone shed light on how the decision to transition from Java 1.3 to Java 1.4 unfolded? Any lessons learned or applicable here? Mike "Robert Engels" <[EMAIL PROTECTED]> 06/20/2006 02:24 PM Please respond to java-dev@lucene.apache.org To cc Subject RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) I think your statement "do not seem to fully appreciate the volunteer-contribution model" hits the nail on the head. There is a minority that wants everything for free, wants it work exactly as they want, and then have the audacity to tell the others they should do more even work to make them happy - all without contributing a single hour of work to the product (maybe via testing...). -Original Message- From: Chuck Williams [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 1:15 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) I think Otis put things perfectly and would like to second everything he's said. This is about facilitating more contributions from the majority vs. creating a version that the minority can use. To answer Otis's question, "How small does the percentage of 1.4 users need to be, before we can have 1.5 in Lucene?", I think there are some other factors that need to be considered. How many contributors to Lucene are generating contributions out of work they are doing for their companies or other vocations, submitting these to Lucene to achieve the benefits of community usage/maintenance/enhancement, and using 1.5 as their daily environment? My suspicion is that while the user ratio may be 2:1 1.5:1.4 that the contributor ratio is even more skewed in favor of 1.5. One of the reasons I suspect this is that the 1.4 users who have spoken up thus far do not seem to fully appreciate the volunteer-contribution model of the Lucene community (e.g., see the thread below). I think it is safe to assume that potential contributors will be less motivated if they are forced to back port their code. If Lucene makes the 1.5 decision, about 1/3 of the Lucene user base today will not be able to build off the head, although they will have a fully supported 2.0.x. The 1/3 portion will decline continually, but this is still a substantial problem. I'm sure the Lucene pmc/committers do not want to leave so many users behind. If Lucene makes the 1.4 decision, it will get fewer contributions. As one example, I will only submit bug fixes. I'm waiting to see how this turns out to decide whether or not to contribute some new features that are all coded in 1.5. The question is how many contributors are in a similar situation? If this number is say greater than 80%, rather than the 67% indicated in the usage poll, then making the 1.4 decision is also a substantial problem for Lucene's future. Chuck Otis Gospodnetic wrote on 06/20/2006 09:33 AM: > Sorry, for some reason my Yahoo email doesn't prepend ">" on replies, so I'll use "OG" for my lines. > > - Original Message > From: Dan Armbrust <[EMAIL PROTECTED]> Robert Engels > wrote: > > >> People making these arguments against 1.5 sound really ill-informed, >> or lazy. Neither of which is good for open-source development. >> >> > > Preface - I'm not a lucene developer - just an interested user. > > I don't know - it seems to me that it is the 1.5 crowd that is making > the lazy argument. You are in effect, saying, that the highly skilled > developers who would be making lucene contributions are unable or > unwilling to write 1.4 java code? Come on... it really not that hard. > Which set is being lazy? I'll stop the name calling now, and try to > make a better point. > > OG: I think you are missing or misinterpreting things here. Lucene contributors tend to be people who write nice extensions to Lucene, and want to give them back to Lucene. Typically those extensions come out of their day jobs, or at least that is my impression. When they use 1.5 there, their contribution will be 1.5. External contributors already spend extra time and effort to do this. Requiring them to modify their code not to use 1.5 would mean they will be less likely to contribute. I wouldn't bother, if I had to take extra time and effort to contribute, and even "go backwards" with my code, when what I really want is for my piece of code to become a part of Lucene, so I can just use that code instead of maintaining my own variation of it. > > OG: My main concern is losing those contributions. We already have a TON of good patches in JIRA that we didn't integrate, and lots of them are lost, because patch
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
- Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend ">" on replies, so I'll use "OG" for my lines. In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. OG: Again, there have been a LOT of JVM and JDK improvements since 1.4, too, but you are still using 1.4. OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. One can get the performance gains just by using the Java 5 jre. OG: Correct. But one can also not get a performance improvement or a bug fix if it comes as part of an external contribution that happens to use 1.5 because the contributor uses 1.5 in his/her work and doesn't have time to "downgrade" the code, just so it can be accepted in Lucene. How many external contributions are to the "core" Lucene? If the "core" Lucene contribution can be applied and then "downgraded" to Java 1.4 easily, what harm is in that? OG: I don't know the number, but JIRA would be the place to look. My guess is about a dozen or more people. Steve Rowe found something that can "downgrade" 1.5 code to 1.4 and looks promising. Otis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
- Original Message From: DM Smith <[EMAIL PROTECTED]> This poll does not indicate anything about Lucene. It is open to anyone who goes to quimble and searches on Java. OG: Oh, come on now! :) Are people really going through a site like Quimble looking for java polls? Come on! No, of course not. Maybe I'll start a fake poll just to test this out. Otis On 6/16/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: > > It looks like I would have won a beer had anyone wagered me. > > 1.5 IS the Java version that the majority Lucene users use, not 1.4! > > Does this mean we can now start accepting 1.5 code? > > Otis > > - Original Message > From: Otis Gospodnetic <[EMAIL PROTECTED]> > To: java-user@lucene.apache.org > Sent: Friday, June 16, 2006 11:48:15 AM > Subject: Survey: Lucene and Java 1.4 vs. 1.5 > > Hello everyone, > > If you have 15 seconds to spare, please let us (Lucene developers) know > which version of Java you are using with Lucene: 1.4 or 1.5 > > All it takes is 1 click on one of the two choices: > http://www.quimble.com/poll/view/2156 > > No cheating, please. Thanks! > Otis > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/20/06, DM Smith <[EMAIL PROTECTED]> wrote: > In any case, there is still GCJ too. If GCJ supported 1.5, and we > could make a 1.4 library with Retrotranslator, that should cover most > users, right? If I am not mistaken: future support for 1.5 in gcj is ambiguous and/or will be incomplete. You don't use GCJ right? GCJ is currently incomplete, and needs patches to get it to work with lucene (and lucene committers have accepted patches to ease this porting in the past). GCJ support in Lucene isn't as much for the end-user IMO, but for developers who maintain other Lucene ports. Time will tell how good the Java5 support is for GCJ. Hopefully less time rather than more ;-) -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
This looks like a very good find that might solve our problems and put an end to the discussion. It looks like this would require a change to the build process (Ant stuff) and nothing else. If anyone want to contribute a patch (Ray? Steve? Dan? DM Smith?), I'd love to test it out and commit it, if it solves everyone's problems. It it works on source and creates a 1.4-runnable Jar, great. If it works on a 1.5 Jar and creates a 1.4-runnable Jar, also great. Otis - Original Message From: Ray Tsang <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Tuesday, June 20, 2006 3:50:20 PM Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) I think retrotranslator only work on the syntax, but not on the 1.5 specific libraries (for obvious reasons). A real use case was written up by a Java 5 web mvc framework at http://stripes.mc4j.org/confluence/display/stripes/Java+1.4+and+Stripes Once again, so long we stay away from non-1.4 compatible language features of 1.5, we can always compile to 1.4 code anyways. I don't know exactly what everyone is saying that makes it convinient for them to develop in 1.5. But I believe majority of it are in basic syntax improvements of 1.5 which are (should) fully compatible to be compiled into 1.4 bytecode (although i could see a use of the concurrent package?) Looking at hibernate and spring, do we see them rushing into 1.5? They do have great support for users using both 1.4 and 1.5. Surely it's on a different scale, different user base, and different type of libraries. But the point is they have a good compromise between the 2, and there is no branching, but incremental versions that adds 1.5 extensions on top of what they already have. I think to avoid branching, it can come down to what 1.5 language features are we willing to accept in the core, and anything-goes in the contributions. We do realize that not every feature needs to be in the core, right? ray, On 6/20/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: > On 6/20/06, Steven Rowe <[EMAIL PROTECTED]> wrote: > > Could not tools like Retrotranslator[2] or Retroweaver[3] be used to > > satisfy both camps? > > That's an interesting option Steven... Retrotranslator certainly looks > like they handle almost everything! > > If we ended up taking that route, we have enough 1.4 users that I > think it would be nice to have > - a 1.4 compatible jar included in the distributions along with the 1.5 jar > - an easy way to run all the unit tests against the 1.4 compatible jar > > -Yonik > http://incubator.apache.org/solr Solr, the open-source Lucene search server > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-415) Merge error during add to index (IndexOutOfBoundsException)
[ http://issues.apache.org/jira/browse/LUCENE-415?page=comments#action_12416990 ] Yonik Seeley commented on LUCENE-415: - Thanks Andy! I've committed a patch to set the length to zero if it wasn't already. If this doesn't also fix the "some fairly odd but repeatable issues with stale/invalid file handles under windows XP. " issue, please open a new bug. This bug was imported from Bugzilla, doesn't have a status, and hence I can't resolve it. Anyone else with higher JIRA perms? > Merge error during add to index (IndexOutOfBoundsException) > --- > > Key: LUCENE-415 > URL: http://issues.apache.org/jira/browse/LUCENE-415 > Project: Lucene - Java > Type: Bug > Components: Index > Versions: 1.4 > Environment: Operating System: Linux > Platform: Other > Reporter: Daniel Quaroni > Assignee: Lucene Developers > > I've been batch-building indexes, and I've build a couple hundred indexes > with > a total of around 150 million records. This only happened once, so it's > probably impossible to reproduce, but anyway... I was building an index with > around 9.6 million records, and towards the end I got this: > java.lang.IndexOutOfBoundsException: Index: 54, Size: 24 > at java.util.ArrayList.RangeCheck(ArrayList.java:547) > at java.util.ArrayList.get(ArrayList.java:322) > at org.apache.lucene.index.FieldInfos.fieldInfo(FieldInfos.java:155) > at org.apache.lucene.index.FieldInfos.fieldName(FieldInfos.java:151) > at > org.apache.lucene.index.SegmentTermEnum.readTerm(SegmentTermEnum.java > :149) > at org.apache.lucene.index.SegmentTermEnum.next > (SegmentTermEnum.java:115) > at org.apache.lucene.index.SegmentMergeInfo.next > (SegmentMergeInfo.java:52) > at org.apache.lucene.index.SegmentMerger.mergeTermInfos > (SegmentMerger.java:294) > at org.apache.lucene.index.SegmentMerger.mergeTerms > (SegmentMerger.java:254) > at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:93) > at org.apache.lucene.index.IndexWriter.mergeSegments > (IndexWriter.java:487) > at org.apache.lucene.index.IndexWriter.maybeMergeSegments > (IndexWriter.java:458) > at > org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:310) > at > org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:294) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-569) NearSpans skipTo bug
[ http://issues.apache.org/jira/browse/LUCENE-569?page=all ] paul.elschot updated LUCENE-569: Attachment: NearSpansOrdered.java NearSpansUnordered.java These two attachments (NearSpansOrdered and NearSpansUnordered), together with the near spans patch at the issue indicated above, pass all tests here, including the patched spans explanation test. The attachments share the code that defines the ordering of spans. Some minor refactoring will probably be needed. > NearSpans skipTo bug > > > Key: LUCENE-569 > URL: http://issues.apache.org/jira/browse/LUCENE-569 > Project: Lucene - Java > Type: Bug > Components: Search > Reporter: Hoss Man > Attachments: NearSpansOrdered.java, NearSpansUnordered.java, > SpanScorer.explain.testcase.patch, TestNearSpans.java > > NearSpans appears to have a bug in skipTo that causes it to skip over some > matching documents completely. I discovered this bug while investigating > problems with SpanWeight.explain, but as far as I can tell the Bug is not > specific to Explanations ... it seems like it could potentially result in > incorrect matching in some situations where a SpanNearQuery is nested in > another query such thatskipTo will be used ... I tried to create a high level > test case to exploit the bug when searching, but i could not. TestCase > exploiting the class using NearSpan and SpanScorer will follow... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote: - Original Message From: DM Smith On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo email doesn't prepend ">" on replies, so I'll use "OG" for my lines. In my situation, I am constantly working on improving an open source application. Our use of Lucene is very trivial (from a lucene perspective) but critical to the application. If there are bug fixes, enhancements and performance improvements, I want to use them to improve my user's experience. So, each time there is a release of Lucene, I get it, test it and if it in itself offers an improvement, I release our application just upgrading the lucene jar. OG: Again, there have been a LOT of JVM and JDK improvements since 1.4, too, but you are still using 1.4. I am using the Java 5 compiler to build a 1.4 compatible binary. So I get the compiler improvements for all my users. OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is _substantially_ faster. If you want performance improvements, why not also upgrade Java then? Ths really bugs me. People want the latest and greatest Lucene, but are okay with the old Java, yet they claim they want performance, bug fixes, etc. It's not up to me. Each user of BibleDesktop has to decide for themselves. Users of MacOS 10.3 and earlier are stuck using Java 1.4. Users that have upgraded to Java 5 get the advantages of that runtime. As for me I am running Java 5. One can get the performance gains just by using the Java 5 jre. OG: Correct. But one can also not get a performance improvement or a bug fix if it comes as part of an external contribution that happens to use 1.5 because the contributor uses 1.5 in his/her work and doesn't have time to "downgrade" the code, just so it can be accepted in Lucene. That's the core argument that you are making and it is a good one. If it could be designated in Jira whether the attachment were Java 5 then others (perhaps myself) could take the patch, downgrade it and attach it to the same issue. It sure would beat forking the project. How many external contributions are to the "core" Lucene? If the "core" Lucene contribution can be applied and then "downgraded" to Java 1.4 easily, what harm is in that? OG: I don't know the number, but JIRA would be the place to look. My guess is about a dozen or more people. Steve Rowe found something that can "downgrade" 1.5 code to 1.4 and looks promising. If so then perhaps the committers could run the code through it after applying the patch. Then the contributers would not be adversely affected. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On Jun 20, 2006, at 5:21 PM, Yonik Seeley wrote: On 6/20/06, DM Smith <[EMAIL PROTECTED]> wrote: > In any case, there is still GCJ too. If GCJ supported 1.5, and we > could make a 1.4 library with Retrotranslator, that should cover most > users, right? If I am not mistaken: future support for 1.5 in gcj is ambiguous and/or will be incomplete. You don't use GCJ right? Correct. We couldn't because of our use of Swing. It appears that it is sufficiently far along that it is worth trying again. The problem we have is trying to explain to users how to install java in order to get our application to work. If we could redistribute java as a seamless part of our application we would. We are planning to migrate from Swing to Eclipse's RCP/JFace/SWT and then we can and would use GCJ. If Lucene goes to Java 5, we will need to re-examine those plans. GCJ is currently incomplete, and needs patches to get it to work with lucene (and lucene committers have accepted patches to ease this porting in the past). GCJ support in Lucene isn't as much for the end-user IMO, but for developers who maintain other Lucene ports. Time will tell how good the Java5 support is for GCJ. Hopefully less time rather than more ;-) -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
I don't follow... If a user came to you and said I want to run BibleDesktop, and they have MS-DOS, you would tell them you can't (or you might have to run the very old BibleDesktop 1.0). If they told you they have Windows 98 with Java 1.4 and 256mb or memory, you would say you can run BibleDesktop 2.0 (which includes Lucene 2.0). If they told you they have Windows XP with Java 1.5, you would say you can run BibleDesktop 3.0 (which includes Lucene 2.1). Certainly seems like a packaging/marketing issue for you. Your users would not know if they were running Lucene 1.4, 1.9 2.0 or 2.1, nor would they care. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:17 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:09 PM, Otis Gospodnetic wrote: > - Original Message > From: DM Smith > > > On 6/20/06, Otis Gospodnetic wrote: Sorry, for some reason my Yahoo > email doesn't prepend ">" on replies, so I'll use "OG" for my lines. > > In my situation, I am constantly working on improving an open source > application. Our use of Lucene is very trivial (from a lucene > perspective) but critical to the application. If there are bug fixes, > enhancements and performance improvements, I want to use them to > improve my user's experience. So, each time there is a release of > Lucene, I get it, test it and if it in itself offers an improvement, I > release our application just upgrading the lucene jar. > > OG: Again, there have been a LOT of JVM and JDK improvements since > 1.4, too, but you are still using 1.4. I am using the Java 5 compiler to build a 1.4 compatible binary. So I get the compiler improvements for all my users. > > > OG: But I benchmarked Java 1.4 and 1.5 a few weeks ago. 1.5 is > _substantially_ faster. If you want performance improvements, why > not also upgrade Java then? Ths really bugs me. People want the > latest and greatest Lucene, but are okay with the old Java, yet > they claim they want performance, bug fixes, etc. It's not up to me. Each user of BibleDesktop has to decide for themselves. Users of MacOS 10.3 and earlier are stuck using Java 1.4. Users that have upgraded to Java 5 get the advantages of that runtime. As for me I am running Java 5. > > One can get the performance gains just by using the Java 5 jre. > > OG: Correct. But one can also not get a performance improvement or > a bug fix if it comes as part of an external contribution that > happens to use 1.5 because the contributor uses 1.5 in his/her work > and doesn't have time to "downgrade" the code, just so it can be > accepted in Lucene. That's the core argument that you are making and it is a good one. If it could be designated in Jira whether the attachment were Java 5 then others (perhaps myself) could take the patch, downgrade it and attach it to the same issue. It sure would beat forking the project. > > How many external contributions are to the "core" Lucene? > If the "core" Lucene contribution can be applied and then > "downgraded" to Java 1.4 easily, what harm is in that? > > OG: I don't know the number, but JIRA would be the place to > look. My guess is about a dozen or more people. > Steve Rowe found something that can "downgrade" 1.5 code to 1.4 and > looks promising. If so then perhaps the committers could run the code through it after applying the patch. Then the contributers would not be adversely affected. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Installing Java requires about 2 mouse clicks from java.sun.com. Installing Java from your distribution CD (if you don't have one) requires no mouse clicks. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:24 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:21 PM, Yonik Seeley wrote: > On 6/20/06, DM Smith <[EMAIL PROTECTED]> wrote: >> > In any case, there is still GCJ too. If GCJ supported 1.5, and we >> > could make a 1.4 library with Retrotranslator, that should cover >> most >> > users, right? >> >> If I am not mistaken: future support for 1.5 in gcj is ambiguous >> and/or will be incomplete. > > You don't use GCJ right? Correct. We couldn't because of our use of Swing. It appears that it is sufficiently far along that it is worth trying again. The problem we have is trying to explain to users how to install java in order to get our application to work. If we could redistribute java as a seamless part of our application we would. We are planning to migrate from Swing to Eclipse's RCP/JFace/SWT and then we can and would use GCJ. If Lucene goes to Java 5, we will need to re-examine those plans. > > GCJ is currently incomplete, and needs patches to get it to work with > lucene (and lucene committers have accepted patches to ease this > porting in the past). GCJ support in Lucene isn't as much for the > end-user IMO, but for developers who maintain other Lucene ports. > > Time will tell how good the Java5 support is for GCJ. Hopefully less > time rather than more ;-) > > > -Yonik > http://incubator.apache.org/solr Solr, the open-source Lucene search > server > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On Tue, 20 Jun 2006, DM Smith wrote: We are planning to migrate from Swing to Eclipse's RCP/JFace/SWT and then we can and would use GCJ. If Lucene goes to Java 5, we will need to re-examine those plans. If you are planning to compile Java Lucene with gcj you may want to take a look at the tricks and patches used in the PyLucene project where this is done. - apply these patches: http://svn.osafoundation.org/pylucene/trunk/patches.lucene - use ant and javac to compile from .java to .jar - use gcj to compile from .jar to .o Which version of gcj to use depends on your constraints and your platform. I use gcj 4.0.2 (patched) on Intel Mac OS X, gcj 3.4.5 on PPC Mac OS X, gcj 3.4.6 on Ubuntu 6.06 Linux. I've been able to also use gcj 4.1.0 on PPC Mac OS X, but the same didn't work on Ubuntu 6.06. As for Java 1.5 support, the ecj integration seems to be going well. This very recent post should prove interesting: http://gcc.gnu.org/ml/java/2006-06/msg00146.html Still, there is no date promises attached here and a full gcj release cycle can be quite long. And then, usually, it takes a (long) while for a new gcj platform to be stable and usable on platforms other than Red Hat Linux. (See the version details I wrote about above). GCJ is currently incomplete, and needs patches to get it to work with lucene (and lucene committers have accepted patches to ease this porting in the past). GCJ support in Lucene isn't as much for the end-user IMO, but for developers who maintain other Lucene ports. libgcj, mostly based on the classpath project is indeed incomplete but is actively being working on and is complete enough to cover Java Lucene (of course your app may have needs beyond that). I've only had to patch in regex support in libgcj 3.4.x so far. Andi.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Finding good SWT support on anything but the latest (and major) OS's is going to be rather poor and inconsistent. Just check the SWT bugs (especially for things like printing). For a company that seems to want to allow their users to stay in the dark ages - good luck with SWT. -Original Message- From: DM Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 5:24 PM To: java-dev@lucene.apache.org Subject: Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5) On Jun 20, 2006, at 5:21 PM, Yonik Seeley wrote: > On 6/20/06, DM Smith <[EMAIL PROTECTED]> wrote: >> > In any case, there is still GCJ too. If GCJ supported 1.5, and we >> > could make a 1.4 library with Retrotranslator, that should cover >> most >> > users, right? >> >> If I am not mistaken: future support for 1.5 in gcj is ambiguous >> and/or will be incomplete. > > You don't use GCJ right? Correct. We couldn't because of our use of Swing. It appears that it is sufficiently far along that it is worth trying again. The problem we have is trying to explain to users how to install java in order to get our application to work. If we could redistribute java as a seamless part of our application we would. We are planning to migrate from Swing to Eclipse's RCP/JFace/SWT and then we can and would use GCJ. If Lucene goes to Java 5, we will need to re-examine those plans. > > GCJ is currently incomplete, and needs patches to get it to work with > lucene (and lucene committers have accepted patches to ease this > porting in the past). GCJ support in Lucene isn't as much for the > end-user IMO, but for developers who maintain other Lucene ports. > > Time will tell how good the Java5 support is for GCJ. Hopefully less > time rather than more ;-) > > > -Yonik > http://incubator.apache.org/solr Solr, the open-source Lucene search > server > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
On 6/20/06, DM Smith <[EMAIL PROTECTED]> wrote: The problem we have is trying to explain to users how to install java in order to get our application to work. Ahh... if you didn't already have a large code base, I'd suggest trying PyLucene in conjunction with freeze (which can make a python program into a standalone executable). Some kind of native-code thing does seem ideal for wide distribution to non-technical end users. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Core vs Contrib
I think that it might be good to define 3 levels: fundamental - what all programs probably will use useful - what many programs might use and contrib - mostly examples and code that is not quite ready to be classed as useful On Jun 16, 2006, at 6:03 PM, Chris Hostetter wrote: Are there any written (or unwritten) guidelines on when something should be commited to the core code base vs when a contrib module should be used? Obviously if a new feature rquires changing APIs omodifying one of the existing core classes, then that kind of needs to be in the core -- and there is precidence for the idea thatlangauge specific analyzers should go in contrib; and then of course there are things like the Span queries which seem like htey would have been a prime canidate for a contrib module but they aren't (possibly just because when they were added there was no "contrib" -- just the sandbox, and it didn't rev with lucene core). ...But I'm just wondering if as we move forward, there should be some sated policy "unless there is a specific reason why it must be in the core, put it in a contrib" to help keep the core small -- or if i'm wrong about hte general sentiment of the Lucene core. (FYI: my impedus for asking this question is LUCENE-406 -- I think it's a pretty handy feature that everyone might want, but that doesn't mean it's not just as usefull commited in contrib/miscellaneous) -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-451) BooleanQuery explain with boost==0
[ http://issues.apache.org/jira/browse/LUCENE-451?page=all ] Hoss Man updated LUCENE-451: Attachment: bq.containing.clause.with.zero.boost.tests.patch a revised version of hte previous tst patch ... this fixes a lot of the things that made the tests "invalid" before -- cheifly by: 1) using a Similarity that doesn't choke on boosts of 0.0 2) using a HitCollector to check matching (which is neccessary when matching docs have scores of 0) ..also in this patch is a tweak to the way the expected results are tested -- first by looking at the set of matching documents *then* look at the explanations for those documents (which makes it obvious when your assumptions about what matches are wrong before you look at why the explanation doesn't equal what it should) > BooleanQuery explain with boost==0 > -- > > Key: LUCENE-451 > URL: http://issues.apache.org/jira/browse/LUCENE-451 > Project: Lucene - Java > Type: Bug > Components: Search > Versions: CVS Nightly - Specify date in submission > Reporter: Yonik Seeley > Assignee: Hoss Man > Priority: Minor > Attachments: bq.containing.clause.with.zero.boost.tests.patch, > bq.containing.clause.with.zero.boost.tests.patch > > BooleanWeight.explain() uses the returned score of subweights to determine if > a clause matched. > If any required clause has boost==0, the returned score will be zero and the > explain for the entire BooleanWeight will be simply Explanation(0.0f, "match > required"). > I'm not sure what the correct fix is here. I don't think it can be done > based on score alone, since that isn't how scorers work. Perhaps we need a > new method "boolean Explain.matched()" that returns true on a match, > regardless of what the score may be? > Related to the problem above, even if no boosts are zero, it it sometimes > nice to know *why* a particular query failed to match. It would mean a > longer explanation, but maybe we should include non matching explains too? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-605) Make Explanation include information about match/non-match
[ http://issues.apache.org/jira/browse/LUCENE-605?page=all ] Hoss Man updated LUCENE-605: Attachment: demo-subclassing-explanation-approach.patch patch showing the first steps towards the subclassing approach. I definitely think this is a much better way to go. Which this new subclass, and some very simple changes to BooleanQuery/TermQuery, several of the bugs in the LUCENE-451 test patch are fixed ... the rest should be a simple matter of making the corrisponding small changes to the various other query types. > Make Explanation include information about match/non-match > -- > > Key: LUCENE-605 > URL: http://issues.apache.org/jira/browse/LUCENE-605 > Project: Lucene - Java > Type: Improvement > Components: Search > Reporter: Hoss Man > Assignee: Hoss Man > Attachments: demo-fix.patch, demo-subclassing-explanation-approach.patch > > As discussed, I'm looking into the possibility of improving the Explanation > class to include some basic info about the "match" status of the Explanation > -- independent of the value... > http://www.nabble.com/BooleanWeight.normalize%28float%29-doesn%27t-normalize-prohibited-clauses--t1596471.html#a4347644 > This is neccesary to deal with things like LUCENE-451 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
