You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Michael McCandless (JIRA)" <ji...@apache.org> on 2007/01/13 11:52:27 UTC
[jira] Created: (LUCENE-773) Deprecate "create" method in
FSDirectory.getDirectory in favor of IndexWriter's "create"
Deprecate "create" method in FSDirectory.getDirectory in favor of IndexWriter's "create"
----------------------------------------------------------------------------------------
Key: LUCENE-773
URL: https://issues.apache.org/jira/browse/LUCENE-773
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 2.0.0, 1.9, 2.0.1, 2.1
Reporter: Michael McCandless
Assigned To: Michael McCandless
Priority: Minor
It's confusing that there is a create=true|false at the FSDirectory
level and then also another create=true|false at the IndexWriter
level. Which one should you use when creating an index?
Our users have been confused by this in the past:
http://www.gossamer-threads.com/lists/lucene/java-user/4792
I think in general we should try to have one obvious way to achieve
something (like Python: http://en.wikipedia.org/wiki/Python_philosophy).
And the fact that there are now two code paths that are supposed to do
the same (similar?) thing, can more easily lead to sneaky bugs. One
case of LUCENE-140 (already fixed in trunk but not past releases),
which inspired this issue, can happen if you send create=false to the
FSDirectory and create=true to the IndexWriter.
Finally, as of lockless commits, it is now possible to open an
existing index for "create" while readers are still using the old
"point in time" index, on Windows. (At least one user had tried this
previously and failed). To do this, we use the IndexFileDeleter class
(which retries on failure) and we also look at the segments file to
determine the next segments_N file to write to.
With future issues like LUCENE-710 even more "smarts" may be required
to know what it takes to "create" a new index into an existing
directory. Given that we have have quite a few Directory
implemenations, I think these "smarts" logically should live in
IndexWriter (not replicated in each Directory implementation), and we
should leave the Directory as an interface that knows how to make
changes to some backing store but does not itself try to make any
changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-773) Deprecate "create" method in
FSDirectory.getDirectory in favor of IndexWriter's "create"
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464590 ]
Michael McCandless commented on LUCENE-773:
-------------------------------------------
Nicolas, I think you meant LUCENE-662 above?
But I'll take the +1 :)
> Deprecate "create" method in FSDirectory.getDirectory in favor of IndexWriter's "create"
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-773
> URL: https://issues.apache.org/jira/browse/LUCENE-773
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 1.9, 2.0.0, 2.0.1, 2.1
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
>
> It's confusing that there is a create=true|false at the FSDirectory
> level and then also another create=true|false at the IndexWriter
> level. Which one should you use when creating an index?
> Our users have been confused by this in the past:
> http://www.gossamer-threads.com/lists/lucene/java-user/4792
> I think in general we should try to have one obvious way to achieve
> something (like Python: http://en.wikipedia.org/wiki/Python_philosophy).
> And the fact that there are now two code paths that are supposed to do
> the same (similar?) thing, can more easily lead to sneaky bugs. One
> case of LUCENE-140 (already fixed in trunk but not past releases),
> which inspired this issue, can happen if you send create=false to the
> FSDirectory and create=true to the IndexWriter.
> Finally, as of lockless commits, it is now possible to open an
> existing index for "create" while readers are still using the old
> "point in time" index, on Windows. (At least one user had tried this
> previously and failed). To do this, we use the IndexFileDeleter class
> (which retries on failure) and we also look at the segments file to
> determine the next segments_N file to write to.
> With future issues like LUCENE-710 even more "smarts" may be required
> to know what it takes to "create" a new index into an existing
> directory. Given that we have have quite a few Directory
> implemenations, I think these "smarts" logically should live in
> IndexWriter (not replicated in each Directory implementation), and we
> should leave the Directory as an interface that knows how to make
> changes to some backing store but does not itself try to make any
> changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-773) Deprecate "create" method in
FSDirectory.getDirectory in favor of IndexWriter's "create"
Posted by "Nicolas Lalevée (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464608 ]
Nicolas Lalevée commented on LUCENE-773:
----------------------------------------
ho, yeah, it's the 662 of course, my eyes might have squited. :) (and it can't be the 622 as I am definitively not a maven user ^^)
> Deprecate "create" method in FSDirectory.getDirectory in favor of IndexWriter's "create"
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-773
> URL: https://issues.apache.org/jira/browse/LUCENE-773
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 1.9, 2.0.0, 2.0.1, 2.1
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
>
> It's confusing that there is a create=true|false at the FSDirectory
> level and then also another create=true|false at the IndexWriter
> level. Which one should you use when creating an index?
> Our users have been confused by this in the past:
> http://www.gossamer-threads.com/lists/lucene/java-user/4792
> I think in general we should try to have one obvious way to achieve
> something (like Python: http://en.wikipedia.org/wiki/Python_philosophy).
> And the fact that there are now two code paths that are supposed to do
> the same (similar?) thing, can more easily lead to sneaky bugs. One
> case of LUCENE-140 (already fixed in trunk but not past releases),
> which inspired this issue, can happen if you send create=false to the
> FSDirectory and create=true to the IndexWriter.
> Finally, as of lockless commits, it is now possible to open an
> existing index for "create" while readers are still using the old
> "point in time" index, on Windows. (At least one user had tried this
> previously and failed). To do this, we use the IndexFileDeleter class
> (which retries on failure) and we also look at the segments file to
> determine the next segments_N file to write to.
> With future issues like LUCENE-710 even more "smarts" may be required
> to know what it takes to "create" a new index into an existing
> directory. Given that we have have quite a few Directory
> implemenations, I think these "smarts" logically should live in
> IndexWriter (not replicated in each Directory implementation), and we
> should leave the Directory as an interface that knows how to make
> changes to some backing store but does not itself try to make any
> changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-773) Deprecate "create" method in
FSDirectory.getDirectory in favor of IndexWriter's "create"
Posted by "Nicolas Lalevée (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464586 ]
Nicolas Lalevée commented on LUCENE-773:
----------------------------------------
I was working on the IndexFormat mechanism, LUCENE-622 being the first draft of it. And I have tried to use some Java-1.5 parametered types to see if it is possible to make index readers/writers typed by the index format. And I am in front of one issue : the directory have to know the index format because of the IndexNameFilter and the create feature. And I don't think it is a good idea because of how they are instanciated.
I have not finished the design of this Java-1.5-way-of-typing, I have other issues to look at, but I vote +1 for removing any index structure specificity in the store package.
> Deprecate "create" method in FSDirectory.getDirectory in favor of IndexWriter's "create"
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-773
> URL: https://issues.apache.org/jira/browse/LUCENE-773
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 1.9, 2.0.0, 2.0.1, 2.1
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
>
> It's confusing that there is a create=true|false at the FSDirectory
> level and then also another create=true|false at the IndexWriter
> level. Which one should you use when creating an index?
> Our users have been confused by this in the past:
> http://www.gossamer-threads.com/lists/lucene/java-user/4792
> I think in general we should try to have one obvious way to achieve
> something (like Python: http://en.wikipedia.org/wiki/Python_philosophy).
> And the fact that there are now two code paths that are supposed to do
> the same (similar?) thing, can more easily lead to sneaky bugs. One
> case of LUCENE-140 (already fixed in trunk but not past releases),
> which inspired this issue, can happen if you send create=false to the
> FSDirectory and create=true to the IndexWriter.
> Finally, as of lockless commits, it is now possible to open an
> existing index for "create" while readers are still using the old
> "point in time" index, on Windows. (At least one user had tried this
> previously and failed). To do this, we use the IndexFileDeleter class
> (which retries on failure) and we also look at the segments file to
> determine the next segments_N file to write to.
> With future issues like LUCENE-710 even more "smarts" may be required
> to know what it takes to "create" a new index into an existing
> directory. Given that we have have quite a few Directory
> implemenations, I think these "smarts" logically should live in
> IndexWriter (not replicated in each Directory implementation), and we
> should leave the Directory as an interface that knows how to make
> changes to some backing store but does not itself try to make any
> changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-773) Deprecate "create" method in
FSDirectory.getDirectory in favor of IndexWriter's "create"
Posted by "Nicolas Lalevée (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464588 ]
Nicolas Lalevée commented on LUCENE-773:
----------------------------------------
forget what I have said about "removing any index structure specificity in the store package.". Actually, the directory is the only central instance that can holds an indexformat instance.
Anyway, I still +1 for not duplicating code ! :)
> Deprecate "create" method in FSDirectory.getDirectory in favor of IndexWriter's "create"
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-773
> URL: https://issues.apache.org/jira/browse/LUCENE-773
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 1.9, 2.0.0, 2.0.1, 2.1
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
>
> It's confusing that there is a create=true|false at the FSDirectory
> level and then also another create=true|false at the IndexWriter
> level. Which one should you use when creating an index?
> Our users have been confused by this in the past:
> http://www.gossamer-threads.com/lists/lucene/java-user/4792
> I think in general we should try to have one obvious way to achieve
> something (like Python: http://en.wikipedia.org/wiki/Python_philosophy).
> And the fact that there are now two code paths that are supposed to do
> the same (similar?) thing, can more easily lead to sneaky bugs. One
> case of LUCENE-140 (already fixed in trunk but not past releases),
> which inspired this issue, can happen if you send create=false to the
> FSDirectory and create=true to the IndexWriter.
> Finally, as of lockless commits, it is now possible to open an
> existing index for "create" while readers are still using the old
> "point in time" index, on Windows. (At least one user had tried this
> previously and failed). To do this, we use the IndexFileDeleter class
> (which retries on failure) and we also look at the segments file to
> determine the next segments_N file to write to.
> With future issues like LUCENE-710 even more "smarts" may be required
> to know what it takes to "create" a new index into an existing
> directory. Given that we have have quite a few Directory
> implemenations, I think these "smarts" logically should live in
> IndexWriter (not replicated in each Directory implementation), and we
> should leave the Directory as an interface that knows how to make
> changes to some backing store but does not itself try to make any
> changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Resolved: (LUCENE-773) Deprecate "create" method in
FSDirectory.getDirectory in favor of IndexWriter's "create"
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless resolved LUCENE-773.
---------------------------------------
Resolution: Fixed
OK I committed this:
* Added removal of old write lock in IndexWriter's create (it
already removes unreferenced files).
* Deprecated FSDirectory.getDirectory constructors that take a
boolean create.
* Verified all unit tests still pass while using deprecated create.
* Fixed all but one unit test to no longer use the now-deprecated
constructors (I left one to make sure we do in fact continue to
test the deprecated getDirectory constructor). I added an "rmDir"
utility method in a new class o/a/l/util/_TestUtil.java for those
tests that were using getDirectory to just remove a directory.
* Removed FSDirectory.getDirectory methods that had "create" that we
had added with LockFactory. These methods were never released so
no sense newly releasing deprecated APIs.
> Deprecate "create" method in FSDirectory.getDirectory in favor of IndexWriter's "create"
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-773
> URL: https://issues.apache.org/jira/browse/LUCENE-773
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 1.9, 2.0.0, 2.0.1, 2.1
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
> Fix For: 2.1
>
>
> It's confusing that there is a create=true|false at the FSDirectory
> level and then also another create=true|false at the IndexWriter
> level. Which one should you use when creating an index?
> Our users have been confused by this in the past:
> http://www.gossamer-threads.com/lists/lucene/java-user/4792
> I think in general we should try to have one obvious way to achieve
> something (like Python: http://en.wikipedia.org/wiki/Python_philosophy).
> And the fact that there are now two code paths that are supposed to do
> the same (similar?) thing, can more easily lead to sneaky bugs. One
> case of LUCENE-140 (already fixed in trunk but not past releases),
> which inspired this issue, can happen if you send create=false to the
> FSDirectory and create=true to the IndexWriter.
> Finally, as of lockless commits, it is now possible to open an
> existing index for "create" while readers are still using the old
> "point in time" index, on Windows. (At least one user had tried this
> previously and failed). To do this, we use the IndexFileDeleter class
> (which retries on failure) and we also look at the segments file to
> determine the next segments_N file to write to.
> With future issues like LUCENE-710 even more "smarts" may be required
> to know what it takes to "create" a new index into an existing
> directory. Given that we have have quite a few Directory
> implemenations, I think these "smarts" logically should live in
> IndexWriter (not replicated in each Directory implementation), and we
> should leave the Directory as an interface that knows how to make
> changes to some backing store but does not itself try to make any
> changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Reopened: (LUCENE-773) Deprecate "create" method in
FSDirectory.getDirectory in favor of IndexWriter's "create"
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless reopened LUCENE-773:
---------------------------------------
My fix here broke one case of backwards compatibility for Directory implementations that provide their own locking implementation (ie, that do not use Lockfactory). See here:
http://www.gossamer-threads.com/lists/lucene/java-dev/44555
> Deprecate "create" method in FSDirectory.getDirectory in favor of IndexWriter's "create"
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-773
> URL: https://issues.apache.org/jira/browse/LUCENE-773
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 1.9, 2.0.0, 2.0.1, 2.1
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
> Fix For: 2.1
>
>
> It's confusing that there is a create=true|false at the FSDirectory
> level and then also another create=true|false at the IndexWriter
> level. Which one should you use when creating an index?
> Our users have been confused by this in the past:
> http://www.gossamer-threads.com/lists/lucene/java-user/4792
> I think in general we should try to have one obvious way to achieve
> something (like Python: http://en.wikipedia.org/wiki/Python_philosophy).
> And the fact that there are now two code paths that are supposed to do
> the same (similar?) thing, can more easily lead to sneaky bugs. One
> case of LUCENE-140 (already fixed in trunk but not past releases),
> which inspired this issue, can happen if you send create=false to the
> FSDirectory and create=true to the IndexWriter.
> Finally, as of lockless commits, it is now possible to open an
> existing index for "create" while readers are still using the old
> "point in time" index, on Windows. (At least one user had tried this
> previously and failed). To do this, we use the IndexFileDeleter class
> (which retries on failure) and we also look at the segments file to
> determine the next segments_N file to write to.
> With future issues like LUCENE-710 even more "smarts" may be required
> to know what it takes to "create" a new index into an existing
> directory. Given that we have have quite a few Directory
> implemenations, I think these "smarts" logically should live in
> IndexWriter (not replicated in each Directory implementation), and we
> should leave the Directory as an interface that knows how to make
> changes to some backing store but does not itself try to make any
> changes.
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Resolved: (LUCENE-773) Deprecate "create" method in
FSDirectory.getDirectory in favor of IndexWriter's "create"
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless resolved LUCENE-773.
---------------------------------------
Resolution: Fixed
OK I added a unit test that hits the NPE, and corrected it so the test
now passes.
Sorry about this and thanks for catching it Aaron!
> Deprecate "create" method in FSDirectory.getDirectory in favor of IndexWriter's "create"
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-773
> URL: https://issues.apache.org/jira/browse/LUCENE-773
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 1.9, 2.0.0, 2.0.1, 2.1
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
> Fix For: 2.1
>
>
> It's confusing that there is a create=true|false at the FSDirectory
> level and then also another create=true|false at the IndexWriter
> level. Which one should you use when creating an index?
> Our users have been confused by this in the past:
> http://www.gossamer-threads.com/lists/lucene/java-user/4792
> I think in general we should try to have one obvious way to achieve
> something (like Python: http://en.wikipedia.org/wiki/Python_philosophy).
> And the fact that there are now two code paths that are supposed to do
> the same (similar?) thing, can more easily lead to sneaky bugs. One
> case of LUCENE-140 (already fixed in trunk but not past releases),
> which inspired this issue, can happen if you send create=false to the
> FSDirectory and create=true to the IndexWriter.
> Finally, as of lockless commits, it is now possible to open an
> existing index for "create" while readers are still using the old
> "point in time" index, on Windows. (At least one user had tried this
> previously and failed). To do this, we use the IndexFileDeleter class
> (which retries on failure) and we also look at the segments file to
> determine the next segments_N file to write to.
> With future issues like LUCENE-710 even more "smarts" may be required
> to know what it takes to "create" a new index into an existing
> directory. Given that we have have quite a few Directory
> implemenations, I think these "smarts" logically should live in
> IndexWriter (not replicated in each Directory implementation), and we
> should leave the Directory as an interface that knows how to make
> changes to some backing store but does not itself try to make any
> changes.
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-773) Deprecate "create" method in
FSDirectory.getDirectory in favor of IndexWriter's "create"
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless updated LUCENE-773:
--------------------------------------
Fix Version/s: 2.1
> Deprecate "create" method in FSDirectory.getDirectory in favor of IndexWriter's "create"
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-773
> URL: https://issues.apache.org/jira/browse/LUCENE-773
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 1.9, 2.0.0, 2.0.1, 2.1
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
> Fix For: 2.1
>
>
> It's confusing that there is a create=true|false at the FSDirectory
> level and then also another create=true|false at the IndexWriter
> level. Which one should you use when creating an index?
> Our users have been confused by this in the past:
> http://www.gossamer-threads.com/lists/lucene/java-user/4792
> I think in general we should try to have one obvious way to achieve
> something (like Python: http://en.wikipedia.org/wiki/Python_philosophy).
> And the fact that there are now two code paths that are supposed to do
> the same (similar?) thing, can more easily lead to sneaky bugs. One
> case of LUCENE-140 (already fixed in trunk but not past releases),
> which inspired this issue, can happen if you send create=false to the
> FSDirectory and create=true to the IndexWriter.
> Finally, as of lockless commits, it is now possible to open an
> existing index for "create" while readers are still using the old
> "point in time" index, on Windows. (At least one user had tried this
> previously and failed). To do this, we use the IndexFileDeleter class
> (which retries on failure) and we also look at the segments file to
> determine the next segments_N file to write to.
> With future issues like LUCENE-710 even more "smarts" may be required
> to know what it takes to "create" a new index into an existing
> directory. Given that we have have quite a few Directory
> implemenations, I think these "smarts" logically should live in
> IndexWriter (not replicated in each Directory implementation), and we
> should leave the Directory as an interface that knows how to make
> changes to some backing store but does not itself try to make any
> changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org