<!-- saved from url=(0022)http://internet.e-mail --> | |
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> | |
<html> | |
<head> | |
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> | |
<meta name="Author" content="Eclipse Project"> | |
<title>Towards More Flexible Project Structure</title> | |
<link rel="stylesheet" href="../../default_style.css" type="text/css"> | |
</head> | |
<body bgcolor="#FFFFFF" > | |
<div align="left"> | |
<h1> Towards More Flexible Project Structure</h1> | |
</div> | |
<blockquote> | |
<p><b>Summary</b> <br> | |
Eclipse requires that the contents of each project be stored in a single directory | |
on disk. Every file and folder in that directory tree on disk must belong | |
to the project in the workspace. This restriction makes it difficult to use | |
Eclipse in conjunction with tools that have specific layout requirements for | |
their files, or with users who have legacy file base layouts that they need | |
to maintain. We would like to improve the situation for the 2.1 release of | |
Eclipse. There is a separate, first <a href="http://www.eclipse.org/eclipse/development/inflexible-projects-problem.html">document | |
describing the nature of the problem</a>. This document explores the space | |
of potential solutions, without drilling down into the details of any of them. | |
The proposed solution is described in a <a href="flexible-projects-proposal.html"> | |
follow-on document</a>.<br> | |
<br> | |
Last Modified: 17:00 October 24, 2002<br> | |
Changes from <a href="towards-more-flexible-projects_20021004.html">previous | |
version</a>: added JBuilder info; split option P-1 into P-1a and P-1b; split | |
option M-1 into M-1a and M-1b</p> | |
</blockquote> | |
<p>In this document we explore the space of potential solutions, to better | |
understand where the various aspects of the problem can and cannot be addressed. | |
Although much of the discussion will center around Java, the problems are likely not | |
confined to | |
Java and will affect tools for other languages. In most cases, we will have the option of addressing the problem at the JDT | |
level without changing the Eclipse Platform. This has its pros and cons. Pro: | |
the solution can be specialized for Java. Con: The solution would not apply to C | |
tools, for example. On the other hand, addressing the problem at the level of | |
the Eclipse Platform also has its pros and cons. Pro: The solution would apply | |
to C tools, etc. Con: The change may impact all tools and users. All this must be | |
factored in to the decision-making process.</p> | |
<p>In the final decision, we may only be able to address a subset of the | |
problems. But here we proceed with an unlimited budget for exploration.</p> | |
<h2>Pros of the current Eclipse</h2> | |
<p>Although the restrictions on the structure of Eclipse projects may come | |
across as inflexible to some, the current scheme has several important virtues:</p> | |
<ul> | |
<li>Single-rooted Eclipse project is simple to explain to users and plug-in | |
writers alike: All of a project's files are in a single file system | |
subdirectory. End of story.</li> | |
<li>All-inclusive Eclipse project means that the project resource tree is an | |
accurate in-memory model of the corresponding tree of files in the file | |
system. Plug-ins can quickly traverse the in-memory tree without having to | |
make expensive OS file IO calls. Tools that operate directly in the file | |
system can be readily integrated into Eclipse with the after-the-fact | |
application of a simple refresh mechanism to resynchronizes the resource | |
tree with the file system.</li> | |
<li>Non-overlapping Eclipse projects is simple. The mapping from files in the | |
file system to files in the workspace resource tree is 1-1, allowing | |
unambiguous lookup of a resource given a file system path. If projects | |
overlap, that mapping becomes 1-many (multiple distinct resource handles map | |
to the same file).</li> | |
</ul> | |
<h2>What do other IDEs do?</h2> | |
<p> | |
<b>NetBeans 3.4 (</b>and Sun ONE Studio, formerly Forte for Java)</p> | |
<ul> | |
<li>Projects are multi-rooted at the top-level.</li> | |
<li>To use sources and libraries in IDE they must be mounted as | |
filesystems.</li> | |
<li>Filesystem can be a local folder, an archive, or something from VCM.</li> | |
<li>Filesystems are all-inclusive by default. | |
<ul> | |
<li>Regular expression exclusion rules stated at filesystem root.</li> | |
<li>(Refresh rate also set at filesystem root; defaults to 15 | |
s.) </li> | |
</ul> | |
</li> | |
<li>Projects provide context for source files, compilation, and execution.</li> | |
<li>All work done in an open project.</li> | |
<li>Default project if none specified.</li> | |
<li>Can define new projects.</li> | |
<li>Only one project open at a time.</li> | |
<li>Filesystems can be mounted into projects.</li> | |
<li>Filesystems can overlap between projects.</li> | |
<li>Filesystems can overlap even within projects.</li> | |
<li>Project level control of location of generated class files. | |
<ul> | |
<li>Next to source file (default).</li> | |
<li>Output to specific filesystem.</li> | |
</ul> | |
</li> | |
</ul> | |
<b>IntelliJ IDEA 2.6</b> | |
<ul> | |
<li>Projects are multi-rooted at the top-level.</li> | |
<li>Roots are directories or JARs in file system. | |
<ul> | |
<li>Automagically computes correct source folder based on where it | |
finds Java source files</li> | |
</ul> | |
</li> | |
<li>All files under root directory are included in project.</li> | |
<li><i>Remove</i> a root from project; <i>delete</i> a file or folder from | |
a root.</li> | |
<li>Info about project is kept in separate project configuration file | |
named <ProjectName>.ipr</li> | |
<li>Project has compiler option for ignoring specified files or | |
subdirectories.</li> | |
<li>Workspace consists of a single open project.</li> | |
<li>Default project if none specified.</li> | |
<li>Can define new projects.</li> | |
<li>Only one project open at a time. | |
<ul> | |
<li>But you can run multiple instances of IDE at same time.</li> | |
</ul> | |
</li> | |
<li>Separate projects are free to overlap (no special support).</li> | |
<li>Within a project, separate roots may overlap.</li> | |
<li>Source files appearing under more than one root generate compile | |
errors. | |
<ul> | |
<li>Cannot be remedied with compiler option.</li> | |
</ul> | |
</li> | |
<li>One output folder per project. | |
<ul> | |
<li>Location of generated class files is a project property.</li> | |
<li>(But...IDEA 3.0 is more flexible: different output folder for each | |
source folder)</li> | |
</ul> | |
</li> | |
</ul> | |
<b>Together® ControlCenter 6.0.1</b> | |
<ul> | |
<li>Projects are multi-rooted at the top-level.</li> | |
<li>Roots are directories or JARs in file system.</li> | |
<li>Roots are added and removed only in project properties dialog.</li> | |
<li>All files under root directory are included in project unless excluded | |
by a "skip path" entry.</li> | |
<li>Info about project is kept in separate project file named | |
<ProjectName>.tpr.</li> | |
<li>Project file is kept in primary root directory along with other | |
project-level property files.</li> | |
<li>Workspace consists of a single open project.</li> | |
<li>Can define new projects.</li> | |
<li>Only one project open at a time. | |
<ul> | |
<li>But you can run multiple instances of IDE at same time.</li> | |
</ul> | |
</li> | |
<li>Separate projects are free to overlap (no special support).</li> | |
<li>Within a project, separate roots may overlap.</li> | |
<li>Source files appearing under more than one root generate compile | |
errors. | |
<ul> | |
<li>Can be remedied with "skip path" feature.</li> | |
</ul> | |
</li> | |
<li>Location of generated class files is internal and unspecified.</li> | |
</ul> | |
<p> | |
<b>Borland® JBuilder Enterprise 7</b></p> | |
<ul> | |
<li>Projects are multi-rooted at the top-level.</li> | |
<li>Roots are directories in file system (source paths).</li> | |
<li>Source paths are added and removed only in project properties dialog.</li> | |
<li>All Java source files under a source path are included in project. | |
<ul> | |
<li>Can explicitly exclude a package in regular Browser.</li> | |
</ul> | |
</li> | |
<li>Info about project is kept in separate project file named | |
<ProjectName>.jpx.</li> | |
<li>Project file is kept in project directory.</li> | |
<li>Project directory defaults to C:\Documents and Settings\<user>\jbproject\<ProjectName>\</li> | |
<li>Project directory is default location for everything (source, class | |
files, doc, etc.)</li> | |
<li>Source path defaults to <project directory>/src</li> | |
<li>Single output path per project.</li> | |
<li>Output path defaults to <project directory>/classes</li> | |
<li>Any number of projects can be open in a browser at a time.</li> | |
<li>Browser only shows one project at a time.</li> | |
<li>There can be multiple browsers; same project can be open in several.</li> | |
<li>Separate projects are free to overlap (no special support).</li> | |
<li>Within a project, separate source paths may overlap. | |
<ul> | |
<li>Longer source path "steals" subtree from the source | |
paths it overlaps.</li> | |
</ul> | |
</li> | |
<li>Project can also have loose source files not appearing in a package | |
directory. | |
</li> | |
</ul> | |
<p> | |
<b>Microsoft Development Environment 2002 Version 7 (Visual Studio .NET)</b> | |
</p> | |
<p>[This section is incomplete]</p> | |
<ul> | |
<li>Projects come in various types. | |
<ul> | |
<li>Some types of projects (e.g., Visual Basic Web and Visual C# .NET | |
Web projects) are a single-rooted tree of files</li> | |
<li>Some types of projects (e.g., Visual C++ .NET projects) consist | |
entirely of links to individual files</li> | |
<li>Some types of projects (e.g., Visual Basic .NET and Visual C# .NET | |
projects) are a mix of both, primarily </li> | |
</ul> | |
</li> | |
<li>File inclusion is inherently selective. | |
<ul> | |
<li>There are Include in Project and Exclude from Project menu items.</li> | |
</ul> | |
</li> | |
<li>Workspace consists of several projects (collected into solutions).</li> | |
<li>[TBD - whether projects are allowed to coincide or overlap]</li> | |
</ul> | |
<h2>Improving the Output Folder</h2> | |
<p>How could we change Eclipse to make the Java output folder more flexible?</p> | |
<p>Here are some options (in no particular order):</p> | |
<p><b>Option P-1a</b>: Change JDT to allow the output folder to be external to | |
the workspace.</p> | |
<p>JDT allows library JARs to be either local to a Java project (specified by | |
workspace path) or external to the workspace (specified by an absolute file | |
system path). So one option is to be similarly flexible with the location of a | |
Java project's output folder.</p> | |
<p>This would entail changing JDT Core API as well as JDT UI, but could likely | |
be done in a non-breaking fashion.</p> | |
<p>The chief drawback of this approach is that there would be no resource deltas | |
for tracking changes to files in a project's output folder in the case where it | |
was external to the workspace. This would have serious repercussions in at least | |
three areas: (a) the JDT debugger's HotSwap facility relies on resource deltas to | |
class files in the output folder; (b) the Java incremental project builder uses | |
builder-supplied resource deltas to track changes to class files in dependent | |
projects, and (c) other incremental project builders on the same project would | |
be unable to track changes to anything in the output folder as well. Without resource deltas, it is hard to see how either could be | |
supported.</p> | |
<p>A smaller drawback is that any code that creates and reads class files in the | |
output folder would have to be written in such a way that it could deal with | |
resources in the workspace (using resource handles provided by the workspace | |
API) and outside the workspace (using java.io.File API directly).</p> | |
<p><b>Option P-1b</b>: Change JDT to allow the output folder to be in a | |
different project.</p> | |
<p>A user could designate that a Java project's generated class files be created | |
in another project. Since each project can reside on a different drive, this | |
arrangement would allow the Java project to live on a network drive with its | |
generated class files living on a local drive, or wherever.</p> | |
<p>The advantage of this arrangement is that it does not require new concepts.</p> | |
<p>The chief drawback is that it may force users into creating additional | |
"storage" projects. In the worst case, these projects are nothing more | |
than a bunch of files (no builders, no VCM). It should be possible to hide such | |
projects from the user.</p> | |
<p>This change would break existing clients that assume that all generated class | |
files for a Java project are always located within the project itself. </p> | |
<p><b>Option P-2</b>: Change Eclipse Platform workspace to allow arbitrary | |
directory in the file system to be "mounted" as a folder inside a | |
project.</p> | |
<p>A user would then be able to mount an external file system subdirectory into | |
their Java project, and designate their output folder at (or below) that mount | |
point. The net effect is that the generated class files would be written | |
directly to the desired location. As long as mounted subdirectories are | |
considered to be a regular part of the project's file, the regular resource API | |
and resource deltas apply. JDT would not even need to be aware that the output | |
folder was separated from the rest of the project's files.</p> | |
<p>The pros and cons of this approach are chiefly those of mount points | |
generally (covered below).</p> | |
<p>PDE launches a runtime | |
workbench with a special command line option specifying one or more | |
plug-in-relative paths (e.g., -dev bin) that are to be included on each plug-in | |
class loader's class path. PDE includes the project-relative paths of all output | |
folders; this is just the path "bin" when all plug-in projects locate | |
their output folder in the default location. If an external directory is mounted | |
as a Java project's output folder, the existing Eclipse Platform Core Runtime | |
mechanisms would need to be revamped to allow PDE to supply an absolute file | |
system path for each plug-in.</p> | |
<p>Some other observations:</p> | |
<ul> | |
<li>JDT marks the output folder as containing "derived" resources, | |
and repository providers tend to ignore resources marked as | |
"derived". This means that it probably does not matter whether a | |
mounted folder is considered part of the project for VCM purposes.</li> | |
<li>If the JDT UI exposes the support for mounting the output folder, there | |
would be no need to provide generic mount support in the Workbench UI. This | |
would allow the complicating nature of mount points to be confined to the | |
types of projects that are prepared for them.</li> | |
</ul> | |
<p><b>Option P-3</b>: Advocate use of OS-level symlinks. </p> | |
<p>Unix file system have symlinks, and Windows 2000 NTFS has an unsupported | |
feature called <a href="http://www.sysinternals.com/ntw2k/source/misc.shtml#junction">junctions</a>. These | |
file system mechanisms allow a directory in one part of the file system to be | |
linked in to somewhere else. For example, if the project root directory of | |
Project1 is C:/myws/project1 and the Java output folder is in its standard | |
location, a symlink from C:/myws/project1/bin to C:/tomcat/webapps/mytest/WEB-INF/classes | |
ensures that the files in the output folder are created directly in the web | |
server's subdirectory. </p> | |
<p>The advantage of this option is that the user can create this arrangement | |
using existing OS-specific tools, and does not require explicit support from the | |
Eclipse. So this option is already supported in 2.0. </p> | |
<p>Operating systems may have restrictions on symlinks that make this option less | |
workable for some purposes. For instance, NTFS junctions work on Windows | |
2000 or better, and only work within | |
and between local drives. Furthermore, junctions are an unsupported feature. </p> | |
<p><b>Option P-4</b>: Advocate use of external tool builders for copying the output folder to an | |
external location. </p> | |
<p>Eclipse allows the user to add Ant-scripted steps as an external tool | |
builder. Coping new and changed files from the output folder to another location | |
can be done with one Ant command. </p> | |
<p>This option is low-tech and works in Eclipse 2.0; however, it only ensures | |
that the files in the output folder end up in the desired location; it does not | |
reduce the network traffic when the project's files are stored on a network | |
drive. </p> | |
<p><b>Option Q-1 (orthogonal)</b>: Allow one output folder per source folder. </p> | |
<p>Orthogonal to the other options, flexibility could be improved by allowing | |
different output folders to be specified for each source folder. In other words, | |
allowing the output folder could be partitioned along source folder lines. The | |
changes allows, for example, a single Java project to contain both product | |
source code and test suites partitioned into separate source and output | |
folders. </p> | |
<p>The additional output folders would need to find their way onto the runtime | |
class path, and the debugger would need to know how to map from generated class | |
file to source file. Neither should be a problem. </p> | |
<p>This change would break existing clients that assume that all generated class | |
files for a Java project are in a single output folder. </p> | |
<h3>Assessment </h3> | |
<ul> | |
<li>P-1a is a non-starter.</li> | |
<li>P-1b is promising, but requires changes to JDT. </li> | |
<li>P-2 is promising, but requires changes to the Eclipse Platform. </li> | |
<li>P-3 requires no work but is only a partial solution.</li> | |
<li>P-4 requires no work but is only a partial solution.</li> | |
</ul> | |
<h2>Allowing Multi-rooted Projects</h2> | |
<p>How could we change Eclipse to make Java projects (source folders in | |
particular) be multi-rooted rather than single-rooted?</p> | |
<p>Here are some options (in no particular order):</p> | |
<p><b>Option M-1a</b>: Change JDT to allow a Java project source folder to lie outside the workspace.</p> | |
<p>Supporting a source folder outside the workspace entirely would have many of | |
the same problems as with external output folders. These files would need to be | |
accessed with java.io.File API (not resource handles), and there would be no | |
resource deltas for updating the Java model or triggering recompilation.</p> | |
<p><b>Option M-1b</b>: Change JDT to allow a Java project source folder to lie | |
inside another project.</p> | |
<p>It would be relatively straightforward to allow a source folder for a Java | |
project to lie inside a different Java project. Because these files are still | |
inside the workspace, resource deltas can still be used for updating the Java | |
model and triggering recompilation. Since each project can reside on a different | |
drive, this arrangement would allow a Java project's source files to be drawn | |
from several places in the file system..</p> | |
<p>The advantage of this arrangement is that it does not require new concepts.</p> | |
<p>The chief drawback is that it may force users into creating additional | |
"storage" projects.</p> | |
<p>This change would break existing clients that assume that source files for a Java project are | |
always located within the project itself. </p> | |
<p><b>Option M-2</b>: Change Eclipse Platform to "mount" a file system | |
directory as a project folder.</p> | |
<p>We would add a new workspace concept of mount points, and allow a directory | |
in the file system to be grafted into a project's resource tree. For example, | |
mounting C:/JavaSources at /Project1/src would mean that the files and folders | |
under /Project1/src are stored under the subdirectory C:/JavaSources; e.g., the | |
file C:/JavaSources/com/example/Egg.java would appear in the workspace at the | |
resource path /Project1/src/com/example/Egg.java. Any project files not below a | |
mount point would be held within the project's root directory, as they are | |
currently. Tools that navigate the resource tree using the workspace API need | |
not be aware of the file's location. </p> | |
<p>It would also be possible to allow a portion of one project's resource tree | |
to be directly grafted into another (instead of doing this indirectly through the file system). | |
This implies some form of overlap be allowed.</p> | |
<p> | |
With the ability to mount a file system directory into the root of a project, a | |
Java project can have its source folders in different locations on disk. | |
</p> | |
<p> | |
This would be a breaking change for clients of the workspace because it alters the current | |
implicit understanding that all project contents are stored in one file system | |
subtree. However, it should be possible to minimize the effects of this breakage | |
and provide good compatibility with existing 2.0 tools and team (VCM) providers. | |
</p> | |
<p><b>Option M-3</b>: Advocate use of OS-level symlinks. </p> | |
<p>The use of symlinks is discussed above (Output Folder, Option P-3). These are | |
the file system equivalents of the mount points in Option M-2. </p> | |
<p>The advantage of this option is that the user can create this arrangement | |
using existing OS-specific tools, and does not require explicit support from the | |
Eclipse. So this option is already supported in 2.0. </p> | |
<p>Operating systems may have restrictions on symlinks that make this option less | |
workable for some purposes. For instance, NTFS junctions work on Windows | |
2000 or better, and only work within | |
and between local drives. Furthermore, junctions are an unsupported feature. </p> | |
<h3>Assessment </h3> | |
<ul> | |
<li>M-1a is a non-starter.</li> | |
<li>M-1b is promising, but requires changes to JDT. </li> | |
<li>M-2 is promising, but requires changes to the Eclipse Platform (same | |
change as P-2). </li> | |
<li>M-3 requires no work but is only a partial solution.</li> | |
</ul> | |
<h2>Allowing Selectivity</h2> | |
<p>How could we change Eclipse to make the Java source folders selective rather | |
than all-inclusive?</p> | |
<p>Here are some options (in no particular order):</p> | |
<p><b>Option S-1</b>: Change Eclipse Platform to add support for resource working sets with the capability to browse and manipulate a subset of the workspace where certain files and folders are excluded.</p> | |
<p>This option does not involve changing the nature of the workspace resource | |
tree and its relation to the file system. It simply adds ways to provide | |
filtered views of that resource tree.</p> | |
<p>A Java project source folder is currently specified with a project-relative | |
folder path. All *.java source files found in the project subtree are | |
automatically included in the Java model and on the Java compiler's class | |
path. The source folder specification could be enhanced to permit the user to | |
specify which files and folders to exclude (think <a href="http://jakarta.apache.org/ant/manual/CoreTypes/fileset.html">Ant | |
filesets</a>).</p> | |
<p>The source folders of a Java project are not currently allowed to coincide or | |
otherwise overlap. Some relaxation of this rule is required to handle the case where a source folder | |
containing tests is nested inside the main source folder (<a href="http://www.eclipse.org/eclipse/development/inflexible-projects-problem.html">Example | |
3</a>). One relaxation is to allow source folders to coincide or overlap but use the mechanism for excluding | |
files to prevent the same file from being included in both source folders.</p> | |
<p>This option would entail changing Eclipse Platform Core to provide infrastructure, possibly in the form of a rule-based resource | |
visitor. We would explore a possible connection to the existing UI notion of working sets. JDT Core API | |
and JDT UI would need to change as well, but could | |
likely be done in a non-breaking manner by adding working sets to | |
classpath entries (<a href="http://dev.eclipse.org:8080/help/content/help:/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/IClasspathEntry.html">IClasspathEntry</a>) | |
and revamping the rules for legal source folder overlap.</p> | |
<p><b>Option S-2 (orthogonal)</b>: Change JDT to allow overlapping source folders but | |
automatically exclude the overlapped portion from the parent.</p> | |
<p>A different approach is to provide the kind of selectivity required to handle | |
cases like where a source folder | |
containing tests is nested inside the main source folder (<a href="http://www.eclipse.org/eclipse/development/inflexible-projects-problem.html">Example | |
3</a>). The solution is to allow the overlap, but automatically exclude the | |
files accounted for by the more specific folder from the less specific one. For | |
example, if /src/ and /src/tests/ as both specified as source folders, files | |
under /src/tests/ would only appear under the latter source folder, and the | |
former source folder would act as if it had no child named tests.</p> | |
<p>This option would involve a non-breaking change to JDT to remove the current | |
restrictions that prohibit overlap and define how overlapping source folders are | |
interpreted. This option is orthogonal to the other selectivity options, and | |
could be done in conjunction with any of them.</p> | |
<p><b>Option S-3</b>: Radically change the Eclipse Platform policy for adding and removing | |
files from the workspace.</p> | |
<p>The workspace folder refresh operation (<a href="http://dev.eclipse.org:8080/help/content/help:/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/IResource.html#refreshLocal">IResource.refreshLocal</a>) automatically creates entries in the workspace resource tree | |
for newly discovered files and folders out in the file system, and discards | |
entries for any files and folders that are no longer present in the file system. | |
(This refresh action is also implicit in a number of workspace operations when | |
the force flag is used). This characteristic makes a project's workspace | |
resource tree a more-or-less faithful mirror of the project's subtree in the | |
file system. This gives workspace projects their all-inclusive feel.</p> | |
<p>There are other IDEs (including Visual Studio .net) that allow the user to | |
control which files and folders belong in a project; other files and folders may | |
exist in the local file system, but are simply ignored by the IDE if not flagged | |
as belonging to the project. This characteristic means that the IDE's notion of | |
project is more like a "view" onto files in the file system. This | |
alternate conception of workspace could be achieved by changing Eclipse policy | |
so that file and folder entries are never added to or removed from the resource | |
tree due to a refresh operation; new API would be added so that entries could be | |
added or removed explicitly. This would give workspace projects a selective | |
feel.</p> | |
<p>On the plus side, the resource tree would be smaller if some files and | |
folders were to be excluded, and this would improve performance. It would also | |
reduce workspace clutter and make Eclipse behave more like certain other popular | |
IDEs (Visual Studio .NET).</p> | |
<p>The downside of this option is that it is impossible to do while maintaining | |
compatibility. Consider an existing tool that is calling IResource.refreshLocal | |
to cause files created directly in the file system to appear in the workspace (a | |
common problem when bridging external programs to Eclipse). Changing the | |
semantics of IResource.refreshLocal so that it does not discover new files would | |
clearly break this tool. On the other hand, if the semantics of | |
IResource.refreshLocal is not changed, then running this tool would | |
automatically admit files to the workspace, even against the user's wishes. | |
Either path leads to a different kind of breakage.</p> | |
<p><b>Option S-4</b>: Add Eclipse Platform mechanism to prevent refreshLocal from | |
adding certain files to the workspace resource tree.</p> | |
<p>Another option is to change the Eclipse Platform refresh mechanism is a more | |
modest way to provide a way to selectively exclude files. If the refresh | |
operation was governed by exclusion rules, it would be possible for the user to | |
explicitly prevent certain files and folders in the file system from being added | |
automatically to the workspace. By default, there would be no exclusion rules, | |
and the workspace would behave exactly as in 2.0. If the user indicates that a | |
particular file or folder is to be excluded, the refresh operation would never | |
add it to the resource tree, even if the file or folder exists in the file | |
system. This would give workspace projects an initially all-inclusive feel which | |
could be made more selective as required.</p> | |
<p>New API would be required to change the exclusion rule set, to explicitly add | |
a file or folder to the resource tree even if on the excluded list, and to | |
remove a file or folder from the resource tree without deleting the file in the | |
file system. The semantics of IResource.refreshLocal would not have to change in | |
a breaking way. A project's workspace | |
resource tree is a more-or-less faithful mirror of the project's subtree in the | |
file system except for the files and folders that the user has explicitly taken | |
off the table.</p> | |
<p>On the plus side, the resource tree would be smaller if some files and | |
folders were to be excluded, and this would improve performance. It would also | |
reduce workspace clutter and make Eclipse behave more like certain other popular | |
IDEs. On the minus side, it does mean that in-memory workspace resource tree is | |
not quite as faithful a mirror of the file system.</p> | |
<p><b>Option S-5</b>: Add Eclipse Platform mechanism to hide certain files in the workspace resource | |
tree.</p> | |
<p> Eclipse Platform 2.0 has a "team private member" mechanism for | |
hiding certain resources. These resources are represented by entries in the | |
workspace resource tree, but are explicitly marked as hidden so that clients | |
will not see these resources unless they ask to see them. Imagine that this | |
mechanism was generalized and extended so that other resources could be | |
similarly hidden from clients that do not ask for them. By default, there would be no | |
hidden files, | |
and the workspace would behave exactly as in 2.0. The refresh operation would | |
automatically add and remove files as in 2.0. The user could explicitly control | |
whether they were marked as hidden, and whether hidden files were shown in the | |
UI. This would give workspace projects an all-inclusive feel | |
which the user | |
could make more selective as required.</p> | |
<p>New API would be required to change the hidden flag and to include or exclude | |
hidden resources when navigating the workspace. The semantics of IResource.refreshLocal would not have to change. A project's workspace | |
resource tree is a more-or-less faithful mirror of the project's subtree in the | |
file system except for the files and folders that the user has explicitly taken | |
off the table.</p> | |
<h3>Assessment </h3> | |
<ul> | |
<li>S-1 is promising.</li> | |
<li>S-2 is also promising; it provides less flexibility that S-1, but is also | |
simpler all around.</li> | |
<li>S-3 is a non-starter.</li> | |
<li>S-4 is promising.</li> | |
<li>S-5 is promising.</li> | |
</ul> | |
<h2>Allowing Overlap</h2> | |
<p>How could we change Eclipse to allow Java source folders to overlap?</p> | |
<p>Here are some options (in no particular order):</p> | |
<p><b>Option V-1</b>: Change JDT to allow overlap within a project's source | |
folders.</p> | |
<p>This option is discussed in S-1 and S-2.</p> | |
<p><b>Option V-2</b>: Allow "mounted" file system directories to | |
overlap.</p> | |
<p>One of the design details of option M-2 is whether to allow mounted | |
directories to overlap, either within a single project or across all projects in | |
the workspace. </p> | |
<p> The simple interpretation of overlapping mount points would mean that the same file on | |
disk might have multiple distinct resource handles. This would create a semantic | |
problem for the IWorkspaceRoot.getContainer/FileForLocation API methods which | |
presuppose that there is at most one resource handle for any candidate file system path.</p> | |
<p>Other issues if two resources /P1/Foo.txt and /P2/Foo.txt correspond to the | |
same file C:/Sources/Foo.txt:</p> | |
<ul> | |
<li>Refresh: Does refreshing one resource also refresh the other?</li> | |
<li>VCM: How to decide which project is responsible for VCM?</li> | |
</ul> | |
<h3>Assessment </h3> | |
<ul> | |
<li>V-1 is promising.</li> | |
<li>V-2 is promising, but has some API breakage, and some semantic questions | |
that need to be worked through.</li> | |
</ul> | |
<p>Options V-1 and V-2 are not necessarily mutually exclusive. There may be reason to allow overlapping source folders regardless of mount points, and vice-versa.</p> | |
</body> | |
</html> |