sbt Plugin dynamisch benutzerdefinierten Code laden?

8

Ich arbeite an einem sbt-Plugin , das Scala-Modelle erzeugt, die mit Slick-Code-Generator

Ich würde natürlich wollen, dass Benutzer den Code-Generator überschreiben, so dass mein Plugin dies unterstützen muss:

  • Wie auch immer, ich kann eine Scala-Klasse dynamisch laden, wenn ein Pfad dazu in den build.sbt-Plugin-Schlüsseln angegeben ist. Zum Beispiel würde sie im Elternteil build.sbt des Benutzers etwas wie codegen.override=com.company.project.CustomCodegenerator bereitstellen, das sieht so aus

  • Ähnlich wie oben; Der benutzerdefinierte Codegen kann einige andere Bibliotheken verwenden, sodass eine einfache dynamische Klassenlast möglicherweise nicht ausreicht. Wie auch immer, ein sbt-Plugin kann die Abhängigkeiten des Projekts mit diesem Plugin erben.

Hier ist die vollständige Diskussion darüber: Ссылка

    
pathikrit 19.11.2014, 19:06
quelle

1 Antwort

2

Am Ende des Tages müssen Sie etwas Code ausführen, um Scala-Quelldateien zu erzeugen.

Dateien generieren

Wie Sie wissen, verfügt sbt über einen Hook zum Erzeugen von Quelldateien mit dem Namen sourceGenerators , der in Dateien generieren . Sie als Autor des Plugins sollten eine Aufgabe bereitstellen, die Seq[File] unter (sourceManaged in Compile).value / "garfield" erzeugt, indem Sie den Slick-Code-Generator als Standardimplementierung verwenden. Nennen wir das generateModel . Ihr Plugin könnte die folgenden Einstellungen haben:

%Vor%

Wenn Ihr Build-Benutzer generateModel neu verkabeln möchte, könnte er dies folgendermaßen tun:

%Vor%

Wenn die Code-Generierung wie oben beschrieben im sbt-Plugin enthalten ist, müssen Sie keine dynamischen Dinge tun. Da play-slick-evolutions-codegen-plugin von Slick-Codegen abhängt, sollte dies kein Problem sein.

Den Code des Benutzers dynamisch laden

Da die Frage direkt auf das dynamische Laden des Benutzercodes gerichtet ist, würde ich auch einige Hinweise darauf geben.

  • Eine Möglichkeit ist die Verwendung von sbt.Run API von einem bestehende Konfiguration Dies entspricht dem Aufruf von run task mit einigen benutzerdefinierten Parametern. Wenn Sie Code für die Compile -Konfiguration generieren, ist es nicht sinnvoll, den Runner für jede Konfiguration zu verwenden, die davon abhängt.
  • Ein anderer ähnlicher Weg ist die Verwendung von sbt.Fork API . Mit Forking können Sie Code außerhalb des Plugins ausführen.

Gegeben, dass sbt automatisch Aufgaben basierend auf den Abhängigkeiten zwischen ihnen ordnet und mehrere Tasks parallel ausführt, ist die dynamische Ausführung von Code mit unerwarteten Gefahren behaftet.

    
Eugene Yokota 09.01.2015 07:44
quelle