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.
My project nature extends the Java project nature. At various times, I need to know the packages that the user has created. I think the Java Project APIs should provide a method to retrieve these. Currently, I have to retrieve the CompilationUnits, from that get the SourceRoots, from that, get the RootSet and then go through the source roots and determine the packages. The Java Projects module must be doing this (since the package nodes are properly displayed) so it would be great if that API was exposed so other developers could easily get the packages (a Set or Collection of FileObjects would be great).
I don't fully understand the requirement. Do you want to get just the flat list of FileObjects like: /home/jw/src/org /home/jw/src/org/netbeans /home/jw/src/org/netbeans/foo /home/jw/testsrc/org /home/jw/testsrc/org/netbeans /home/jw/testsrc/org/netbeans/foo Or just those package fragments (folders) which contain some java files? Assuming there is no source files outside of org.netbeans.foo package you would then get: /home/jw/src/org/netbeans/foo /home/jw/testsrc/org/netbeans/foo Note that there can be more than just one or two package roots (in the example I have two /home/jw/src, /home/jw/testsrc). IMO the list of Strings would be better, the transitions from package identifier (String) to its fragments (folders - FileObjects) is easy through the project's sourcepath, e.g.: ClassPath cp = ProjectPath.findPath(compilationUnit.getBuildTarget(), ProjectPath.PATH_SOURCE); List fragments = cp.findAllResources(packageId); The fragments is the list of FileObjects.
Basically, I want a list of FileObjects that correspond to the Java packages where the user can create java classes. For example, if I select "New File/Folder" on the Packages node, and create a new package named "com.sun.joe", a node for this shows up under the Packages node.Then on my "com.sun.joe" node, I create a subpkg, "pkg1", this node is displayed. So, in theory, these are the packages where users can add java files. So, programatically, I'd like to retrieve these two packages (as FileObjects) via some API. Actually, I guess the "correct" result, would return the FileObjects for "com", "com.sun", "com.sun.joe" and "com.sun.joe.pkg1" since it would seem that any of those Packages is a valid place in which a java file can get created.
Joe, a package does not directly correspond to a FileObject. A package can be mapped to an ordered list of FileObjects, since several roots of classpath may contain the folder with the package's qualified name. I do not understand what do you suppose to get as an advantage over the regular ClassPath API: just ask for PATH_SOURCE and get the roots of that classpath - they are FileObjects. You do not need any special purpose API call to get the roots. The display that coalesces empty nested packages into one node is UI chrome only and will not be exposed as an API; different presentations may need different rules for coalescing/flattening the structure, so it's better left for each implementor. I do not think that API (basically a 10-line helper that anyone can write better suited to the particular purpose) that recursively enumerates directories underneath roots of PATH_SOURCE classpath (2 calls to get that for a given source). I would like to note that the display in projects tree is incorrect in the case there are 2 or more Compilation Units in the project: the display contains merged view, but the sources are, in fact, processed (compiled) independently. I do not think that this issue is valid - unless there's a clear functional benefit over Classpath API.
I agree with Svata, there is no need for such API. The ClassPath API covers obtaining of the java source roots, from the roots it is simple to obtain all the subfolders. I don't see this functionality as a part of any of Java APIs. If you want a helper function for recursive finding of all subfolders of a FileObject, the right place for it may be org.openide.filesystems.FileUtil class.
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped. Marking issue as VERIFIED --->
---> CLOSED