[jira] Commented: (LUCENE-2076) Add org.apache.lucene.store.FSDirectory.getDirectory()
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] Updated: (LUCENE-2076) Add org.apache.lucene.store.FSDirectory.getDirectory()
[ 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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2076) Add org.apache.lucene.store.FSDirectory.getDirectory()
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2076) Add org.apache.lucene.store.FSDirectory.getDirectory()
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-707) Lucene Java Site docs
[ https://issues.apache.org/jira/browse/LUCENE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Aroush updated LUCENE-707: - Attachment: lucene.apache.org.patch Hi Dough, Attached is a patch to add Lucene.Net to TLP of Lucene site. Thanks. -- George Aroush Lucene Java Site docs - Key: LUCENE-707 URL: https://issues.apache.org/jira/browse/LUCENE-707 Project: Lucene - Java Issue Type: Improvement Components: Website Environment: N/A Reporter: Grant Ingersoll Assigned To: Grant Ingersoll Priority: Minor Attachments: lucene.apache.org.patch It would be really nice if the Java site docs where consistent with the rest of the Lucene family (namely, with navigation tabs, etc.) so that one can easily go between Nutch, Hadoop, etc. -- 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-707) Lucene Java Site docs
[ https://issues.apache.org/jira/browse/LUCENE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461894 ] George Aroush commented on LUCENE-707: -- Hi, What will it take to fix the page at http://lucene.apache.org/ so that Lucene.Net is also on tab'ed-link? On the 22nd of Nov Otis pointed this out but I still don't see a mention of Lucene.Net. Since Lucene4c is a dead project now, replacing it with Lucene.Net is an appropriate thing to do (Lucene.Net can use some exposure.) The link to Lucene.Net is: http://incubator.apache.org/lucene.net/ Also, as a note, the project name is Lucene.Net and not Lucene.NET. Thanks! -- George Lucene Java Site docs - Key: LUCENE-707 URL: https://issues.apache.org/jira/browse/LUCENE-707 Project: Lucene - Java Issue Type: Improvement Components: Website Environment: N/A Reporter: Grant Ingersoll Assigned To: Grant Ingersoll Priority: Minor It would be really nice if the Java site docs where consistent with the rest of the Lucene family (namely, with navigation tabs, etc.) so that one can easily go between Nutch, Hadoop, etc. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-707) Lucene Java Site docs
[ https://issues.apache.org/jira/browse/LUCENE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461904 ] George Aroush commented on LUCENE-707: -- Thanks for the quick response Grant! Unfortunately, I am not familiar with forrest which is how I believe the patch must be generated. If I supply the required text changes, can someone take care of making the changes? If not, can someone point me to where I can learn about forrest? I believe Doug does have commit privilege. Regards, -- George Lucene Java Site docs - Key: LUCENE-707 URL: https://issues.apache.org/jira/browse/LUCENE-707 Project: Lucene - Java Issue Type: Improvement Components: Website Environment: N/A Reporter: Grant Ingersoll Assigned To: Grant Ingersoll Priority: Minor It would be really nice if the Java site docs where consistent with the rest of the Lucene family (namely, with navigation tabs, etc.) so that one can easily go between Nutch, Hadoop, etc. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
