Do you have a proposed API, or details? I can make something up but I have no concrete test case to develop against (i.e. project type which actually works with non-java.io.File's). Maybe something like

/*service*/ interface RemoteProjectLocationProvider {
    List<? extends RemoteProjectLocation> getLocations();
}
interface RemoteProjectLocation {
    String getDisplayName();
    File getBaseFile();
    FileSystemView getFileSystemView();
    @CheckForNull FileObject translate(File projectDirectory);
}

Unfortunately in JDK 6, FileSystemView and JFileChooser are not all that flexible since they require a java.io.File; you have to make a fake file like

new File("/remote/some.host/actual/path")

and have the FSV parse out its path and make a virtual file tree. (JDK 7 should make this cleaner with NIO.2.)

Jesse,

(Thanks for your incredible responsiveness!)

I hadn't a ready API proposal at the moment of filing this issue.

I like what you propose, the only thing that I doubt is "Location" term, I'm thinking of replacement, but can't propose a better one right now.

Sure we have to deal with java.io.Filein JDK6. We already have all necessary implementations (FileSystemView, java.io.File extension, FileSystem, UrlMapper, UrlStreamHandler implementations).

Frankly, I'm not quite sure CND project will work well with FileObjects without files, I'm going to check and fix this.

BTW if you launch IDE with -J-Dcnd.remote.show.fs=true, activate C++ and go to services, you'll see list of host that are set up, and, when a host is connected, browse its file system there. You can also add file objects from there to favorites.

Unfortunately there are no "Open Project" item on such folders in favorites. I guess it's CND fault. I filed issue 193253 in this respect and going to fix it soon.

(In reply to comment #2)
> I like what you propose, the only thing that I doubt is "Location" term, I'm
> thinking of replacement, but can't propose a better one right now.

OK. By the way I will be away from work until January, so I hope it can wait; otherwise you can try to submit an API review yourself and hope others will review it.

> UrlStreamHandler implementations

I guess that would be RemoteFileURLStreamHandler?

Pending an SPI for the Open Project dialog, you could perhaps make sure that your project type is fully able to work with remote projects (fixing any bugs in projectui as needed); and add a special File > Open Remote Project menu item which would show your own chooser. When this SPI is implemented, that menu item can be removed, but in the meantime you can test everything else end-to-end.

It appeared that it can't be loaded from favorites because of
AntBasedProjectFactorySingleton.java:223
public @Override Project loadProject(FileObject projectDirectory, ProjectState
state) throws IOException {
        if (FileUtil.toFile(projectDirectory) == null) {
            LOG.log(Level.FINE, "no disk dir {0}", projectDirectory);
            return null;
        }


Is it worth filing another issue or will we consider it's this one?

(In reply to comment #4)
> (In reply to comment #2)
> > I like what you propose, the only thing that I doubt is "Location" term, I'm
> > thinking of replacement, but can't propose a better one right now.
> 
> OK. By the way I will be away from work until January, so I hope it can wait;
> otherwise you can try to submit an API review yourself and hope others will
> review it.

OK, have a good vacations. I'll submit an API review myself then. I won't file a separate issue, just this one, ok? And whom would you advise to ask to participate?

> 
> > UrlStreamHandler implementations
> 
> I guess that would be RemoteFileURLStreamHandler?

Exactly.

> 
> Pending an SPI for the Open Project dialog, you could perhaps make sure that
> your project type is fully able to work with remote projects (fixing any bugs
> in projectui as needed); and add a special File > Open Remote Project menu item
> which would show your own chooser. When this SPI is implemented, that menu item
> can be removed, but in the meantime you can test everything else end-to-end.

Yes, that's what I'm going to do in parallel with API review.

(In reply to comment #5)
> It appeared that it can't be loaded from favorites because of
> AntBasedProjectFactorySingleton

project.ant does not support projects not based on java.io.File and this is not likely to change; the existence of a FileObject <-> File mapping for files in the project directory (and external source roots) is relied upon extensively.

If you want remote projects, you must use your own ProjectFactory. Anyway it does not make sense for CND Makefile-based projects to be using project.ant, since this module is expressly designed to support a very specific class of project based on IDE-generated Ant scripts with certain characteristics relating to Ant property evaluation semantics etc.

(In reply to comment #6)
> I'll submit an API review myself then. I won't file
> a separate issue, just this one, ok?

Yes, once you have a concrete proposal, just add API_REVIEW_FAST (or API_REVIEW if potentially controversial) to Keywords, and CC apireviews.

> whom would you advise to ask to participate?

People subscribed to api-changes@netbeans.org should see it if apireviews is CC'd. I am the current maintainer of projectuiapi and similar so I'm not sure who else would want to chime in.

The particular proposal is as follows. 

If there is a provider of the spi below, project open dialog contains a combo box filled with display names and uses the correspondent FileSystemView. If there are no such provider, UI stays as it is now (from CND point of view it's quite OK if it always present, but I believe it isn't OK from other use cases).

The justification is as follows. Oracle Solaris Studio should be able to open projects that are located remotely (not accessible via shared directories). If this issue is not solved, we will have to have a separate item "Open Remote Project", which does exactly the same ordinary "Open Project" item does, but on a remote file system - which is sure an ugly UI.


/**
 * Provides alternative locations where a project can be stored -
 * @see AlternativeLocation
 */
interface AlternativeLocationProvider {
    List<? extends AlternativeLocation> getLocations();
}


/**
 * Represent an alternative location (file system)
 * a project can reside in
 */
interface AlternativeLocation {

    /**
     * Gets a file system
     * @return
     */
    FileSystem getFileSystem();

    /**
     * Gets this location display name to display in UI
     * (combo-box within file chooser, file chooser title, etc.)
     * @return
     */
    String getDisplayName();

    /**
     * Gets a view of this file system to use in JFileChooser
     * @return
     */
    javax.swing.filechooser.FileSystemView getFileSystemView();

    /**
     * Translates a file that is got from chooser into file object
     * @param file file to translate
     * @return file object that corresponds to this file. 
     * If the file is got from chooser that uses FileSystemView 
     * provided by this provider,it should never be null. 
     * If another file is passed, the return value will be null.
     */
    FileObject toFileObject(File file);
}

[JG01] getFileSystem() seems wrong. The implicit intent, I guess, is that its root is the starting point for the chooser when this location is selected. But why should the provider be forced to use the root of a FileSystem as the starting point? Perhaps it wants to offer various subdirs of one FS as starting points, or even create a FileSystem on demand for a given selection. Anyway this method does not help the JFileChooser impl to actually create a java.io.File for the initial selection, since there is no reverse mapping FileObject -> File.

Suggest my originally proposed method 'File getBaseFile()', which would directly offer the file chooser the initial selection to use when the location is selected, and place no restrictions on the location provider as to what sort of FileObject will be worked with. Or just omit this method altogether, since FileSystemView.getDefaultDirectory() would naturally have this meaning.


[JG02] Where would the proposed interfaces go? org.netbeans.spi.project.ui? Is AlternativeLocation to be a nested class of the provider class or vice versa or neither?


Note that these are just preliminary comments; for an actual review, there needs to be a full patch with (1) SPI classes (and perhaps apichanges); (2) implementation in projectui (perhaps in ProjectChooserAccessory); (3) functional SPI impls in CND code.

(In reply to comment #9)

> [JG01] getFileSystem() seems wrong... 
<skipped>

Agreed. Let's remove getFileSystem().
Let's use FileSystemView.getDefaultDirectory() for the initial directory.

> [JG02] Where would the proposed interfaces go? org.netbeans.spi.project.ui? 

This depends on whether we consider other usages apart from opening a project.
Generally, this might be of interest in "Add to Favirites..." or "File > Open". Although I wouldn't touch the latter in 7.0, it's worth doing this on more common level. I'm not sure I know the correct place. openide.filesystems? What do you think?

> Is AlternativeLocation to be a nested class of the provider class 
> or vice versa or neither?

I propose to make them top level.

> Note that these are just preliminary comments; for an actual review, there
> needs to be a full patch with (1) SPI classes (and perhaps apichanges); (2)
> implementation in projectui (perhaps in ProjectChooserAccessory); (3)
> functional SPI impls in CND code.

Understood. As I understand nobody but me will do this, right?
So I'm going to do this in a couple of days.

(In reply to comment #10)
> this might be of interest in "Add to Favorites..." or "File > Open".
> [...] I'm not sure I know the correct place. openide.filesystems?

Might make sense; if you really support remote FSs for projects then it would be useful for other places in the IDE where a file path is input to accept remote locations. Would then need some API (in FileChooserBuilder?) to accept remote locations as well as local; this means FCB should somehow offer a resulting FileObject rather than a File for the selection, or at least tell you what the current AlternativeLocation is so you can do the conversion yourself.

This kind of broadening of scope is potentially fruitful but it means we need a patch that covers another use case beyond projectui.

I digged the history as I remember there was a way to plug into JFileChooser. Here is code that used to create a JFileChooser that worked on any (e.g. also virtual) DataObject (means also FileObject):

http://hg.netbeans.org/main/annotate/93358404e3ef/o.n.core/src/org/netbeans/beaninfo/editors/DataObjectListView.java

It is not necessary to encode some specific string into name of a File, it seems it is easier to subclass the File (as the changeset does with NodeFile).

If I am not mistaken, you need to tweak every filechooser in the system to allow access to your virtual files, right? Will you lookup the AlternativeLocationProviders?

As far as the right place for the API goes. There is 
http://bits.netbeans.org/dev/javadoc/org-openide-filesystems/org/openide/filesystems/FileChooserBuilder.html
it can be enhanced to support additional virtual FileObject based location, if you create the patch and maintain the code...

(In reply to comment #12)

Thanks for the link to DataObjectListView. Sure we have to subclass File. We already did this and we already have our own chooser that is now used within cnd project.

Yes, we need to tweak more file choosers. But nearly all of them are inside cnd components (adding files to a project, etc).

I agree, it would be fine if FileChooserBuilder took into account alternative locations. I'm ready to make a patch and maintain the code.

(In reply to comment #13)
> Yes, we need to tweak more file choosers. But nearly all of them are inside cnd
> components (adding files to a project, etc).

If all of them would be in cnd, you'd need no API change in the platform....

> I agree, it would be fine if FileChooserBuilder took into account alternative
> locations. I'm ready to make a patch and maintain the code.

OK, I am looking forward to your contribution. I see two problems:

1. how to get list of all virtual locations? Maybe interface FileChooserFavorites {
  FileObject[] getFavorites();
} would be enough. Display name for a fileobject can be obtained from FileSystem.Status. Icon as well.

2. How to get the selected FileObject back when the file chooser finishes? Probably instance of check in FileUtil.toFileObject(File) could convert the special File subclass to FileObject.

It's too late to make such changes in 7.0 time frame. Let's revisit this in the next release cycle.

Created attachment 104703 [details]
Sample (but broken and incomplete) patch allowing use of ABPFS on virtual FS while keeping java.io.File performance

> Jesse replied on Jan 4, 2011 to:
> On 12/23/2010 03:47 AM, Jaroslav Tulach wrote:
> > This is an example of the code as I envision it (subject to more tests, API
> > review and Jesse's approval of course). It is much simpler than any other
> > approach, and possibly doable for 7.0.
>
> Haven't reviewed it in detail but if it is fairly straightforward and causes no > performance regression then it is OK.

Good. I think performance will be OK.

> The patch I see includes only changes to AntBasedProjectFactorySingleton.java,
> I suppose. But there are various other classes in project.ant which probably
> assume java.io.File and would need to be changed as well 

Very likely. Those need to be changed by submitter too. 

> A unit test using FileUtil.createMemoryFileSystem should catch at 
> least the most obvious usages, but a search for File in the 
> module's source code is likely needed.

Right, I definitely see this as better approach than duplicating all classes in cnd. I hope cnd guys will implement that in future.

(In reply to comment #5)
> Is it worth filing another issue

bug #197896

This got abandoned. So far there is not a complete working patch so it is not API_REVIEW_FAST. Let me know if you still need this.

*** Bug 197896 has been marked as a duplicate of this bug. ***