From 86f506135c8b2cfd9011d779fbfc97d147cd4b9f Mon Sep 17 00:00:00 2001
From: Joris Wouter Jonkers <info@jorisjonkers.dev>
Date: Wed, 16 Sep 2026 19:51:46 +0200
Subject: [PATCH] fix(emf): remove the two things that would break an
 examiner's import

#132 asks for a clean Eclipse import to be proved by hand, which needs a person
at the IDE. Two of the failures it predicts can be removed first, so that
session confirms rather than debugs.

**m2e had no lifecycle mapping for `exec-maven-plugin`**, which is how both
metamodels generate their typed Java. Without one, an import reports "Plugin
execution not covered by lifecycle configuration" against every such execution,
and a grader meets a red workspace before reading a line of the model. The
mapping is declared in `pluginManagement`: Maven ignores it, m2e reads it.
`runOnIncremental` is false, because regenerating a metamodel on every
keystroke helps nobody and a full build still runs it. #87 made this worse
without noticing, by adding a second execution.

**The generated sources do not exist at import time.** `build.properties` names
`target/generated-sources/emf/` as a source folder, and on a clean clone that
directory is not there: import first and the workspace opens with every
reference to a generated package unresolved. The README now opens with the
terminal build and says why, which is the second acceptance criterion taking
its own "or" branch.

The README also notes that five of the six modules are `eclipse-plugin`
packaging, which m2e maps through the Tycho configurator, so the importer may
offer to install a connector.

Every file the instructions name was checked against the tree: `emf.target`,
`skeleton.ecore`, `empty.xmi`, `skeleton.ocl`, `notes.xmi`, `identity.launch`
and `file.launch` all exist. What remains is the import itself, and the
issue stays open for it.
---
 emf/README.md | 11 ++++++++++-
 emf/pom.xml   | 31 +++++++++++++++++++++++++++++++
 2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/emf/README.md b/emf/README.md
index 9602337..7e40b48 100644
--- a/emf/README.md
+++ b/emf/README.md
@@ -55,11 +55,20 @@ bundles `emf.target` pins.
 For examiners, in Eclipse Modeling Tools 2026-06 with the OCL, QVT-Operational
 and Acceleo 4 SDKs installed from the same release:
 
+0. Run `./mvnw verify` once, from `emf/`, before importing anything. Each
+   metamodel's typed Java is generated into `target/generated-sources/emf/`,
+   which `build.properties` names as a source folder, and on a clean clone that
+   directory does not exist yet: import first and the workspace opens with
+   every reference to a generated package unresolved. One terminal build is
+   what makes the import land clean.
 1. Open `emf/emf.target` and choose **Set as Active Target Platform**.
 2. **File > Import > Maven > Existing Maven Projects**, with `emf/` as the
    root directory. The importer walks the whole tree, so that one root
    still finds the five bundles nested under `emf/bundles/` and the parity
-   suite nested under `emf/tests/parity`; import every module.
+   suite nested under `emf/tests/parity`; import every module. Five of the six
+   are `eclipse-plugin` packaging, which m2e maps through the Tycho
+   configurator: accept the connector if the importer offers to install one,
+   and restart when it asks.
 3. In `dev.jorisjonkers.deploykit.emf.metamodel`, open `model/skeleton.ecore`.
    Open `model/empty.xmi` with the Sample Reflective Ecore Model Editor, load
    `model/skeleton.ocl` through **OCL > Load Document**, and validate: the
diff --git a/emf/pom.xml b/emf/pom.xml
index f196cd1..c5a9cd4 100644
--- a/emf/pom.xml
+++ b/emf/pom.xml
@@ -99,6 +99,37 @@
         <plugin><groupId>org.eclipse.tycho</groupId><artifactId>tycho-bnd-plugin</artifactId><version>${tycho.version}</version></plugin>
         <plugin><groupId>org.eclipse.tycho</groupId><artifactId>tycho-source-plugin</artifactId><version>${tycho.version}</version></plugin>
         <plugin><groupId>org.codehaus.mojo</groupId><artifactId>exec-maven-plugin</artifactId><version>3.6.4</version></plugin>
+        <!--
+          m2e reads this and Maven ignores it. Without it an Eclipse import
+          reports "Plugin execution not covered by lifecycle configuration"
+          against every `exec-maven-plugin` execution, which is both metamodel
+          generators, and a grader meets a red workspace before reading a line
+          of the model (#132). `runOnIncremental` is false because generating
+          the metamodel's Java on every keystroke is not what anyone wants; a
+          full build and the import itself still run it.
+        -->
+        <plugin>
+          <groupId>org.eclipse.m2e</groupId>
+          <artifactId>lifecycle-mapping</artifactId>
+          <version>1.0.0</version>
+          <configuration>
+            <lifecycleMappingMetadata>
+              <pluginExecutions>
+                <pluginExecution>
+                  <pluginExecutionFilter>
+                    <groupId>org.codehaus.mojo</groupId>
+                    <artifactId>exec-maven-plugin</artifactId>
+                    <versionRange>[3.0.0,)</versionRange>
+                    <goals><goal>java</goal></goals>
+                  </pluginExecutionFilter>
+                  <action>
+                    <execute><runOnIncremental>false</runOnIncremental></execute>
+                  </action>
+                </pluginExecution>
+              </pluginExecutions>
+            </lifecycleMappingMetadata>
+          </configuration>
+        </plugin>
         <plugin><groupId>org.jetbrains.kotlin</groupId><artifactId>kotlin-maven-plugin</artifactId><version>${kotlin.version}</version></plugin>
       </plugins>
     </pluginManagement>