blob: 4e3aa79adbfb6b2e6c71858feb24a9d5b1d5d240 [file] [log] [blame]
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.75 [en] (Win98; U) [Netscape]">
Extension Directory Support</h1>
The WSAD effort has exposed the need for extension directories so as to
simplify their classpath setup. Interestingly enough, the classpath rework
(make classpath less sensitive to project change from source to binary
form) has some nice connections with this project.
<p>The direction followed would allow to contribute all JARs contained
inside a given project to dependent projects. Thus such a project could
act as an extension directory relatively to its dependent projects. This
would however require to materialize such extension directories with true
projects, and could be considered as one way to achieve this, but a true
extension directory support should also exist, in a similar way as we allow
users to directly refer to external JARs if they want.
<p>We could add a new classpath entry kind for these. Now the next issue
is: do we allow classpath variables to denote extension directories ? Presumably,
this would be expected.
<p>A classpath variable is not bound to a particular classpath entry, but
rather to an IPath which is then resolved when the variable is substituted
with a resolved classpath entry. The resolution process can either bind
a variable to a project or a library, depending to what the IPath maps
<p>In the library case, it can either be an archive file (*.jar, *.zip)
or a binary folder (*.class files). The distinction is made again depending
on the nature of what the IPath maps to, is it a JAR/ZIP file or a folder.
Now, if we want to fit the extension directory support in this, it will
be hard to distinguish in between a folder containing JARs or .class files...
<p>We could however imagine that the syntax of the IPath would tell which
one is expected to be resolved. For example, a path of the form "/SomeDirectory"
would continue to indicate a binary folder, whereas "/SomeDirectory/*"
would mean an extension directory. The benefit for this is that we actually
do not need to add a new type of entry. We just add a third flavor of a
library entry, the one mapping to an extension directory.
<p>Thus, extension directories would just be particular cases of library
ones, and be eligible in classpath variables.