This interface defines a strategy for loading module definitions. The module definition hierarchy can be loaded by any implementation of {@link ModuleDefinitionSource}. Module definitions are not metadata. When you load a {@link ModuleDefinition} you are not loading the module, just anabstract representation of what the module is supposed to contain. There are a number of implementations of ModuleDefintionSource. Which implementation is best to use depends on the circumstances. {@link org.impalaframework.module.source.XMLModuleDefinitionSource} uses by default an
moduledefinitions.xmlplaced on the web application class loader's class path (for example, in _WEB-INF\classes). For integration tests, it's easier to implement {@link org.impalaframework.module.source.InternalModuleDefinitionSource} incode the test directly. Here's an example:
public class EntryDAOTest implements ModuleDefinitionSource { ... public RootModuleDefinition getModuleDefinition() { return new InternalModuleDefinitionSource(new String[]{"example-dao", "example-hibernate"}).getModuleDefinition(); } } The example above uses {@link InternalModuleDefinitionSource}, which involves a passed in array of names of modules.
@see InternalModuleDefinitionSource
@see XMLModuleDefinitionSource
@author Phil Zoio