| <!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="GENERATOR" content="Mozilla/4.75 [en] (Win98; U) [Netscape]"> |
| </head> |
| <body> |
| |
| <h1> |
| 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> |
| <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> |
| <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 |
| to.</p> |
| <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> |
| <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> |
| <p>Thus, extension directories would just be particular cases of library |
| ones, and be eligible in classpath variables.</p> |
| </body> |
| </html> |
