| | |
|
|
|
Zero Application Classpath
Project Zero uses conventions for locating files to be added to the classpath. This section describes what is added to your application's classpath by default.
Classloading
Zero applications use the system classloader for loading classes except groovy classes and scripts, which are dynamically loaded by the GroovyClassLoader. In the spirit of radical simplicity, we intend to keep the classloader complexity to a minimum, so we do not intend to add any additional classloaders in the core libraries.
Local Application Classpath Entries
There are two directories that are added to the classpath under the application's home directory. These are /classes and /lib.
The /classes directory is the target directory for the compiled java source located in /java. The /lib directory is a location for adding third-party JAR libraries that cannot be resolved remotely by the zero ivy resolver. For more information on the application's directory layout, see Application Layout.
Ideally, you should try to find any libraries that you depend on in a remote repository, either a zero one or a maven one. See Dependencies and Packaging. This allows the application to easily change versions by editing the ivy.xml dependencies and reduces the size of the application package. Sometimes, however, you will not be able to resolve your dependency from a remote repository. For example, you may need to use a licensed library that is not available in the repository. In this case, you can copy the JAR files into the /lib directory under your application home directory. If you're using the Zero command line, then zero resolve will update your application's classpath. In Eclipse, the plug-in is triggered by changes in /lib to update the classpath.
Adding native libraries to your application
In addition to classloading conventions, Zero also uses some conventions for adding native libraries to the java.library.path so they can be loaded via loadLibrary. You can add native libraries into an appropriate subdirectory under /lib that has the name of the target platform. For example, to add a native .so library for linux x86, you would copy the .so file into /lib/x86/Linux. The zero run command and Eclipse launch configuration will use these system properties to locate the directory to be added to your java.library.path.
The native support for a zero application needs to be extensible, and also configurable by the application. The application can define the operating system names and architectures that have native support. The Zero environment will provide two property files that will contain the default mappings. These property files are located in the config directory under zerohome, and can be updated to define newly supported environments. The application can also provide a copy of these files in the config directory of the application to customize the mappings.
Operating System Name
The current operating system name is obtained from the System property os.name. The file osNameMappings.properties provides the default mappings for the os.name, similar to Ant's family. So for example, Windows 95 and Windows XP are both mapped to windows. If the application actually needs a Windows XP specific library, then the osNameMappings.properties file can be copied into the config directory of the application and modified. If a mapping for the os.name value is not found, then the os.name value is returned. The keys in the mapping files are lower cased, while the values can be mixed case, and spaces are supported for the keys and values.
Architecture Type
The architecture type is a little more complicated. The base architecture type is obtained from the System property os.arch. The same type of mappings are provided through osArchMappings.properties file. So for example i386, x86_64 and i686 are all mapped to x86 by default. The actual architecture type is determined from the base type and the bit size of the JVM. The system property sun.arch.data.model is used to determine the JVM bit size. For example, os.arch type of x86_64 would result in a base type of x86. The architecture type lookup on a JVM whose bit sized is determined to be 32, would perform a lookup of x86.32 to get the value x86. The same lookup on a JVM with a bit size of 64 would lookup x86.64 which has a value of x86_64. If the bit size can not be determined then the base architecture type is used. If a mapping for the os.arch value is not found, then the os.arch value is returned. The keys in the mapping property file are lower cased, but the values can be mixed case.
The Native libraries
The native library path is determined at resolve time, and a property natives is set in the .zeroresolved.properties file. The Operating System and Architecture are determined as described above. The natives path is expected to exist under the lib directory of the application, lib/${architecture}/${os_name}. If the path exists then the natives property is set.
The application can use the default mappings to determine the directory names to place the native libs. If, however, these mappings are not sufficient, the mappings can be be customized by the application, by providing the properties files in the config directory of the application.
Resolved Dependencies
As explained in Dependencies and Packaging. Zero is capable of resolving your application's dependencies from local and remote repositories. When resolving from a remote repository, the libraries are copied into a local repository. The zero CLI commands and eclipse plug-in will add the necessary JAR files from the local repository to your classpath, and the necessary native library directories to your java.library.path.
|
|
r3 - 08 Feb 2008 - 11:15:12 - steveims
|
|
|
| | |
