You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "George Aroush (JIRA)" <ji...@apache.org> on 2009/11/17 02:55:39 UTC
[jira] Created: (LUCENE-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Add org.apache.lucene.store.FSDirectory.getDirectory()
------------------------------------------------------
Key: LUCENE-2076
URL: https://issues.apache.org/jira/browse/LUCENE-2076
Project: Lucene - Java
Issue Type: Wish
Components: Store
Affects Versions: 3.0
Reporter: George Aroush
Priority: Minor
Fix For: 3.0
On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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] Commented: (LUCENE-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "George Aroush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779101#action_12779101 ]
George Aroush commented on LUCENE-2076:
---------------------------------------
Mark's response is right on. I'm also fine with adding getDir(), but prefer to see getDirectory().
Uwe, the issue (and I just realized, I didn't clarify this in my original description of this issue) is with the way Java treats java.io.File objects, which can be a file or a directory. As I pointed in the description of this issue, for .NET, a file is managed using System.IO.FileInfo, and a directory is managed using System.IO.DirectoryInfo. Up to Lucene.Net 2.4.0, all ports were done such that we are using System.IO.FileInfo. This meant, internally, and even for public API's, we have to first make sure the object is a directory before using it.
With 2.9.1, anywhere we were using System.IO.FileInfo, we are now depreciating them in favor of using System.IO.DirectoryInfo. The one area where we could not do this is for org.apache.lucene.store.FSDirectory.getFile() this is because the issue is with the return type -- thus, we can't overload the method name.
This is why, in Lucene.Net, we added Lucene.Net.Store.FSDirectory.GetDirectory() and flaged Lucene.Net.Store.FSDirectory.GetFile() as depreciated. To keep the APIs consistent between Java and Lucene.Net, I'm requesting that Java Lucene add org.apache.lucene.store.FSDirectory.getDirectory().
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Priority: Minor
> Fix For: 3.1
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated LUCENE-2076:
----------------------------------
Fix Version/s: (was: 3.0)
3.1
I see no reason to duplicate this method, especially as Directory is a "reserved" word in Lucene, being the superclass of FSDirectory.
I do not undertand the whole issue, why not simply call getFile() ?
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Priority: Minor
> Fix For: 3.1
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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] Commented: (LUCENE-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "Mark Miller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779077#action_12779077 ]
Mark Miller commented on LUCENE-2076:
-------------------------------------
Perhaps getDir or something then? Not a fan of getFile either - its going to return a directory, and while I know a File can be either, getDir or getDirectory are more descriptive as to what you are getting. I don't even think getDirectory is a problem myself - it returns a File, so its pretty clear its not a Lucene Directory - we have an issue there no matter - a file system directory came around quite a bit before a Lucene Directory :)
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Priority: Minor
> Fix For: 3.1
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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] Commented: (LUCENE-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779395#action_12779395 ]
Michael McCandless commented on LUCENE-2076:
--------------------------------------------
bq. If Java Lucene does the same, can this be done for 3.0?
The problem is, we're trying hard to avoid new deprecations in 3.0. 2.9 was our chance to do deprecations. Can we do this for 3.1 instead?
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Priority: Minor
> Fix For: 3.1
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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] Commented: (LUCENE-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "George Aroush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779424#action_12779424 ]
George Aroush commented on LUCENE-2076:
---------------------------------------
Sure, 3.1 will do. Thanks guys!
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "George Aroush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
George Aroush updated LUCENE-2076:
----------------------------------
Attachment: FSDirectory.patch
Patch attached.
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Priority: Minor
> Fix For: 3.0
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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] Commented: (LUCENE-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779142#action_12779142 ]
Michael McCandless commented on LUCENE-2076:
--------------------------------------------
Shouldn't we deprecate getFile in the process? Ie we rename getFile -> getDirectory?
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Priority: Minor
> Fix For: 3.1
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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] Commented: (LUCENE-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "Mark Miller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779145#action_12779145 ]
Mark Miller commented on LUCENE-2076:
-------------------------------------
Yeah, I'd say so.
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Priority: Minor
> Fix For: 3.1
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless resolved LUCENE-2076.
----------------------------------------
Resolution: Fixed
Thanks George!
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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] Commented: (LUCENE-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779399#action_12779399 ]
Uwe Schindler commented on LUCENE-2076:
---------------------------------------
Because of that I moved this issue to 3.1. The RC phase of 3.0 started yesterday evening.
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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] Commented: (LUCENE-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "George Aroush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779261#action_12779261 ]
George Aroush commented on LUCENE-2076:
---------------------------------------
Under Lucene.Net 2.9.1, we have depreciated GetFIle, and added GetDirectory. If Java Lucene does the same, can this be done for 3.0?
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Priority: Minor
> Fix For: 3.1
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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] Assigned: (LUCENE-2076) Add
org.apache.lucene.store.FSDirectory.getDirectory()
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless reassigned LUCENE-2076:
------------------------------------------
Assignee: Michael McCandless
> Add org.apache.lucene.store.FSDirectory.getDirectory()
> ------------------------------------------------------
>
> Key: LUCENE-2076
> URL: https://issues.apache.org/jira/browse/LUCENE-2076
> Project: Lucene - Java
> Issue Type: Wish
> Components: Store
> Affects Versions: 3.0
> Reporter: George Aroush
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
> Attachments: FSDirectory.patch
>
>
> On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.
> One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.
> Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.
> Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.
--
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