[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
