Description Dirk Baeumer 2005-10-21 12:52:35 EDT

Hi Martin,

enclosed a list of open issues I encountered when converting JDT/UI to use EFS:

Javadoc export wizard
  - assumes that the destination of the export is the local file system. As
    long as this holds no further action is needed.

  - no warnings are generated for source that is not local. The current 
    implementation (as of 3.0) simply ignores them. IMO we should think about
    extending the dialog to present a message box for those locations that got
    ignored

Jar export wizard:
  - assumes that the destination of the export is the local file system. As
    long as this holds no further action is needed.

New Java project wizard:
  - since we don't have any UI yet to specify a location different than in the
    local file system, I haven't adjusted the LocationGroup yet. As soon as 
    Platform/UI has a user interface here we have to see what we have to do.
    However I adapted all the internal code of the wizards to use URI and 
    I currently convert the path provided in the UI into an URI. See method
    JavaProjectWizardSecondPage#getProjectLocationURI()

LinkFolderDialog:
  - same as with the new wizard. If a link can point to a different file
    system we have to adapt the code as soon as Platform/UI provide UI to
    define them.

Build path: I made the following assumptions when converting the code to
  EFS (so the use of getLocation and toFile on Path is still ok):
  - archives as source attachements only support for archiives on local 
    file systems. 
  - class path variables can only point to files and folders on local
    file systems. 

Philippe, be already discussed the source attachement. I assume that the same is
true of class path variables as well. If not, some new API on Core is needed to
map class path variables to URIs.