5 コマンドライン

grails [command name]

• USER_HOME/.grails/scripts
• PROJECT_HOME/scripts
• PROJECT_HOME/plugins/*/scripts
• GRAILS_HOME/scripts

grails run-app

• USER_HOME/.grails/scripts/RunApp.groovy
• PROJECT_HOME/scripts/RunApp.groovy
• PLUGINS_HOME/*/scripts/RunApp.groovy
• GLOBAL_PLUGINS_HOME/*/scripts/RunApp.groovy
• GRAILS_HOME/scripts/RunApp.groovy

grails help

Usage (optionals marked with *):
grails [environment]* [target] [arguments]*
Examples:
grails dev run-app
grails create-app books
Available Targets (type grails help 'target-name' for more info):
grails bootstrap
grails bug-report
grails clean
grails compile
...

Refer to the Command Line reference in the Quick Reference menu of the reference guide for more information about individual commands

左メニューにある個別のコマンドラインリファレンス情報も参照して下さい。

export GRAILS_OPTS="-Xmx1G -Xms256m -XX:MaxPermSize=256m"
grails run-app

非インタラクティブモード

grails war --non-interactive

5.1 インタラクティブモード

If you need to open a file whilst within interactive mode you can use the open command which will TAB complete file paths:

Even better, the open command understands the logical aliases 'test-report' and 'dep-report', which will open the most recent test and dependency reports respectively. In other words, to open the test report in a browser simply execute open test-report. You can even open multiple files at once: open test-report test/unit/MyTests.groovy will open the HTML test report in your browser and the MyTests.groovy source file in your text editor.

TAB completion also works for class names after the create-* commands:

If you need to run an external process whilst interactive mode is running you can do so by starting the command with a !:

Note that with ! (bang) commands, you get file path auto completion - ideal for external commands that operate on the file system such as 'ls', 'cat', 'git', etc.

The stop-app command will stop an application that has been run with the run-app command.

To exit interactive mode enter the exit command. Note that if the Grails application has been run with run-app normally it will terminate when the interactive mode console exits because the JVM will be terminated. An exception to this would be if the application were running in forked mode which means the application is running in a different JVM. In that case the application will be left running afer the interactive mode console terminates. If you want to exit interactive mode and stop an application that is running in forked mode, use the quit command. The quit command will stop the running application and then close interactive mode.

5.2 フォークモード

フォーク実行

forkConfig = [maxMemory: 1024, minMemory: 64, debug: false, maxPerm: 256]
grails.project.fork = [
   test: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, daemon:true], // configure settings for the test-app JVM
   run: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256], // configure settings for the run-app JVM
   war: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256], // configure settings for the run-war JVM
   console: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256]// configure settings for the Console UI JVM
]

フォークされたテスト実行

grails test-app

$ grails
$ grails> test-app

forkConfig = [maxMemory: 1024, minMemory: 64, debug: false, maxPerm: 256]
grails.project.fork = [
   test: false,
   …
]

Using the Test Runnner Deamon to Speed-up Test Execution

The defaut configuration for the testing is to activate a daemon to run tests using the daemon argument:

grails.project.fork = [
   test: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, daemon:true], // configure settings for the test-app JVM
   ...

This only works in interactive mode, so if you start Grails with the 'grails' command and then using test-app the daemon will be used:

$ grails
$ grails> test-app

This has the effect of speeding-up test executions times. You can disable the daemon by setting daemon to false. If the daemon becomes unresponsive you can restart it with restart-daemon:

$ grails> restart-daemon

Debugging and Forked Execution (debug vs debug-fork)

An important consideration when using forked execution is that the debug argument will allow a remote debugger to be attached to the build JVM but not the JVM that your application is running in. To debug your application you should use the debug-fork argument:

grails test-app --debug-fork

Or for run-app:

grails run-app --debug-fork

フォークされたTomcat実行

• Grailsビルドシステムを終了できるため、メモリ消費量を減らせる
• ランタイムクラスパスからビルドクラスパスを隔離できる
• 依存関係のコンフリクトなしに、他のGrails/Springアプリケーションを並列デプロイできる

grails.project.fork.run=true

grails stop-app

grails.project.fork.run= [maxMemory:1024, minMemory:64, debug:false, maxPerm:256, jvmArgs: '..arbitrary JVM arguments..']

フォークモードでの追加WARファイルの自動デプロイ

grails.project.autodeploy.dir="/path/to/my/war/files"

フォークされたTomcatインスタンスのカスタマイズ

void customize(Tomcat tomcat) {
 // your code here
}

5.3 Gantスクリプトの作成

grails create-script compile-sources

target(default:"The default target is the one that gets executed by Grails") {
    depends(clean, compile)
}
target(clean:"Clean out things") {
    ant.delete(dir:"output")
}
target(compile:"Compile some sources") {
    ant.mkdir(dir:"mkdir")
    ant.javac(srcdir:"src/java", destdir:"output")
}

In previous versions of Grails (1.0.3 and below), the variable was Ant, i.e. with a capital first letter.

前バージョンのGrails(1.0.3以前)では、変数名はAntのように大文字始まりでした。

デフォルトターゲット

The default target

target("clean-compile": "Performs a clean compilation on the app source") {
    depends(clean, compile)
}
target(clean:"Clean out things") {
    ant.delete(dir:"output")
}
target(compile:"Compile some sources") {
    ant.mkdir(dir:"mkdir")
    ant.javac(srcdir:"src/java", destdir:"output")
}
setDefaultTarget("clean-compile")

5.4 Grailsスクリプトの再利用

includeTargets << grailsScript("_GrailsBootstrap")
target ('default': "Database stuff") {
    depends(configureProxy, packageApp, classpath, loadApp, configureApp)
    Connection c
    try {
        c = appCtx.getBean('dataSource').getConnection()
        // do something with connection
    }
    finally {
        c?.close()
    }
}

他のスクリプトからターゲットを取り出す

Pulling in targets from other scripts

includeTargets << new File("/path/to/my/script.groovy")
includeTargets << gant.tools.Ivy

Core Grailsターゲット

Core Grails targets

./scripts/FunctionalTests.groovy:
includeTargets << new File("${basedir}/scripts/_FunctionalTests.groovy")
target(default: "Runs the functional tests for this project.") {
    depends(runFunctionalTests)
}
./scripts/_FunctionalTests.groovy:
includeTargets << grailsScript("_GrailsTest")
target(runFunctionalTests: "Run functional tests.") {
    depends(...)
    …
}

• スクリプトを"コマンドスクリプト"と"内部スクリプト"に分割します。
• 実装の大部分は"内部スクリプト"で行います。
• 引数の解析は"コマンドスクリプト"で行います。
• ターゲットに引数を渡すには、いくつかのスクリプト変数を作成し、ターゲットを呼び出す前にそれらを初期化します。
• ターゲットの代わりにスクリプト変数に割り当てられているクロージャを使用して名前の衝突を避けるようにします。そうすれば、引数をクロージャに直接渡すことができます。

5.5 イベントを取得する

イベントハンドラを定義する

Defining event handlers

• USER_HOME/.grails/scripts - ユーザー固有のイベントハンドラ
• PROJECT_HOME/scripts - アプリケーション固有のイベントハンドラ
• PLUGINS_HOME/*/scripts - プラグイン固有のイベントハンドラ
• GLOBAL_PLUGINS_HOME/*/scripts - グローバルプラグインによって提供されているイベントハンドラ

eventCreatedArtefact = { type, name ->
   println "Created $type $name"
}
eventStatusUpdate = { msg ->
   println msg
}
eventStatusFinal = { msg ->
   println msg
}

• CompileStart - sourceまたはtestsコンパイル開始時に発行されます。
• CompileEnd - sourceまたはtestsコンパイル終了時に発行されます。

イベントトリガー

Triggering events

includeTargets << grailsScript("_GrailsEvents")
event("StatusFinal", ["Super duper plugin action complete!"])

共通イベント

Common Events

5.6 ビルドのカスタマイズ

初期値

The defaults

初期値を上書きする

Overriding the defaults

grails -Dgrails.project.work.dir=work compile

grails.project.work.dir = "work"

使用可能なビルド設定

Available build settings

リローディングエージェントキャッシュディレクトリ

Reloading Agent Cache Directory

Grails uses an agent based reloading system in the development environment that allows source code changes to be picked up while the application is running. This reloading agent caches information needed to carry out the reloading efficiently. By default this information is stored under <USER_HOME_DIR>/.grails/.slcache/. The GRAILS_AGENT_CACHE_DIR environment variable may be assigned a value to cause this cache information to be stored somewhere else. Note that this is an operating system environment variable, not a JVM system property or a property which may be defined in BuildConfig.groovy. This setting must be defined as an environment variable because the agent cache directory must be configured very early in the JVM startup process, before any Grails code is executed.

5.7 AntとMaven

Antへの統合

Ant Integration

grails integrate-with --ant

• clean - Grailsアプリケーションをクリーンします。
• compile - アプリケーションのソースコードをコンパイルします。
• test - ユニットテストを実行します。
• run - Grailsの"run-app"コマンド相当を実行します。
• war - WARファイルを作成します。
• deploy - デフォルトでは空ですが、自動配備を実装することができます。

ant war

<taskdef name="grailsTask"
         classname="grails.ant.GrailsTask"
         classpathref="grails.classpath"/>

• classpath - ビルド時のクラスパス。（GantとGrailsスクリプトロード時に使用）
• compileClasspath - アプリケーションコンパイル時のクラスパス。
• runtimeClasspath - アプリケーションとWARパッケージ実行時のクラスパス。通常compileClasspathに全てが含まれます。
• testClasspath - コンパイル時と、テスト実行時のクラスパス。通常runtimeClasspathに全てが含まれます。

Maven統合

Maven Integration

準備

Preparation

The Maven 2 integration for Grails has been designed and tested for Maven 2.0.9 and above. It will not work with earlier versions.

GrailsのMaven2統合は、Maven 2.0.9以上を対象として設計・テストされています。それ以前のバージョンでは動作しません。

The default mvn setup DOES NOT supply sufficient memory to run the Grails environment. We recommend that you add the following environment variable setting to prevent poor performance:

既定のmvnコマンド設定ではGrails環境で実行するための十分なメモリを供給できません。パフォーマンス低下を防止するため、次の環境変数を追加することをお勧めします:

export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=256"

GrailsのMavenのプロジェクトを作成する

Creating a Grails Maven Project

$ grails create-app myapp
$ cd myapp
$ grails create-pom com.mycompany

• compile - Grailsプロジェクトをコンパイル
• package - GrailsプロジェクトのWARファイルをビルドする
• install - WARファイル(又はプラグインの場合はZIPかJAR)をビルドしてMavenローカルキャッシュにインストールします
• test - Grailsプロジェクトのテストを実行します
• clean - Grailsプロジェクトをクリーンします

• grails:create-controller - create-controllerコマンドを呼び出します
• grails:create-domain-class - create-domain-classコマンドを呼び出します
• grails:create-integration-test - create-integration-testコマンドを呼び出します
• grails:create-pom - 既存のGrailsプロジェクトにMaven POMを新規作成します
• grails:create-script - create-scriptコマンドを呼び出します
• grails:create-service - create-serviceコマンドを呼び出します
• grails:create-taglib - create-tag-libコマンドを呼び出します
• grails:create-unit-test - create-unit-testコマンドを呼び出します
• grails:exec - 任意のGrailsコマンドラインスクリプトを実行します
• grails:generate-all - generate-allコマンドを呼び出します
• grails:generate-controller - generate-controllerコマンドを呼び出します
• grails:generate-views - generate-viewsコマンドを呼び出します
• grails:install-templates - install-templatesコマンドを呼び出します
• grails:list-plugins - list-pluginsコマンドを呼び出します
• grails:package - packageコマンドを呼び出します
• grails:run-app - run-appコマンドを呼び出します

Archetypeを使用したGrails Mavenプロジェクトの作成

Creating a Grails Maven Project using the Archetype

mvn archetype:generate -DarchetypeGroupId=org.grails \
    -DarchetypeArtifactId=grails-maven-archetype \
    -DarchetypeVersion=2.1.0.RC1 \
    -DgroupId=example -DartifactId=my-app

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <source>1.5</source>
    <target>1.5</target>
  </configuration>
</plugin>

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <source>1.6</source>
    <target>1.6</target>
  </configuration>
</plugin>

cd my-app
mvn initialize

プラグイン依存を定義する

Defining Plugin Dependencies

All Grails plugins are published to a standard Maven repository located at . When using the Maven plugin for Grails you must ensure that this repository is declared in your list of remote repositories: 全ての公式Grailsプラグインは、のMavenリポジトリに公開されています。Mavenプラグインを使用する場合は、リモートリポジトリの定義にリポジトリが追加されている必要があります。

<repository>
    <id>grails-plugins</id>
    <name>grails-plugins</name>
    <url>http://repo.grails.org/grails/plugins</url>
</repository>

<dependency>
    <groupId>org.grails.plugins</groupId>
    <artifactId>database-migration</artifactId>
    <version>1.1</version>
    <scope>runtime</scope>
    <type>zip</type>
</dependency>

Grailsフォーク実行

Forked Grails Execution

By default the Maven plugin will run Grails commands in-process, meaning that the Grails process occupies the same JVM as the Maven process. This can put strain on the Maven process for particularly large applications.

In this case it is recommended to use forked execution. Forked execution can be configured in the configuration element of the plugin:

<plugin>
    <groupId>org.grails</groupId>
    <artifactId>grails-maven-plugin</artifactId>
    <version>${grails.version}</version>
    <configuration>
        <!-- Whether for Fork a JVM to run Grails commands -->
        <fork>true</fork>
    </configuration>
    <extensions>true</extensions>
</plugin>

With this configuration in place a separate JVM will be forked when running Grails commands. If you wish to debug the JVM that is forked you can add the forkDebug element:

<!-- Whether for Fork a JVM to run Grails commands -->
    <fork>true</fork>
    <forkDebug>true</forkDebug>

If you need to customize the memory of the forked process the following elements are available:

• forkMaxMemory - The maximum amount of heap (default 1024)
• forkMinMemory - The minimum amount of heap (default 512)
• forkPermGen - The amount of permgen (default 256)

Multi Module Maven Builds

The Maven plugin can be used to power multi-module Grails builds. The easiest way to set this is up is with the create-multi-project-build command:

$ grails create-app myapp
$ grails create-plugin plugin1
$ grails create-plugin plugin2
$ grails create-multi-project-build org.mycompany:parent:1.0

Running mvn install will build all projects together. To enable the 'grails' command to read the POMs you can modify BuildConfig.groovy to use the POM and resolve dependencies from your Maven local cache:

grails.project.dependency.resolution = {
    …
    pom true
    repositories {
        …
        mavenLocal()    
    }
}

By reading the pom.xml file you can do an initial mvn install from the parent project to build all plugins and install them into your local maven cache and then cd into your project and use the regular grails run-app command to run your application. All previously built plugins will be resolved from the local Maven cache.

Grailsコマンドをフェーズに追加する

Adding Grails commands to phases

<plugin>
    <groupId>org.grails</groupId>
    <artifactId>grails-maven-plugin</artifactId>
    <version>2.1.0.RC2</version>
    <extensions>true</extensions>
    <executions>
        <execution>
            <goals>
            …
            </goals>
        </execution>
        <!-- Add the "functional-tests" command to the "integration-test" phase -->
        <execution>
            <id>functional-tests</id>
            <phase>integration-test</phase>
            <goals>
                <goal>exec</goal>
            </goals>
            <configuration>
                <command>functional-tests</command>
            </configuration>
        </execution>
    </executions>
</plugin>

mvn grails:exec -Dcommand=create-webtest -Dargs=Book

GrailsのMavenプロジェクトのデバッグ

Debugging a Grails Maven Project

mvnDebug grails:run-app

MAVEN_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
mvn grails:run-app

問題提起

Raising issues

5.8 Grailsラッパー

Generating The Wrapper

The wrapper command can be used to generate the wrapper shell scripts and supporting jar files. Execute the wrapper command at the top of an existing Grails project.

grails wrapper

In order to do this of course Grails must be installed and configured. This is only a requirement for bootstrapping the wrapper. Once the wrapper is generated there is no need to have a Grails installation configured in order to use the wrapper.

See the wrapper command documentation for details about command line arguments.

By default the wrapper command will generate a grailsw shell script and grailsw.bat batch file at the top of the project. In addition to those, a wrapper/ directory (the name of the directory is configurable via command line options) is generated which contains some support files which are necessary to run the wrapper. All of these files should be checked into the source code control system along with the rest of the project. This allows developers to check the project out of source code control and immediately start using the wrapper to execute Grails commands without having to install and configure Grails.

Using The Wrapper

The wrapper script accepts all of the same arguments as the normal grails command.

./grailsw create-domain-class com.demo.Person
./grailsw run-app
./grailsw test-app unit:
etc...