Interface ElementPathLoader

All Known Implementing Classes:
DirectoryElementPathLoader

public interface ElementPathLoader
Used to load Element instances from local paths on disk. As a single Element may span multiple sources for executable code, this provides loading semantics for code on disk in a structured manner. When loading Elements, the loader will search a Path with the following rules.
  • If the Path is a file, it will assume that the entire Element is in one file.
  • If thd Path is a directory, it will assume all files in the directory make up the Element
  • For each directory in the Path, it will create a new subordinate ElementRegistry
  • Each loaded Element will follow the hierarchy of the directory.
  • Empty directories, or directories containing directories will be skipped.
  • Aside from those specified (lib and classpath), directory names are irrelevant. All Element metadata will come from the annotations.
When searching each directory, the ElementPathLoader will look for the following files/directories to determine the makings of the Element.
  • dev.getelements.element.attributes.properties - custom attributes for the Element
  • lib - every file is assumed to be a jar file
  • classpath - every file inside this directory is added to the classpath
For example, let's say we have the following directories with the following Elements define inside each of them:
  • foo - com.example.foo
  • foo/a - com.example.foo.a
  • foo/b - com.example.foo.b
  • bar - com.example.bar
  • bar/a - com.example.bar.a
  • bar/b - com.example.bar.b
This will result in six ElementRegistry instances and Element instances chained as follows:
  • Root
  • Root -> Foo
  • Root -> Foo -> A
  • Root -> Foo -> B
  • Root
  • Root -> Bar
  • Root -> Bar -> A
  • Root -> Bar -> B