Re: [platform-core-dev] Re: IResource outside the workspace

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Funny story - my mailer has two buttons
side by side: Send and Save.  I wrote this reply a couple of days
ago and then promptly hit Save rather than Send.  This time, I'll
try hitting Send...



Bob Foster wrote on 28/07/2005 05:22:56 PM:
> > True. In fact, metadata wasn't stored in the project folder in
Eclipse 
> > 1.0. However, people wanted it there so that when the project
was 
> > transferred to another workspace, either via repository or zipping
and 
> > emailing to a friend, it wouldn't be lost and require recreating.
> 
> I certainly understand the use case. It would have been nice to retain
> the option. (If you tell me you did, I'm _really_ going to be 
> embarrassed. But I'd love to hear it!)

There is a "story" for how this can work,
although it's admittedly not practical in many cases:

1. Put your source code somewhere in your file system
outside the workspace location
2. Create a project in the default location
3. Go to the "Source" tab of the Java build
path property page
4. Add Folder > Create New Folder > Advanced
> Link to folder in the file system

Now the Eclipse artifacts (.project, .classpath, etc),
will be stored in the workspace location, and your code can live separately
without being contaminated with Eclipse files.  This is only a partial
story because it doesn't really work with Eclipse repository tools, and
if you have many files/folders at the top level in your project, each one
has to be linked separately.

> 
> Ok, got me there. I knew you could link to projects but I really thought
> they had to be in some workspace. It's a little unnatural to make
a 
> folder visible/usable by creating a new project, and when you do it
> metadata gets scribbled in your folder, but it does work. I didn't
know 
> that. Always, you say?

Yep, since 1.0 you have been able to choose the project
location from the new project wizard and have it pull in the existing content
found there.  I know this is a confusing and little known feature.
In the UI we only have "new" wizards and "import" wizards.
If you want to create a "new" Eclipse project but with existing
content on disk, it's not intuitive that you would go to the "new"
wizard (In this case "new" means new to this workspace). It's
further confused by the fact that some "import" wizards will
also create new projects (import existing project, import from CVS).  What
the user often wants is some hybrid new/import wizard where they can specify
the project type and the project content all in one go.  The UI team
has often struggled with how to improve this, and I'm sure suggestions
are welcome.

> The reason for bringing RCP into the conversation is because many
RCP 
> applications _do_ use files and many would like to use features that
> depend on using files but have nothing to do with an IDE, like editors
> with markers and annotations. (For the life of me I don't see why
> markers are an IDE-related concept.) In my experience, you can't just
> add these things to an RCP app and expect them to work. You have to
> bring the IDE along with them.

The text editor framework is divided into "RCP"
plugins (org.eclipse.text, org.eclipse.jface.text, and org.eclipse.ui.workbench.texteditor),
and "IDE" plugins (org.eclipse.ui.editors). The bulk of the framework
is in the former group of plugins that doesn't require the IDE. This includes
infrastructure for "annotations", which are the UI manifestation
of markers.  Markers are not inherently an IDE concept, but their
API pulls in IDE-specific concepts (just for fun: IMarker.getResource().getProject().getDescription().getBuildSpec()...
suddenly you're in distinctly IDE space).  While the editor framework
handles this split between annotations (RCP) and markers (IDE), this doesn't
carry over into other views that currently only know only about markers
(tasks, problems, bookmarks, ...).  The problem is, you need somewhere
to store these annotations. When a random file from the file system is
opened in an editor, and annotations are added, it's not clear how those
annotations can be persisted in a way that they will stick with the file
if it's opened elsewhere.  I believe there is also editor work planned
for 3.2 to push more editor functionality down into the "RCP-enabled"
editor plugins.

> 
> I may have over-generalized the Eclipse issues, but there are some
yet. 
> Save As external file. Double-click to open from desktop. All subjects
> of individual bug reports, but all file-related operations outside
a 
> workspace.

I agree, these are all valid problems. I'm just not
sure the solution is as simple as detaching IFile from the workspace.  Many
parts of the API on IFile and IResource carry along baggage that doesn't
fit outside the workspace, and splitting/forking this API would be very
complicated. I'm instead leaning towards the idea of a trimmed down RCP
equivalent of IFile (something closer to java.io.File but something that
clients could implement). You would then be able to create IDE IFiles on
top of that layer, or just use the "RCP file" to avoid dragging
in other unwanted dependencies.

John