Eine einfache Individualisierung hinzufügen

In dieser Lektion wird die Beispielaufgabe variabel: Ein Platzhalter wird mit einer minimalen individualization.json verbunden.

Bisher enthält Ihre Vorlage einen Platzhalter:

$Vehicle$

Jetzt verwenden Sie den divekit dev-Scan, um diesen Platzhalter zu inspizieren, und lassen anschließend --write-individualization das passende Grundgerüst für individualization.json anlegen.

Führen Sie zuerst divekit dev aus

Bevor irgendetwas geschrieben wird, schauen Sie sich an, was der Scanner findet:

divekit dev

Das ist ein reiner Lese-Scan: Er inspiziert das Projekt in seinem aktuellen Zustand und listet jedes noch unaufgelöste Token — ohne eine Datei anzufassen.

Solange noch keine passende Individualisierung existiert, sieht die Ausgabe so aus:

$ divekit dev
Scan source: origin project
Scanned 2 files, unresolved tokens: 4, invalid template tokens: 0, possible variable residues: 0, broken template fragments: 0, suggestions: 0

  UNRESOLVED TOKENS

$Vehicle$
  README.md:
    3: This assignment contains one placeholder: `$Vehicle$`.
  src/$Vehicle$.java:
    filepath contains token
    1: public class $Vehicle$ {
    3: return "$Vehicle$";

Lesen Sie die Liste aufmerksam, bevor Sie weitermachen: Der Scan meldet alles, was wie ein Platzhalter aussieht — auch Text, der nur zufällig so aussieht. Enthält die Liste ein Token, das Sie nie als Platzhalter gemeint haben (ein False Positive), korrigieren Sie zuerst die Quelldateien.

Dieser Check zählt in größeren Projekten noch mehr:

• ein Platzhalter kann leicht übersehen werden
• eine Datei kann ein Token verwenden, das Sie zu definieren vergessen haben
• ein verirrtes $...$ in einem Text kann auftauchen, obwohl es gar nicht variieren soll

Für dieses Einsteigerbeispiel ist der Check schnell erledigt: Das einzige unaufgelöste Token ist $Vehicle$ — und genau das wollen Sie.

Das Grundgerüst mit --write-individualization anlegen

Sobald die Liste nur noch Tokens enthält, die Sie wirklich individualisieren wollen, lassen Sie Divekit das Grundgerüst schreiben:

divekit dev --write-individualization

Das führt denselben Scan aus und legt zusätzlich .divekit/individualization.json an oder erweitert sie — mit einem Eintrag pro unaufgelöstem Token:

$ divekit dev --write-individualization
Scan source: origin project
Scanned 2 files, unresolved tokens: 4, invalid template tokens: 0, possible variable residues: 0, broken template fragments: 0, suggestions: 0

  UNRESOLVED TOKENS

$Vehicle$
  ...

Updated individualization scaffold at /home/your-name/vehicle-workshop/.divekit/individualization.json (1 new object entries)

Sie könnten individualization.json auch von Hand schreiben — das Flag spart Ihnen nur diesen Schritt, deshalb nutzt dieser Kurs es. Genau darum kommt der Lese-Check zuerst: Mit dem Flag landet jedes unaufgelöste Token in der Datei, False Positives eingeschlossen.

Wo individualization.json liegt

In diesem Kurs liegt die Datei auf Projektebene:

.divekit/individualization.json

Das generierte Grundgerüst prüfen

Das Grundgerüst registriert das fehlende Objekt, erfindet aber keine Optionen für Sie.
Direkt nach dem Scan sieht .divekit/individualization.json so aus:

{
  "version": "2.0",
  "variations": {
    "objects": [
      {
        "id": "Vehicle",
        "kinds": []
      }
    ]
  }
}

Die möglichen kinds ergänzen

Füllen Sie jetzt die Optionen aus, aus denen Divekit wählen darf:

{
  "version": "2.0",
  "variations": {
    "objects": [
      {
        "id": "Vehicle",
        "kinds": [
          {
            "id": "Car"
          },
          {
            "id": "Bike"
          },
          {
            "id": "Plane"
          }
        ]
      }
    ]
  }
}

Die Datei lesen

Wichtig ist diese Zuordnung:

• das Variationsobjekt wird durch Vehicle identifiziert
• Divekit darf eine der aufgelisteten kinds wählen
• das konkrete Ergebnis steht erst später bei der Distribution fest

Das bedeutet:

• ein Repository kann Car bekommen
• ein anderes Bike
• ein weiteres Plane

Platzhalter und Variation verbinden

Ihre Quelldatei enthält:

public class $Vehicle$ {
    public String kind() {
        return "$Vehicle$";
    }
}

Ihre Individualisierungsdatei definiert, wie Vehicle ersetzt werden darf.

Das zentrale Einsteigermuster ist:

• Platzhalter in der Vorlage
• passende Objekt-ID in individualization.json
• konkrete Auswahl später festgehalten in individuals.json

Was später passiert

Nach einer echten Distribution generiert Divekit individuals.json.

Diese Datei hält fest, welche konkrete Wahl für jede UUID tatsächlich getroffen wurde.

Die Unterscheidung ist also:

• individualization.json = mögliche Optionen
• individuals.json = tatsächlich gewählte Optionen

Den Scan nach Änderungen erneut ausführen

Nachdem Sie die generierte Datei geprüft oder verfeinert haben, führen Sie den Lese-Scan erneut aus:

divekit dev

Jetzt sollte der Scan Vehicle nicht mehr als unaufgelöst bemängeln.

Das ist das praktische Einsteigermuster:

• divekit dev ausführen und die unaufgelösten Tokens auf False Positives prüfen
• sie mit divekit dev --write-individualization ins Grundgerüst schreiben lassen
• die kinds in individualization.json ergänzen oder verfeinern
• divekit dev erneut ausführen, bis keine unaufgelösten Tokens mehr übrig sind

Ein sauberes Ergebnis, nachdem Sie die kinds ergänzt haben, sieht so aus:

$ divekit dev
Scan source: origin project
Scanned 2 files, unresolved tokens: 0, invalid template tokens: 0, possible variable residues: 0, broken template fragments: 0, suggestions: 0

Was Sie vergleichen sollten

Öffnen Sie diese zwei Dinge nebeneinander:

1. src/$Vehicle$.java
2. .divekit/individualization.json

Fragen Sie sich:

• verwendet der Platzhalter durchgängig Vehicle?
• definiert individualization.json exakt dieselbe ID?
• stehen drei Optionen zur Verfügung?

Wenn die Namen nicht exakt übereinstimmen, funktioniert die Individualisierung nicht.

Typische Fehler

Check

Führen Sie den Scan aus, lassen Sie das Grundgerüst schreiben, prüfen Sie .divekit/individualization.json und beantworten Sie dann: