[jira] Commented: (LUCENE-2252) stored field retrieve slow

[ https://issues.apache.org/jira/browse/LUCENE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830689#action_12830689 ] Michael McCandless commented on LUCENE-2252: bq. The very simple store mechani

lucene build test failed

i have checked out revision 907418 ant test fails with download-snowball-vocab-tests: [exec] svn: invalid option: --trust-server-cert [exec] Type 'svn help' for usage. BUILD FAILED build.xml:47 what version of svn do you use -- Rohit Banga

Re: lucene build test failed

You SVN version is too old. you need subversion >= 1.6 If you run ubuntu this is a problem but there are upgrade guides around... try gooogle... simon On Sun, Feb 7, 2010 at 1:38 PM, Rohit Banga wrote: > i have checked out revision 907418 > > ant test fails with > > download-snowball-vocab-test

Re: lucene build test failed

it works thanks! On Sun, Feb 7, 2010 at 6:09 PM, Simon Willnauer < [email protected]> wrote: > You SVN version is too old. you need subversion >= 1.6 > > If you run ubuntu this is a problem but there are upgrade guides > around... try gooogle... > > simon > > On Sun, Feb 7, 2010 at 1

[jira] Created: (LUCENE-2253) Lucene 3.0 - Deprecated QueryParser Constructor in Demo Code [new QueryParser( "contents", analyzer)]

Lucene 3.0 - Deprecated QueryParser Constructor in Demo Code [new QueryParser( "contents", analyzer)] - Key: LUCENE-2253 URL: https://issues.apache.org/jira/browse

[jira] Resolved: (LUCENE-2253) Lucene 3.0 - Deprecated QueryParser Constructor in Demo Code [new QueryParser( "contents", analyzer)]

[ https://issues.apache.org/jira/browse/LUCENE-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-2253. - Resolution: Duplicate duplicate of LUCENE-2132, fixed there in both trunk and 3.0 branch. > Luc

[jira] Updated: (LUCENE-2253) Lucene 3.0 - Deprecated QueryParser Constructor in Demo Code [new QueryParser( "contents", analyzer)]

[ https://issues.apache.org/jira/browse/LUCENE-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-2253: Component/s: Examples Priority: Trivial (was: Major) Issue Type: Task (was: B

Release Lucene Java 2.9.2 & 3.0.(1|2) together soon

Hallo all, I think it is ready to start the release process of 3.0.(1|2) and 2.9.2 soon. Before building the artifacts I would compare the changelogs and try to merge them to get a similar bugfix level for both versions. I would like to release both versions on the same day with the same releas

Re: Release Lucene Java 2.9.2 & 3.0.(1|2) together soon

+1 to release. Thank you for volunteering :) We've got a number of good bug fixes pending... But: I think we should simply name it 3.0.1? If we skip 3.0.1 I think it will cause confusion? We can state in the CHANGES that 2.9.2 has same bug fixes as 3.0.1 and vice/versa? Mike On Sun, Feb 7, 2

Re: Release Lucene Java 2.9.2 & 3.0.(1|2) together soon

On Sun, Feb 7, 2010 at 2:45 PM, Michael McCandless wrote: > +1 to release.  Thank you for volunteering :)  We've got a number of > good bug fixes pending... +1 I already know a couple of people looking forward to this releases! > > But: I think we should simply name it 3.0.1?  If we skip 3.0.1 I t

Hudson build is back to normal : Lucene-trunk #1086

See - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]

Having a default constructor in Analyzers

Hello, I've seen that some core Analyzers are now missing a default constructor; this is preventing many applications to configure/load Analyzers by reflection, which is a common use case to have Analyzers chosen in configuration files. Would it be possible to add, for example, a constructor like

Re: Having a default constructor in Analyzers

Almost no Analyzer has a default ctor anymore due to the introduction of Version. This should not be an issue for API users loading Analyzers per reflection. You can still call the version Ctor alternatively. Providing a default ctor with the current version could be very risky in many regards, a b

RE: Having a default constructor in Analyzers

Hi Sanne, Exactly that usage we want to prevent. Using Version.LUCENE_CURRENT is the badest thing you can do if you want to later update your Lucene version and do not want to reindex all your indexes (see javadocs). It is easy to modify your application to create analyzers even from config fi

RE: Having a default constructor in Analyzers

