Classpath Manager

The classpath manager currently lives in org.asdt.core, but it might move, it might not.

Like the build manager (in org.asdt.compiler) the classpath manager stores a projects classpath in an xml file, this time called .asdt_classpath

Each entry of the file corresponds to an IClasspathEntry and records the location and type of the path and if the path is exported.

Here is an example classpath file : 

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
  <classpathentry exported="true" kind="source" path="src" />
  <classpathentry exported="false" kind="project" path="/Project B" />
  <classpathentry exported="true" kind="link" path="logger" />
</classpath>

There are currently 3 kinds of classpath entry : source, link (a linked folder) and project. Source and link paths are relative to their project and project paths are specified from the workspace root.

The export flag is important when using project dependencies as it determines which classpath entries are visible to projects ‘upstream’. For example if Project A has a classpath entry for Project B and Project B exports one classpath entry then that entry is available in Project A.

To obtain the classpath for a project you can either request the raw classpath, which is a List of IClasspathEntry as specified in the classpath file or you can ask for the resolved classpath which is a List of IContainer fully specifying the classpath with all project dependencies resolved. At the moment there is no protection against circular project dependencies so asking for a resolved classpath with circular dependencies will prove harmful.

As I see it there are 3 choices for dealing with the circular dependency issue

  1. Check the project tree when asked for a resolved classpath and only resolve a project once.
  2. Limit the resolution depth to 1. e.g. if Project A requires B and B requires C then asking for A’s resolved classpath WONT retrieve C.
  3. Analyse the classpath tree when the user attempts to add a project and prevent them from creating circular dependencies.

the third seems like the best plan, it just needs implementing. :-)