[jira] Commented: (LUCENE-804) build.xml: result of "dist-src" should support "build-contrib"
[ https://issues.apache.org/jira/browse/LUCENE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473316 ] Doron Cohen commented on LUCENE-804: This can be easily fixed like this: Index: build.xml === --- build.xml (revision 507610) +++ build.xml (working copy) @@ -37,7 +37,7 @@ build.xml: result of "dist-src" should support "build-contrib" > -- > > Key: LUCENE-804 > URL: https://issues.apache.org/jira/browse/LUCENE-804 > Project: Lucene - Java > Issue Type: Task > Components: Other >Affects Versions: 2.1 >Reporter: Doron Cohen >Priority: Minor > Fix For: 2.1 > > > Currently the packed src distribution would fail to run "ant build-contrib". > It would be much nicer if that work. > In fact, would be nicer if you could even "re-pack" with it. > For now I marked this for 2.1, although I am not yet sure if this is a > stopper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Lucene 2.1
: Please vote to officially release these packages as Lucene 2.1. +0 the inability to build several contribs in the source release because the jars they depend on are excluded (and there's no docs on what they are for people to download them manually) seems pretty bad ... but i don't know that i like the idea of increasing the source dist size that much to include them. i don't have any particular suggestion on how to proceed ... after spending so much time scrutinizing and tweaking the initial Solr release, the Lucene Java release artifacts/mechanisms seem fairly flawed -- but the that doesn't mean we'd be better off *not* having a release just to spend a bunch of time retooling the packaging. -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Lucene 2.1
> > : Please vote to officially release these packages as Lucene 2.1. > > +0 > > the inability to build several contribs in the source release because the > jars they depend on are excluded (and there's no docs on what they are for > people to download them manually) seems pretty bad ... I think this is solved easily with http://issues.apache.org/jira/browse/LUCENE-804 > but i don't know > that i like the idea of increasing the source dist size that much to > include them. Actually the current src dist that included gdata/ext-libs instead of gdata/lib, and was 8.9 MB. After fixing this it drops to 6.8 MB. > > i don't have any particular suggestion on how to proceed ... after > spending so much time scrutinizing and tweaking the initial Solr release, > the Lucene Java release artifacts/mechanisms seem fairly flawed -- but the > that doesn't mean we'd be better off *not* having a release just to spend > a bunch of time retooling the packaging. > > > > > -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Lucene 2.1
On Feb 15, 2007, at 2:55 AM, Chris Hostetter wrote: : > I'm not exactly sure if this is show stopper, but when I get the : > binary, the build.xml that is included is not usable b/c it is : > missing common-build.xml. : Oops... I think we should fix this for the release if at all : possible. It is handy for folks to be able to pull down a buildable : archive and rest assured that they are getting something built at the : same time the binary was made. I'm confused ... the binary builds don't even include src/java/ so it's not a buildable archive by any strech of hte imagination -- how would having the common-build.xml help assure people of anything? i'm not even sure why we inlcude the build.xml in the binary releases. Yeah, I'm not sure we need the build included for binary releases either, I just think it should work if it is included. What's weird, is I don't think much has changed build wise from the last release, yet we all of a sudden noticed all these things. -Grant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Lucene 2.1
I've been reading this thread and here is my take as I will be updating jpackage for a 2.1 release. The content of a binary distribution differs widely as to what is included in it. It obviously needs to have one or more jar files that represent the product. Beyond that I have never really cared. Some include the source; others the javadoc; others readme, licenses, changes and the like; etc. I don't think that one should ever expect to build from a binary package. Even if one could. What is necessary for JPackage (or any other build system) is the pristine SOURCE package from which the jars, javadoc, readmes, licenses and the like can be generated or obtained. For JPackage, I have needed to patch the source so that it can build (e.g. JPackage 1.6 and 1.7 are Java 1.4.2 distributions and the Java 5 specific stuff needs to be excuded or modified). So for me, the question of a release is whether I can package the source package for JPackage and whether I can use the binary package as is when I don't grab it from JPackage. From this thread, I gather Lucene 2.1 is ready enough for me. On Feb 14, 2007, at 12:20 PM, Yonik Seeley wrote: Release artifacts for review are at http://people.apache.org/~yonik/staging_area/lucene/ Please vote to officially release these packages as Lucene 2.1. -Yonik - 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: [VOTE] release Lucene 2.1
On Feb 15, 2007, at 6:50 AM, Grant Ingersoll wrote: On Feb 15, 2007, at 2:55 AM, Chris Hostetter wrote: : > I'm not exactly sure if this is show stopper, but when I get the : > binary, the build.xml that is included is not usable b/c it is : > missing common-build.xml. : Oops... I think we should fix this for the release if at all : possible. It is handy for folks to be able to pull down a buildable : archive and rest assured that they are getting something built at the : same time the binary was made. I'm confused ... the binary builds don't even include src/java/ so it's not a buildable archive by any strech of hte imagination -- how would having the common-build.xml help assure people of anything? i'm not even sure why we inlcude the build.xml in the binary releases. Yeah, I'm not sure we need the build included for binary releases either, I just think it should work if it is included. What's weird, is I don't think much has changed build wise from the last release, yet we all of a sudden noticed all these things. Sorry, I was thinking by "binary" you meant the -src.(zip|tar.gz) "binary" and that is where the build was failing. The -src distributions should be buildable, the purely binary releases should, of course, be only the .jar files and LICENSE files and such, but no source (except perhaps the demo code?). I should shut up and go try the darn build and see what happens since I had my hands in there once up on a time. Ok off to see what's up first hand Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Lucene 2.1
On Feb 15, 2007, at 8:10 AM, DM Smith wrote: I don't think that one should ever expect to build from a binary package. Even if one could. Here's the hitch... the demo code that comes with Lucene, as sad as it is :(, gets shipped as source code in the binary distribution. This makes sense. What I've just seen is that we distribute build.xml but not common-build.xml and thus the build doesn't work, but even copying common-build.xml to that directory the build still fails as its trying to build Lucene itself without source code. We need a custom build.xml for the demo code, I think. I can whip something like that up, but it'll take me a week or so to squeeze it in. I don't think we should hold up a release for this issue - I suspect we shipped Lucene 2.0 like this as well. On the positive side, the source distribution works fine (from trunk): ~/dev/lucene/dist/src/lucene-2.2-dev erik$ ant Buildfile: build.xml javacc-uptodate-check: javacc-notice: init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: common.compile-core: [mkdir] Created dir: /Users/erik/dev/lucene/dist/src/lucene-2.2- dev/build/classes/java [javac] Compiling 204 source files to /Users/erik/dev/lucene/ dist/src/lucene-2.2-dev/build/classes/java [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. compile-core: [rmic] RMI Compiling 1 class to /Users/erik/dev/lucene/dist/src/ lucene-2.2-dev/build/classes/java jar-core: [jar] Building jar: /Users/erik/dev/lucene/dist/src/lucene-2.2- dev/build/lucene-core-2.2-dev.jar default: BUILD SUCCESSFUL Total time: 5 seconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-805) New Lucene Demo
New Lucene Demo --- Key: LUCENE-805 URL: https://issues.apache.org/jira/browse/LUCENE-805 Project: Lucene - Java Issue Type: Improvement Components: Examples Reporter: Grant Ingersoll Assigned To: Grant Ingersoll Priority: Minor The much maligned demo, while useful, could use a breath of fresh air. This issue is to start collecting requirements about what people would like to see in a demo and what they don't like in the current one. Ideas (not necessarily in order of importance): 1. More in-depth tutorial explaining indexing/searching 2. Multilingual support/demonstration 3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, Filters, sorting, etc. 4. Dealing with different content types and pointers to resources 5. Wiki use cases links -- I think it would be cool to solicit people to contribute use cases to the docs. 6. Demonstration of contrib packages, esp. Highlighter 7. Performance issues/factors/tradeoffs. Lucene lessons learned and best practices Advanced tutorials: 1. Hadoop + Lucene 2. Writing custom analyzers/filters/tokenizers 3. Changing Scoring 4. Payloads (when they are committed) Please contribute what else you would like to see. I may be able to address some of these issues for my ApacheCon talk, but not all of them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Lucene 2.1
On 2/15/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote: What's weird, is I don't think much has changed build wise from the last release, yet we all of a sudden noticed all these things. Yes, I just verified that things are pretty much in the same shape in the 2.0.0 release. contrib/(ant, lucli, regex) fail to build from the src dist. -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Lucene 2.1
I vote for release of 2.1 as-is... no one really uses that demo stuff anyway. I'll tackle the binary custom demo build.xml file as soon as I can and commit that. When folks complain, we can point them to the new build.xml file and they'll just plop that into a 2.1 binary release and it'll work. Erik On Feb 15, 2007, at 11:21 AM, Yonik Seeley wrote: On 2/15/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote: What's weird, is I don't think much has changed build wise from the last release, yet we all of a sudden noticed all these things. Yes, I just verified that things are pretty much in the same shape in the 2.0.0 release. contrib/(ant, lucli, regex) fail to build from the src dist. -Yonik - 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-805) New Lucene Demo
[ https://issues.apache.org/jira/browse/LUCENE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473419 ] Erik Hatcher commented on LUCENE-805: - The examples from Lucene in Action are freely available and Otis and I are fine with assigning the ASL to them (its currently unspecified but implicitly ASLd). If these would be useful, at least the Indexer.java and Searcher.java which are better demos than current demo application, we're free to use that as a starter. All the code could be contributed if folks are ok with that. In fact, maybe Otis and I should do the 2nd edition codebase within the Lucene svn somewhere so that it serves as a built-in example. > New Lucene Demo > --- > > Key: LUCENE-805 > URL: https://issues.apache.org/jira/browse/LUCENE-805 > Project: Lucene - Java > Issue Type: Improvement > Components: Examples >Reporter: Grant Ingersoll > Assigned To: Grant Ingersoll >Priority: Minor > > The much maligned demo, while useful, could use a breath of fresh air. This > issue is to start collecting requirements about what people would like to see > in a demo and what they don't like in the current one. > Ideas (not necessarily in order of importance): > 1. More in-depth tutorial explaining indexing/searching > 2. Multilingual support/demonstration > 3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, > Filters, sorting, etc. > 4. Dealing with different content types and pointers to resources > 5. Wiki use cases links -- I think it would be cool to solicit people to > contribute use cases to the docs. > 6. Demonstration of contrib packages, esp. Highlighter > 7. Performance issues/factors/tradeoffs. Lucene lessons learned and best > practices > Advanced tutorials: > 1. Hadoop + Lucene > 2. Writing custom analyzers/filters/tokenizers > 3. Changing Scoring > 4. Payloads (when they are committed) > Please contribute what else you would like to see. I may be able to address > some of these issues for my ApacheCon talk, but not all of them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Lucene 2.1
Recap: - some contrib modules can't be built without the user downloading more jars themselves - the "demo" in the binary package currently needs to be built by the user, and needs a special build.xml that doesn't rely on lucene source code (oops). I just verified that this was also broken in the 2.0.0 release. My opinion: - things aren't worse than in past releases - people can always use the binary release to get pre-built jars - people can always get the source for any version out of our subversion repository - most people's use of the source jar is not to build Lucene, but to study the source and/or point their IDE at it. - not all contrib modules are equal... some like highlighting and stemmers are often used, while others like gdata shouldn't even be rev'd at the same time as lucene. So, given that these aren't code quality issues, I think the biggest benefit to users would be to get this out the door as is, and work on the output of "ant dist src-dist" going forward to tighten things up. -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-804) build.xml: result of "dist-src" should support "build-contrib"
[ https://issues.apache.org/jira/browse/LUCENE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-804: --- Attachment: 804.build.xml.patch 804.build.xml.patch removes loadable jars from the src_dist and adds back in jars that are (currently) not downloadable. This allows src_dist to compile contribs (or even to "re-dist"). src-dist size effect of this - reduced from 8.9 MB to 6.8 MB. > build.xml: result of "dist-src" should support "build-contrib" > -- > > Key: LUCENE-804 > URL: https://issues.apache.org/jira/browse/LUCENE-804 > Project: Lucene - Java > Issue Type: Task > Components: Other >Affects Versions: 2.1 >Reporter: Doron Cohen >Priority: Minor > Fix For: 2.1 > > Attachments: 804.build.xml.patch > > > Currently the packed src distribution would fail to run "ant build-contrib". > It would be much nicer if that work. > In fact, would be nicer if you could even "re-pack" with it. > For now I marked this for 2.1, although I am not yet sure if this is a > stopper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-804) build.xml: result of "dist-src" should support "build-contrib"
[ https://issues.apache.org/jira/browse/LUCENE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-804: --- Lucene Fields: [New, Patch Available] (was: [New]) > build.xml: result of "dist-src" should support "build-contrib" > -- > > Key: LUCENE-804 > URL: https://issues.apache.org/jira/browse/LUCENE-804 > Project: Lucene - Java > Issue Type: Task > Components: Other >Affects Versions: 2.1 >Reporter: Doron Cohen >Priority: Minor > Fix For: 2.1 > > Attachments: 804.build.xml.patch > > > Currently the packed src distribution would fail to run "ant build-contrib". > It would be much nicer if that work. > In fact, would be nicer if you could even "re-pack" with it. > For now I marked this for 2.1, although I am not yet sure if this is a > stopper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Lucene 2.1
+1. Out the door is good, esp. since there haven't been complaints about it in the past. Thanks for doing this Yonik! On Feb 15, 2007, at 11:42 AM, Yonik Seeley wrote: Recap: - some contrib modules can't be built without the user downloading more jars themselves - the "demo" in the binary package currently needs to be built by the user, and needs a special build.xml that doesn't rely on lucene source code (oops). I just verified that this was also broken in the 2.0.0 release. My opinion: - things aren't worse than in past releases - people can always use the binary release to get pre-built jars - people can always get the source for any version out of our subversion repository - most people's use of the source jar is not to build Lucene, but to study the source and/or point their IDE at it. - not all contrib modules are equal... some like highlighting and stemmers are often used, while others like gdata shouldn't even be rev'd at the same time as lucene. So, given that these aren't code quality issues, I think the biggest benefit to users would be to get this out the door as is, and work on the output of "ant dist src-dist" going forward to tighten things up. -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Grant Ingersoll Center for Natural Language Processing http://www.cnlp.org Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/ LuceneFAQ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-805) New Lucene Demo
[ https://issues.apache.org/jira/browse/LUCENE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473429 ] Grant Ingersoll commented on LUCENE-805: I'm all for that the examples from LIA, but I also think the key part is the documentation that goes with it. I don't think it should be a requirement to buy LIA (even though I think everyone should :-) ) in order to understand the demo. So, we would have to figure out some way to get it documented w/o infringing on LIA, which may prove difficult. -Grant -- Grant Ingersoll Center for Natural Language Processing http://www.cnlp.org Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/ LuceneFAQ > New Lucene Demo > --- > > Key: LUCENE-805 > URL: https://issues.apache.org/jira/browse/LUCENE-805 > Project: Lucene - Java > Issue Type: Improvement > Components: Examples >Reporter: Grant Ingersoll > Assigned To: Grant Ingersoll >Priority: Minor > > The much maligned demo, while useful, could use a breath of fresh air. This > issue is to start collecting requirements about what people would like to see > in a demo and what they don't like in the current one. > Ideas (not necessarily in order of importance): > 1. More in-depth tutorial explaining indexing/searching > 2. Multilingual support/demonstration > 3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, > Filters, sorting, etc. > 4. Dealing with different content types and pointers to resources > 5. Wiki use cases links -- I think it would be cool to solicit people to > contribute use cases to the docs. > 6. Demonstration of contrib packages, esp. Highlighter > 7. Performance issues/factors/tradeoffs. Lucene lessons learned and best > practices > Advanced tutorials: > 1. Hadoop + Lucene > 2. Writing custom analyzers/filters/tokenizers > 3. Changing Scoring > 4. Payloads (when they are committed) > Please contribute what else you would like to see. I may be able to address > some of these issues for my ApacheCon talk, but not all of them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Lucene 2.1
15 feb 2007 kl. 17.42 skrev Yonik Seeley: Recap: - some contrib modules can't be built without the user downloading more jars themselves I would not mind introducing Maven builds in Lucene. It would solve / at least/ this problem. And it would merge so great with my other projects. :) I'd be happy to help out , but there are some wicked anting going on in a lot of build.xml:s so I would probably need a lot of help from the contributors understanding whats going on. Most of the build scripts could be halfway housed using maven-antrun- plugin. -- karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
request for comments, 626
https://issues.apache.org/jira/browse/LUCENE-626 Did anyone try out or took a look at my redesign of the spell checker? I'd love some feedback. -- karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Welcome Doron Cohen!
I'm pleased to announce that the Lucene PMC has voted to make Doron Cohen a Lucene committer. Congrats, and welcome aboard, Doron! -Yonik ps: Doron - you can test out your new privileges by updating the who-we-are page, and regenerating + updating the site. And it would be nice to introduce yourself of course :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-805) New Lucene Demo
[ https://issues.apache.org/jira/browse/LUCENE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473480 ] Erik Hatcher commented on LUCENE-805: - That was my concern as well, Grant. At least the LIA code is fairly well self documenting (we used JUnit for a reason :) and the build file itself is a nice example of how to launch applications and examples from a common starting point. What other documentation would be needed to make this a palatable? > New Lucene Demo > --- > > Key: LUCENE-805 > URL: https://issues.apache.org/jira/browse/LUCENE-805 > Project: Lucene - Java > Issue Type: Improvement > Components: Examples >Reporter: Grant Ingersoll > Assigned To: Grant Ingersoll >Priority: Minor > > The much maligned demo, while useful, could use a breath of fresh air. This > issue is to start collecting requirements about what people would like to see > in a demo and what they don't like in the current one. > Ideas (not necessarily in order of importance): > 1. More in-depth tutorial explaining indexing/searching > 2. Multilingual support/demonstration > 3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, > Filters, sorting, etc. > 4. Dealing with different content types and pointers to resources > 5. Wiki use cases links -- I think it would be cool to solicit people to > contribute use cases to the docs. > 6. Demonstration of contrib packages, esp. Highlighter > 7. Performance issues/factors/tradeoffs. Lucene lessons learned and best > practices > Advanced tutorials: > 1. Hadoop + Lucene > 2. Writing custom analyzers/filters/tokenizers > 3. Changing Scoring > 4. Payloads (when they are committed) > Please contribute what else you would like to see. I may be able to address > some of these issues for my ApacheCon talk, but not all of them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Lucene 2.1
On Feb 15, 2007, at 12:10 PM, karl wettin wrote: I would not mind introducing Maven builds in Lucene. It would solve /at least/ this problem. And it would merge so great with my other projects. :) I'd be happy to help out , but there are some wicked anting going on in a lot of build.xml:s so I would probably need a lot of help from the contributors understanding whats going on. Most of the build scripts could be halfway housed using maven- antrun-plugin. I'm open to Maven builds, for the record. I'll do what I can to help with understanding any of the wicked anting in there, but I don't know Maven so the best I'll be able to do is explain what is going on. The main complexity we have is the contrib area, oh and JavaCC... the rest is straightforward stuff. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-805) New Lucene Demo
I think that code is great and is often self-documenting, but it only represents the result of someone writing the code, it doesn't explain the why part of it. So, it would need English (and translations???) to explain why a particular approach was taken, along with possible alternatives. On Feb 15, 2007, at 2:25 PM, Erik Hatcher (JIRA) wrote: [ https://issues.apache.org/jira/browse/LUCENE-805? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12473480 ] Erik Hatcher commented on LUCENE-805: - That was my concern as well, Grant. At least the LIA code is fairly well self documenting (we used JUnit for a reason :) and the build file itself is a nice example of how to launch applications and examples from a common starting point. What other documentation would be needed to make this a palatable? New Lucene Demo --- Key: LUCENE-805 URL: https://issues.apache.org/jira/browse/LUCENE-805 Project: Lucene - Java Issue Type: Improvement Components: Examples Reporter: Grant Ingersoll Assigned To: Grant Ingersoll Priority: Minor The much maligned demo, while useful, could use a breath of fresh air. This issue is to start collecting requirements about what people would like to see in a demo and what they don't like in the current one. Ideas (not necessarily in order of importance): 1. More in-depth tutorial explaining indexing/searching 2. Multilingual support/demonstration 3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, Filters, sorting, etc. 4. Dealing with different content types and pointers to resources 5. Wiki use cases links -- I think it would be cool to solicit people to contribute use cases to the docs. 6. Demonstration of contrib packages, esp. Highlighter 7. Performance issues/factors/tradeoffs. Lucene lessons learned and best practices Advanced tutorials: 1. Hadoop + Lucene 2. Writing custom analyzers/filters/tokenizers 3. Changing Scoring 4. Payloads (when they are committed) Please contribute what else you would like to see. I may be able to address some of these issues for my ApacheCon talk, but not all of them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Grant Ingersoll http://www.grantingersoll.com/ http://www.paperoftheweek.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven builds (was: [VOTE] release Lucene 2.1)
15 feb 2007 kl. 20.27 skrev Erik Hatcher: On Feb 15, 2007, at 12:10 PM, karl wettin wrote: I would not mind introducing Maven builds in Lucene. It would solve /at least/ this problem. And it would merge so great with my other projects. :) I'd be happy to help out , but there are some wicked anting going on in a lot of build.xml:s so I would probably need a lot of help from the contributors understanding whats going on. Most of the build scripts could be halfway housed using maven- antrun-plugin. I'm open to Maven builds, for the record. I'll do what I can to help with understanding any of the wicked anting in there, but I don't know Maven so the best I'll be able to do is explain what is going on. The main complexity we have is the contrib area, oh and JavaCC... the rest is straightforward stuff. I'll see what I can do this weekend. +++ ATH - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request for comments, 626
I looked at it briefly and said to myself: "Wow, cool! I'll have to check that out some day." :-) Just a friendly reminder that lack of comments != lack of interest. Perhaps a little more description of how things work, esp the adaptive part, might elicit some feedback (and if it's in the mailing list already, put a pointer to it in the JIRA bug) -Yonik On 2/15/07, karl wettin <[EMAIL PROTECTED]> wrote: https://issues.apache.org/jira/browse/LUCENE-626 Did anyone try out or took a look at my redesign of the spell checker? I'd love some feedback. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven builds
There are cultural issues as well as technical issues to adopting Maven. Most folks involved with Lucene are familiar with using Ant and maintaining an Ant-based build system. So merely converting Lucene to be built by Maven will not cause everyone who currently works on Lucene to become willing and able to to use Maven on a daily basis. Long-term, we probably should not attempt to maintain two official build systems. But, short-term, it would be useful for developers to be able to evaluate Maven, then discussion can begin about whether the project should switch to Maven as its primary build system. Doug karl wettin wrote: 15 feb 2007 kl. 20.27 skrev Erik Hatcher: On Feb 15, 2007, at 12:10 PM, karl wettin wrote: I would not mind introducing Maven builds in Lucene. It would solve /at least/ this problem. And it would merge so great with my other projects. :) I'd be happy to help out , but there are some wicked anting going on in a lot of build.xml:s so I would probably need a lot of help from the contributors understanding whats going on. Most of the build scripts could be halfway housed using maven-antrun-plugin. I'm open to Maven builds, for the record. I'll do what I can to help with understanding any of the wicked anting in there, but I don't know Maven so the best I'll be able to do is explain what is going on. The main complexity we have is the contrib area, oh and JavaCC... the rest is straightforward stuff. I'll see what I can do this weekend. +++ ATH - 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: Maven builds
My first impression of ant: Ok, the syntax is a little funky, and I can't re-use my knowledge of command line options to tools w/o doing an exec... I need to learn the "ant" parameters for all the different tasks now. I can look at a build.xml and tweak/fix it because there isn't too much "magic" involved... it's fairly straight forward do-this then do-that, specified in portable XML. My first impression of maven: Pretty websites as part of the build system - cool! And it's *great* for starting a new project... unit tests automatically run, website is built, automatic packaging, jar/war build, everything you need! But, it all seems like magic to me... if I want to do something different, even a minor little change, I don't know where to start. If I want to add an additional compile flag, where does that go??? I have no idea. To change the behavior (like using Java5 source) I need to google and find the magic incantation. Maybe the benefits of maven pay off over the long run, but as one casual/newbie user, it just seemed like too much of a black box that I can't quickly hack to get it to do what I want. -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Welcome Doron Cohen!
Yonik Seeley wrote: I'm pleased to announce that the Lucene PMC has voted to make Doron Cohen a Lucene committer. Congrats, and welcome aboard, Doron! -Yonik Awesome news, Doron! Welcome aboard. Congratulations, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven builds
15 feb 2007 kl. 21.24 skrev Yonik Seeley: But, it all seems like magic to me... if I want to do something different, even a minor little change, I don't know where to start. If I want to add an additional compile flag, where does that go??? I have no idea. To change the behavior (like using Java5 source) I need to google and find the magic incantation. I felt the same way until I registred the POM schema in my editor. As always there was a threadshold to pass before getting used to it. Now my general opinion is that maven(2) is a very mature and highly configurable but still easy to use build system that takes care of everything for me. I'm especially fond of the surefire test plugin, the in depth dependency handling and how it creates the project in my development environment. -- karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: add svn ignores for eclipse artifacts
On 2/14/07, Grant Ingersoll (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/LUCENE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473274 This probably goes for IntelliJ too *.iml *.iws *.ipr > add svn ignores for eclipse artifacts Whenever I set up an IntelliJ project, I change the default location of these files to be one directory up. So I have f:/code/solr/CHANGES.txt, etc... the solr trunk f:/code/solr.iml f:/code/solr.ipr f:/code/solr.iws So if something gets weird with the source tree (svn problems, etc), I can just remove f:/code/solr and check it out again w/o having to worry about destroying my project files. -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven builds
I think a POM for Lucene core and demo is pretty trivial, since there are no dependencies, although I haven't tried Maven 2 yet. Contrib modules w/ dependencies is a little bit harder and getting them all to work together is a bit more on top of that. We made the switch to Maven 1 at CNLP over two years ago and I can't say I've ever wanted to go back to writing ANT build files. We have completely automated our build/release mechanism (which includes compilation, jar, SVN tagging, Unit testing, etc., email announcements, updating bugzilla versions, site publication, etc.) and I think it is safe to say the whole process would be a lot harder to do in ANT (not that it couldn't be done). Just like Solr removes much of the messiness of setting up Lucene and puts it into config files, so does Maven when it comes to project mgmt. For the most part, the magic is pretty well documented and straightforward to find (but not always) So, I'm +1 for seeing experimenting, as Doug suggested. On Feb 15, 2007, at 4:20 PM, karl wettin wrote: 15 feb 2007 kl. 21.24 skrev Yonik Seeley: But, it all seems like magic to me... if I want to do something different, even a minor little change, I don't know where to start. If I want to add an additional compile flag, where does that go??? I have no idea. To change the behavior (like using Java5 source) I need to google and find the magic incantation. I felt the same way until I registred the POM schema in my editor. As always there was a threadshold to pass before getting used to it. Now my general opinion is that maven(2) is a very mature and highly configurable but still easy to use build system that takes care of everything for me. I'm especially fond of the surefire test plugin, the in depth dependency handling and how it creates the project in my development environment. -- karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Grant Ingersoll Center for Natural Language Processing http://www.cnlp.org Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/ LuceneFAQ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Welcome Doron Cohen!
Congrats, Doron! Glad to have you on board! Your benchmark contribution is really useful as are the many contributions to discussions, etc. Look forward to working with you in the future! -Grant On Feb 15, 2007, at 1:49 PM, Yonik Seeley wrote: I'm pleased to announce that the Lucene PMC has voted to make Doron Cohen a Lucene committer. Congrats, and welcome aboard, Doron! -Yonik ps: Doron - you can test out your new privileges by updating the who-we-are page, and regenerating + updating the site. And it would be nice to introduce yourself of course :-) - 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: Welcome Doron Cohen!
Thanks everyone! I am very happy to become part of this team! Grant Ingersoll <[EMAIL PROTECTED]> wrote on 15/02/2007 13:42:58: > Congrats, Doron! Glad to have you on board! > > Your benchmark contribution is really useful as are the many > contributions to discussions, etc. Look forward to working with you > in the future! > > -Grant > > On Feb 15, 2007, at 1:49 PM, Yonik Seeley wrote: > > > I'm pleased to announce that the Lucene PMC has voted to make Doron > > Cohen a Lucene committer. > > > > Congrats, and welcome aboard, Doron! > > > > -Yonik > > > > ps: Doron - you can test out your new privileges by updating the > > who-we-are page, and regenerating + updating the site. And it would > > be nice to introduce yourself of course :-) Well... I Got my MSc in Computer Science on 1990 from the Technion, Haifa, Israel, and joined IBM. I worked in the areas of compiler backend optimization (instruction scheduling), database applications, and eventually search. Recent few years I was involved in a pure Java search engine called Juru, and about a year ago started to work with Lucene, gradually falling for it and getting involved. I very much like the ASF way, and Lucene - design and evolution, - and, still, sure have a lot to learn in both! Doron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven builds
karl wettin wrote: > > 15 feb 2007 kl. 20.27 skrev Erik Hatcher: >> On Feb 15, 2007, at 12:10 PM, karl wettin wrote: >>> I would not mind introducing Maven builds in Lucene. It would solve >>> /at least/ this problem. And it would merge so great with my other >>> projects. :) I'd be happy to help out , but there are some wicked >>> anting going on in a lot of build.xml:s so I would probably need a >>> lot of help from the contributors understanding whats going on. >>> >>> Most of the build scripts could be halfway housed using >>> maven-antrun-plugin. >> >> I'm open to Maven builds, for the record. I'll do what I can to help >> with understanding any of the wicked anting in there, but I don't know >> Maven so the best I'll be able to do is explain what is going on. >> The main complexity we have is the contrib area, oh and JavaCC... the >> rest is straightforward stuff. > > I'll see what I can do this weekend. "Maven" refers to two very different products. Which version to use ought to be a serious consideration. Karl, do you mean to use Maven 1.X or Maven2? Maven 1.X (which I use) seems not to be all that well maintained (e.g., Maven 1.1 has been in beta for 20 months now), and Maven2 is fairly new (first released 16 months ago), so probably has a smaller user base. The Maven site docs encourage new adopters to take the Maven2 route. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven builds
15 feb 2007 kl. 23.03 skrev Steven Rowe: I'll see what I can do this weekend. "Maven" refers to two very different products. Which version to use ought to be a serious consideration. Karl, do you mean to use Maven 1.X or Maven2? Maven2. mvn. -- karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven builds
Here is a couple of alternative points of view on Maven. Make sure your kids are not reading this: http://www.jroller.com/page/fate/?anchor=why_maven_sucks http://www.jroller.com/page/fate/?anchor=maven_refresher_course - Original Message - From: "karl wettin" <[EMAIL PROTECTED]> To: Sent: Thursday, February 15, 2007 2:05 PM Subject: Re: Maven builds > > 15 feb 2007 kl. 23.03 skrev Steven Rowe: > > >> I'll see what I can do this weekend. > > > > "Maven" refers to two very different products. Which version to use > > ought to be a serious consideration. > > > > Karl, do you mean to use Maven 1.X or Maven2? > > Maven2. mvn. > > -- > karl > > - > 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: request for comments, 626
15 feb 2007 kl. 20.52 skrev Yonik Seeley: I looked at it briefly and said to myself: "Wow, cool! I'll have to check that out some day." :-) Just a friendly reminder that lack of comments != lack of interest. At least I don't have to call my mom for confirmation now. :) Perhaps a little more description of how things work, esp the adaptive part, might elicit some feedback (and if it's in the mailing list already, put a pointer to it in the JIRA bug) There is not much except for the unit tests and the javadocs. The latter if fairly extensive. I'll try to build something from that can be read chronologically. Also, this could be a good time to credit Bob Carpenter. I sort of kidnapped him as an algorithmic mentor for a while there. I should probably put that somewhere in the non existing documentation. It'll be a hectic weekend. -- karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven builds
These articles are over 3 years old or more, I think the large community that uses Maven says it is a worthwhile thing. I'm curious, Slava, how many of ViewTier's Parabuild clients use Maven, since your website says you support it? I'm not saying Maven is the be all end all, but it works pretty well IMO. Having said that, we have most everything we need in the ANT scripts we already have, except, maybe automated releases and nice project metadata like the POM provides, so I'm not that compelled to switch. In light of our prior discussions of having more frequent releases, I think having more automated releases is needed. -Grant On Feb 15, 2007, at 5:19 PM, Slava Imeshev wrote: Here is a couple of alternative points of view on Maven. Make sure your kids are not reading this: http://www.jroller.com/page/fate/?anchor=why_maven_sucks http://www.jroller.com/page/fate/?anchor=maven_refresher_course - Original Message - From: "karl wettin" <[EMAIL PROTECTED]> To: Sent: Thursday, February 15, 2007 2:05 PM Subject: Re: Maven builds 15 feb 2007 kl. 23.03 skrev Steven Rowe: I'll see what I can do this weekend. "Maven" refers to two very different products. Which version to use ought to be a serious consideration. Karl, do you mean to use Maven 1.X or Maven2? Maven2. mvn. -- karl - 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] -- Grant Ingersoll Center for Natural Language Processing http://www.cnlp.org Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/ LuceneFAQ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven builds
Parabuild is build-tool agnostic, nor Viewtier has any tool preferences. The open source projects that we are currently supporting at http://parabuild.viewtier.com:8080 vary in use of builds tools. Our experience with setting up that projects has shown that Ant-based ones have been somewhat easier to set up. Maybe that's because with Ant it is possible to quickly figure out what you get. My personal opinion is that Ant is good enough and that Java has reached build automation nirvana with it, just like C/C++ with make. But as far as understand Apache requires you to move, so it's not really your call. If I had a voice I'd vote for multi-threaded indexing in Lucene instead of implementing Maven builds. - Original Message - From: "Grant Ingersoll" <[EMAIL PROTECTED]> To: Sent: Thursday, February 15, 2007 2:55 PM Subject: Re: Maven builds > These articles are over 3 years old or more, I think the large > community that uses Maven says it is a worthwhile thing. I'm > curious, Slava, how many of ViewTier's Parabuild clients use Maven, > since your website says you support it? Regards, Slava Imeshev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven builds
16 feb 2007 kl. 00.37 skrev Slava Imeshev: My personal opinion is that Ant is good enough and that Java has reached build automation nirvana with it, just like C/C++ with make. Did I start yet another tech-religous war thread now? Sorry about that. However, I don't think that the Buddha defined Nivana as "good enough". -- karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven builds
On Thu, 15 Feb 2007 18:58:00 -0500, karl wettin <[EMAIL PROTECTED]> wrote: 16 feb 2007 kl. 00.37 skrev Slava Imeshev: My personal opinion is that Ant is good enough and that Java has reached build automation nirvana with it, just like C/C++ with make. Did I start yet another tech-religous war thread now? Sorry about that. However, I don't think that the Buddha defined Nivana as "good enough". Do you only read websites that validate to XHTML 1.0 strict? who is the buddha? :) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (LUCENE-805) New Lucene Demo
On Feb 15, 2007, at 2:33 PM, Grant Ingersoll wrote: I think that code is great and is often self-documenting, but it only represents the result of someone writing the code, it doesn't explain the why part of it. So, it would need English (and translations???) to explain why a particular approach was taken, along with possible alternatives. So how about following the Solr lead with incredible wiki documentation and tutorial stuff. The code could be contributed and then documented by the community. I'd have no problem copy/pasting sections of LIA that were relevant and useful. Or writing some stuff from scratch on the examples. Erik On Feb 15, 2007, at 2:25 PM, Erik Hatcher (JIRA) wrote: [ https://issues.apache.org/jira/browse/LUCENE-805? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12473480 ] Erik Hatcher commented on LUCENE-805: - That was my concern as well, Grant. At least the LIA code is fairly well self documenting (we used JUnit for a reason :) and the build file itself is a nice example of how to launch applications and examples from a common starting point. What other documentation would be needed to make this a palatable? New Lucene Demo --- Key: LUCENE-805 URL: https://issues.apache.org/jira/browse/ LUCENE-805 Project: Lucene - Java Issue Type: Improvement Components: Examples Reporter: Grant Ingersoll Assigned To: Grant Ingersoll Priority: Minor The much maligned demo, while useful, could use a breath of fresh air. This issue is to start collecting requirements about what people would like to see in a demo and what they don't like in the current one. Ideas (not necessarily in order of importance): 1. More in-depth tutorial explaining indexing/searching 2. Multilingual support/demonstration 3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, Filters, sorting, etc. 4. Dealing with different content types and pointers to resources 5. Wiki use cases links -- I think it would be cool to solicit people to contribute use cases to the docs. 6. Demonstration of contrib packages, esp. Highlighter 7. Performance issues/factors/tradeoffs. Lucene lessons learned and best practices Advanced tutorials: 1. Hadoop + Lucene 2. Writing custom analyzers/filters/tokenizers 3. Changing Scoring 4. Payloads (when they are committed) Please contribute what else you would like to see. I may be able to address some of these issues for my ApacheCon talk, but not all of them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Grant Ingersoll http://www.grantingersoll.com/ http://www.paperoftheweek.com/ - 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: Maven builds
karl wettin wrote: However, I don't think that the Buddha defined Nivana as "good enough". http://en.wikipedia.org/wiki/Nirvana, "It is a mode of being that is free from mind-contaminants (Kilesa) such as lust, anger or craving." That's not far from "good enough". Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-794) Beginnings of a span based highlighter
[ https://issues.apache.org/jira/browse/LUCENE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated LUCENE-794: --- Attachment: HighlighterTest.java QuerySpansExtractor.java Highlighter.java Updated code to address deficiency in highlighting BooleanQueries. Use the following latest classes: CachedTokenStream DefaultEncoder Encoder Formatter Highlighter QuerySpansExtractor SimpleFormatter HighlighterTest > Beginnings of a span based highlighter > -- > > Key: LUCENE-794 > URL: https://issues.apache.org/jira/browse/LUCENE-794 > Project: Lucene - Java > Issue Type: Improvement > Components: Other >Reporter: Mark Miller >Priority: Minor > Attachments: CachedTokenStream.java, DefaultEncoder.java, > Encoder.java, Formatter.java, Highlighter.java, Highlighter.java, > Highlighter.java, Highlighter.java, HighlighterTest.java, > HighlighterTest.java, HighlighterTest.java, HighlighterTest.java, > MemoryIndex.java, QuerySpansExtractor.java, QuerySpansExtractor.java, > SimpleFormatter.java > > > This is some test code to start the work of adding a span based highlighting > approach to the existing highlighter in contrib. See > http://issues.apache.org/jira/browse/LUCENE-403 for some background. > There is a dependency on MemoryIndex. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-794) Beginnings of a span based highlighter
[ https://issues.apache.org/jira/browse/LUCENE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473578 ] Mark Miller commented on LUCENE-794: Using an Analyzer that produces multiple tokens at the same position does not yet operate correctly if used at query time. Using such a 'synonym' analyzer for indexing and a non 'synonym' analyzer for searching will work fine. > Beginnings of a span based highlighter > -- > > Key: LUCENE-794 > URL: https://issues.apache.org/jira/browse/LUCENE-794 > Project: Lucene - Java > Issue Type: Improvement > Components: Other >Reporter: Mark Miller >Priority: Minor > Attachments: CachedTokenStream.java, DefaultEncoder.java, > Encoder.java, Formatter.java, Highlighter.java, Highlighter.java, > Highlighter.java, Highlighter.java, HighlighterTest.java, > HighlighterTest.java, HighlighterTest.java, HighlighterTest.java, > MemoryIndex.java, QuerySpansExtractor.java, QuerySpansExtractor.java, > SimpleFormatter.java > > > This is some test code to start the work of adding a span based highlighting > approach to the existing highlighter in contrib. See > http://issues.apache.org/jira/browse/LUCENE-403 for some background. > There is a dependency on MemoryIndex. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Welcome Doron Cohen!
Welcome Doron! Otis - Original Message From: Yonik Seeley <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Friday, February 16, 2007 2:49:54 AM Subject: Welcome Doron Cohen! I'm pleased to announce that the Lucene PMC has voted to make Doron Cohen a Lucene committer. Congrats, and welcome aboard, Doron! -Yonik ps: Doron - you can test out your new privileges by updating the who-we-are page, and regenerating + updating the site. And it would be nice to introduce yourself of course :-) - 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-645) Highligter fails to include non-token at end of string to be highlighted
[
https://issues.apache.org/jira/browse/LUCENE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated LUCENE-645:
--
This fix works well for our case with JapaneseAnalyzer.
input text: "AAA BBB CCC (DDD EEE)"
output (w/ lucene-highlighter-2.0.0.jar)
AAA BBB CCC (DDD EEE
output(w/ lucene-highlighter-2.1-dev.jar)
AAA BBB CCC (DDD EEE)
We hope that the fix will be included at next release.
Regards,
Koji
> Highligter fails to include non-token at end of string to be highlighted
>
>
> Key: LUCENE-645
> URL: https://issues.apache.org/jira/browse/LUCENE-645
> Project: Lucene - Java
> Issue Type: Bug
> Components: Other
>Affects Versions: 1.9
> Environment: Red Hat Linux, Java 1.5
> Windows Java 1.5
>Reporter: Andrew Palmer
>Priority: Minor
>
> The following code extract show the problem
> TermQuery query= new TermQuery( new Term( "data", "help" ));
> Highlighter hg = new Highlighter(new SimpleHTMLFormatter(), new
> QueryScorer( query ));
> hg.setTextFragmenter( new NullFragmenter() );
>
> String match = null;
> try {
> match = hg.getBestFragment( new StandardAnalyzer(),
> "data", "help me [54-65]" );
> } catch (IOException e) {
> e.printStackTrace();
> }
> System.out.println( match );
> The sytsem outputs
> help me [54-65
> would expect
> help me [54-65]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
