3

同じデータレイヤーを使用する内部と外部の 2 つの異なるプロジェクトが必要であり、ドライネスの理由で構成ファイルを複製することは避けたいと考えています。

http://www.playframework.org/documentation/2.0.2/SBTSubProjectsにあるサブ プロジェクトのドキュメントを確認しましたが、ドキュメントはかなり短いものです。

@Georg Engel のおかげで、構成をモジュール化する可​​能性を認識しています。

import sbt._
import Keys._
import PlayProject._

object ApplicationBuild extends Build {

    val appName         = "MyApp"
    val appVersion      = "1.0-SNAPSHOT"

    val appDependencies = Seq(
      // Add your project dependencies here,
    )

    lazy val common = Project(appName + "-common", file("modules/common"))

    lazy val website = PlayProject(
    appName + "-website", appVersion, path = file("modules/website")
    ).dependsOn(common)

    lazy val adminArea = PlayProject(
    appName + "-admin", appVersion, path = file("modules/admin")
    ).dependsOn(common)

    lazy val main = PlayProject(appName, appVersion, appDependencies, mainLang = SCALA).settings(
      // Add your own project settings here      
    ).dependsOn(
    website, adminArea
    )


}

そして、私が持っていたコンパイルエラーは、リバースルーターが原因でした（ルートをキャンセルしても、コントローラーのアクションではなく、これが発生します）

4

3 に答える 3

5

これが私がしていることとやったことです。私はマルチモジュール Mavenプロジェクトを作成し、基本的に再利用可能なコア コードをすべて保持しています。

次に、他のすべての Web プロジェクト (WAR を作成するプロジェクト) で、SBT、Gradle、さらには Ant と Maven プラグインを使用する場合もあります。これらのプロジェクトには、独自の構成 (db ホストや資格情報など) が保持されます。

framework
   - pom.xml
   - db-module
     - pom.xml
     - src/main/resources # possible classpath loading config here
     - etc...
   - mail-module
     - pom.xml
     - etc...
   - service-module
     - pom.xml
     - etc...

他のプロジェクトはフレームワークに依存するだけで、SBT プロジェクト (play 2.0) の場合は、リゾルバーの 1 つがローカルの Maven リポジトリになるように設定できます: https://github.com/harrah/xsbt/wiki/Getting-Started -ライブラリ依存関係

明確化のために編集: Framework pom.xml は親プロジェクトです。mail-module を db-module に依存させることができ、別の Web アプリ プロジェクトで mail-module に依存させるだけで、 mail-module と db -module の両方を取得できます。

多くの人が Maven を無視していますが、それでも Maven は他の何よりも優れたマルチモジュール プロジェクトを実行します。

詳細説明:

于 2012-08-03T11:49:38.283 に答える
2

このようなサブモジュールを使用しています (「コア」は共有サブモジュールです):

Build.scala

val coreModule = PlayProject(appName + "-core", "1.0", appDependencies, path = file("modules") / "core")

val main = PlayProject(appName + "-app", appVersion, appDependencies, mainLang = SCALA).settings(
  // Add your own project settings here      
).dependsOn(coreModule).aggregate(coreModule)

残念ながら、サブモジュールはプロジェクト ツリーの下に存在する必要があります (「../core」パスは使用できないため)。そのため、共有モジュールをツリーに入れるために git サブモジュールを使用しています。

git submodule add git://git.example.com/modules.git modules

git submodule init

git submodule update

おそらくSVN外部、mercurialサブモジュールなどもこの仕事をします。

于 2012-08-06T08:57:07.957 に答える
1

ソース ツリーのどこかに存在するモジュールへのソース依存関係は、必要なビルドを実現するのに役立ちます。

import sbt._
import Keys._
import PlayProject._

object ApplicationBuild extends Build {

    val appName         = "test"
    val appVersion      = "1.0-SNAPSHOT"

    val appDependencies = Seq(
      // Add your project dependencies here,
    )

    lazy val main = PlayProject(appName, appVersion, appDependencies, mainLang = SCALA).settings(
      // Add your own project settings here      
    ).dependsOn(common)


    lazy val common = RootProject(file("../common")) 


}

Play プロジェクトを別のプロジェクトと混在させることはできないため、構成は「依存関係」にある必要があります。ソースの依存関係の良いところは、それらがプロジェクト内に存在することです (SBT の再帰性のおかげです)。依存関係のソースが変更された場合、メイン プロジェクトは次のコンパイル時に変更を取得します。

私のマルチモジュール プレイ アプリの完全な構造は、 https ://github.com/un-jon/play2MultiModule で確認できます。

于 2012-08-06T18:04:26.907 に答える