Hi Sanne, This is example code used e.g. in my applications. This method allows you to create an analyzer via reflection for both cases: default ctor or with version: final Analyzer createAnalyzer(String className, Version matchVersion) throws Exception { final Class clazz = Class.forNam

Re: Having a default constructor in Analyzers

I propose we remove LUCENE_CURRENT completely, as soon as TEST_VERSION is done. On Sun, Feb 7, 2010 at 12:53 PM, Uwe Schindler wrote: > Hi Sanne, > > Exactly that usage we want to prevent. Using Version.LUCENE_CURRENT is the > badest thing you can do if you want to later update your Lucene versi

[jira] Reopened: (LUCENE-2080) Improve the documentation of Version

[ https://issues.apache.org/jira/browse/LUCENE-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir reopened LUCENE-2080: - It seems that LUCENE_CURRENT is still causing some confusion. I am reopening this issue and propose

Re: Having a default constructor in Analyzers

Thanks for all the quick answers; finding the ctor having only a Version parameter is fine for me, I had noticed this "frequent pattern" but didn't understand that was a general rule. So can I assume this is an implicit contract for all Analyzers, to have either an empty ctor or a single-parameter

[jira] Updated: (LUCENE-2080) Improve the documentation of Version

[ https://issues.apache.org/jira/browse/LUCENE-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-2080: Attachment: LUCENE-2080.patch attached is a patch that deprecates LUCENE_CURRENT, adds some scarie

Re: Having a default constructor in Analyzers

ok, I think you have a valid case for using this for testing. We just have to be careful about wording and such, because i think right now we encourage users to use this constant. I created a patch to make it scary and deprecated under LUCENE-2080, we don't have to remove the constant just keep it

Re: Having a default constructor in Analyzers

Sanne, I would recommend you building a Factory pattern around you Analyzers / TokenStreams similar to what solr does. That way you can load you own "default ctor" interface via reflection and obtain you analyzers from those factories. That makes more sense anyway as you only load the factory via r

Re: Having a default constructor in Analyzers

Simon, can you explain how removing CURRENT makes it harder for users to upgrade? If you mean for the case of people that always re-index all documents when upgrading lucene jar, then this makes sense to me. I guess as a step we can at least deprecate this thing and strongly discourage its use, pl

Re: Having a default constructor in Analyzers

On Sun, Feb 7, 2010 at 8:38 PM, Robert Muir wrote: > Simon, can you explain how removing CURRENT makes it harder for users to > upgrade? If you mean for the case of people that always re-index all > documents when upgrading lucene jar, then this makes sense to me. That is what I was alluding to! N

[jira] Updated: (LUCENE-2080) Improve the documentation of Version

[ https://issues.apache.org/jira/browse/LUCENE-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-2080: Attachment: LUCENE-2080.patch I think this wording is even better and scarier: * i bolded *re-inde

[jira] Commented: (LUCENE-2080) Improve the documentation of Version

[ https://issues.apache.org/jira/browse/LUCENE-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830760#action_12830760 ] Simon Willnauer commented on LUCENE-2080: - I like this extension and I think it i

Re: Having a default constructor in Analyzers

Does it make sense to use different values across the same application? Obviously in the unlikely case you want to threat different indexes in a different way, but does it make sense when working all on the same index? If not, why not introduce a value like "Version.BY_ENVIRONMENT" which is statica

Re: Having a default constructor in Analyzers

On Feb 7, 2010, at 5:32 PM, Sanne Grinovero wrote: > Does it make sense to use different values across the same > application? Obviously in the unlikely case you want to threat > different indexes in a different way, but does it make sense when > working all on the same index? I think it entirel

Re: Having a default constructor in Analyzers

> > Also, wouldn't it make sense to be able to read the recommended > > version from the Index? > > Absolutely! > > how would this work when the Query analyzer differs from the Index analyzer? For example, using commongrams in solr means you use a different Query analyzer from Index analyzer, and t

Re: Having a default constructor in Analyzers

DM Smith: > Imagine that each index maintains a manifest of the toolchain for the index, > which includes the version of each part of the chain. Since the index is > created all at once, this probably is the same as the version of lucene. > When the user searches the index the manifest is consulte

[jira] Commented: (LUCENE-2080) Improve the documentation of Version

[ https://issues.apache.org/jira/browse/LUCENE-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830804#action_12830804 ] Michael McCandless commented on LUCENE-2080: I like the new scary javadoc Robe

[jira] Commented: (LUCENE-2080) Improve the documentation of Version

[ https://issues.apache.org/jira/browse/LUCENE-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830807#action_12830807 ] Robert Muir commented on LUCENE-2080: - I was thinking... this wording could be more co