(クイックリファレンス)
2 スタートガイド
Authors: Graeme Rocher, Peter Ledbrook, Marc Palmer, Jeff Brown, Luke Daley, Burt Beckwith ,
Japanese Translation: T.Yamamoto, Japanese Grails Doc Translating Team
このドキュメントの内容はスナップショットバージョンを元に意訳されているため、一部現行バージョンでは未対応の機能もあります。
Version: 2.1.0.BUILD-SNAPSHOT
2 スタートガイド
2.1 インストール必要条件
Before installing Grails you will as a minimum need a Java Development Kit (JDK) installed version 1.6 or above and environment variable called JAVA_HOME pointing to the location of this installation. On some platforms (for example OS X) the Java installation is automatically detected. However in many cases you will want to manually configure the location of Java. For example:
Grailsをインストールする前に、Java Development Kit (JDK) 1.6以上がインストール済みで、
JAVA_HOMEが指定されている必要があります。一部のプラットフォームでは(OS Xの例で言うと)、自動的にJavaのインストール先を認識します。手動で定義する場合等、必要に応じて次のようにJavaの設定を行ってください。
export JAVA_HOME=/Library/Java/Home
export PATH="$PATH:$JAVA_HOME/bin"
Note that although JDK 1.6 is required to use Grails at development time it is possible to deploy Grails to JDK 1.5 VMs by setting the grails.project.source.level and grails.project.target.level settings to "1.5" in grails-app/conf/BuildConfig.groovy:
JDK1.6はGrailsでの開発時に必要です。
grails-app/conf/BuildConfig.groovyに、
grails.project.source.levelと
grails.project.target.levelを"1.5"と指定することで、JDK1.5の環境に対してのデプロイが可能です。
grails.project.source.level = 1.5
grails.project.target.level = 1.5
In addition, Grails supports Servlet versions 2.5 and above. If you wish to use newer features of the Servlet API (such as 3.0) you should configure the grails.servlet.version in BuildConfig.groovy appropriately:
Grailsでは、2.5とそれ以上のサーブレットのバージョンに対応しています。 Servlet API(3.0等)の新機能を使用したい場合は、
BuildConfig.groovyに
grails.servlet.versionの定義をしてください。
grails.servlet.version = "3.0"
2.2 ダウンロードとインストール
The first step to getting up and running with Grails is to install the distribution. To do so follow these steps:
まず最初にGrailsをインストールすることから始めましょう。手順は次のようになります:
- Download a binary distribution of Grails and extract the resulting zip file to a location of your choice
- Set the GRAILS_HOME environment variable to the location where you extracted the zip
- On Unix/Linux based systems this is typically a matter of adding something like the following
export GRAILS_HOME=/path/to/grails to your profile
- On Windows this is typically a matter of setting an environment variable under
My Computer/Advanced/Environment Variables
- Then add the
bin directory to your PATH variable:
- On Unix/Linux based systems this can be done by adding
export PATH="$PATH:$GRAILS_HOME/bin" to your profile
- On Windows this is done by modifying the
Path environment variable under My Computer/Advanced/Environment Variables
- Grailsをダウンロードし、任意の場所にzipファイルを解凍します。
- zipファイルを解凍した場所にGRAILS_HOME環境変数を設定します。
- Unix/Linuxベースのシステムでは、次のようなものをプロファイル（.profileなど）に追加します。
export GRAILS_HOME=/path/to/grails
- Windowsでは、マイコンピュータ＞詳細＞環境変数に設定します。
- さらに、
PATH変数にbinディレクトリを追加する必要があります。
- Unix/Linuxベースのシステムでは、このように設定します。
export PATH="$PATH:$GRAILS_HOME/bin"
- Windowsでは、マイコンピュータ＞詳細＞環境変数の
Pathに%GRAILS_HOME%binを追加します。
If Grails is working correctly you should now be able to type grails -version in the terminal window and see output similar to this:
ターミナルで
grailsと入力し実行することで下記のような出力がされれば、Grailsが正常に動作しています:
Grails version: 2.0.0
2.3 Grails下位バージョンからの更新
Although the Grails development team have tried to keep breakages to a minimum there are a number of items to consider when upgrading a Grails 1.0.x, 1.1.x, 1.2.x, or 1.3.x applications to Grails 2.0. The major changes are described in more detail below, but here's a brief summary of what you might encounter when upgrading from Grails 1.3.x:
Grails開発チームではできる限りの下位互換を心がけていますが、Grails 2.0へ更新する際に、下位バージョンから考慮しなくてはならない内容が幾つか存在します。大きな変更点を以下にまとめます。
* Logging by convention packages have changed, so you may not see the logging output you expect. Update your logging configuration as described below.
- ロギングDSLのパッケージが変更されたので正常にログ出力がされない場合があります。ログの設定を変更する必要があります。
* HSQLDB has been replaced with H2 as default in-memory database. If you use the former, either change your data source to H2 or add HSQLDB as a runtime dependency.
- デフォルトのインメモリーデータベースがHSQLDBからH2へ変更になりました。使用している場合はデータソースの設定を変更するか、HSQLDBを依存管理に追加する必要があります。
* The redirect() method no longer commits the response, so isCommitted() will return false. If you use that method, then call request.isRedirected() instead.
redirect()メソッドがレスポンスを返さなくなります。これにより、isCommitted()はfalseを返す事になります。isCommitted()を使用している場合は、代わりにrequest.isRedirected()を使用しましょう
* The redirect() method now uses the grails.serverURL config setting to generate the redirect URL. You may need to remove the setting, particularly from the development and test environments.
redirect()メソッドは、設定のgrails.serverURLを使用してリダイレクトのURLを生成するようになります。developmentとtestの環境設定からgrails.serverURL設定を外す必要があります。
* withFormat() no longer takes account of the request content type. If you want to do something based on the request content type, use request.withFormat().
withFormat()がリクエストコンテントタイプを取得しなくなりました。リクエストコンテントタイプでの動作を実装する場合は、request.withFormat()を使用してください。
* Adaptive AJAX tags using Prototype will break. In this situation you must install the new Prototype plugin.
- Prototypeを使用したAJAXタグは動作しません。必要であれば、Prototypeプラグインをインストールしてください。
* If you install Resources (or it is installed automatically), tags like <g:javascript> won't write anything to the page until you add the <r:layoutResources/> tags to your layout.
- Resourcesプラグインをインストールした場合(または、自動的にインストールされた場合)、
<r:layoutResources/>をレイアウトに記述するまで、<g:javascript>からは何も出力されません。
* Resources adds a '/static' URL, so you may have to update your access control rules accordingly.
- ResourcesプラグインはURL '/static'を追加します。それに応じたアクセスコントロールを更新する必要があります。
* Some plugins may fail to install because one or more of their dependencies can not be found. If this happens, the plugin probably has a custom repository URL that you need to add to your project's BuildConfig.groovy.
- 幾つかのプラグインは依存が見つからなかった際にインストールに失敗する場合があります。その場合は、プラグインがカスタムリポジトリURLを使用している可能性があるので、プロジェクトの
BuildConfig.groovyに追加する必要があります。
* The behaviour of abstract domain classes has changed, so if you use them you will either have to move the abstract classes to 'src/groovy' or migrate your database schema and data.
- 抽象ドメインクラスの振る舞いが変更されました。使用している場合は、抽象クラスを'src/groovy'に移動するか、データベースのスキーマとデータを変更する必要があります。
* Criteria queries default to INNER_JOIN for associations rather than OUTER_JOIN. This may affect some of your result data.
- クライテリアクエリーのデフォルトがOUTER_JOINからINNER_JOINに変更になりました。幾つかの実装結果に影響が出る可能性があります。
* Constraints declared for non-existent properties will now throw an exception.
- 存在しないプロパティがconstraintsに定義してある場合、例外を投げるようになりました。
* Public methods in controllers will now be treated as actions. If you don't want this, make them protected or private.
- コントローラ内のパブリックメソッドはアクションとして扱われるようになります。アクションとして扱われたくないメソッドは、protectedまたは、privateに変更してください。
* The new unit testing framework won't work with the old GrailsUnitTestCase class hierarchy. Your old tests will continue to work, but if you wish to use the new annotations, do not extend any of the *UnitTestCase classes.
- 新ユニットテストフレームワークにより、古い
GrailsUnitTestCaseクラス階層は使用できません。新しい仕組みを使用しながら古いテスト仕様で動作させるには、*UnitTestCaseを継承しないようにしてください。
* Output from Ant tasks is now hidden by default. If your scripts are using ant.echo(), ant.input(), etc. you might want to use alternative mechanisms for output.
- Antタスクからの出力はデフォルトで隠すようになりました。
ant.echo(), ant.input()等をスクリプトで使用している場合は、出力用の代替機能を使用してください。
* Domain properties of type java.net.URL may no longer work with your existing data. The serialisation mechanism for them appears to have changed. Consider migrating your data and domain models to String.
- ドメインプロパティでjava.net.URL型を使用している場合は、既存のデータで動作しません。シリアライゼーションの仕組みが変更になったようです。ドメインモデルとデータをStringに変更することを検討してください。
* The Ivy cache location has changed. If you want to use the old location, configure the appropriate global setting (see below) but be aware that you may run into problems running Grails 1.3.x and 2.x projects side by side.
- Ivyのキャッシュ場所が変更になりました。古い場所を使用したい場合は、グローバル設定で変更することができます。ただし、1.3.x系と2.x系を平行利用する場合は問題が発生します。
* With new versions of various dependencies, some APIs (such as the Servlet API) may have changed. If you have code that implements any of those APIs, you will need to update it. Problems will typically manifest as compilation errors.
- 多くのライブラリが新バージョンに変更されました。更新されたライブラリを使用している場合は変更が必要となります。
* The following deprecated classes have been removed: grails.web.JsonBuilder and grails.web.OpenRicoBuilder.
- 次の非推奨クラスが削除されました:
grails.web.JsonBuilder、grails.web.OpenRicoBuilder
Grails 1.3.xからのアップグレード
Upgrading from Grails 1.3.x
web.xmlテンプレートの内容変更
Changes to web.xml template
If you have customized the web.xml provided by grails install-templates then you will need to update this customized template with the latest version provided by Grails. Failing to do so will lead to a ClassNotFoundException for the org.codehaus.groovy.grails.web.util.Log4jConfigListener class.
grails install-templatesで提供されたweb.xmlをカスタマイズしている場合は、最新のGrailsで提供される無いように更新する必要が有ります。変更を行わなかった場合は、
org.codehaus.groovy.grails.web.util.Log4jConfigListenerクラスのClassNotFoundExceptionを引き起こします。
Groovy 1.8での変更点
Groovy 1.8 Changes
Groovy 1.8 is a little stricter in terms of compilation so you may be required to fix compilation errors in your application that didn't occur under Grails 1.3.x.
Groovy 1.8ではｍコンパイルが少し厳しくなっています。そのため、Grails 1.3.xでは発生しなかったコンパイルエラーに対応する必要があります。
Groovy 1.8 also requires that you update many of the libraries that you may be using in your application. Libraries known to require an upgrade include:
さらに、Groovy 1.8では、アプリケーションで使用している幾つかのライブラリを更新する必要があります。解っている更新が必要なライブラリは以下になります。
- Spock
- Geb
- GMock (upgrade unavailable as of this writing)
HSQLDBからH2へ変更
HSQLDB Has Been Replaced With H2
HSQLDB is still bundled with Grails but is not configured as a default runtime dependency. Upgrade options include replacing HSQLDB references in DataSource.groovy with H2 references or adding HSQLDB as a runtime dependency for the application.
HSQLDBは現在もGrailsにバンドルされていますが、デフォルトでは依存定義されていません。アップグレードした場合はDataSource.groovyのHSQLDB定義をH2に変更するか、依存管理にHSQLDBを追加する必要があります。
If you want to run an application with different versions of Grails, it's simplest to add HSQLDB as a runtime dependency, which you can do in BuildConfig.groovy:
もしアプリケーションを他のバージョンのGrailsと平行して動作させたい場合は、単純にBuildConfig.groovyの依存定義にHSQLDBを追加しましょう:
grails.project.dependency.resolution = {
inherits("global") {
}
repositories {
grailsPlugins()
grailsHome()
grailsCentral()
} dependencies {
// HSQLDBの依存定義 (Add HSQLDB as a runtime dependency)
runtime 'hsqldb:hsqldb:1.8.0.10'
}
}A default DataSource.groovy which is compatible with H2 looks like this:
H2データベースへ変更する場合は、以下を参考にして、DataSource.groovyを変更してください:
dataSource {
driverClassName = "org.h2.Driver"
username = "sa"
password = ""
}
// environment specific settings
environments {
development {
dataSource {
dbCreate = "create-drop" // one of 'create', 'create-drop','update'
url = "jdbc:h2:mem:devDb"
}
}
test {
dataSource {
dbCreate = "update"
url = "jdbc:h2:mem:testDb"
}
}
production {
dataSource {
dbCreate = "update"
url = "jdbc:h2:prodDb"
}
}
}Another significant difference between H2 and HSQLDB is in the handling of byte[] domain class properties. HSQLDB's default BLOB size is large and so you typically don't need to specify a maximum size. But H2 defaults to a maximum size of 255 bytes! If you store images in the database, the saves are likely to fail because of this. The easy fix is to add a maxSize constraint to the byte[] property:
他にH2とHSQLDBの重大な違いは、ドメインクラスのプロパティで定義した
byte[] の扱いです。HSQLDBでのBLOBのデフォルトサイズは、大きいので大抵最大サイズを定義する必要が無かったかと思います。H2では最大サイズの初期値が255バイトになっているので、調整する必要があります。調整するには、 制約の
maxSize を
byte[] のプロパティに定義するだけです。
class MyDomain {
byte[] data static constraints = {
data maxSize: 1024 * 1024 * 2 // 2MB
}
}This constraint influences schema generation, so in the above example H2 will have the data column set to BINARY(2097152) by Hibernate.
上記の制約定義でスキーマ生成を変更します。この例では、dataカラムは、
BINARY(2097152) としてHibernateがセットします。
抽象クラスの継承が変更になります
Abstract Inheritance Changes
In previous versions of Grails abstract classes in grails-app/domain were not treated as persistent. This is no longer the case and has a significant impact on upgrading your application. For example consider the following domain model in a Grails 1.3.x application:
以前のバージョンで、
grails-app/domain に存在する抽象クラスは、永続化対象として扱われませんでした。今後は違うため、アプリケーション更新には重大な影響を与えます。例として以下のようなドメインモデルをGrails-1.3.xで持っていたとします。
abstract class Sellable {}
class Book extends Sellable {}In Grails 1.3.x you would get a BOOK table and the properties from the Sellable class would be stored within the BOOK table. However, in Grails 2.x you will get a SELLABLE table and the default table-per-hierarchy inheritance rules apply with all properties of the Book stored in the SELLABLE table.
Grails 1.3.xの場合は、
BOOK テーブルが生成され、BOOKテーブルに
Sellable クラスのプロパティも含まれました。Grails 2.0からは、デフォルトのtable-per-hierarchy (クラス階層ごとのテーブル)継承ルールで、
BOOK クラスの全てのプロパティが含まれた
SELLABLE テーブルが生成されます。
You have two options when upgrading in this scenario:
これを更新するには２つの方法があります:
- Move the abstract
Sellable class into the src/groovy package. If the Sellable class is in the src/groovy directory it will no longer be regarded as persistent.
- Use the database migration plugin to apply the appropriate changes to the database (typically renaming the table to the root abstract class of the inheritance tree).
- 抽象クラス
Sellable をsrc/groovyに移動する。src/groovyに移動すれば永続化対象のクラスとしては認識しません。
- データベースマイグレーションプラグイン を使用して、データベースに適した変更を行う。(通常はルート抽象クラスのテーブル名称に変更すれば良いです。)
クライテリアクエリのデフォルトがINNER JOINになります
Criteria Queries Default to INNER JOIN
The previous default of LEFT JOIN for criteria queries across associations is now INNER JOIN.
今まではLEFT JOINがデフォルトでした。これからはINNER JOINになります。
存在しないプロパティの制約で例外を投げます
Invalid Constraints Now Thrown an Exception
Previously if you defined a constraint on a property that doesn't exist no error would be thrown:
以前は存在しないプロパティをconstraintに定義してもエラーが出ませんでした:
class Person {
String name
static constraints = {
bad nullable:false // invalid property, no error thrown
}
}Now the above code will result in an exception
上記のコードは、例外を投げるようになります。
ログでの慣習変更
Logging By Convention Changes
The packages that you should use for Grails artifacts have mostly changed. In particular:
Grailsアーテファクトのパッケージのほぼ全てが変更になりました:
service -> servicescontroller -> controllerstagLib -> taglib (case change)bootstrap -> confdataSource -> conf
service -> servicescontroller -> controllerstagLib -> taglib (Lが小文字に)bootstrap -> confdataSource -> conf
You can find out more about logging by convention in the
main part of the user guide, under "Configuring loggers". This change is a side-effect of injecting the
log property into artefacts at compile time.
ログの詳細については、
ユーザガイド を参考にしてください。
PrototypeからjQueryに変更
jQuery Replaces Prototype
The Protoype Javascript library has been removed from Grails core and now new Grails applications have the jQuery plugin configured by default. This will only impact you if you are using Prototype with the adaptive AJAX tags in your application, e.g. <g:remoteLink/> etc, because those tags will break as soon as you upgrade.
JavascriptライブラリPrototypeはGrailsのコアから削除されました。今後はjQueryがデフォルトとして定義されます。この変更では、ProtoypeベースのAJAXライブラリを使用してる場合に影響を受けます。例えば<g:remoteLink/>などは、アップデートをしたら直ちに影響を受けます。
To resolve this issue, simply install the
Prototype plugin in your application. You can also remove the prototype files from your
web-app/js/prototype directory if you want.
この問題は
Prototypeプラグイン をインストールすることで解決できます。Prototypeはプラグイン内から参照するようになるので、不用になるweb-app/js/prototypeディレクトリは削除できます。
Resourcesプラグイン
The Resources Plugin
The Resources plugin is a great new feature of Grails that allows you to manage static web resources better than before, but you do need to be aware that it adds an extra URL at
/static. If you have access control in your application, this may mean that the static resources require an authenticated user to load them! Make sure your access rules take account of the
/static URL.
コントローラのパブリックメソッド
Controller Public Methods
As of Grails 2.0, public methods of controllers are now treated as actions in addition to actions defined as traditional Closures. If you were relying on the use of methods for privacy controls or as helper methods then this could result in unexpected behavior. To resolve this issue you should mark all methods of your application that are not to be exposed as actions as private methods.
Grails 2.0からは、今までのクロージャに加えて、コントローラのパブリックメソッドもアクションとして扱われるようになりました。もし補助機能や内部機能としてメソッドを使用している場合は必ずメソッドを
private にしてください。
リダイレクトメソッド
The redirect Method
The
redirect method no longer commits the response. The result of this is code that relies of this behavior will break in 2.0. For example:
リダイレクト
redirect メソッドがレスポンスを返さなくなります。以下のコードは2.0では動作しなくなります:
redirect action: "next"
if (response.committed) {
// do something
}In this case in Grails 1.3.x and below the response.committed property would return true and the if block will execute. In Grails 2.0 this is no longer the case and you should instead use the new isRedirected() method of the request object:
このケースが1.3.xの場合では、
response.committed プロパティがtrueを返すため
if ブロックが実行されます。Grails 1.4では、同等の動きをしないため、代わりに
request インスタンスの
isRedirected() メソッドを使用します。
redirect action: "next"
if (request.redirected) {
// do something
}Another side-effect of the changes to the redirect method is that it now always uses the grails.serverURL configuration option if it's set. Previous versions of Grails included default values for all the environments, but when upgrading to Grails 2.0 those values more often than not break redirection. So, we recommend you remove the development and test settings for grails.serverURL or replace them with something appropriate for your application.
他のリダイレクトメソッドへの変更による副作用は、
grails.serverURL が設定されていれば常に使用するという点です。以前のバージョンのGrailsではデフォルトの値を保持していました、Grails 2.0に更新するとそれらを参照するために問題が発生します。したがって、test、developmentの定義から
grails.serverURL を外すか、妥当な値に設定することを推奨します。
コンテントネゴシエーション
Content Negotiation
As of Grails 2.0 the
withFormat method of controllers no longer takes into account the request content type (dictated by the
CONTENT_TYPE header), but instead deals exclusively with the response content type (dictated by the
ACCEPT header or file extension). This means that if your application has code that relies on reading XML from the request using
withFormat this will no longer work:
Grails 2.0からコントローラのwithFormatメソッドは、リクエストのコンテントタイプ(
CONTENT_TYPEヘッダ)を評価しなくなりました。これにかわって、レスポンスのコンテントタイプ(
ACCEPTヘッダまたはファイル拡張子)が排他的に処理を行います。これによって今までのアプリケーションの
withFormatを使用してリクエストからXMLを読み込む等のコードは動作しなくなります。
def processBook() {
withFormat {
xml {
// read request XML
}
html {
// read request parameters
}
}
}Instead you use the withFormat method provided on the request object:
withFormat の代わりに、
request オブジェクトで提供されているwithFormatメソッドを使用できます:
def processBook() {
request.withFormat {
xml {
// read request XML
}
html {
// read request parameters
}
}
}Unitテストフレームワーク
Unit Test Framework
Grails 2 introduces a new unit testing framework that is simpler and behaves more consistently than the old one. The old framework based on the GrailsUnitTestCase class hierarchy is still available for backwards compatibility, but it does not work with the new annotations.
Grails 2では、古い仕様より単純でかつ安定した、新しいUnitテストフレームワークを実装しています。下位互換として
GrailsUnitTestCaseクラス階層をベースとした古いフレームワークも使用可能です。但し、新しい仕組みのアノテーションとは平行利用できません。
Migrating unit tests to the new approach is non-trivial, but recommended. Here are a set of mappings from the old style to the new:
新しい仕組みのUnitテストへの移行は大変ですが推奨します。以下は古い仕組みから新しい仕組みへ更新する方法です:
- Remove
extends *UnitTestCase and add a @TestFor annotation to the class if you're testing a core artifact (controller, tag lib, domain class, etc.) or @TestMixin(GrailsUnitTestMixin) for non-core artifacts and non-artifact classes.
- Add
@Mock annotation for domain classes that must be mocked and use new MyDomain().save() in place of mockDomain().
- Replace references to
mockRequest, mockResponse and mockParams with request, response and params.
- Remove references to
renderArgs and use the view and model properties for view rendering, or response.text for all others.
- Replace references to
redirectArgs with response.redirectedUrl. The latter takes into account the URL mappings as is a string URL rather than a map of redirect() arguments.
- The
mockCommandObject() method is no longer needed as Grails automatically detects whether an action requires a command object or not.
- コアアーテファクト(コントローラ、タグリブ、ドメインクラス等)のテストの場合は、
extends *UnitTestCaseを削除して、@TestForアノテーションをクラスに追加します。コアアーティファクト以外やアーティファクト以外の場合は、@TestMixin(GrailsUnitTestMixin)アノテーションを追加します。
- モックするドメインクラスで、
mockDomain()の代わりに、new MyDomain().save()を使用するために、@Mockアノテーションでドメインクラスを指定します。
mockRequest、mockResponse、mockParamsへの参照をrequest、response、paramsに変更します。renderArgsを参照している部分を削除して、viewとmodelプロパティをビューレンダリング用に、また他はresponse.textを使用するようにします。redirectArgsは、response.redirectedUrlに変更します。後者はURLマッピングの内容を、redirect()のマップのでは無く、文字列のURLで返します。mockCommandObject()メソッドは、アクションが必要であれば自動的にコマンドオブジェクトを認識するため必要無くなりました。
There are other differences, but these are the main ones. We recommend that you read the
chapter on testing thoroughly to understand everything that has changed.
他にも違いは多数有りますが、これらがメインとなります。
chapter on testingをしっかり読んで理解することを推奨します。
Note that the Grails annotations don't need to be imported in your test cases to run them from the command line, but your IDE may need them. So, here are the relevant classes with packages:
Grailsのアノテーションはコマンドラインで実行する場合はインポートする必要が有りませんが、IDEは必要とします。ここに関連するクラスとパッケージを列挙します。
grails.test.mixin.TestForgrails.test.mixin.TestMixingrails.test.mixin.Mockgrails.test.mixin.support.GrailsUnitTestMixingrails.test.mixin.domain.DomainClassUnitTestMixingrails.test.mixin.services.ServiceUnitTestMixingrails.test.mixin.web.ControllerUnitTestMixingrails.test.mixin.web.FiltersUnitTestMixingrails.test.mixin.web.GroovyPageUnitTestMixingrails.test.mixin.web.UrlMappingsUnitTestMixingrails.test.mixin.webflow/WebFlowUnitTestMixin
Note that you're only ever likely to use the first two explicitly. The rest are there for reference.
コマンドライン出力
Command Line Output
Ant output is now hidden by default to keep the noise in the terminal to a minimum. That means if you use ant.echo in your scripts to communicate messages to the user, we recommend switching to an alternative mechanism.
ターミナルの表示を最小にするためにAnt出力は表示されなくなりました。これによりスクリプトでの出力としての
ant.echo からのメッセージは表示されなくなります。それに変わる方法に変更することをお勧めします。
For status related messages, you can use the event system:
ステータス表示には、イベントの仕組みが使用できます:
event "StatusUpdate", ["Some message"]
event "StatusFinal", ["Some message"]
event "StatusError", ["Some message"]
For more control you can use the
grailsConsole script variable, which gives you access to an instance of
GrailsConsole. In particular, you can log information messages with
log() or
info(), errors and warnings with
error() and
warning(), and request user input with
userInput().
さらなる制御として、api:grails.build.logging.GrailsConsoleインスタンスにアクセスするスクリプト変数 GrailsConsole|api:grails.build.logging.GrailsConsole] を使用することもできます。特に情報のログをとるための、
log() 、
info() 、エラーや警告用に
error() 、
warning() を使用したり、ユーザからの入力を要求する場合は
userInput() を使用できます。
カスタムプラグインリポジトリー
Custom Plugin Repositories
Many plugins have dependencies, both other plugins and straight JAR libraries. These are often located in Maven Central, the Grails core repository or the Grails Central Plugin Repository in which case applications are largely unaffected if they upgrade to Grails 2. But sometimes such dependencies are located elsewhere and Grails must be told where they can be found.
Due to changes in the way Grails handles the resolution of dependencies, Grails 2.0 requires you to add any such
custom repository locations to your project if an affected plugin is to install properly.
Ivyキャッシュ場所が変更
Ivy cache location has changed
The default Ivy cache location for Grails has changed. If the thought of yet another cache of JARs on your disk horrifies you, then you can change this in your
settings.groovy:
grails.dependency.cache.dir = "${userHome}/.ivy2/cache"If you do this, be aware that you may run into problems running Grails 2 and earlier versions of Grails side-by-side. These problems can be avoided by excluding "xml-apis" and "commons-digester" from the inherited global dependencies in Grails 1.3 and earlier projects.
URL型のドメインプロパティ
URL Domain Properties
If your domain model has any properties of type
java.net.URL, they may cease to work once you upgrade to Grails 2. It seems that the default mapping of
URL to database column has changed with the new version of Hibernate. This is a tricky problem to solve, but in the long run it's best if you migrate your
URL properties to strings. One technique is to use the
database migration plugin to add a new text column and then execute some code in
BootStrap (using Grails 1.3.x or earlier) to fetch each row of the table as a domain instance, convert the
URL properties to string URLs, and then write those values to the new column.
基盤となるAPIの更新
Updated Underlying APIs
Grails 2.0 contains updated dependencies including Servlet 3.0, Tomcat 7, Spring 3.1, Hibernate 3.6 and Groovy 1.8. This means that certain plugins and applications that depend on earlier versions of these APIs may no longer work. For example the Servlet 3.0 HttpServletRequest interface includes new methods, so if a plugin implements this interface for Servlet 2.5 but not for Servlet 3.0 then said plugin will break. The same can be said of any Spring interface.
Grails 2.0では、Servlet 3.0、Tomcat 7、Spring 3.1、Hibernate 3.6、Groovy 1.8などのライブラリを更新しました。以前のバージョンのプラグインなどでこれらのライブラリに依存がある場合動作しなくなります。例としてServlet 3.0の
HttpServletRequest インターフェイスは新しい物を多く含んでいます。この逆もあり得るので、Servlet 2.5のインターフェイスで実装され、Servlet 3.0に存在しない機能を持っているプラグインは動作しません。もちろんこの事はSpringなど他のライブラリにも同じ事が言えます。注意しましょう。
release-pluginコマンド除去
Removal of release-plugin
The built in
release-plugin command for releases plugins to the central Grails plugin repository has been removed. The new
release plugin should be used instead which provides an equivalent
publish-plugin command.
プラグインを公式リポジトリに発行するコマンド
release-plugin が除去されました。新たに
リリースプラグイン を使用して同じ意味を持つ
publish-plugin コマンドを使用してください。
非推奨クラスの除去
Removal of Deprecated Classes
The following deprecated classes have been removed: grails.web.JsonBuilder, grails.web.OpenRicoBuilder
次のクラスが除去されました。
grails.web.JsonBuilder ,
grails.web.OpenRicoBuilderGrails 1.2.x からのアップグレード
Upgrading from Grails 1.2.x
プラグイン・リポジトリ
Plugin Repositories
As of Grails 1.3, Grails no longer natively supports resolving plugins against secured SVN repositories. The plugin resolution mechanism in Grails 1.2 and below has been replaced by one built on
Ivy, the upside of which is that you can now resolve Grails plugins against Maven repositories as well as regular Grails repositories.
Grails 1.3では、認証付きSVNリポジトリ内のプラグイン解決に標準では対応しなくなりました。Grails 1.2以前のプラグイン解決の仕組みは、
Ivyをベースに構築された実装により、Grailsのライブラリと同等にMavenリポジトリを対象に、プラグイン解決の仕組みに変更されました。
Ivy supports a much richer set of repository resolvers for resolving plugins, including support for Webdav, HTTP, SSH and FTP. See the section on
resolvers in the Ivy docs for all the available options and the section of
plugin repositories in the user guide which explains how to configure additional resolvers.
Ivyでは、WebDAV, HTTP, SSHやFTPなど豊富なリポジトリ解決方法があります。利用可能なオプションについてはIvyのドキュメントの
リゾルバのセクションを、追加のリゾルバの設定方法については、このユーザーガイドのプラグイン・リポジトリのセクションを参照してください。
If you still need support for resolving plugins against secured SVN repositories then the
IvySvn project provides a set of resolvers for SVN repositories.
認証付きSVNリポジトリ内に対してのプラグイン解決が必要な場合は、SVNリポジトリに対してのIvyリゾルバを提供している
IvySvnプロジェクトを参考にしてください。
Grails 1.1.x からのアップグレード
Upgrading from Grails 1.1.x
翻訳チームの判断により、Grails 1.1.xからの更新は翻訳を行いません。ご了承ください。
プラグインのパス
Plugin paths
In Grails 1.1.x typically a pluginContextPath variable was used to establish paths to plugin resources. For example:
Grails 1.1.xではプラグイン内のリソースを参照するために変数
pluginContextPathが、以下のように使用されていました:
<g:resource dir="${pluginContextPath}/images" file="foo.jpg" />In Grails 1.2 views have been made plugin aware and this is no longer necessary:
Grails 1.2からはプラグイン認識されるため、この変数は不要になりました:
<g:resource dir="images" file="foo.jpg" />
Additionally the above example will no longer link to an application image from a plugin view. To do so change the above to:
この変更により、上記の例ではプラグイン内のビューからアプリケーション本体の/imagesなどへのパスを生成しません。従って、アプリケーション本体へのパスを生成するためには、次のようにする必要があります:
<g:resource contextPath="" dir="images" file="foo.jpg" />
タグや
renderタグも同様の記述ができます。
タグとボディの戻り値
Tag and Body return values
Tags no longer return java.lang.String instances but instead return a Grails StreamCharBuffer instance. The StreamCharBuffer class implements all the same methods as String but doesn't extend String, so code like this will break:
タグは
java.lang.Stringインスタンスを返さず、その代わりに
StreamCharBufferインスタンスを返します。
StreamCharBufferクラスは、
Stringと同じメソッドを実装していますが、このようなコードの場合は破綻します:
def foo = body()
if (foo instanceof String) {
// do something
}In these cases you should check for the java.lang.CharSequence interface, which both String and StreamCharBuffer implement:
この場合、
Stringと
StreamCharBufferの両方が実装している
java.lang.CharSequenceインタフェースを使用します:
def foo = body()
if (foo instanceof CharSequence) {
// do something
}新しいJSONBuilder
New JSONBuilder
There is a new version of
JSONBuilder which is semantically different from the one used in earlier versions of Grails. However, if your application depends on the older semantics you can still use the deprecated implementation by setting the following property to
true in Config.groovy:
grails.json.legacy.builder=true
フラッシュでのバリデーション
Validation on Flush
Grails now executes validation routines when the underlying Hibernate session is flushed to ensure that no invalid objects are persisted. If one of your constraints (such as a custom validator) executes a query then this can cause an additional flush, resulting in a
StackOverflowError. For example:
static constraints = {
author validator: { a ->
assert a != Book.findByTitle("My Book").author
}
}The above code can lead to a
StackOverflowError in Grails 1.2. The solution is to run the query in a new Hibernate
session (which is recommended in general as doing Hibernate work during flushing can cause other issues):
static constraints = {
author validator: { a ->
Book.withNewSession {
assert a != Book.findByTitle("My Book").author
}
}
}Grails 1.0.xからのアップグレード
Upgrading from Grails 1.0.x
翻訳チームの判断により、Grails 1.0.xからの更新は翻訳を行いません。ご了承ください。
Groovy 1.6
Grails 1.1 and above ship with Groovy 1.6 and no longer supports code compiled against Groovy 1.5. If you have a library that was compiled with Groovy 1.5 you must recompile it against Groovy 1.6 or higher before using it with Grails 1.1.
Java 5.0
Grails 1.1 now no longer supports JDK 1.4, if you wish to continue using Grails then it is recommended you stick to the Grails 1.0.x stream until you are able to upgrade your JDK.
Configuration Changes
1) The setting
grails.testing.reports.destDir has been renamed to
grails.project.test.reports.dir for consistency.
2) The following settings have been moved from
grails-app/conf/Config.groovy to
grails-app/conf/BuildConfig.groovy:
grails.config.base.webXmlgrails.project.war.file (renamed from grails.war.destFile)grails.war.dependenciesgrails.war.copyToWebAppgrails.war.resources
3) The
grails.war.java5.dependencies option is no longer supported, since Java 5.0 is now the baseline (see above).
4) The use of jsessionid (now considered harmful) is disabled by default. If your application requires jsessionid you can re-enable its usage by adding the following to
grails-app/conf/Config.groovy:
grails.views.enable.jsessionid=true
5) The syntax used to configure Log4j has changed. See the user guide section on
Logging for more information.
Plugin Changes
As of version 1.1, Grails no longer stores plugins inside your
PROJECT_HOME/plugins directory by default. This may result in compilation errors in your application unless you either re-install all your plugins or set the following property in
grails-app/conf/BuildConfig.groovy:
grails.project.plugins.dir="./plugins"
Script Changes
1) If you were previously using Grails 1.0.3 or below the following syntax is no longer support for importing scripts from GRAILS_HOME:
Ant.property(environment:"env")
grailsHome = Ant.antProject.properties."env.GRAILS_HOME"includeTargets << new File("${grailsHome}/scripts/Bootstrap.groovy")Instead you should use the new
grailsScript method to import a named script:
includeTargets << grailsScript("_GrailsBootstrap")2) Due to an upgrade of Gant all references to the variable
Ant should be changed to
ant.
3) The root directory of the project is no longer on the classpath, so loading a resource like this will no longer work:
def stream = getClass().classLoader.getResourceAsStream(
"grails-app/conf/my-config.xml")Instead you should use the Java File APIs with the
basedir property:
new File("${basedir}/grails-app/conf/my-config.xml").withInputStream { stream ->
// read the file
}Command Line Changes
The
run-app-https and
run-war-https commands no longer exist and have been replaced by an argument to
run-app:
Data Mapping Changes
1) Enum types are now mapped using their String value rather than the ordinal value. You can revert to the old behavior by changing your mapping as follows:
static mapping = {
someEnum enumType:"ordinal"
}2) Bidirectional one-to-one associations are now mapped with a single column on the owning side and a foreign key reference. You shouldn't need to change anything; however you should drop column on the inverse side as it contains duplicate data.
REST Support
Incoming XML requests are now no longer automatically parsed. To enable parsing of REST requests you can do so using the
parseRequest argument inside a URL mapping:
"/book"(controller:"book",parseRequest:true)
Alternatively, you can use the new
resource argument, which enables parsing by default:
2.4 アプリケーション作成
To create a Grails application you first need to familiarize yourself with the usage of the grails command which is used in the following manner:
Grailsアプリケーションを作成する前に、基本的な
grailsコマンドの使用法に慣れておきましょう。
アプリケーションを作成するコマンドは
create-appです。
grails create-app helloworld
This will create a new directory inside the current one that contains the project. Navigate to this directory in your console:
このコマンドを実行することにより、現在のディレクトリ内にプロジェクトが含まれる新しいディレクトリが作成されます。コンソールで、このディレクトリに移動してください。
cd helloworld
2.5 ハローワールド例
To implement the typical "hello world!" example cd into the "helloworld" directory created in the previous section and activate interactive mode:
単純な"Hello World！"を実装してみましょう。前のセクションで作成されたディレクトリ"helloworld"に
cdコマンドで移動してインタラクティブモードを開始します。
Grails' interactive mode will be activated and you should see a prompt that looks like the following:
Grailsのインタラクティブモードが開始されたら、プロンプトが次のように表示されます:
では、
create-controllerコマンドを実行してみましょう:
grails> create-controller hello
This will create a new controller (Refer to the section on
Controllers for more information) in the
grails-app/controllers directory called
helloworld/HelloController.groovy.
このコマンドによって、
grails-app/controllersディレクトリ内に、
HelloController.groovyという新しいコントローラ（詳細については
コントローラのセクションを参照してください）が生成されます。
If no package is specified with create-controller script, Grails automatically uses the application name as the package name. This default is configurable with the grails.project.groupId attribute in Config.groovy.
create-controllerスクリプトでパッケージが指定されなかった場合はGrailsが自動的にアプリケーション名をパッケージ名として使用します。デフォルト値はConfig.groovyにgrails.project.groupIdを指定することで変更可能です。
Controllers are capable of dealing with web requests and to fulfil the "hello world!" use case our implementation needs to look like the following:
コントローラは、Webリクエストを処理します。"hello world!"を表示するには、次のように記述します。
package helloworldclass HelloController { def world() {
render "Hello World!"
}
}Job done. Now start-up the container with another new command called
run-app:
作業は以上です。次に
run-appコマンドで、このアプリケーションを起動させましょう:
grails> run-app
This will start-up a server on port 8080 and you should now be able to access your application with the URL: http://localhost:8080/helloworld
これで8080番ポートでサーバを起動します。
http://localhost:8080/helloworldをブラウザで見てみましょう。
The result will look something like the following screenshot:
結果は次のスクリーンショットのようになります:
This is the Grails intro page which is rendered by the web-app/index.gsp file. You will note it has a detected the presence of your controller and clicking on the link to our controller we can see the text "Hello World!" printed to the browser window.
これは
grails-app/views/index.gspファイルによって描写されたアプリケーションの初期画面です。画面にはコントローラへのリンクが表示されています。このリンクをクリックすることで、画面に"Hello World！"が表示されます。
2.6 インタラクティブモードの利用
Grails 2.0 features an interactive mode which makes command execution faster since the JVM doesn't have to be restarted for each command. To use interactive mode simple type 'grails' from the root of any projects and use TAB completion to get a list of available commands. See the screenshot below for an example:
Grails 2.0では、コマンドの起動を速くするために、コマンド毎にJVMに再起動が必要無いインタラクティブモードを提供しています。インタラクティブモードを使用するには、プロジェクトルートで単に'grails'と入力するだけです。使用可能なコマンドをタブ補完することもできます。例としてスクリーンショットを参照してください:
For more information on the capabilities of interactive mode refer to the section on
Interactive Mode in the user guide.
さらなるインタラクティブモードの能力と情報に関しては、ユーザガイドの
インタラクティブモードセクションを参照してください。
2.7 IDEの設定
IntelliJ IDEA
IntelliJ IDEAと
JetGroovyプラグインは、Groovy＆Grailsの開発者に十分な機能を提供します。機能概要については、JetBrainsのウェブサイトの
Groovy and Grailsを参照してください。
To integrate Grails with IntelliJ run the following command to generate appropriate project files:
Grails 1.2でIntelliJの設定をするには、次のコマンドを実行してIntelliJ用のプロジェクトファイルを生成します。
grails integrate-with --intellij
Eclipse
We recommend that users of
Eclipse looking to develop Grails application take a look at
SpringSource Tool Suite, which offers built in support for Grails including automatic classpath management, a GSP editor and quick access to Grails commands. See the
STS Integration page for an overview.
ユーザーがGrailsアプリケーションの開発をする際は、
SpringSource Tool Suiteを探して取得することをお勧めします。それは自動クラスパス管理機能、GSPエディタやGrailsコマンドへの迅速なアクセス機能を含んだGrailsのためのサポートが組み込まれて提供されています。概要については、
STS Integrationのページを参照してください。
NetBeans
NetBeans provides a Groovy/Grails plugin that automatically recognizes Grails projects and provides the ability to run Grails applications in the IDE, code completion and integration with the Glassfish server. For an overview of features see the
NetBeans Integration guide on the Grails website which was written by the NetBeans team.
他にも良好なオープンソースのIDEとしてSunのNetBeansがあります。NetBeansはGroovy/Grailsプラグインで自動的にGrailsプロジェクトを認識します。また、IDEでのGrailsアプリケーションの実行、コード補完、SunのGlassfishサーバとの連携などの機能も提供しています。機能概要については、NetBeansチームによって記述されたGrails公式サイト上の
NetBeans Integrationガイドを参照してください。
TextMate
Since Grails' focus is on simplicity it is often possible to utilize more simple editors and
TextMate on the Mac has an excellent Groovy/Grails bundle available from the
Texmate bundles SVN.
単純さに焦点があたっているGrailsは、より単純なエディタを利用することが可能です。そしてMac上の
TextMate は
TextmateにバンドルされたSVNから優秀なGroovy/Grailsバンドルを利用可能です。
To integrate Grails with TextMate run the following command to generate appropriate project files:
GrailsでTextMateの設定をするには、次のコマンドを実行してTextMate用のプロジェクトファイルを生成します。
grails integrate-with --textmate
Alternatively TextMate can easily open any project with its command line integration by issuing the following command from the root of your project:
またTextMateはプロジェクトのルートから次のコマンドを発行することによりコマンドラインと統合し、任意のプロジェクトを簡単に開くことができます:
2.8 Convention over Configuration 設定より規約
Grails uses "convention over configuration" to configure itself. This typically means that the name and location of files is used instead of explicit configuration, hence you need to familiarize yourself with the directory structure provided by Grails.
Grailsは、"convention over configuration"を使用して、自動的に設定をおこないます。一般的に、名前とファイルの位置が明確な構成の代わりに使われることを意味します。それゆえに、Grailsによって提供されるディレクトリ構造に慣れ親む必要があります。
Here is a breakdown and links to the relevant sections:
概要と関連するセクションへのリンクです。:
grails-app - top level directory for Groovy sourcesscripts - Gant scripts.src - Supporting sources
groovy - Other Groovy sourcesjava - Other Java sources
test - Unit and integration tests.
grails-app - Groovyのソースディレクトリの最上位scripts - Gantスクリプトsrc - サポートソース
groovy - その他のGroovyのソースjava - その他のJavaソース
test - ユニットテストと統合テスト
2.9 アプリケーションの起動
Grails applications can be run with the built in Tomcat server using the
run-app command which will load a server on port 8080 by default:
Grailsアプリケーションは、
run-appコマンドを使用することで組み込みTomcatで実行することができます。デフォルトポートは8080番です。
You can specify a different port by using the server.port argument:
起動オプションに
server.portを指定して別のポートで起動することもできます。
grails -Dserver.port=8090 run-app
Note that it is better to start up the application in interactive mode since a container restart is much quicker:
$ grails
grails> run-app
| Server running. Browse to http://localhost:8080/helloworld
| Application loaded in interactive mode. Type 'exit' to shutdown.
| Downloading: plugins-list.xml
grails> exit
| Stopping Grails server
grails> run-app
| Server running. Browse to http://localhost:8080/helloworld
| Application loaded in interactive mode. Type 'exit' to shutdown.
| Downloading: plugins-list.xml
More information on the
run-app command can be found in the reference guide.
コマンドの詳細は、リファレンスガイドを参照してください。
2.10 アプリケーションのテスト
The
create-* commands in Grails automatically create unit or integration tests for you within the
test/unit or
test/integration directory. It is of course up to you to populate these tests with valid test logic, information on which can be found in the section on
Testing.
Grailsの
create-*コマンドは、自動的にUnitテストまたは統合テストをそれぞれ
test/unitまた
test/integrationディレクトリに生成します。スケルトンのテストのロジックは各自で実装してください。テストの詳細については
Testingを参考にしてください。
To execute tests you run the
test-app command as follows:
テストを実行する場合は、
test-appコマンドを使用します:
2.11 アプリケーションのデプロイ
Grails applications are deployed as Web Application Archives (WAR files), and Grails includes the
war command for performing this task:
GrailsアプリケーションはWebアプリケーションアーカイブ（WARファイル）としてデプロイされます。Grailsにはアーカイブを作成するための
warコマンドがあります:
This will produce a WAR file under the target directory which can then be deployed as per your container's instructions.
コンテナにデプロイ可能なWarファイルが
targetディレクトリ以下に生成されます。
Unlike most scripts which default to the development environment unless overridden, the war command runs in the production environment by default. You can override this like any script by specifying the environment name, for example:
他のほとんどのスクリプトと違い、
warコマンドでは、環境が
developmentにオーバーライドされて、
productionがデフォルトになります。他のスクリプトと同じく環境名を指定することで変更可能です。
NEVER deploy Grails using the
run-app command as this command sets Grails up for auto-reloading at runtime which has a severe performance and scalability implications
When deploying Grails you should always run your containers JVM with the -server option and with sufficient memory allocation. A good set of VM flags would be:
Grailsをデプロイする場合は、
-serverオプションと十分なメモリを割り当てて、Webコンテナを動作させましょう。JVM起動オプションの良い設定は次のようになります:
-server -Xmx512M -XX:MaxPermSize=256m
2.12 サポートされている Java EE コンテナ
Grails runs on any container that supports Servlet 2.5 and above and is known to work on the following specific container products:
GrailsはServlet 2.5をサポートする任意のWebコンテナで動作します。次の製品で動作することが確認されています。
- Tomcat 7
- Tomcat 6
- SpringSource tc Server
- Eclipse Virgo
- GlassFish 3
- GlassFish 2
- Resin 4
- Resin 3
- JBoss 6
- JBoss 5
- Jetty 7
- Jetty 6
- IBM Websphere 7.0
- IBM Websphere 6.1
- Oracle Weblogic 10.3
- Oracle Weblogic 10
- Oracle Weblogic 9
一部のWebコンテナにはバグがありますが、ほとんどの場合では回避することができます。
既知の開発時における課題の一覧は、GrailsのWikiにあります。
2.13 アプリケーション生成
To get started quickly with Grails it is often useful to use a feature called
Scaffolding to generate the skeleton of an application. To do this use one of the
generate-* commands such as
generate-all, which will generate a
controller (and its unit test) and the associated
views:
Grailsでは、アプリケーションのスケルトンを生成する
スカッフォールディングの機能を使用することにより、素早く開発することができます。Grailsにはアプリケーションのスケルトンを生成する
スカッフォールディングという機能があります。これをするには、
コントローラと関連する
ビューを生成する
generate-allなどを使用します。
2.14 アーテファクトの作成
Grailsには
コントローラや様々なアーテファクトを生成する
create-controllerや
create-domain-classなどのコマンドが存在します。
These are just for your convenience and you can just as easily use an IDE or your favourite text editor.
アーテファクト生成は便利機能です。IDEやテキストエディタを使用してもかまいません。
For example to create the basis of an application you typically need a
domain model:
例として
ドメインモデルを生成するには:
grails create-domain-class book
This will result in the creation of a domain class at grails-app/domain/Book.groovy such as:
このコマンドを実行すると、
grails-app/domain/Book.groovyに以下のようなドメインクラスが作成されます:
There are many such create-* commands that can be explored in the command line reference guide.
他にも
create-*コマンドがあります。詳しくはコマンドライン・リファレンス・ガイドを参照しましょう。
To decrease the amount of time it takes to run Grails scripts, use the
interactive mode.
