This project contains classes (not otherwise related, necessarily)
that AMIL will load and invoke as needed. There are two areas:
- com.bae.meta.dynamic contains implementations and utilities for the
  AMIL dynamic node service (see DynamicNodeService and IDynamicNode
  in the AMIL source directory). This is how "dynamic" nodes (a
  generalization of the old "external" nodes, which are now
  implemented using this mechanism) are handled. See below for
  details.
- com.bae.meta.amilextern contains implementation classes for external
  nodes, which are invoked through the External dynamic node
  provider. They all implement the IExternal interface. Only the
  GenericExecutable class is used in the demo; the others are for
  testing.

To compile this directory, you need to have run mvn install on the
manual artifacts project recently (after an update since June 17) to
get the SPI JAR into your repository. 
[For Eclipse follow the docs/MavenAndEclipse.pdf]
<strike>  Further, to build in Eclipse,
you need to modify the settings for the AmilExtern project to install
the SPI JAR as an annotation processor. For the latter step, go to
properties for the project, and navigate to Java Compiler/Annotation
Processing. Check Enable project specific settings, Enable annotation
processing, and Enable processing in editor. Then select the Factory
Path dialog (under Annotation Processing), once again Enable project
specific settings, and use Add JARs... to add a reference to the
ManualArtifacts project jars/spi-full-2.4.jar. This will allow
compilation of the @ProviderFor annotation that you'll find in, for
example, External.java.
</strike>

These services are loaded using Java's ServiceLoader class, which
requires JDK >= 1.6. The annotation manages the bookkeeping required
for Java to find the implementations, because it searches a
distinguished subdirectory of META-INF. At execution time, AMIL will
get into this code if it's retrieving a node with a non-null valueType
attribute other than "immediate" (for example, "external"). It uses
the ServiceLoader mechanism to find a class whose getServicedType()
method returns a string matching the valueType attribute; it then
calls the getNodeMap method of that class, which does whatever it
needs to (in the case of "external" nodes, this then looks in the node
for a class name, loads the class, and runs its invoke() method).

Other node types, such as "metric," will be added as required.


// TODO - for Sept demo


Populate CML - search data / data:
	search data: populated using OWL, nodes that are in the ontology
	need to use a single ontology; IAN's
	At startup AMIL loads ontology. 
	CML meta data will be a separate file loaded, for now will load when we clear the db.
	The meta data has to be OWL data - need to translate the current engine data into this format. (18 engines) - Marty
		I [ASK] assume that this will include a mvn coordinate for each engine.
	Greg and Tim - find common ontology
	Brent does not actually need engines in Artifactory; he is using the nodes ( meta data )
	Ethan will populate 18 engines into Artifactory
	
Query CML:
	sprql query returns a set of json objects {class:node ids}
	Examples to be sent out by Tim


Use returned nodes:
Use a CML node:
	ASK - implement the cmllink node type.

Issue: unit conversion, we are not doing - none is being done - so we need to agree
 length - meters
 weight - kg
 power - watts
 
 
Getting sysml model from Artifactory:
	Engine has a cml coordinate
	the cml entry would have a sysml selector that can get back url for the sysml file in Artifactory (mdzip files)