When you need to refer explicitly another entity defined in another file, you have to use the require primitive. It allows loading definitions of an other Kermeta file when file is processed. In the following example, we define a class C which inherits from the A class previously defined.

// file : MyPackage-part1.kmt
package subPackage1;

class A 
{
  // ...
}

// file : MyPackage-part2.kmt
package MyPackage;
require "MyPackage-part1.kmt"

class C inherits subPackage1::A 
{
	// ...
}

You can require different kind of entity

Obvioulsy, you can require Kermeta textual syntax, ie. *.kmt files

You can require Kermeta models, ie. *.km files .

You can require Ecore models, ie. *.ecore files . These models can then be used as if they were written in Kermeta. In order to add behavior to the classes defined in .ecore files you may : use the weaving to dynamically weave behavior to the ecore, or roundtrip using the button action in the workbench (ecore->kmt->ecore) to statically add the behavior (as EAnnotations) into the ecore file.

In order to use the seamless java import (still prototype in v0.4.2), you can require a jar file . It will automatically convert the java into a Kermeta representation in order to be able to call java code as if it was written in Kermeta. see Section 2.24, “Using existing java code in Kermeta ” for more details.

Kermeta reuse some of the protocols provided by Eclipse.

Relative path.  You can use a path relative to the current file using the normal syntax (./ , ../, etc)

Eclipse workspace relative path.  In Eclipse, you can use a path relative to the user's workspace. In that case the path looks like platform:/resource/ your_project_name / path_to_the_file

Eclipse plugin relative path.  In Eclipse, you can use a path that search in the installed plugins. In that case the path looks like platform:/plugin/ plugin_name / path_to_the_file

Eclipse workspace or plugin relative path.  When deploying Kermeta code, it is sometime interesting to search in both the user's workspace and in the plugins. In that case the path looks like platform:/lookup/ plugin_or_project_name / path_to_the_file

Registered Ecore.  A variant of requiring an ecore file is to require a registered EPackage . When Eclipse deploys an ecore model plugin, it also registers the EPackage using a unique identifier (nsuri) in order to retreive it quickly. In Kermeta you can also use this nsuri into the require statement. This approach is useful because you can be sure that you require the very same model as Eclipse use to load and save models of that sort. For example, instead of requiring ecore.ecore you may use require "http://www.eclipse.org/emf/2002/Ecore" . This also works for all other registered metamodels (Your own registered metamodel, UML metamodel, etc). Kermeta user interface provides a view that display all registered EPackages and their nsuri.

Kermeta lets you organise your code the way you prefer. There is no predefined organisation of your code, but the language and the workbench proposes various mechanisms and tools to structure it according to your needs and the style you wish for your code. Typically if you use Kermeta internal weaver (see Section 2.22, “ Weaving Kermeta code ” ), manually transform your ecore into Kermeta, eventually weaving the ecore using the merge button available on the worbench.

For example, you can put all your classes into a single file (like in Ecore, every classes is in the .ecore file) or you may create a file for each of them and then use the require to indicates that they must know each other. You can also use an organisation like java, with a file per class and a directory per package.