| <!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>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 | |
| to. | |
| <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. | |
| </body> | |
| </html> |