[jira] Resolved: (LUCENE-931) Some files are missing the license headers
[ https://issues.apache.org/jira/browse/LUCENE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch resolved LUCENE-931. -- Resolution: Fixed Committed to trunk & 2.2 branch. Thanks, Jukka! > Some files are missing the license headers > -- > > Key: LUCENE-931 > URL: https://issues.apache.org/jira/browse/LUCENE-931 > Project: Lucene - Java > Issue Type: Wish > Components: Javadocs >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Trivial > Fix For: 2.2 > > Attachments: lucene-931.patch > > > Jukka provided the following list of files that are missing the license > headers. > In addition there might be other files (like build scripts) that don't have > the headers. > src/java/org/apache/lucene/document/MapFieldSelector.java > src/java/org/apache/lucene/search/PrefixFilter.java > src/test/org/apache/lucene/TestHitIterator.java > src/test/org/apache/lucene/analysis/TestISOLatin1AccentFilter.java > src/test/org/apache/lucene/index/TestAddIndexesNoOptimize.java > src/test/org/apache/lucene/index/TestBackwardsCompatibility.java > src/test/org/apache/lucene/index/TestFieldInfos.java > src/test/org/apache/lucene/index/TestIndexFileDeleter.java > src/test/org/apache/lucene/index/TestIndexWriter.java > src/test/org/apache/lucene/index/TestIndexWriterDelete.java > src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java > src/test/org/apache/lucene/index/TestIndexWriterMergePolicy.java > src/test/org/apache/lucene/index/TestNorms.java > src/test/org/apache/lucene/index/TestParallelTermEnum.java > src/test/org/apache/lucene/index/TestSegmentTermEnum.java > src/test/org/apache/lucene/index/TestTerm.java > src/test/org/apache/lucene/index/TestTermVectorsReader.java > src/test/org/apache/lucene/search/TestRangeQuery.java > src/test/org/apache/lucene/search/TestTermScorer.java > src/test/org/apache/lucene/store/TestBufferedIndexInput.java > src/test/org/apache/lucene/store/TestWindowsMMap.java > src/test/org/apache/lucene/store/_TestHelper.java > src/test/org/apache/lucene/util/_TestUtil.java > contrib/benchmark/src/java/org/apache/lucene/benchmark/byTask/feeds/SimpleSloppyPhraseQueryMaker.java > contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/FeedNotFoundException.java > contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/registry/ComponentType.java > contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/registry/RegistryException.java > contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/storage/lucenestorage/StorageAccountWrapper.java > contrib/gdata-server/src/core/src/test/org/apache/lucene/gdata/storage/lucenestorage/TestModifiedEntryFilter.java > contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/AtomUriElementTest.java > contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMEntryImplTest.java > contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMFeedImplTest.java > contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMGenereatorImplTest.java > contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMSourceImplTest.java > contrib/highlighter/src/java/org/apache/lucene/search/highlight/TokenSources.java > contrib/javascript/queryConstructor/luceneQueryConstructor.js > contrib/javascript/queryEscaper/luceneQueryEscaper.js > contrib/javascript/queryValidator/luceneQueryValidator.js > contrib/queries/src/java/org/apache/lucene/search/BooleanFilter.java > contrib/queries/src/java/org/apache/lucene/search/BoostingQuery.java > contrib/queries/src/java/org/apache/lucene/search/FilterClause.java > contrib/queries/src/java/org/apache/lucene/search/FuzzyLikeThisQuery.java > contrib/queries/src/java/org/apache/lucene/search/TermsFilter.java > contrib/queries/src/java/org/apache/lucene/search/similar/MoreLikeThisQuery.java > contrib/queries/src/test/org/apache/lucene/search/BooleanFilterTest.java > contrib/regex/src/test/org/apache/lucene/search/regex/TestSpanRegexQuery.java > contrib/snowball/src/java/net/sf/snowball/Among.java > contrib/snowball/src/java/net/sf/snowball/SnowballProgram.java > contrib/snowball/src/java/net/sf/snowball/TestApp.java > contrib/spellchecker/src/test/org/apache/lucene/search/spell/TestSpellChecker.java > contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/BooleanQueryTst.java > contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/ExceptionQueryTst.java > contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/SingleFieldTestDb.java > contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/Test01Exceptions.java > contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/Test02Boolean.java > contrib/surro
[jira] Updated: (LUCENE-622) Provide More of Lucene For Maven
[ https://issues.apache.org/jira/browse/LUCENE-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated LUCENE-622: -- Attachment: test-project.tar.gz The file attached contains a very simple maven2 project that uses few of the artifacts that Michael put on staging area. (for showing the obvious way how to test them) On the root dir just enter "mvn test" to see dependencies get fetched, project compiled and junit tests run. > Provide More of Lucene For Maven > > > Key: LUCENE-622 > URL: https://issues.apache.org/jira/browse/LUCENE-622 > Project: Lucene - Java > Issue Type: Task >Affects Versions: 2.0.0 >Reporter: Stephen Duncan Jr >Assignee: Michael Busch > Fix For: 2.2 > > Attachments: lucene-622.txt, lucene-core.pom, > lucene-highlighter-2.0.0.pom, lucene-maven.patch, lucene-maven.tar.bz2, > test-project.tar.gz > > > Please provide javadoc & source jars for lucene-core. Also, please provide > the rest of lucene (the jars inside of "contrib" in the download bundle) if > possible. -- 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-622) Provide More of Lucene For Maven
[ https://issues.apache.org/jira/browse/LUCENE-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503013 ] Hoss Man commented on LUCENE-622: - Seeing Michael's update to this issue reminded me that a few days ago when looking in the archives to see some of the discussion that happened during the 2.1 release I was realized that was when the last really big discussion about using maven came up, and one of the ideas put forth was to use the "maven antlib" (some custom ant tasks provided by the maven project) to deal with fetching remote dependencies for contribs (that have them) and publishing our jars (and their pom files) to the main maven repository. thinking about it more now, this also solves our "how do we communicate contrib dependencies to people who download binary distributions?" problem -- we can inlcude the pom.xml files in the release, and people can easily read them even if they don't use maven. between Sami's patch and Karl's tarball it seems like we already have some good pom files for all of the projects, the hard parts are making sure they stay up to date with reality as contribs evolve, and publishing them to the maven repository correctly. it seems maven't ant tasks can trivially solve the second problem, and easily solve the first if we make some changes to use it for fetching dependencies http://www.nabble.com/-VOTE--release-Lucene-2.1-tf3228536.html#a9014632 http://maven.apache.org/ant-tasks.html thoughts? > Provide More of Lucene For Maven > > > Key: LUCENE-622 > URL: https://issues.apache.org/jira/browse/LUCENE-622 > Project: Lucene - Java > Issue Type: Task >Affects Versions: 2.0.0 >Reporter: Stephen Duncan Jr >Assignee: Michael Busch > Fix For: 2.2 > > Attachments: lucene-622.txt, lucene-core.pom, > lucene-highlighter-2.0.0.pom, lucene-maven.patch, lucene-maven.tar.bz2 > > > Please provide javadoc & source jars for lucene-core. Also, please provide > the rest of lucene (the jars inside of "contrib" in the download bundle) if > possible. -- 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] Resolved: (LUCENE-917) Javadoc improvements for Payload class
[ https://issues.apache.org/jira/browse/LUCENE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch resolved LUCENE-917. -- Resolution: Fixed Committed to trunk & 2.2 branch. > Javadoc improvements for Payload class > -- > > Key: LUCENE-917 > URL: https://issues.apache.org/jira/browse/LUCENE-917 > Project: Lucene - Java > Issue Type: Wish > Components: Javadocs >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Trivial > Fix For: 2.2 > > Attachments: lucene-917.patch > > > Some methods in org.apache.lucene.index.Payload don't have javadocs -- 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-931) Some files are missing the license headers
[ https://issues.apache.org/jira/browse/LUCENE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch updated LUCENE-931: - Attachment: lucene-931.patch This patch adds the license header to all files listed above and to the ant build files. > Some files are missing the license headers > -- > > Key: LUCENE-931 > URL: https://issues.apache.org/jira/browse/LUCENE-931 > Project: Lucene - Java > Issue Type: Wish > Components: Javadocs >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Trivial > Fix For: 2.2 > > Attachments: lucene-931.patch > > > Jukka provided the following list of files that are missing the license > headers. > In addition there might be other files (like build scripts) that don't have > the headers. > src/java/org/apache/lucene/document/MapFieldSelector.java > src/java/org/apache/lucene/search/PrefixFilter.java > src/test/org/apache/lucene/TestHitIterator.java > src/test/org/apache/lucene/analysis/TestISOLatin1AccentFilter.java > src/test/org/apache/lucene/index/TestAddIndexesNoOptimize.java > src/test/org/apache/lucene/index/TestBackwardsCompatibility.java > src/test/org/apache/lucene/index/TestFieldInfos.java > src/test/org/apache/lucene/index/TestIndexFileDeleter.java > src/test/org/apache/lucene/index/TestIndexWriter.java > src/test/org/apache/lucene/index/TestIndexWriterDelete.java > src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java > src/test/org/apache/lucene/index/TestIndexWriterMergePolicy.java > src/test/org/apache/lucene/index/TestNorms.java > src/test/org/apache/lucene/index/TestParallelTermEnum.java > src/test/org/apache/lucene/index/TestSegmentTermEnum.java > src/test/org/apache/lucene/index/TestTerm.java > src/test/org/apache/lucene/index/TestTermVectorsReader.java > src/test/org/apache/lucene/search/TestRangeQuery.java > src/test/org/apache/lucene/search/TestTermScorer.java > src/test/org/apache/lucene/store/TestBufferedIndexInput.java > src/test/org/apache/lucene/store/TestWindowsMMap.java > src/test/org/apache/lucene/store/_TestHelper.java > src/test/org/apache/lucene/util/_TestUtil.java > contrib/benchmark/src/java/org/apache/lucene/benchmark/byTask/feeds/SimpleSloppyPhraseQueryMaker.java > contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/FeedNotFoundException.java > contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/registry/ComponentType.java > contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/registry/RegistryException.java > contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/storage/lucenestorage/StorageAccountWrapper.java > contrib/gdata-server/src/core/src/test/org/apache/lucene/gdata/storage/lucenestorage/TestModifiedEntryFilter.java > contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/AtomUriElementTest.java > contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMEntryImplTest.java > contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMFeedImplTest.java > contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMGenereatorImplTest.java > contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMSourceImplTest.java > contrib/highlighter/src/java/org/apache/lucene/search/highlight/TokenSources.java > contrib/javascript/queryConstructor/luceneQueryConstructor.js > contrib/javascript/queryEscaper/luceneQueryEscaper.js > contrib/javascript/queryValidator/luceneQueryValidator.js > contrib/queries/src/java/org/apache/lucene/search/BooleanFilter.java > contrib/queries/src/java/org/apache/lucene/search/BoostingQuery.java > contrib/queries/src/java/org/apache/lucene/search/FilterClause.java > contrib/queries/src/java/org/apache/lucene/search/FuzzyLikeThisQuery.java > contrib/queries/src/java/org/apache/lucene/search/TermsFilter.java > contrib/queries/src/java/org/apache/lucene/search/similar/MoreLikeThisQuery.java > contrib/queries/src/test/org/apache/lucene/search/BooleanFilterTest.java > contrib/regex/src/test/org/apache/lucene/search/regex/TestSpanRegexQuery.java > contrib/snowball/src/java/net/sf/snowball/Among.java > contrib/snowball/src/java/net/sf/snowball/SnowballProgram.java > contrib/snowball/src/java/net/sf/snowball/TestApp.java > contrib/spellchecker/src/test/org/apache/lucene/search/spell/TestSpellChecker.java > contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/BooleanQueryTst.java > contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/ExceptionQueryTst.java > contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/SingleFieldTestDb.java > contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/Test01Exceptions.java > contrib/surround/src/test/org/apache/lucene/queryParser
[jira] Resolved: (LUCENE-922) TermVectorOffsetInfo has incomplete Javadocs
[ https://issues.apache.org/jira/browse/LUCENE-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch resolved LUCENE-922. -- Resolution: Duplicate Grant submitted a patch for this on LUCENE-918. > TermVectorOffsetInfo has incomplete Javadocs > > > Key: LUCENE-922 > URL: https://issues.apache.org/jira/browse/LUCENE-922 > Project: Lucene - Java > Issue Type: Wish > Components: Javadocs >Reporter: Michael Busch >Assignee: Grant Ingersoll >Priority: Trivial > Fix For: 2.2 > > > org.apache.lucene.index.TermVectorOffsetInfo has no javadocs at all. -- 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-917) Javadoc improvements for Payload class
[ https://issues.apache.org/jira/browse/LUCENE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch updated LUCENE-917: - Attachment: lucene-917.patch > Javadoc improvements for Payload class > -- > > Key: LUCENE-917 > URL: https://issues.apache.org/jira/browse/LUCENE-917 > Project: Lucene - Java > Issue Type: Wish > Components: Javadocs >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Trivial > Fix For: 2.2 > > Attachments: lucene-917.patch > > > Some methods in org.apache.lucene.index.Payload don't have javadocs -- 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] Resolved: (LUCENE-923) Should SegmentTermPositionVector be public?
[ https://issues.apache.org/jira/browse/LUCENE-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch resolved LUCENE-923. -- Resolution: Fixed Committed to trunk & 2.2 branch. > Should SegmentTermPositionVector be public? > --- > > Key: LUCENE-923 > URL: https://issues.apache.org/jira/browse/LUCENE-923 > Project: Lucene - Java > Issue Type: Wish > Components: Index >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Trivial > Fix For: 2.2 > > Attachments: lucene-923.patch > > > I'm wondering why SegmentTermPositionVector is public. It implements the > public > interface TermPositionVector. Should we remove "public"? -- 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-923) Should SegmentTermPositionVector be public?
[ https://issues.apache.org/jira/browse/LUCENE-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch updated LUCENE-923: - Attachment: lucene-923.patch There were no objections against making SegmentTermPositionVector package-private, so I will go ahead and commit this patch soon. > Should SegmentTermPositionVector be public? > --- > > Key: LUCENE-923 > URL: https://issues.apache.org/jira/browse/LUCENE-923 > Project: Lucene - Java > Issue Type: Wish > Components: Index >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Trivial > Fix For: 2.2 > > Attachments: lucene-923.patch > > > I'm wondering why SegmentTermPositionVector is public. It implements the > public > interface TermPositionVector. Should we remove "public"? -- 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-622) Provide More of Lucene For Maven
[ https://issues.apache.org/jira/browse/LUCENE-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502991 ] Michael Busch commented on LUCENE-622: -- Sami, I applied your patch to my local checkout and uploaded the directory tree with the generated artifacts to http://people.apache.org/~buschmi/staging_area/lucene/. (I admitted already that I'm a maven newbie, so the following question hopefully won't be too embarrassing ;) ) How do we test if the generated artifacts are ok? > Provide More of Lucene For Maven > > > Key: LUCENE-622 > URL: https://issues.apache.org/jira/browse/LUCENE-622 > Project: Lucene - Java > Issue Type: Task >Affects Versions: 2.0.0 >Reporter: Stephen Duncan Jr >Assignee: Michael Busch > Fix For: 2.2 > > Attachments: lucene-622.txt, lucene-core.pom, > lucene-highlighter-2.0.0.pom, lucene-maven.patch, lucene-maven.tar.bz2 > > > Please provide javadoc & source jars for lucene-core. Also, please provide > the rest of lucene (the jars inside of "contrib" in the download bundle) if > possible. -- 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-930) fail build if contrib tests fail to compile
[ https://issues.apache.org/jira/browse/LUCENE-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated LUCENE-930: Attachment: LUCENE-930.patch 1) rather then add empty src/test directories to contribs (which might confuse people: they might assume tests exist by seeing the dir, they might assume they didn't get the tests in their release since the dir is empty, they might svn remove the dirs not realizing it will break the build, etc...) i made the contrib-build.xml skip the compile-test and test targets if there are no tests. 2) Encountered a problem while testing the patch: tests in some contribs rely on the core tests files (spellchecker depends on the English class for example) and "ant clean test-contrib" doesn't ensure that the core tests are compiled (because build-contrib no longer depends on compile-test). I view this is really a problem with the way contrib dependencies are built and not the main build.xml ... on a clean checkout you should be able to do "cd contrib/foo; ant test" and have it automatically build all your dependencies (this already works for the core lucene jar because of the "build-lucene" task). so I made some additions to contrib-build.xml to support this (a "build-lucene-test" task), and the spellchecker contrib that needed it. 3) with Michael's encouragement, i went ahead and removed the "compile-test-contrib" target and just made "build-contrib" take care of it ... this involved adding a new "build-jar-and-tests" since contrib-crawl/subant only support a single target name ... this is much cleaner in my opinion then the old way where build-contrib would just run whatever the 'default' target was for each contrib (which could be named anything, and could do anything) .. now the expected semantics are clearer (although i'm open torenaming the target) ...but i ran into a slight snag because of the "javacc-uptodate-check" init depends on which doesn't work for "meta-contribs" like gdata and db that don't have a src dir ... the task even has a TODO that it really only needs to be done for a few contribs, so that looks like a good thing to fix to ... but i've got to run now. i'll try to update the patch a little later tonight (any feedback in the meantime would be appreciated) > fail build if contrib tests fail to compile > --- > > Key: LUCENE-930 > URL: https://issues.apache.org/jira/browse/LUCENE-930 > Project: Lucene - Java > Issue Type: Bug > Components: Build >Affects Versions: 2.1 >Reporter: Hoss Man >Assignee: Hoss Man > Attachments: LUCENE-930.patch, LUCENE-930.patch > > > spinoff of LUCENE-885, from Steven's comments... > Looking at the current build (r545324) it looks like the some contrib > failures are getting swallowed. Things like lucli are throwing errors along > the lines of > [subant] /home/barronpark/smparkes/work/lucene/trunk/common-build.xml:366: > srcdir "/home/barronpark/smparkes/work/lucene/trunk/contrib/lucli/src/test" > does not exist! > but these don't make it back up to the top level status. > It looks like the current state will bubble up junit failures, but maybe not > build failures? > ... > It's "test-compile-contrib" (if you will) that fails and rather being > contrib-crawled, that's only done as the target of "test" in each contrib > directory, at which point, it's running in the protected contrib-crawl. > Easy enough to lift this loop into another target, e.g., build-contrib-test. > And that will start surfacing errors, which I can work through. -- 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] Created: (LUCENE-931) Some files are missing the license headers
Some files are missing the license headers -- Key: LUCENE-931 URL: https://issues.apache.org/jira/browse/LUCENE-931 Project: Lucene - Java Issue Type: Wish Components: Javadocs Reporter: Michael Busch Assignee: Michael Busch Priority: Trivial Fix For: 2.2 Jukka provided the following list of files that are missing the license headers. In addition there might be other files (like build scripts) that don't have the headers. src/java/org/apache/lucene/document/MapFieldSelector.java src/java/org/apache/lucene/search/PrefixFilter.java src/test/org/apache/lucene/TestHitIterator.java src/test/org/apache/lucene/analysis/TestISOLatin1AccentFilter.java src/test/org/apache/lucene/index/TestAddIndexesNoOptimize.java src/test/org/apache/lucene/index/TestBackwardsCompatibility.java src/test/org/apache/lucene/index/TestFieldInfos.java src/test/org/apache/lucene/index/TestIndexFileDeleter.java src/test/org/apache/lucene/index/TestIndexWriter.java src/test/org/apache/lucene/index/TestIndexWriterDelete.java src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java src/test/org/apache/lucene/index/TestIndexWriterMergePolicy.java src/test/org/apache/lucene/index/TestNorms.java src/test/org/apache/lucene/index/TestParallelTermEnum.java src/test/org/apache/lucene/index/TestSegmentTermEnum.java src/test/org/apache/lucene/index/TestTerm.java src/test/org/apache/lucene/index/TestTermVectorsReader.java src/test/org/apache/lucene/search/TestRangeQuery.java src/test/org/apache/lucene/search/TestTermScorer.java src/test/org/apache/lucene/store/TestBufferedIndexInput.java src/test/org/apache/lucene/store/TestWindowsMMap.java src/test/org/apache/lucene/store/_TestHelper.java src/test/org/apache/lucene/util/_TestUtil.java contrib/benchmark/src/java/org/apache/lucene/benchmark/byTask/feeds/SimpleSloppyPhraseQueryMaker.java contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/FeedNotFoundException.java contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/registry/ComponentType.java contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/registry/RegistryException.java contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/storage/lucenestorage/StorageAccountWrapper.java contrib/gdata-server/src/core/src/test/org/apache/lucene/gdata/storage/lucenestorage/TestModifiedEntryFilter.java contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/AtomUriElementTest.java contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMEntryImplTest.java contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMFeedImplTest.java contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMGenereatorImplTest.java contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMSourceImplTest.java contrib/highlighter/src/java/org/apache/lucene/search/highlight/TokenSources.java contrib/javascript/queryConstructor/luceneQueryConstructor.js contrib/javascript/queryEscaper/luceneQueryEscaper.js contrib/javascript/queryValidator/luceneQueryValidator.js contrib/queries/src/java/org/apache/lucene/search/BooleanFilter.java contrib/queries/src/java/org/apache/lucene/search/BoostingQuery.java contrib/queries/src/java/org/apache/lucene/search/FilterClause.java contrib/queries/src/java/org/apache/lucene/search/FuzzyLikeThisQuery.java contrib/queries/src/java/org/apache/lucene/search/TermsFilter.java contrib/queries/src/java/org/apache/lucene/search/similar/MoreLikeThisQuery.java contrib/queries/src/test/org/apache/lucene/search/BooleanFilterTest.java contrib/regex/src/test/org/apache/lucene/search/regex/TestSpanRegexQuery.java contrib/snowball/src/java/net/sf/snowball/Among.java contrib/snowball/src/java/net/sf/snowball/SnowballProgram.java contrib/snowball/src/java/net/sf/snowball/TestApp.java contrib/spellchecker/src/test/org/apache/lucene/search/spell/TestSpellChecker.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/BooleanQueryTst.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/ExceptionQueryTst.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/SingleFieldTestDb.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/Test01Exceptions.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/Test02Boolean.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/Test03Distance.java contrib/wordnet/src/java/org/apache/lucene/wordnet/SynExpand.java contrib/wordnet/src/java/org/apache/lucene/wordnet/SynLookup.java contrib/wordnet/src/java/org/apache/lucene/wordnet/Syns2Index.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. ---
Re: Please help testing the release files
Jukka Zitting wrote: Tested on: - Windows XP, Sun Java 1.4.2_12 - Windows XP, Sun Java 1.6.0-b105 - Ubuntu 7.04, Sun Java 1.6.0-b105 Great, thank you, Jukka! I also ran RAT (http://code.google.com/p/arat/) on the source archive, and there seem to be some files without license headers. Nothing really major, but you may want to check at least some of the files. I've listed the source files below, but I think the best practice would nowadays be to include license headers also in things like Ant build scripts, etc. I will take care of the license headers. Thanks! - Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-930) fail build if contrib tests fail to compile
[ https://issues.apache.org/jira/browse/LUCENE-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502966 ] Michael Busch commented on LUCENE-930: -- > would those people really care if the build took a little longer > because it compile the tests even though they weren't run? IMO this is fine. > and since i'm not certain these additional changes will make it > into the 2.2 branch (not my call to make) Since this is contrib stuff I would say it is ok to get it into 2.2 as long as we also fix the failing tests with this patch. > fail build if contrib tests fail to compile > --- > > Key: LUCENE-930 > URL: https://issues.apache.org/jira/browse/LUCENE-930 > Project: Lucene - Java > Issue Type: Bug > Components: Build >Affects Versions: 2.1 >Reporter: Hoss Man >Assignee: Hoss Man > Attachments: LUCENE-930.patch > > > spinoff of LUCENE-885, from Steven's comments... > Looking at the current build (r545324) it looks like the some contrib > failures are getting swallowed. Things like lucli are throwing errors along > the lines of > [subant] /home/barronpark/smparkes/work/lucene/trunk/common-build.xml:366: > srcdir "/home/barronpark/smparkes/work/lucene/trunk/contrib/lucli/src/test" > does not exist! > but these don't make it back up to the top level status. > It looks like the current state will bubble up junit failures, but maybe not > build failures? > ... > It's "test-compile-contrib" (if you will) that fails and rather being > contrib-crawled, that's only done as the target of "test" in each contrib > directory, at which point, it's running in the protected contrib-crawl. > Easy enough to lift this loop into another target, e.g., build-contrib-test. > And that will start surfacing errors, which I can work through. -- 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-930) fail build if contrib tests fail to compile
[ https://issues.apache.org/jira/browse/LUCENE-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502965 ] Hoss Man commented on LUCENE-930: - No worries Steven. Looking at the patch now, i'm wondering if it's really worth adding the top level "compile-test-contrib" target, or if the top level "build-contrib" target should just take care of calling the compile-test target (and making test-contrib depend on build-contrib) ... it would be one less time we have to crawl the contribs, and the only "downside" is that there is no longer a way to build all contirbs without compiling the tests for each contrib as well ... is that really that bad? is anyone building binary distributions without running the tests anyway? would those people really care if the build took a little longer because it compile the tests even though they weren't run? > fail build if contrib tests fail to compile > --- > > Key: LUCENE-930 > URL: https://issues.apache.org/jira/browse/LUCENE-930 > Project: Lucene - Java > Issue Type: Bug > Components: Build >Affects Versions: 2.1 >Reporter: Hoss Man >Assignee: Hoss Man > Attachments: LUCENE-930.patch > > > spinoff of LUCENE-885, from Steven's comments... > Looking at the current build (r545324) it looks like the some contrib > failures are getting swallowed. Things like lucli are throwing errors along > the lines of > [subant] /home/barronpark/smparkes/work/lucene/trunk/common-build.xml:366: > srcdir "/home/barronpark/smparkes/work/lucene/trunk/contrib/lucli/src/test" > does not exist! > but these don't make it back up to the top level status. > It looks like the current state will bubble up junit failures, but maybe not > build failures? > ... > It's "test-compile-contrib" (if you will) that fails and rather being > contrib-crawled, that's only done as the target of "test" in each contrib > directory, at which point, it's running in the protected contrib-crawl. > Easy enough to lift this loop into another target, e.g., build-contrib-test. > And that will start surfacing errors, which I can work through. -- 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] Assigned: (LUCENE-930) fail build if contrib tests fail to compile
[ https://issues.apache.org/jira/browse/LUCENE-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reassigned LUCENE-930: --- Assignee: Hoss Man > fail build if contrib tests fail to compile > --- > > Key: LUCENE-930 > URL: https://issues.apache.org/jira/browse/LUCENE-930 > Project: Lucene - Java > Issue Type: Bug > Components: Build >Affects Versions: 2.1 >Reporter: Hoss Man >Assignee: Hoss Man > Attachments: LUCENE-930.patch > > > spinoff of LUCENE-885, from Steven's comments... > Looking at the current build (r545324) it looks like the some contrib > failures are getting swallowed. Things like lucli are throwing errors along > the lines of > [subant] /home/barronpark/smparkes/work/lucene/trunk/common-build.xml:366: > srcdir "/home/barronpark/smparkes/work/lucene/trunk/contrib/lucli/src/test" > does not exist! > but these don't make it back up to the top level status. > It looks like the current state will bubble up junit failures, but maybe not > build failures? > ... > It's "test-compile-contrib" (if you will) that fails and rather being > contrib-crawled, that's only done as the target of "test" in each contrib > directory, at which point, it's running in the protected contrib-crawl. > Easy enough to lift this loop into another target, e.g., build-contrib-test. > And that will start surfacing errors, which I can work through. -- 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-930) fail build if contrib tests fail to compile
[ https://issues.apache.org/jira/browse/LUCENE-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502959 ] Steven Parkes commented on LUCENE-930: -- Thanks, Chris. Sorry for the extra steps. > fail build if contrib tests fail to compile > --- > > Key: LUCENE-930 > URL: https://issues.apache.org/jira/browse/LUCENE-930 > Project: Lucene - Java > Issue Type: Bug > Components: Build >Affects Versions: 2.1 >Reporter: Hoss Man > Attachments: LUCENE-930.patch > > > spinoff of LUCENE-885, from Steven's comments... > Looking at the current build (r545324) it looks like the some contrib > failures are getting swallowed. Things like lucli are throwing errors along > the lines of > [subant] /home/barronpark/smparkes/work/lucene/trunk/common-build.xml:366: > srcdir "/home/barronpark/smparkes/work/lucene/trunk/contrib/lucli/src/test" > does not exist! > but these don't make it back up to the top level status. > It looks like the current state will bubble up junit failures, but maybe not > build failures? > ... > It's "test-compile-contrib" (if you will) that fails and rather being > contrib-crawled, that's only done as the target of "test" in each contrib > directory, at which point, it's running in the protected contrib-crawl. > Easy enough to lift this loop into another target, e.g., build-contrib-test. > And that will start surfacing errors, which I can work through. -- 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-930) fail build if contrib tests fail to compile
[ https://issues.apache.org/jira/browse/LUCENE-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502957 ] Hoss Man commented on LUCENE-930: - Damn, i forgot to include these comments from Steven regarding the patch... This patch file removes the swallowed failures by doing more of the build steps out of the guarded loop (that only detects junit failures, not others). In addition the patch, need to create and "svn add" A contrib/wordnet/src/test A contrib/similarity/src/test A contrib/lucli/src/test This makes it possible to actually run the gdata-server tests, which were not running before. I have seen one case where it hung, but maybe that was a fluke. > fail build if contrib tests fail to compile > --- > > Key: LUCENE-930 > URL: https://issues.apache.org/jira/browse/LUCENE-930 > Project: Lucene - Java > Issue Type: Bug > Components: Build >Affects Versions: 2.1 >Reporter: Hoss Man > Attachments: LUCENE-930.patch > > > spinoff of LUCENE-885, from Steven's comments... > Looking at the current build (r545324) it looks like the some contrib > failures are getting swallowed. Things like lucli are throwing errors along > the lines of > [subant] /home/barronpark/smparkes/work/lucene/trunk/common-build.xml:366: > srcdir "/home/barronpark/smparkes/work/lucene/trunk/contrib/lucli/src/test" > does not exist! > but these don't make it back up to the top level status. > It looks like the current state will bubble up junit failures, but maybe not > build failures? > ... > It's "test-compile-contrib" (if you will) that fails and rather being > contrib-crawled, that's only done as the target of "test" in each contrib > directory, at which point, it's running in the protected contrib-crawl. > Easy enough to lift this loop into another target, e.g., build-contrib-test. > And that will start surfacing errors, which I can work through. -- 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-930) fail build if contrib tests fail to compile
[ https://issues.apache.org/jira/browse/LUCENE-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated LUCENE-930: Attachment: LUCENE-930.patch patch orriginally contributed by Steven Parkes in LUCENE-885 using the name "LUCENE-885-pt2.patch" > fail build if contrib tests fail to compile > --- > > Key: LUCENE-930 > URL: https://issues.apache.org/jira/browse/LUCENE-930 > Project: Lucene - Java > Issue Type: Bug > Components: Build >Affects Versions: 2.1 >Reporter: Hoss Man > Attachments: LUCENE-930.patch > > > spinoff of LUCENE-885, from Steven's comments... > Looking at the current build (r545324) it looks like the some contrib > failures are getting swallowed. Things like lucli are throwing errors along > the lines of > [subant] /home/barronpark/smparkes/work/lucene/trunk/common-build.xml:366: > srcdir "/home/barronpark/smparkes/work/lucene/trunk/contrib/lucli/src/test" > does not exist! > but these don't make it back up to the top level status. > It looks like the current state will bubble up junit failures, but maybe not > build failures? > ... > It's "test-compile-contrib" (if you will) that fails and rather being > contrib-crawled, that's only done as the target of "test" in each contrib > directory, at which point, it's running in the protected contrib-crawl. > Easy enough to lift this loop into another target, e.g., build-contrib-test. > And that will start surfacing errors, which I can work through. -- 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] Created: (LUCENE-930) fail build if contrib tests fail to compile
fail build if contrib tests fail to compile --- Key: LUCENE-930 URL: https://issues.apache.org/jira/browse/LUCENE-930 Project: Lucene - Java Issue Type: Bug Components: Build Affects Versions: 2.1 Reporter: Hoss Man spinoff of LUCENE-885, from Steven's comments... Looking at the current build (r545324) it looks like the some contrib failures are getting swallowed. Things like lucli are throwing errors along the lines of [subant] /home/barronpark/smparkes/work/lucene/trunk/common-build.xml:366: srcdir "/home/barronpark/smparkes/work/lucene/trunk/contrib/lucli/src/test" does not exist! but these don't make it back up to the top level status. It looks like the current state will bubble up junit failures, but maybe not build failures? ... It's "test-compile-contrib" (if you will) that fails and rather being contrib-crawled, that's only done as the target of "test" in each contrib directory, at which point, it's running in the protected contrib-crawl. Easy enough to lift this loop into another target, e.g., build-contrib-test. And that will start surfacing errors, which I can work through. -- 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] Resolved: (LUCENE-885) clean up build files so contrib tests are run more easily
[ https://issues.apache.org/jira/browse/LUCENE-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved LUCENE-885. - Resolution: Fixed Steven: Since changes with this issue number have already been committed and recorded in the CHANGES.txt file prior to the 2.2 branch, and since i'm not certain these additional changes will make it into the 2.2 branch (not my call to make) i think it would be better to open a new (linked) issue with a unique number for tracking purposes. I'll take care of that now. > clean up build files so contrib tests are run more easily > - > > Key: LUCENE-885 > URL: https://issues.apache.org/jira/browse/LUCENE-885 > Project: Lucene - Java > Issue Type: Improvement > Components: Build >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 2.2 > > Attachments: LUCENE-885-pt2.patch, LUCENE-885.patch, LUCENE-885.patch > > > Per mailing list discussion... > http://www.nabble.com/Tests%2C-Contribs%2C-and-Releases-tf3768924.html#a10655448 > Tests for contribs should be run when "ant test" is used, existing "test" > target renamed to "test-core" -- 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: Please help testing the release files
Hi, On 6/5/07, Michael Busch <[EMAIL PROTECTED]> wrote: So please help testing the release files on different platforms with different JVM versions. Tested on: - Windows XP, Sun Java 1.4.2_12 - Windows XP, Sun Java 1.6.0-b105 - Ubuntu 7.04, Sun Java 1.6.0-b105 I also ran RAT (http://code.google.com/p/arat/) on the source archive, and there seem to be some files without license headers. Nothing really major, but you may want to check at least some of the files. I've listed the source files below, but I think the best practice would nowadays be to include license headers also in things like Ant build scripts, etc. BR, Jukka Zitting src/java/org/apache/lucene/document/MapFieldSelector.java src/java/org/apache/lucene/search/PrefixFilter.java src/test/org/apache/lucene/TestHitIterator.java src/test/org/apache/lucene/analysis/TestISOLatin1AccentFilter.java src/test/org/apache/lucene/index/TestAddIndexesNoOptimize.java src/test/org/apache/lucene/index/TestBackwardsCompatibility.java src/test/org/apache/lucene/index/TestFieldInfos.java src/test/org/apache/lucene/index/TestIndexFileDeleter.java src/test/org/apache/lucene/index/TestIndexWriter.java src/test/org/apache/lucene/index/TestIndexWriterDelete.java src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java src/test/org/apache/lucene/index/TestIndexWriterMergePolicy.java src/test/org/apache/lucene/index/TestNorms.java src/test/org/apache/lucene/index/TestParallelTermEnum.java src/test/org/apache/lucene/index/TestSegmentTermEnum.java src/test/org/apache/lucene/index/TestTerm.java src/test/org/apache/lucene/index/TestTermVectorsReader.java src/test/org/apache/lucene/search/TestRangeQuery.java src/test/org/apache/lucene/search/TestTermScorer.java src/test/org/apache/lucene/store/TestBufferedIndexInput.java src/test/org/apache/lucene/store/TestWindowsMMap.java src/test/org/apache/lucene/store/_TestHelper.java src/test/org/apache/lucene/util/_TestUtil.java contrib/benchmark/src/java/org/apache/lucene/benchmark/byTask/feeds/SimpleSloppyPhraseQueryMaker.java contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/FeedNotFoundException.java contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/registry/ComponentType.java contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/server/registry/RegistryException.java contrib/gdata-server/src/core/src/java/org/apache/lucene/gdata/storage/lucenestorage/StorageAccountWrapper.java contrib/gdata-server/src/core/src/test/org/apache/lucene/gdata/storage/lucenestorage/TestModifiedEntryFilter.java contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/AtomUriElementTest.java contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMEntryImplTest.java contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMFeedImplTest.java contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMGenereatorImplTest.java contrib/gdata-server/src/gom/src/test/org/apache/lucene/gdata/gom/core/GOMSourceImplTest.java contrib/highlighter/src/java/org/apache/lucene/search/highlight/TokenSources.java contrib/javascript/queryConstructor/luceneQueryConstructor.js contrib/javascript/queryEscaper/luceneQueryEscaper.js contrib/javascript/queryValidator/luceneQueryValidator.js contrib/queries/src/java/org/apache/lucene/search/BooleanFilter.java contrib/queries/src/java/org/apache/lucene/search/BoostingQuery.java contrib/queries/src/java/org/apache/lucene/search/FilterClause.java contrib/queries/src/java/org/apache/lucene/search/FuzzyLikeThisQuery.java contrib/queries/src/java/org/apache/lucene/search/TermsFilter.java contrib/queries/src/java/org/apache/lucene/search/similar/MoreLikeThisQuery.java contrib/queries/src/test/org/apache/lucene/search/BooleanFilterTest.java contrib/regex/src/test/org/apache/lucene/search/regex/TestSpanRegexQuery.java contrib/snowball/src/java/net/sf/snowball/Among.java contrib/snowball/src/java/net/sf/snowball/SnowballProgram.java contrib/snowball/src/java/net/sf/snowball/TestApp.java contrib/spellchecker/src/test/org/apache/lucene/search/spell/TestSpellChecker.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/BooleanQueryTst.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/ExceptionQueryTst.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/SingleFieldTestDb.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/Test01Exceptions.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/Test02Boolean.java contrib/surround/src/test/org/apache/lucene/queryParser/surround/query/Test03Distance.java contrib/wordnet/src/java/org/apache/lucene/wordnet/SynExpand.java contrib/wordnet/src/java/org/apache/lucene/wordnet/SynLookup.java contrib/wordnet/src/java/org/apache/lucene/wordnet/Syns2Index.java - To unsubscribe, e-mail: [EMAIL PRO
[jira] Commented: (LUCENE-914) Scorer.skipTo(current) remains on current for some scorers
[ https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502882 ] Doug Cutting commented on LUCENE-914: - Note also that Scorer#skipTo() is specified almost identically to TermDocs#skipTo(). It would be best if the contracts for these interfaces stayed similar, to avoid confusion. > Scorer.skipTo(current) remains on current for some scorers > -- > > Key: LUCENE-914 > URL: https://issues.apache.org/jira/browse/LUCENE-914 > Project: Lucene - Java > Issue Type: Bug > Components: Search >Reporter: Doron Cohen >Priority: Minor > Attachments: lucene-914.patch > > > Background in http://www.nabble.com/scorer.skipTo%28%29-contr-tf3880986.html > It appears that several scorers do not strictly follow the spec of > Scorer.skipTo(n), and skip to current location remain in current location > whereas the spec says: "beyond current". > We should (probably) either relax the spec or fix the implementations. -- 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-914) Scorer.skipTo(current) remains on current for some scorers
[ https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502873 ] Yonik Seeley commented on LUCENE-914: - Yes, I remember an initial doc()==-1 would be nice (and easy I think). For example DisjunctionMaxScorer could simply remove firstTime blocks in both skipTo() and next() with no other changes. Even the "more" flag could easily be removed I think. > Scorer.skipTo(current) remains on current for some scorers > -- > > Key: LUCENE-914 > URL: https://issues.apache.org/jira/browse/LUCENE-914 > Project: Lucene - Java > Issue Type: Bug > Components: Search >Reporter: Doron Cohen >Priority: Minor > Attachments: lucene-914.patch > > > Background in http://www.nabble.com/scorer.skipTo%28%29-contr-tf3880986.html > It appears that several scorers do not strictly follow the spec of > Scorer.skipTo(n), and skip to current location remain in current location > whereas the spec says: "beyond current". > We should (probably) either relax the spec or fix the implementations. -- 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-924) IndexWriter has incomplete Javadocs
[ https://issues.apache.org/jira/browse/LUCENE-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-924: -- Attachment: LUCENE-924.patch All javadoc changes to add missing docs in IndexWriter. > IndexWriter has incomplete Javadocs > --- > > Key: LUCENE-924 > URL: https://issues.apache.org/jira/browse/LUCENE-924 > Project: Lucene - Java > Issue Type: Wish > Components: Javadocs >Reporter: Michael Busch >Assignee: Michael McCandless >Priority: Trivial > Fix For: 2.2 > > Attachments: LUCENE-924.patch > > > A couple of getter methods in IndexWriter have no javadocs. -- 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-912) DisjunctionMaxScorer.skipTo has bug that keeps it from skipping
[ https://issues.apache.org/jira/browse/LUCENE-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502854 ] Doron Cohen commented on LUCENE-912: I think you're right, and actually wondered about the same thing while verifying that fix: "why return in next() but not in skipTo()?" - I believe this is the right thing to do because at the initialization (ie in add(Scorer)) each added sub-scorer is advanced to its first match. So the first time that next() is called, sub-scorers are already "on the right spot", and not so for the first time skipTo() is called, because skipTo does not necessarily goes to the first match. > DisjunctionMaxScorer.skipTo has bug that keeps it from skipping > --- > > Key: LUCENE-912 > URL: https://issues.apache.org/jira/browse/LUCENE-912 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 2.0.0, 2.1 >Reporter: Hoss Man >Assignee: Doron Cohen > Fix For: 2.2 > > Attachments: checkTwoCallsToScore.patch, checkTwoCallsToScore.patch, > dismax_skipto.patch, lucene-912.patch > > > as reported on the mailing list, DisjunctionMaxScorer.skipTo is broken if > called before next in some situations... > http://www.nabble.com/Potential-issue-with-DisjunctionMaxScorer-tf3846366.html#a10894987 -- 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-843) improve how IndexWriter uses RAM to buffer added documents
[ https://issues.apache.org/jira/browse/LUCENE-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502793 ] Michael McCandless commented on LUCENE-843: --- I ran a benchmark using more than 1 thread to do indexing, in order to test & compare concurrency of trunk and the patch. The test is the same as above, and runs on a 4 core Mac Pro (OS X) box with 4 drive RAID 0 IO system. Here are the raw results: DOCS = ~5,500 bytes plain text RAM = 32 MB MERGE FACTOR = 10 With term vectors (positions + offsets) and 2 small stored fields AUTOCOMMIT = false (commit only once at the end) NUM THREADS = 1 new 20 docs in 172.3 secs index size = 1.7G old 20 docs in 539.5 secs index size = 1.7G Total Docs/sec: old 370.7; new 1161.0 [ 213.2% faster] Docs/MB @ flush:old47.9; new 334.6 [ 598.7% more] Avg RAM used (MB) @ flush: old 131.9; new33.1 [ 74.9% less] NUM THREADS = 2 new 21 docs in 130.8 secs index size = 1.7G old 21 docs in 452.8 secs index size = 1.7G Total Docs/sec: old 441.7; new 1529.3 [ 246.2% faster] Docs/MB @ flush:old47.9; new 301.5 [ 529.7% more] Avg RAM used (MB) @ flush: old 226.1; new35.2 [ 84.4% less] NUM THREADS = 3 new 22 docs in 105.4 secs index size = 1.7G old 22 docs in 428.4 secs index size = 1.7G Total Docs/sec: old 466.8; new 1897.9 [ 306.6% faster] Docs/MB @ flush:old47.9; new 277.8 [ 480.2% more] Avg RAM used (MB) @ flush: old 289.8; new37.0 [ 87.2% less] NUM THREADS = 4 new 23 docs in 104.8 secs index size = 1.7G old 23 docs in 440.4 secs index size = 1.7G Total Docs/sec: old 454.1; new 1908.5 [ 320.3% faster] Docs/MB @ flush:old47.9; new 259.9 [ 442.9% more] Avg RAM used (MB) @ flush: old 293.7; new37.1 [ 87.3% less] NUM THREADS = 5 new 24 docs in 99.5 secs index size = 1.7G old 24 docs in 425.0 secs index size = 1.7G Total Docs/sec: old 470.6; new 2010.5 [ 327.2% faster] Docs/MB @ flush:old47.9; new 245.3 [ 412.6% more] Avg RAM used (MB) @ flush: old 390.9; new38.3 [ 90.2% less] NUM THREADS = 6 new 25 docs in 106.3 secs index size = 1.7G old 25 docs in 427.1 secs index size = 1.7G Total Docs/sec: old 468.2; new 1882.3 [ 302.0% faster] Docs/MB @ flush:old47.8; new 248.5 [ 419.3% more] Avg RAM used (MB) @ flush: old 340.9; new38.7 [ 88.6% less] NUM THREADS = 7 new 26 docs in 106.1 secs index size = 1.7G old 26 docs in 435.2 secs index size = 1.7G Total Docs/sec: old 459.6; new 1885.3 [ 310.2% faster] Docs/MB @ flush:old47.8; new 248.7 [ 420.0% more] Avg RAM used (MB) @ flush: old 408.6; new39.1 [ 90.4% less] NUM THREADS = 8 new 27 docs in 109.0 secs index size = 1.7G old 27 docs in 469.2 secs index size = 1.7G Total Docs/sec: old 426.3; new 1835.2 [ 330.5% faster] Docs/MB @ flush:old47.8; new 251.3 [ 425.5% more] Avg RAM used (MB) @ flush: old 448.9; new39.0 [ 91.3% less] Some quick comments: * Both trunk & the patch show speedups if you use more than 1 thread to do indexing. This is expected since the machine has concurrency. * The biggest speedup is from 1->2 threads but still good gains from 2->5 threads. * Best seems to be 5 threads. * The patch allows better concurrency: relatively speaking it speeds up faster than the trunk (the % faster increases as we add threads) as you increase # threads. I think this makes sense because we flush less often with the patch, and, flushing is time consuming and single threaded. > improve how IndexWriter uses RAM to buffer added documents > -- > > Key: LUCENE-843 > URL: https://issues.apache.org/jira/browse/LUCENE-843 > Project: Lucene - Java > Issue Type: Improvement > Components: Index >Affects Versions: 2.2 >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Attac
[jira] Updated: (LUCENE-843) improve how IndexWriter uses RAM to buffer added documents
[ https://issues.apache.org/jira/browse/LUCENE-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-843: -- Attachment: LUCENE-843.take7.patch Latest working patch attached. I've cutover to using Lucene's normal segment merging for all merging (ie, I no longer use a different merge-efficient format for segments when autoCommit=false); this has substantially simplified the code. All unit tests pass except disk-full test and certain contrib tests (gdata-server, lucli, similarity, wordnet) that I think I'm not causing. Other changes: * Consolidated flushing of a new segment back into IndexWriter (previously DocumentsWriter would do its own flushing when autoCommit=false). I would also like to consolidate merging entirely into IndexWriter; right now DocumentsWriter does its own merging of the flushed segments when autoCommit=false (this is because those segments are "partial" meaning they do not have their own stored fields or term vectors). I'm trying to find a clean way to do this... * Thread concurrency now works: each thread writes into a separate Postings hash (up until a limit (currently 5) at which point the threads share the Postings hashes) and then when flushing the segment I merge the docIDs together. I flush when the total RAM used across threads is over the limit. I ran a test comparing thread concurrency on current trunk vs this patch, which I'll post next. * Reduced bytes used per-unique-term to be lower than current Lucene. This means the worst-case document (many terms, all of which are unique) should use less RAM overall than Lucene trunk does. * Added some new unit test cases; added missing "writer.close()" to one of the contrib tests. * Cleanup, comments, etc. I think the code is getting more "approachable" now. > improve how IndexWriter uses RAM to buffer added documents > -- > > Key: LUCENE-843 > URL: https://issues.apache.org/jira/browse/LUCENE-843 > Project: Lucene - Java > Issue Type: Improvement > Components: Index >Affects Versions: 2.2 >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Attachments: LUCENE-843.patch, LUCENE-843.take2.patch, > LUCENE-843.take3.patch, LUCENE-843.take4.patch, LUCENE-843.take5.patch, > LUCENE-843.take6.patch, LUCENE-843.take7.patch > > > I'm working on a new class (MultiDocumentWriter) that writes more than > one document directly into a single Lucene segment, more efficiently > than the current approach. > This only affects the creation of an initial segment from added > documents. I haven't changed anything after that, eg how segments are > merged. > The basic ideas are: > * Write stored fields and term vectors directly to disk (don't > use up RAM for these). > * Gather posting lists & term infos in RAM, but periodically do > in-RAM merges. Once RAM is full, flush buffers to disk (and > merge them later when it's time to make a real segment). > * Recycle objects/buffers to reduce time/stress in GC. > * Other various optimizations. > Some of these changes are similar to how KinoSearch builds a segment. > But, I haven't made any changes to Lucene's file format nor added > requirements for a global fields schema. > So far the only externally visible change is a new method > "setRAMBufferSize" in IndexWriter (and setMaxBufferedDocs is > deprecated) so that it flushes according to RAM usage and not a fixed > number documents added. -- 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] Closed: (LUCENE-928) field level search
[ https://issues.apache.org/jira/browse/LUCENE-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll closed LUCENE-928. -- Resolution: Invalid Lucene Fields: (was: [New]) Please ask questions on the java-user mailing list (http://lucene.apache.org/java/docs/mailinglists.html). JIRA is reserved for bugs, enhancements, etc. > field level search > -- > > Key: LUCENE-928 > URL: https://issues.apache.org/jira/browse/LUCENE-928 > Project: Lucene - Java > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Sagar Patil >Priority: Minor > > right now there is field level search avilable. But if we dont want to search > on field but on the whole document then to the query parse the whole contet > is to be passed. If we append the titles (captions) to say index > content(which is having all the captions) for every caption indexcontent is > created. to avoid the index content so for a query without the "field:quey" > how is it possible and what to pass to the query analyser as a input so it > searches on teh whole document. -- 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] Created: (LUCENE-929) contrib/benchmark build doesn't handle checking if content is properly extracted
contrib/benchmark build doesn't handle checking if content is properly extracted Key: LUCENE-929 URL: https://issues.apache.org/jira/browse/LUCENE-929 Project: Lucene - Java Issue Type: Bug Components: contrib/benchmark Reporter: Grant Ingersoll Priority: Minor The contrib/benchmark build does not properly handle checking to see if the content (such as Reuters coll.) is properly extracted. It only checks to see if the directory exists. Thus, it is possible that the directory gets created and the extraction fails. Then, the next time it is run, it skips the extraction part and tries to continue on running the benchmark. The workaround is to manually delete the extraction directory. -- 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] Created: (LUCENE-928) field level search
field level search -- Key: LUCENE-928 URL: https://issues.apache.org/jira/browse/LUCENE-928 Project: Lucene - Java Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Sagar Patil Priority: Minor right now there is field level search avilable. But if we dont want to search on field but on the whole document then to the query parse the whole contet is to be passed. If we append the titles (captions) to say index content(which is having all the captions) for every caption indexcontent is created. to avoid the index content so for a query without the "field:quey" how is it possible and what to pass to the query analyser as a input so it searches on teh whole document. -- 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] Issue Comment Edited: (LUCENE-902) Check on PositionIncrement with StopFilter.
[ https://issues.apache.org/jira/browse/LUCENE-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502731 ] Toru Matsuzawa edited comment on LUCENE-902 at 6/8/07 2:14 AM: --- Hi Hoss, Thank you your comments. > 1) in future patches, could you please use 2 spaces instead of tabs? It consented. > 2) am i understanding correctly that the primary use case you are trying to > address is > stop word removal when the stop word has synonyms with a position increment > of 0 > (the expectation being that the synonyms also be removed) ? Your understanding is correct. However, a synonym itself might be a stop word. > ... if so, wouldn't the most efficient thing be to do stop word removal > before doing > synonym expansion? (it means having a bigger stop word list - with all the > synonyms - > but that still seems better to me) ... are there other use cases i'm not > understanding? ... > i freely admit i don't understand the "Japanese morphological analysis" > comment. It is not realistic to have a stop word list with all the synonyms because the morphological engine must understand all the dictionaries to make that list. (The engine analyzes texts with such dictionaries.) > 3) i only glanced over the specifics of removeStopwordCollocatesNext() .. > but would promoting BufferedTokenStream from Solr simplify the code > (it seems to all be about buffering tokens) ... http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/analysis/BufferedTokenStream.java?view=markup I think that it becomes more concise if BufferedTokenStream can be used. > 4) it would be useful if the test case could clarify not only the expected > tokens text > concatenated together, but also what the expected positions of position > increments are > for the tokens... i was certainly confused by the title of this issue. I agree with you. It would be better to compare them with expected tokens. I'm sorry to confuse you with my poor English. was: Hi Hoss, Than you your comments. > 1) in future patches, could you please use 2 spaces instead of tabs? It consented. > 2) am i understanding correctly that the primary use case you are trying to > address is > stop word removal when the stop word has synonyms with a position increment > of 0 > (the expectation being that the synonyms also be removed) ? Your understanding is correct. However, a synonym itself might be a stop word. > ... if so, wouldn't the most efficient thing be to do stop word removal > before doing > synonym expansion? (it means having a bigger stop word list - with all the > synonyms - > but that still seems better to me) ... are there other use cases i'm not > understanding? ... > i freely admit i don't understand the "Japanese morphological analysis" > comment. It is not realistic to have a stop word list with all the synonyms because the morphological engine must understand all the dictionaries to make that list. (The engine analyzes texts with such dictionaries.) > 3) i only glanced over the specifics of removeStopwordCollocatesNext() .. > but would promoting BufferedTokenStream from Solr simplify the code > (it seems to all be about buffering tokens) ... http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/analysis/BufferedTokenStream.java?view=markup I think that it becomes more concise if BufferedTokenStream can be used. > 4) it would be useful if the test case could clarify not only the expected > tokens text > concatenated together, but also what the expected positions of position > increments are > for the tokens... i was certainly confused by the title of this issue. I agree with you. It would be better to compare them with expected tokens. I'm sorry to confuse you with my poor English. > Check on PositionIncrement with StopFilter. > > > Key: LUCENE-902 > URL: https://issues.apache.org/jira/browse/LUCENE-902 > Project: Lucene - Java > Issue Type: Bug > Components: Analysis >Affects Versions: 2.2 >Reporter: Toru Matsuzawa > Attachments: stopfilter.patch, stopfilter20070604.patch, > stopfilter20070605.patch, stopfilter20070608.patch > > > PositionIncrement set with Tokenizer is not considered with StopFilter. > When PositionIncrement of Token is 1, it is deleted by StopFilter. However, > when PositionIncrement of Token following afterwards is 0, it is not deleted. > I think that it is necessary to be deleted. Because it is thought same Token > when PositionIncrement is 0. -- 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 P
[jira] Updated: (LUCENE-902) Check on PositionIncrement with StopFilter.
[ https://issues.apache.org/jira/browse/LUCENE-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toru Matsuzawa updated LUCENE-902: -- Attachment: stopfilter20070608.patch > Check on PositionIncrement with StopFilter. > > > Key: LUCENE-902 > URL: https://issues.apache.org/jira/browse/LUCENE-902 > Project: Lucene - Java > Issue Type: Bug > Components: Analysis >Affects Versions: 2.2 >Reporter: Toru Matsuzawa > Attachments: stopfilter.patch, stopfilter20070604.patch, > stopfilter20070605.patch, stopfilter20070608.patch > > > PositionIncrement set with Tokenizer is not considered with StopFilter. > When PositionIncrement of Token is 1, it is deleted by StopFilter. However, > when PositionIncrement of Token following afterwards is 0, it is not deleted. > I think that it is necessary to be deleted. Because it is thought same Token > when PositionIncrement is 0. -- 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-902) Check on PositionIncrement with StopFilter.
[ https://issues.apache.org/jira/browse/LUCENE-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502731 ] Toru Matsuzawa commented on LUCENE-902: --- Hi Hoss, Than you your comments. > 1) in future patches, could you please use 2 spaces instead of tabs? It consented. > 2) am i understanding correctly that the primary use case you are trying to > address is > stop word removal when the stop word has synonyms with a position increment > of 0 > (the expectation being that the synonyms also be removed) ? Your understanding is correct. However, a synonym itself might be a stop word. > ... if so, wouldn't the most efficient thing be to do stop word removal > before doing > synonym expansion? (it means having a bigger stop word list - with all the > synonyms - > but that still seems better to me) ... are there other use cases i'm not > understanding? ... > i freely admit i don't understand the "Japanese morphological analysis" > comment. It is not realistic to have a stop word list with all the synonyms because the morphological engine must understand all the dictionaries to make that list. (The engine analyzes texts with such dictionaries.) > 3) i only glanced over the specifics of removeStopwordCollocatesNext() .. > but would promoting BufferedTokenStream from Solr simplify the code > (it seems to all be about buffering tokens) ... http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/analysis/BufferedTokenStream.java?view=markup I think that it becomes more concise if BufferedTokenStream can be used. > 4) it would be useful if the test case could clarify not only the expected > tokens text > concatenated together, but also what the expected positions of position > increments are > for the tokens... i was certainly confused by the title of this issue. I agree with you. It would be better to compare them with expected tokens. I'm sorry to confuse you with my poor English. > Check on PositionIncrement with StopFilter. > > > Key: LUCENE-902 > URL: https://issues.apache.org/jira/browse/LUCENE-902 > Project: Lucene - Java > Issue Type: Bug > Components: Analysis >Affects Versions: 2.2 >Reporter: Toru Matsuzawa > Attachments: stopfilter.patch, stopfilter20070604.patch, > stopfilter20070605.patch > > > PositionIncrement set with Tokenizer is not considered with StopFilter. > When PositionIncrement of Token is 1, it is deleted by StopFilter. However, > when PositionIncrement of Token following afterwards is 0, it is not deleted. > I think that it is necessary to be deleted. Because it is thought same Token > when PositionIncrement is 0. -- 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: Please help testing the release files
Grant Ingersoll wrote: As for the binary distributions, they are pretty much worthless unless you have some way of knowing what the dependencies are, right? We could add README.txt files to the contrib directories and package them together with the jars in the binary distribution? The readmes should list the dependencies and where to get them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (LUCENE-924) IndexWriter has incomplete Javadocs
[ https://issues.apache.org/jira/browse/LUCENE-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-924: - Assignee: Michael McCandless > IndexWriter has incomplete Javadocs > --- > > Key: LUCENE-924 > URL: https://issues.apache.org/jira/browse/LUCENE-924 > Project: Lucene - Java > Issue Type: Wish > Components: Javadocs >Reporter: Michael Busch >Assignee: Michael McCandless >Priority: Trivial > Fix For: 2.2 > > > A couple of getter methods in IndexWriter have no javadocs. -- 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-924) IndexWriter has incomplete Javadocs
[ https://issues.apache.org/jira/browse/LUCENE-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502710 ] Michael McCandless commented on LUCENE-924: --- I can take this one. > IndexWriter has incomplete Javadocs > --- > > Key: LUCENE-924 > URL: https://issues.apache.org/jira/browse/LUCENE-924 > Project: Lucene - Java > Issue Type: Wish > Components: Javadocs >Reporter: Michael Busch >Assignee: Michael McCandless >Priority: Trivial > Fix For: 2.2 > > > A couple of getter methods in IndexWriter have no javadocs. -- 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-914) Scorer.skipTo(current) remains on current for some scorers
[ https://issues.apache.org/jira/browse/LUCENE-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502705 ] Paul Elschot commented on LUCENE-914: - I've been struggling with this before at LUCENE-413 . I think the Scorer.skipTo() contract is geared towards TermScorer.skipTo(target), and rightly so, because that is where it is all done in the end, and the current fast implementation should remain possible. I like the idea to further restrict the spec to say that n *must* be > doc() for defined results, but that should also take into account that doc() is not defined initially. An initial doc() == -1 nicely fits here, too. There are some scorers that could have simplified firstTime logic when doc() always return -1 initially, and iirc Yonik had/has ideas about that, but I can't find these back right now. > Scorer.skipTo(current) remains on current for some scorers > -- > > Key: LUCENE-914 > URL: https://issues.apache.org/jira/browse/LUCENE-914 > Project: Lucene - Java > Issue Type: Bug > Components: Search >Reporter: Doron Cohen >Priority: Minor > Attachments: lucene-914.patch > > > Background in http://www.nabble.com/scorer.skipTo%28%29-contr-tf3880986.html > It appears that several scorers do not strictly follow the spec of > Scorer.skipTo(n), and skip to current location remain in current location > whereas the spec says: "beyond current". > We should (probably) either relax the spec or fix the implementations. -- 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-912) DisjunctionMaxScorer.skipTo has bug that keeps it from skipping
[ https://issues.apache.org/jira/browse/LUCENE-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502704 ] Paul Elschot commented on LUCENE-912: - > > I'm not sure, but the patch allows to increment all generators right after > > the first time, and that might cause it to make a mistake in the score > > computation for its first doc. This is from code inspection only, I have no test cases showing wrong behaviour: What I meant is that during DisjunctionMaxScorer.next() initially the subscorers have next() called on them, so they are at their first docs, and then during next() (with the return statement deleted) the "generators are incremented again" even when at firstTime. That means that the score() might be computed on the wrong subscorer docs after the first call to next(). But this issue is about DisjunctionMaxScorer.skipTo(), and removing the firstTime return statement there is correct I think. > DisjunctionMaxScorer.skipTo has bug that keeps it from skipping > --- > > Key: LUCENE-912 > URL: https://issues.apache.org/jira/browse/LUCENE-912 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 2.0.0, 2.1 >Reporter: Hoss Man >Assignee: Doron Cohen > Fix For: 2.2 > > Attachments: checkTwoCallsToScore.patch, checkTwoCallsToScore.patch, > dismax_skipto.patch, lucene-912.patch > > > as reported on the mailing list, DisjunctionMaxScorer.skipTo is broken if > called before next in some situations... > http://www.nabble.com/Potential-issue-with-DisjunctionMaxScorer-tf3846366.html#a10894987 -- 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]
