You are viewing the documentation for the 2.3.x release series. The latest stable release series is 2.4.x.


複雑なプロジェクトを、一つの Play アプリケーションにまとめる必要はありません。大きなプロジェクトは、小さなアプリケーションに分割できます。また、アプリケーションから独立したロジックは Java や Scala ライブラリに切り出すのもよいでしょう。

詳細については「マルチプロジェクト・ビルドについての SBT ドキュメント」 (原文) を参照してください。また、サブプロジェクトを定義するにあたって最も基本的なこととして、サブプロジェクト用のビルドファイルというものはありません。親のビルドファイルにサブプロジェクトを定義します。


アプリケーションからシンプルな「ライブラリプロジェクト」を切り出すことができます。build.sbt に、次のような sbt のプロジェクト定義を追加してください。

name := "my-first-application"

version := "1.0"

lazy val myFirstApplication = (project in file("."))

lazy val myLibrary = project

最終行の小文字の project は、代入先の val の名前を使ってプロジェクトの名前とフォルダを決定する Scala マクロです。

The myFirstApplication project declares the base project. If you don’t have any sub projects, this is already implied, however when declaring sub projects, it’s usually required to declare it so that you can ensure that it aggregates (that is, runs things like compile/test etc on the sub projects when run in the base project) and depends on (that is, adds the sub projects to the main projects classpath) the sub projects.

上記の例では myLibrary ディレクトリにサブプロジェクトを定義しました。サブプロジェクトは普通の sbt プロジェクトの一種であり、標準的なディレクトリ構成に従います。

 └ build.sbt
 └ app
 └ conf
 └ public
 └ myLibrary
   └ build.sbt
   └ src
     └ main
       └ java
       └ scala

myLibrary has its own build.sbt file, this is where it can declare its own settings, dependencies etc.

ビルド設定でサブプロジェクトを有効にした場合、それぞれのプロジェクトを個別にコンパイル、テスト、実行することができます。Play コンソールで projects コマンドを実行すると、全てのプロジェクトが表示されます。

[my-first-application] $ projects
[info] In file:/Volumes/Data/gbo/myFirstApp/
[info] 	 * my-first-application
[info] 	   my-library

デフォルトのプロジェクトは変数名がアルファベット順で最初の物になります。メインプロジェクトを指定したい場合は変数名を aaaMain 等にする事で可能になります。現在のプロジェクトを切り替えるには、project コマンドを使ってください。

[my-first-application] $ project my-library
[info] Set current project to my-library

Play アプリケーションを開発モードで起動している場合、依存するサブプロジェクトも自動的に再コンパイルされます。サブプロジェクトのコンパイルエラーも、ブラウザ上で確認できます。

§Sharing common variables and code

If you want your sub projects and root projects to share some common settings or code, then these can be placed in a Scala file in the project directory of the root project. For example, in project/Common.scala you might have:

import sbt._
import Keys._

object Common {
  val settings: Seq[Setting[_]] = Seq(
    organization := "com.example",
    version := "1.2.3-SNAPSHOT"

  val fooDependency = "" %% "foo" % "2.4"

Then in each of your build.sbt files, you can reference anything declared in the file:

name := "my-sub-module"


libraryDependencies += fooDependency


As a Play application is just a standard sbt project with a default configuration, it can depend on another Play application. You can make any sub module a Play application by adding the PlayJava or PlayScala plugins, depending on whether your project is a Java or Scala project, in its corresponding build.sbt file.

Note: In order to avoid naming collision, make sure your controllers, including the Assets controller in your subprojects are using a different name space than the main project


It’s also possible to split the route file into smaller pieces. This is a very handy feature if you want to create a robust, reusable multi-module play application

§Consider the following build configuration


name := "myproject"

lazy val admin = (project in file("modules/admin")).enablePlugins(PlayScala)

lazy val main = (project in file("."))


name := "myadmin"

libraryDependencies ++= Seq(
  "mysql" % "mysql-connector-java" % "5.1.18",

§Project structure

  └ controllers
  └ models
  └ views
  └ application.conf
  └ routes
  └ admin
    └ build.sbt
    └ conf
      └ admin.routes
    └ app
      └ controllers
      └ models
      └ views
  └ plugins.sbt

Note: Configuration and route file names must be unique in the whole project structure. Particularly, there must be only one application.conf file and only one routes file. To define additional routes or configuration in sub-projects, use sub-project-specific names. For instance, the route file in admin is called admin.routes. To use a specific set of settings in development mode for a sub project, it would be even better to put these settings into the build file, e.g. Keys.devSettings += ("application.router", "admin.Routes").


GET /index                  controllers.Application.index()

->  /admin admin.Routes

GET     /assets/*file"/public", file)


GET /index                  controllers.admin.Application.index()

GET /assets/*file "/public", file)

Note: To export compiled routes to other projects disable reverse ref routing generation using generateRefReverseRouter := false sbt settings. Since routes_reverseRouting depends on every controller disabling the ref routing generation will also improve the compilation speed.

§アセットとコントローラクラスは controllers.admin パッケージ以下に無ければなりません。


package controllers.admin
object Assets extends controllers.AssetsBuilder

Note: Java users can do something very similar i.e.:

package controllers.admin;
import play.api.mvc.*;

public class Assets {
  public static Action<AnyContent> at(String path, String file) {
    return, file);



package controllers.admin

import play.api._
import play.api.mvc._
import views.html._

object Application extends Controller {

  def index = Action { implicit request =>

§admin でのリバースルーティング



and for Assets:"...")









このドキュメントの翻訳は Play チームによってメンテナンスされているものではありません。 間違いを見つけた場合、このページのソースコードを ここ で確認することができます。 ドキュメントガイドライン を読んで、お気軽にプルリクエストを送ってください。