2016-05-16 9 views
0

Ich habe ein von SBT verwaltetes Scala-Projekt, das eine Reihe von Klassen enthält, bei denen es sich um Adapter handelt, die mit proprietärem Code verknüpft sind. Diese verfügen über kommerzielle Lizenzen, die die Verteilung von verknüpften Bibliotheken sowie den von mir selbst geschriebenen Adaptercode ausschließen.Wie strukturiere ich ein JVM-Projekt, um proprietären Code zu isolieren?

Ich möchte diese Adapter vom Rest meines Codes isolieren, so dass ich theoretisch mein Projekt als Open-Source verteilen könnte. Ich muss sicherstellen, dass jeder Adapter

  • ist Version separat gesteuert wird.
  • selektiv on/off während der Kompilierung & JAR Schaffung geschaltet werden

Was sollte die Verzeichnisstruktur in etwa so aussehen (wie --with-xxx Art, wenn ./configure in einem C-Projekt ausgeführt wird)? Was ist mit den SBT-Projekten? Ich möchte, wenn möglich, die übliche Verzeichnisstruktur von Gradle einhalten. Das zu berücksichtigende Problem ist, dass jeder Adapter vom Kernprojekt abhängt (d. H. Er erbt eine im Hauptprojekt definierte Schnittstelle Adapter), und sein Kernprojekt hängt wiederum von einzelnen Adaptern ab. Ich bin mir also nicht sicher, wie ich das einrichten soll, um zirkuläre Abhängigkeiten zu vermeiden, während ich den Kerncode vom Adaptercode isoliere.

+0

Sind die Abhängigkeiten der Adapter auf dem Kernprojekt für die Kompilierung benötigt der Haupt Quellcode oder nur für die Tests? – Teliatko

Antwort

1

Es kann auf diese Weise erreicht werden:

  1. die Adapterschnittstelle von dem ‚Kern‘ Modul in ein neues Modul-Extrakt ‚Adpater-api‘;
  2. Deklarieren Sie es als eine Abhängigkeit für das Kernmodul und alle Adapterimplementierungsmodule;
  3. Deklarieren Sie "Kern" als eine Abhängigkeit der Adapter-Implementierungsmodule.
  4. Jedes Modul kann separat versioniert werden.
  5. Und Adapter-Implementierungsmodule sind separat verpackt.

Projekt Layout:

root 
├── adapter-a 
│   └── src 
│    └── main 
│     ├── resources 
│     └── scala 
├── adapter-api 
│   └── src 
│    └── main 
│     ├── resources 
│     └── scala 
├── adapter-b 
│   └── src 
│    └── main 
│     ├── resources 
│     └── scala 
└── core 
    └── src 
     └── main 
      ├── resources 
      └── scala 

build.sbt:

lazy val root = project 
    .in(file(".")) 
    .aggregate(adapterApi, core, adapterA, adapterB) 

lazy val adapterApi = project 
    .in(file("adapter-api")) 
    .settings(
    version := "1.0" 
) 

lazy val core = project 
    .in(file("core")) 
    .dependsOn(adapterApi) 
    .settings(
    version := "1.5" 
) 

lazy val adapterA = project 
    .in(file("adapter-a")) 
    .dependsOn(adapterApi, core) 
    .settings(
    version := "1.2" 
) 

lazy val adapterB = project 
    .in(file("adapter-b")) 
    .dependsOn(adapterApi, core) 
    .settings(
    version := "1.0" 
) 
+0

Dank @thirstycrow; Dies beantwortet den ersten Aufzählungspunkt. Wie würde dies den zweiten Punkt beantworten? Wenn ich 'publish 'von der sbt-Konsole mache, vermute ich, dass dies * das gesamte Projekt * in eine JAR-Datei packen wird, richtig? Wie würde ich bei der Verpackung für ein Release selektiv jeden Adapter einschließen/ausschließen? – Luciano

+0

@Luciano Jedes Projekt ist ohne Abhängigkeiten verpackt. Sie können das sbt-assembly-Plugin verwenden, um ein fat jar zu erstellen, aber das ist nicht das Standardverhalten. – thirstycrow

+0

Um die Dinge etwas sauberer zu machen, können Sie auch den Befehl 'git submodule' verwenden, um einen 'root' Repo in der Quellcodeverwaltung zu haben, und dann einzelne 'repositor' Reporte, die separat ausgeschlossen/versioniert werden sollen. – Luciano

Verwandte Themen