This topic describes using the how the module classpath is determined.
&ProductName; uses conventions for locating files to be added to the classpath. This section describes what is added to your module's classpath by default.
Modules 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.
There are two directories that are added to the classpath under the module'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 &ProductName; ivy resolver.
Ideally, you should try to find any libraries that you depend on in a remote repository, either a WebSphere sMash or a maven repository. See Dependencies and Packaging. This allows the module to easily change versions by editing the ivy.xml dependencies and reduces the size of the module 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 module home directory. If you're using the &ProductName; command line, then resolve will update your module's classpath.
In addition to classloading conventions, &ProductName; 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 start command will use these system properties to locate the directory to be added to your java.library.path.
The native support for a module needs to be extensible, and also configurable by the module. The module can define the operating system names and architectures that have native support. The &ProductName; command line 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 module can also provide a copy of these files in the config directory of the module to customize the mappings.
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 module actually needs a Windows XP specific library, then the osNameMappings.properties file can be copied into the config directory of the module 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.
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, not the machine. 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 library path is determined at resolve time, and a property natives is set in the .zero/private/resolved.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 module, lib/${architecture}/${os_name}. If the path exists then the natives property is set.
The module 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 customized by the module, by providing the properties files in the config directory of the module.