Merging heterogeneous modules

Document Actions

Semantic

The kp (Kermeta Project) file describe how to weave different modules or files into the final kermeta model.

Since 2.0.98, the Kermeta model is composed of "Metamodel", each metamodel is defined by a kp project. A kp defines one and only one metamodel/project. It can however import existing

The "import" defines the kermeta sources that must be embedded in the project/metamodel being built.

The "importProject" refers to a reusable resource (defined in the kp) which contains either another kermeta project or bytecode to be added on the classpath. If this is a kermeta project .

The syntax of this kp support the following features :

Variable expansion

The kp support some variable expansion in the import and resource urls

The syntax ${varName} is automatically replaced by the associated value.

varName can be a system property. The variable is replaced by the system property value

varName can be "project.baseUri". The variable is replaced by the physical location of the folder containing the current kp file.

varName can be "<resource.name>.baseUri". The variable is replaced by an url allowing to look for resources into the associated the jar or folder (Allowed only in import)

import modifiers

A import can be modified in the following ways :

using EMFBytecode(<NameOfTheResourceContainingTheByteCode>) : applicable for a source that is an ecore file. If present, instead of generating the emf genmodel and bytecode for this ecore file, Kermeta will use the bytecode provided in a dependency.

Additionnaly, the "packageEquivalences" defines some mapping to help the compiler to know how was generated the java code for a given EPackage. This is useful when the genmodel declares some "basePackage" and thus changes the package hierachy of the generated code.

Rationale

We need a simple but flexible way to merge the various input sources into the final km model.

It also need to provide the information about the assembly of the generated bytecode and optional legacy bytecode.

The sources might be heterogeneous (kmt, km, ecore, uml (import the profiles definitions))

Open discussion

Example

Minimal sample:

resource library_standard ="platform:/plugin/org.kermeta.language.library.standard" alternative "mvn:org.kermeta.language/language.library.standard/2.0.98"
importProject library_standard
project hello {
mainClass "hello^mainPackage::MainClass"
mainOperation "mainOperation"

import "${project.baseUri}/src/main/kmt/MainClass.kmt"
}

// resource point to a jar by looking first in eclipse workspace (if running in eclipse) or a specific version in a maven repository.

// the jar library_standard is reused without any changes (no aspect allowed)

// the default main operation is searched in the current project/metamodel

// looks for some kmt file in the current folder

More complex sample:

resource library_standard ="platform:/plugin/org.kermeta.language.library.standard" alternative "mvn:org.kermeta.language/language.library.standard/2.0.98"
resource uml_model ="platform:/plugin/org.eclipse.uml2.uml"
resource ecore_model ="platform:/plugin/org.eclipse.emf.ecore"
resource uml_common = "platform:/plugin/org.eclipse.uml2.common"

importProject library_standard
importProject uml_common

project testUML2ecore{
mainClass "testUML2ecore^mainPackage::MainClass"
mainOperation "mainOperation"

    import "${project.baseUri}/src/main/kmt/UML2Ecore.kmt"
    import "${project.baseUri}/src/main/kmt/SomeUMLAspect.kmt"
    import "${uml.model.baseUri}/model/UML.ecore" using EMFByteCode(uml_model) {packageEquivalence "uml" = "org.eclipse.uml2.uml"}
    import "${ecore.model.baseUri}/model/Ecore.ecore" using EMFByteCode(ecore_model) { packageEquivalence "ecore" = "org.eclipse.emf.ecore" }
}

Sample with extension (and aspects ) on top of another kermeta project:

resource library_standard ="platform:/plugin/org.kermeta.language.library.standard" alternative "mvn:org.kermeta.language/language.library.standard/2.0.98"
resource my_base ="platform:/resource/org.company.my_base" alternative "mvn:org.company/my_base/1.0.0"
importProject library_standard
project my_project extend my_base {
import "${project.baseUri}/src/main/kmt/SomeClassAspect.kmt"
}

Planned evolution

Support for more input formats :

QVT, ALF, KET, java, OCL

Support for disambiguating rules : rename

support for using KMFBytecode; KMF provided by Kevoree offers a more efficient EMF implementation which might be useful when EMF compatibility isn't required. (It still offers XMI interchange, so it can be used in many case)

Navigation