This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Provide a method for acquiring a FileObject for another FileObject, and a relative path as discussed at: http://www.netbeans.org/servlets/BrowseList?listName=nbdev&by=thread&from=19026 So far module authors used methods FileSystem.find(...) and FileSystem.findResource(...) for this, but since now IDE filesystems are the machine filesystems (not explicitly mounted filesystems), these methods are much less useful now.
I just found the method that finds a relative path between two fileobjects duplicated in three places in the WebApps code. Would it be possible to reevaluate this request? I believe a method like this will be useful more generally. Also, I think this API: String findRelativePath(FileObject rootFolder, FileObject relativeObject) should also work in the case that the two files that are sent in as a parameter are the same, in that case it should return "". Unlike currently FileUtil.isParentOf(...), which does not accept such a case, which I think is wrong.
I would very much appreciate this also.
Created attachment 12207 [details] is it OK for you ?
Please see attachment: should be compatible API change just in javadoc. Is it OK and is it enough ? Or do you really need method findRelativePath which is basically specialized substring method that fires IllegalArgumentException. The same could be requested also for Registry API.
This sounds good for the first part of the request, i.e. finding a file from another file based on a relative path. I am only a little bit confused by the Javadoc for method FileObject.getFileObject(String name, String ext), particularly by the part which says: * @param ext extension of the file; <CODE>null</CODE> or <code>""</code> * if the file should have no extension or if folder is requested This sounds like name can not be of the form "MyClass.java" - but in reality it can. I think the Javadoc here should be changed to say that extension can be specified either in the 'ext' parameter, or as a part of the name in the usual syntax (i.e. "name.ext"). Regarding the second part of the request (finding a relative path between two fileobjects), it would still be useful to have such a general API method to me, but this really depends on whether other people need it as well. CC'ing Tomas, so he can also express his opinion on whether this is needed or not. If I am the only one, then I will not push for it.
You are right this javadoc is confusing. I still hasitate whether this method shouldn't be deprecated at all(the same for all methods that take extension).
+1 from me for deprecating methods taking extension... :-) The proposed diff looks OK to me, and findRelativePath would be nice sometimes too (in FileUtil I suppose). Good candidate for devrev fast-track.
Created attachment 12272 [details] relative path
Excellent, I like this. I would only clarify the Javadoc to make it super clear that folder and fo may be the same, e.g.: @param fo arbitrary FileObject in folder's tree (including folder itself) @return relative path between folder and fo. The returned path never starts with a '/'. It never ends with a '/'. Specifically, if folder==fo, returns "". Returns <code>null</code> if fo is not in folder's tree.
Looks OK to me. BTW please remember to always use the -u flag to cvs diff. Most easily, add to ~/.cvsrc or the Win32 equivalent: diff -u
I do not see any tests. Especially > if (result.startsWith("/")) { > result = result.substring(1); > } looks suspicious to me. Probably something you want to ensure. No comments otherwise.
Created attachment 12400 [details] added test
Incorporated all comments, added test. Tommorow will be commited.
In trunk: /cvs/openide/test/unit/src/org/openide/filesystems/FileObjectTestHid.java,v <-- FileObjectTestHid.java new revision: 1.22; previous revision: 1.21 /cvs/openide/src/org/openide/filesystems/FileObject.java,v <-- FileObject.java new revision: 1.80; previous revision: 1.79 /cvs/openide/src/org/openide/filesystems/FileUtil.java,v <-- FileUtil.java new revision: 1.71; previous revision: 1.70 /cvs/openide/api/doc/changes/apichanges.xml,v <-- apichanges.xml new revision: 1.174; previous revision: 1.173
*** Issue 22865 has been marked as a duplicate of this issue. ***