2009年8月10日月曜日

maven setup

Introduction
Quick Overview

The settings element in the settings.xml file contains elements used to define values which configure Maven execution in various ways, like the pom.xml, but should not be bundled to any specific project, or distributed to an audience. These include values such as the local repository location, alternate remote repository servers, and authentication information. There are two locations where a settings.xml file may live:

* The Maven install: $M2_HOME/conf/settings.xml
* A user's install: ${user.home}/.m2/settings.xml

Here is an overview of the top elements under settings:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">












Settings Details
Simple Values

Half of the top-level settings elements are simple values, representing a range of values which describe elements of the build system that are active full-time.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
${user.home}/.m2/repository
true
false
false

org.mortbay.jetty

...


* localRepository: This value is the path of this build system's local repository. The default value is ${user.home}/.m2/repository. This element is especially useful for a main build server allowing all logged-in users to build from a common local repository.
* interactiveMode: true if Maven should attempt to interact with the user for input, false if not. Defaults to true.
* usePluginRegistry: true if Maven should use the ${user.home}/.m2/plugin-registry.xml file to manage plugin versions, defaults to false. Note that for the current version of Maven 2.0, the plugin-registry.xml file should not be depended upon. Consider it dormant for now.
* offline: true if this build system should operate in offline mode, defaults to false. This element is useful for build servers which cannot connect to a remote repository, either because of network setup or security reasons.
* pluginGroups: This element contains a list of pluginGroup elements, each contains a groupId. The list is searched when a plugin is used and the groupId is not provided in the command line. This list automatically contains org.apache.maven.plugins and org.codehaus.mojo. For example, given the above settings the Maven command line may execute org.mortbay.jetty:jetty-maven-plugin:run with the truncated command:

mvn jetty:run

Servers

The repositories for download and deployment are defined by the repositories and distributionManagement elements of the POM. However, certain settings such as username and password should not be distributed along with the pom.xml. This type of information should exist on the build server in the settings.xml.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


server001
my_login
my_password
${user.home}/.ssh/id_dsa
some_passphrase
664
775



...


* id: This is the ID of the server (not of the user to login as) that matches the id element of the repository/mirror that Maven tries to connect to.
* username, password: These elements appear as a pair denoting the login and password required to authenticate to this server.
* privateKey, passphrase: Like the previous two elements, this pair specifies a path to a private key (default is ${user.home}/.ssh/id_dsa) and a passphrase, if required. The passphrase and password elements may be externalized in the future, but for now they must be set plain-text in the settings.xml file.
* filePermissions, directoryPermissions: When a repository file or directory is created on deployment, these are the permissions to use. The legal values of each is a three digit number corrosponding to *nix file permissions, ie. 664, or 775.

Note: If you use a private key to login to the server, make sure you omit the element. Otherwise, the key will be ignored.
Password Encryption

A new feature - server password and passphrase encryption has been added to 2.1.x and 3.0 trunks. See details on this page
Mirrors

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


planetmirror.com
PlanetMirror Australia
http://downloads.planetmirror.com/pub/maven2
central


...


* id, name: The unique identifier and user-friendly name of this mirror. The id is used to differentiate between mirror elements and to pick the corresponding credentials from the section when connecting to the mirror.
* url: The base URL of this mirror. The build system will use this URL to connect to a repository rather than the original repository URL.
* mirrorOf: The id of the repository that this is a mirror of. For example, to point to a mirror of the Maven central repository (http://repo1.maven.org/maven2/), set this element to central. More advanced mappings like repo1,repo2 or *,!inhouse are also possible. This must not match the mirror id.

For a more in-depth introduction of mirrors, please read the Guide to Mirror Settings.
Proxies

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


myproxy
true
http
proxy.somewhere.com
8080
proxyuser
somepassword
*.google.com|ibiblio.org


...


* id: The unique identifier for this proxy. This is used to differentiate between proxy elements.
* active: true if this proxy is active. This is useful for declaring a set of proxies, but only one may be active at a time.
* protocol, host, port: The protocol://host:port of the proxy, seperated into discrete elements.
* username, password: These elements appear as a pair denoting the login and password required to authenticate to this proxy server.
* nonProxyHosts: This is a list of hosts which should not be proxied. The delimiter of the list is the expected type of the proxy server; the example above is pipe delimited - comma delimited is also common.

Profiles

The profile element in the settings.xml is a truncated version of the pom.xml profile element. It consists of the activation, repositories, pluginRepositories and properties elements. The profile elements only include these four elements because they concerns themselves with the build system as a whole (which is the role of the settings.xml file), not about individual project object model settings.

If a profile is active from settings, its values will override any equivalently ID'd profiles in a POM or profiles.xml file.
Activation

Activations are the key of a profile. Like the POM's profiles, the power of a profile comes from its ability to modify some values only under certain circumstances; those circumstances are specified via an activation element.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


test

false
1.5

Windows XP
Windows
x86
5.1.2600


mavenVersion
2.0.3


${basedir}/file2.properties
${basedir}/file1.properties


...


...


Activation occurs when all specified criteria have been met, though not all are required at once.

* jdk: activation has a built in, Java-centric check in the jdk element. This will activate if the test is run under a jdk version number that matches the prefix given. In the above example, 1.5.0_06 will match. Ranges are also supported as of Maven 2.1. See the maven-enforcer-plugin for more details about supported ranges.
* os: The os element can define some operating system specific properties shown above. See the maven-enforcer-plugin for more details about OS values.
* property: The profile will activate if Maven detects a property (a value which can be dereferenced within the POM by ${name}) of the corresponding name=value pair.
* file: Finally, a given filename may activate the profile by the existence of a file, or if it is missing.

The activation element is not the only way that a profile may be activated. The settings.xml file's activeProfile element may contain the profile's id. They may also be activated explicitly through the command line via a comma separated list after the -P flag (e.g. -P test).

To see which profile will activate in a certain build, use the maven-help-plugin.

mvn help:active-profiles

Properties

Maven properties are value placeholder, like properties in Ant. Their values are accessible anywhere within a POM by using the notation ${X}, where X is the property. They come in five different styles, all accessible from the settings.xml file:

1. env.X: Prefixing a variable with "env." will return the shell's environment variable. For example, ${env.PATH} contains the $path environment variable (%PATH% in Windows).
2. project.x: A dot (.) notated path in the POM will contain the corresponding element's value. For example: 1.0 is accessible via ${project.version}.
3. settings.x: A dot (.) notated path in the settings.xml will contain the corresponding element's value. For example: false is accessible via ${settings.offline}.
4. Java System Properties: All properties accessible via java.lang.System.getProperties() are available as POM properties, such as ${java.home}.
5. x: Set within a element or an external files, the value may be used as ${someVar}.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


...

${user.home}/our-project

...


...


The property ${user.install} is accessible from a POM if this profile is active.
Repositories

Repositories are remote collections of projects from which Maven uses to populate the local repository of the build system. It is from this local repository that Maven calls it plugins and dependencies. Different remote repositories may contain different projects, and under the active profile they may be searched for a matching release or snapshot artifact.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


...


codehausSnapshots
Codehaus Snapshots

false
always
warn


true
never
fail

http://snapshots.maven.codehaus.org/maven2
default



...

...


...


* releases, snapshots: These are the policies for each type of artifact, Release or snapshot. With these two sets, a POM has the power to alter the policies for each type independent of the other within a single repository. For example, one may decide to enable only snapshot downloads, possibly for development purposes.
* enabled: true or false for whether this repository is enabled for the respective type (releases or snapshots).
* updatePolicy: This element specifies how often updates should attempt to occur. Maven will compare the local POM's timestamp (stored in a repository's maven-metadata file) to the remote. The choices are: always, daily (default), interval:X (where X is an integer in minutes) or never.
* checksumPolicy: When Maven deploys files to the repository, it also deploys corresponding checksum files. Your options are to ignore, fail, or warn on missing or incorrect checksums.
* layout: In the above description of repositories, it was mentioned that they all follow a common layout. This is mostly correct. Maven 2 has a default layout for its repositories; however, Maven 1.x had a different layout. Use this element to specify which if it is default or legacy.

Plugin Repositories

Repositories are home to two major types of artifacts. The first are artifacts that are used as dependencies of other artifacts. These are the majority of plugins that reside within central. The other type of artifact is plugins. Maven plugins are themselves a special type of artifact. Because of this, plugin repositories may be separated from other repositories (although, I have yet to hear a convincing argument for doing so). In any case, the structure of the pluginRepositories element block is similar to the repositories element. The pluginRepository elements each specify a remote location of where Maven can find new plugins.
Active Profiles

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...

env-test



The final piece of the settings.xml puzzle is the activeProfiles element. This contains a set of activeProfile elements, which each have a value of a profile id. Any profile id defined as an activeProfile will be active, reguardless of any environment settings. If no matching profile is found nothing will happen. For example, if env-test is an activeProfile, a profile in a pom.xml (or profile.xml with a corrosponding id will be active. If no such profile is found then execution will continue as normal.

maven setup

Introduction
Quick Overview

The settings element in the settings.xml file contains elements used to define values which configure Maven execution in various ways, like the pom.xml, but should not be bundled to any specific project, or distributed to an audience. These include values such as the local repository location, alternate remote repository servers, and authentication information. There are two locations where a settings.xml file may live:

* The Maven install: $M2_HOME/conf/settings.xml
* A user's install: ${user.home}/.m2/settings.xml

Here is an overview of the top elements under settings:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">












Settings Details
Simple Values

Half of the top-level settings elements are simple values, representing a range of values which describe elements of the build system that are active full-time.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
${user.home}/.m2/repository
true
false
false

org.mortbay.jetty

...


* localRepository: This value is the path of this build system's local repository. The default value is ${user.home}/.m2/repository. This element is especially useful for a main build server allowing all logged-in users to build from a common local repository.
* interactiveMode: true if Maven should attempt to interact with the user for input, false if not. Defaults to true.
* usePluginRegistry: true if Maven should use the ${user.home}/.m2/plugin-registry.xml file to manage plugin versions, defaults to false. Note that for the current version of Maven 2.0, the plugin-registry.xml file should not be depended upon. Consider it dormant for now.
* offline: true if this build system should operate in offline mode, defaults to false. This element is useful for build servers which cannot connect to a remote repository, either because of network setup or security reasons.
* pluginGroups: This element contains a list of pluginGroup elements, each contains a groupId. The list is searched when a plugin is used and the groupId is not provided in the command line. This list automatically contains org.apache.maven.plugins and org.codehaus.mojo. For example, given the above settings the Maven command line may execute org.mortbay.jetty:jetty-maven-plugin:run with the truncated command:

mvn jetty:run

Servers

The repositories for download and deployment are defined by the repositories and distributionManagement elements of the POM. However, certain settings such as username and password should not be distributed along with the pom.xml. This type of information should exist on the build server in the settings.xml.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


server001
my_login
my_password
${user.home}/.ssh/id_dsa
some_passphrase
664
775



...


* id: This is the ID of the server (not of the user to login as) that matches the id element of the repository/mirror that Maven tries to connect to.
* username, password: These elements appear as a pair denoting the login and password required to authenticate to this server.
* privateKey, passphrase: Like the previous two elements, this pair specifies a path to a private key (default is ${user.home}/.ssh/id_dsa) and a passphrase, if required. The passphrase and password elements may be externalized in the future, but for now they must be set plain-text in the settings.xml file.
* filePermissions, directoryPermissions: When a repository file or directory is created on deployment, these are the permissions to use. The legal values of each is a three digit number corrosponding to *nix file permissions, ie. 664, or 775.

Note: If you use a private key to login to the server, make sure you omit the element. Otherwise, the key will be ignored.
Password Encryption

A new feature - server password and passphrase encryption has been added to 2.1.x and 3.0 trunks. See details on this page
Mirrors

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


planetmirror.com
PlanetMirror Australia
http://downloads.planetmirror.com/pub/maven2
central


...


* id, name: The unique identifier and user-friendly name of this mirror. The id is used to differentiate between mirror elements and to pick the corresponding credentials from the section when connecting to the mirror.
* url: The base URL of this mirror. The build system will use this URL to connect to a repository rather than the original repository URL.
* mirrorOf: The id of the repository that this is a mirror of. For example, to point to a mirror of the Maven central repository (http://repo1.maven.org/maven2/), set this element to central. More advanced mappings like repo1,repo2 or *,!inhouse are also possible. This must not match the mirror id.

For a more in-depth introduction of mirrors, please read the Guide to Mirror Settings.
Proxies

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


myproxy
true
http
proxy.somewhere.com
8080
proxyuser
somepassword
*.google.com|ibiblio.org


...


* id: The unique identifier for this proxy. This is used to differentiate between proxy elements.
* active: true if this proxy is active. This is useful for declaring a set of proxies, but only one may be active at a time.
* protocol, host, port: The protocol://host:port of the proxy, seperated into discrete elements.
* username, password: These elements appear as a pair denoting the login and password required to authenticate to this proxy server.
* nonProxyHosts: This is a list of hosts which should not be proxied. The delimiter of the list is the expected type of the proxy server; the example above is pipe delimited - comma delimited is also common.

Profiles

The profile element in the settings.xml is a truncated version of the pom.xml profile element. It consists of the activation, repositories, pluginRepositories and properties elements. The profile elements only include these four elements because they concerns themselves with the build system as a whole (which is the role of the settings.xml file), not about individual project object model settings.

If a profile is active from settings, its values will override any equivalently ID'd profiles in a POM or profiles.xml file.
Activation

Activations are the key of a profile. Like the POM's profiles, the power of a profile comes from its ability to modify some values only under certain circumstances; those circumstances are specified via an activation element.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


test

false
1.5

Windows XP
Windows
x86
5.1.2600


mavenVersion
2.0.3


${basedir}/file2.properties
${basedir}/file1.properties


...


...


Activation occurs when all specified criteria have been met, though not all are required at once.

* jdk: activation has a built in, Java-centric check in the jdk element. This will activate if the test is run under a jdk version number that matches the prefix given. In the above example, 1.5.0_06 will match. Ranges are also supported as of Maven 2.1. See the maven-enforcer-plugin for more details about supported ranges.
* os: The os element can define some operating system specific properties shown above. See the maven-enforcer-plugin for more details about OS values.
* property: The profile will activate if Maven detects a property (a value which can be dereferenced within the POM by ${name}) of the corresponding name=value pair.
* file: Finally, a given filename may activate the profile by the existence of a file, or if it is missing.

The activation element is not the only way that a profile may be activated. The settings.xml file's activeProfile element may contain the profile's id. They may also be activated explicitly through the command line via a comma separated list after the -P flag (e.g. -P test).

To see which profile will activate in a certain build, use the maven-help-plugin.

mvn help:active-profiles

Properties

Maven properties are value placeholder, like properties in Ant. Their values are accessible anywhere within a POM by using the notation ${X}, where X is the property. They come in five different styles, all accessible from the settings.xml file:

1. env.X: Prefixing a variable with "env." will return the shell's environment variable. For example, ${env.PATH} contains the $path environment variable (%PATH% in Windows).
2. project.x: A dot (.) notated path in the POM will contain the corresponding element's value. For example: 1.0 is accessible via ${project.version}.
3. settings.x: A dot (.) notated path in the settings.xml will contain the corresponding element's value. For example: false is accessible via ${settings.offline}.
4. Java System Properties: All properties accessible via java.lang.System.getProperties() are available as POM properties, such as ${java.home}.
5. x: Set within a element or an external files, the value may be used as ${someVar}.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


...

${user.home}/our-project

...


...


The property ${user.install} is accessible from a POM if this profile is active.
Repositories

Repositories are remote collections of projects from which Maven uses to populate the local repository of the build system. It is from this local repository that Maven calls it plugins and dependencies. Different remote repositories may contain different projects, and under the active profile they may be searched for a matching release or snapshot artifact.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...


...


codehausSnapshots
Codehaus Snapshots

false
always
warn


true
never
fail

http://snapshots.maven.codehaus.org/maven2
default



...

...


...


* releases, snapshots: These are the policies for each type of artifact, Release or snapshot. With these two sets, a POM has the power to alter the policies for each type independent of the other within a single repository. For example, one may decide to enable only snapshot downloads, possibly for development purposes.
* enabled: true or false for whether this repository is enabled for the respective type (releases or snapshots).
* updatePolicy: This element specifies how often updates should attempt to occur. Maven will compare the local POM's timestamp (stored in a repository's maven-metadata file) to the remote. The choices are: always, daily (default), interval:X (where X is an integer in minutes) or never.
* checksumPolicy: When Maven deploys files to the repository, it also deploys corresponding checksum files. Your options are to ignore, fail, or warn on missing or incorrect checksums.
* layout: In the above description of repositories, it was mentioned that they all follow a common layout. This is mostly correct. Maven 2 has a default layout for its repositories; however, Maven 1.x had a different layout. Use this element to specify which if it is default or legacy.

Plugin Repositories

Repositories are home to two major types of artifacts. The first are artifacts that are used as dependencies of other artifacts. These are the majority of plugins that reside within central. The other type of artifact is plugins. Maven plugins are themselves a special type of artifact. Because of this, plugin repositories may be separated from other repositories (although, I have yet to hear a convincing argument for doing so). In any case, the structure of the pluginRepositories element block is similar to the repositories element. The pluginRepository elements each specify a remote location of where Maven can find new plugins.
Active Profiles

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...

env-test



The final piece of the settings.xml puzzle is the activeProfiles element. This contains a set of activeProfile elements, which each have a value of a profile id. Any profile id defined as an activeProfile will be active, reguardless of any environment settings. If no matching profile is found nothing will happen. For example, if env-test is an activeProfile, a profile in a pom.xml (or profile.xml with a corrosponding id will be active. If no such profile is found then execution will continue as normal.

第3回Seasar勉強会

東北デベロッパーズ・コミュニティ:第3回Seasar勉強会CommentsAdd Star

オープンソース, コンピュータ

こちらに参加しての所感

TDC : 第3回Seasar勉強会 in Sendaiを5/30に開催します!

http://tohoku-dev.jp/modules/news/article.php?storyid=18
参加動機と会場について

 正直、SAStrutsの勉強よりも勉強会ってどんなものだろうか?ってのを体感したくて参加してみました。あと、自分は社内で勉強会を開いたり、前でしゃべる機会もある方みたいなのですが、いつも「これでいいのかな?」って思いながらやっている。そんなワケで、どんなしゃべり方、進め方をすればよいか見て参考にするため。


 会場は以外と狭くて、1つのテーブルで2人、2つのテーブルをくっつけてお互いのテーブルの人が向かい側に座る構成。単に机を講師に向けて座るよりこうしたほうが、分からないときにお互いに聞きやすくなるんだろう。(聞く人が1人から、3人に増える)ただ、初めて会う方が多いのに向かい合って座るこういった状況はすごく緊張する。あいている場所で一応「ここいいですか?」って言って座る。駄目って言われたらどうしよう・・・とか思いながら。ここで以前仕事で一緒になった方に会う。あとはぜんぜん知らない人ばかり。正直この人には嫌われていたと思っていたけど、それでもちょっとは気が楽になった。普通に対応してくれて感謝。こういった勉強会は参加するメンバーの固定率が高くなるのかな?自分以外はなんか知り合いって感じがした。


 事前にインストールするソフトウエアなどもあったので、行ったらネットにつなげない環境になるのかなと思ったけど、LANが完備してあって随時必要なものはネットに取りに行けたし、なによりインストールすべきソフトを運営側がUSBで提供してくれていたので、安心でした。こういった勉強会は勉強したくて来るので自分のPC持って来いって言われても何の違和感も無いし、自分のPC使うほうが楽なんだけど、人によっては家ではスペックの低いマシンでメールするぐらいって人もいるだろうから、貸し出しPCも用意されるともっと敷居が低くなるんではと感じた。(無理なお願いですけどね)

Slim3についての紹介(ひがさん講演)

 ひがさんの講演はSlim3の紹介。ブログの方でいろいろ書いていたような気がするけど、正直頭に入っていなかった。講演という形で紹介されると結構わかったような気がしてくるのは不思議。Slim3はGoogle Apps上で実行できるアプリケーションを作るためのフレームワークみたいなものって認識しました。これでよいんだろうか?また、Slim3の開発にはブランクアプリケーションが用意されているので、これを修正、追加する形で作成していく方式。たとえば、Slim3Controlerというクラスがあるので、これを自分で作るアプリケーションにあわせた名前に変えていくとか。

※ Slim3は、Seasar2の後継となるコンテナーとのこと。紹介の中でGoogle Appsと一緒の形で紹介されていたのでGoogle Appsのものを作るためのものかと勘違いしてしまった。ちなみにSimple less moreという言葉から来ているらしく、スリムスリーと呼ぶらしい。
Slim3はMVC

  Slim3はMVCで出来ていて、リクエストはControlerが受け取るということで、1リクエストに対し、1Controlerが必要。でもその Controlerを作るために手でシコシコ書いていくのではなくて、Antで自動生成するとのこと。なるほどこうやって作る人の手間と間違いの元を省いてくれるとな。
Google AppsのBigTable

 Google AppsはRDBMSではなくBigTableというDBを使うけど、そのときにjdoかjpaのどちらかでアクセスするんだけど、お勧めはjdoだそうな。理由はjpaっていうのはRDBMSを意識して作ってあるのに対し、jdoはデータの格納先を意識しないつくりになっていて、たとえば格納先がXMLだろうがRDBMSだろうが、ファイルだろうが意識しなくてもいいようになっている。さらに言うとGoogle Appsを開発している人たちがjdo好きが多いからだそうな。
Slim3とTDDと自分なりの所感

 ブランクアプリケーションにはテストのフォルダもあり、 TDD(テスト駆動開発)についても説明があった。今作ろうとしている小さな部分を頭で整理して小さなテストを書いてからコードを組むんだけど、最終的にはテストは全体のテストを行う集合体になる。作っているうちに前に作ったテストでコケるって言うことは、今作ったものが前作ったメソッドなどの使い方を間違っているかもってことが一目瞭然になる。


 管理者的には「製造」と「テスト」が分けられなくて日程組めないんでは?とか疑問に思うかもしれないけど、この方法をとれば、逆に作るものの日程の「見える化」ができるんではないかと思った。たとえば「xx画面」製造3日、テスト4日って組むんではなくて、「xx画面のyy処理」1日、「xx画面のzzボタン」4時間ってな具合に、作るものを細分化していくことが可能。だけど、普通は開発効率は上がっていくって日程を組むんだろうけど、この場合は前に作ったテストでコケるのは単純に今作ったものが悪いからではなくて、調査する時間も必要になるし、その調査する時間は増えていくと思われるので、その辺を考えて日程を組む必要があるのかなぁと感じた。

Slim3への所感

 ちょっと紹介された程度なので、いい感じなんだけど実際の開発の際には、Controlerの基底クラスなんか作りたいってなるかもしれない。その場合は Antをちょっといじるだけで済むんだろうか。テンプレートファイルがあってそっちを変更する程度なんだろうか?それとも大規模な変更が必要(Slim3 自体を変更してコンパイルしなおすとか)なんだろうか・・・その辺を調べる必要があるなと思った。(※下記追記参照)最後にGoogle Appsにデプロイする方法もやってくれて、Eclipse上からボタン1個でデプロイできた。あまり迷わなそう。実は仕事上こまごまとした空き時間ができてきて、RubyかPHPかGoogle Appsのどれかの調査をしようと思っていたけど、こうなったら決まりね。Google AppsとBigTableを勉強することに決定。その方法としてSlim3を使ってみる。こうして自分の中のJava比率が高まってJavaしか知らない使えない人になっていくのでした。

2009/06/08追記

 http://blog.takeda-soft.jp/blog/show/339を見ていて、ひがさん本人からのコメントを発見!

ひが
2009/06/04
ControllerとTestCaseの継承元を任意のものに
変える機能をslim3-blankにコミットしました。
build.xmlのsuperclassNameとtestCaseSuperclassName
を適当に書き換えてください。

 で、該当するbuild.xmlのプロパティ(superclassName、testCaseSuperclassName)の値を書き換えればいいようですね。下記はhttp://slim3.googlecode.com/svn/trunk/slim3-blank/build.xmlから参照。



・・・省略




・・・省略

 なるほど~!

SAStruts勉強会

 本日のメインイベント。SAStrutsの勉強会。SAStruts、S2JDBC、Doltengを体感するのが目的らしい。SAStrutsはSuper Agile Strutsの略らしい。Strutsなのに設定ファイルを書かないとか、SeasarなんでHot Deployとか。S2JDBCは可読性の高さとIDEの補完機能を有効に活用できるので生産性が高くなりますよということ。


 Doltengでは、プロジェクトを作成すると自動的にブランクアプリケーションみたいなディレクトリ構造を作ってくれるので、これに変更を加えていく開発方法。MFCのウィザードとスケルトンを思い出したのは自分だけだろうか。あと、データベースはすでにH2が組み込まれてあるので、楽だよということ。ローカルPCにデータベースが組まれているので、データはもちろん、テーブル自体を変更する必要がある場合などに、ローカルPCで検証してから全員に反映することも可能になるので開発効率がいいよと言うこと。その際のローカル側のテーブル変更とか、それに伴うプロジェクト側のエンティティの変更とかもAntで一発なので楽ということと、マイグレーションする際に保存してあったデータなんかも復元してくれるらしい。


 SAStrutsでもStrutsと同じくActionクラスを作るんだけどStrutsが1URLに対し1アクションなのに対し、SAStrutsでは1ユースケースあたり1アクション(xx画面を使うとか)になるとのこと。この辺は1アクションクラスにイベントが集まるようになるので、分かりやすいなと思う。通常設計書としてはxx画面とか1まとまりにすることが多いし、フレームワーク非依存(そんなの実は本当に可能かってのは置いといて)に書く場合なんかはxx画面=xxクラスって書かれることが多いけど、そういった場合の設計書との乖離も少なくなると思われる。Actionクラスもたとえば LoginActionクラスとかを作ると、URL上でも「コンテキストパス/login」となるとか、/で終わると、index()が呼び出されるとか、login/xxxxでxxxxがメソッド名になるとか確認が想像しやすいという感じ。

SAStrutsでは設定ファイルを書かない

 そういえば設定ファイルぜんぜん書かないって事に気がついた。struts-config.xmlだのvalidation.xmlだの。全部アノテーションとして表現してる。スゲー。内部ではどんな風に動いているんだろう。アノテーションをガリガリ書かせるってのはなんかJavaじゃないような気がして自分では好きな方ではないけど、POJOで表現する場合にはこういった方法が合っているんだろうなぁ。

Hot Deploy

 あと、Hot Deployだけど、普通Webアプリを作っていて、コンテキストをreloadable=trueにしていれば、クラスを変更するとそのアプリケーションだけ再起動して変更が反映されるよね。Hot Deployってどう違うの?って思っていたけど、なるほどこれはすごいね。サーバを再起動しないといけないようなものもそうだけど、アプリケーションの再起動する時間(サーバが変更を感知して再起動するまでの時間)すらないので、すぐに確認ができる。コレか?


参加して

  Slim3もSAStrutsもだけど、開発する際のディレクトリは実際に実行されるアプリケーションのディレクトリ構造とは異なっていてちょっと面食らう。なんでこう複雑になるかは理由は分かっているんだけど、自分が講習でやるときはWebアプリ未経験者を対象にすることが多いので開発ディレクトリ構成=アプリケーションディレクトリ構成になるようにしてた。そのほうが単純で想像しやすいから。でもこれに関しては、いろいろなAntやDoltengなどの便利ツールの集合体なので、会社で勉強会をやるときは「こんなもんだ」「とりあえず、今日はココは見ないでね」とか、講習の対象者に見る部分を限定させてやるしかないかなと感じた。(見ないでといっても見えてしまうのが人間だから、そこで迷うかもしれないけど、その辺を考える必要があるなと感じた)


 今回はSAStrutsを触ったことが無い人を対象に「使い方」を勉強した。でも「使い方」よりも内部でどんな風に動いているかって方に興味があって、その辺をやってほしいなと思う。オープンソースなので「ソース見ろ」って感じになるけど、その辺を一人で苦労しながら寂しく見るより、みんなで集まって有識者から教えられるベースでコードリーディングすれば、覚えるべき部分が一本の線になるので良いと思う。なにより内部の動きなんかの知識が増ると言うことは、開発の際の色々な調査の元ネタになるので。

 懇親会はヘルニアの調子がおかしくなってきたので辞退させていただきました。次は行ってみたいと思います。運営の皆様、お疲れさまでした。開催することにも興味があるので、次は何かしらスタッフとしても協力できたらと思います。

 P.S LLで、Tracで萌えな話とか、Seasar勉強会なのにWicketとかClickの話をして怒りを買ってみたいとか思った自分がいた。

OGNL

참조
http://starplatina.tistory.com/126?rchid=BR1http%3A%2F%2Fstarplatina.tistory.com%2F126


에서 property 태그는 value의 값을 OGNL로 평가한다.
#표시가 없는 OGNL 표현식 name은 루트 오브젝트의 property이다.
스트럿츠2에서 루트 오브젝트는 value stack이고 value stack 상단에 액션이 있으므로 "name"은 항상 액션의 property가 된다.
JSP EL의 ${name}과 같다.


루트 오브젝트가 아닌 세션 맵의 user를 참조할 때는 위와 같이 "#"을 붙여서 오브젝트 이름과 프라퍼티 또는 맵의 키를 사용해서 참조한다. 루트 오브젝트의 프라퍼티만 프라퍼티 이름만으로 참조 할 수 있다.
JSP EL의 ${sessionScope.user }와 같다.

스트럿츠 2 태그에서 %{...}가 OGNL의 표현식이다. 즉 %{...}내의 텍스트는 OGNL 표현식으로 평가된다.
%{name}이라 하면 문자열 name이 아니고 name을 OGNL 표현식으로 평가한다..
따라서 %{name}은 액션의 name의 프라퍼티 값이 된다.

콜렉션.{ 조작 }

그리고 새로운 콜렉션이 돌려주어진다.{ }안에서는 #this로 현재 요소를 참조할 수 있다.
예를 들면 문자열의 리스트가 있었다고 해서, 각 요소의 뒤에 " ({문자열장})"와 같은 문자열을 부가한 리스트를
작성하고 싶은 경우는 다음과 같이 쓸 수 있다.

list1 의 작성










[]


결과는[aaa (3)] [bb (2)] [ccc (3)] [dd (2)] [eee (3)] [fff (3)]



[]

결과 : [item20][item300]

Struts2의 각종 파일로 이용할 수 있는 OGNL식에서, in구를 사용하면 콜렉션중에서의 요소의 존재를 간단하게 조사할 수 있다JSP의 경우 다음과 같은 리스트가 있었다고 하면
이 결과는item2:[]

item20:[]

item200:[]

이렇게 된다.item2:[false]item20:[true]item200:[false]TIPS:not in도 있다 넘어온 파라메터의 형이 String 타입이면 xxxx.equals("yyyyyy") 로 표현가능

JSON-libでXMLのJSON化

JSON-libでXMLのJSON化
近頃AmazonのAPIで遊んでます。
http://suz-lab.blogspot.com/2008/01/amazon-associates-web-service.html

残念なことに、Amazonからのレスポンスは、
僕の苦手なXMLです。一刻も早くJSONに変換したいところです。

今までは、該当XMLをJavascript側で、
XML.ObjTreeを用いてJSONに変換していましたが、
http://www.kawa.net/works/js/xml/objtree.html
今回は、JSON-libを用いてJava側で変換してみました。
http://json-lib.sourceforge.net/

依存関係も含めて、上記サイトから、
必要なjarを取得&配置すればよいのですが、
XMLまわりの処理では、XOMも必要になります。
http://www.xom.nu/
(サイトのどこかには書いてあるのかなー?見つけられなかった…)

以上のjarが準備できたら、下記のように利用することができます。
--------
String xml ="XMLを文字列かしたもの";
XMLSerializer serializer = new XMLSerializer();
JSON json = serializer.read(xml);
json.toString(); // Stringで出力
--------

いい感じに変換してくれます
ただ、配列まわりの処理が融通ききません。
つまり、


  aaa
  bbb

↓
{root: ["aaa", "bbb"]}


  aaa

↓
{root: "aaa"}

となってしまいます。
{root: ["aaa"]}
となってほしいところですが、
強制的にそうするすべもなさそうです。
(XML.ObjTreeのforce_arrayのようなもの)

なので、今回は、Javascript側で、
object instanceof Array
で条件分岐して対応しました。

こう考えると、XML.ObjTreeの方が使いやすく感じてしまいます。
xmlObjectifier(jQuery)はどうなんだろう?
http://www.terracoder.com/
XPathを使うべきか?
http://coderepos.org/share/wiki/JavaScript-XPath
難しく考えすぎ?

この辺、まだまだ揺れてます。

アノテーションのアノテーション

アノテーションのアノテーション

アノテーションを読み込んでクラスやフィールドなどの情報を管理するという手法が可能になりますが、そのためにメタアノテーションを知る必要があります。 メタアノテーションとは、単純にアノテーションに指定するアノテーションです。

例えば、デフォルトでアノテーションは、クラスやフィールド、メソッドやコンストラクタなど、アノテーションが指定できるあらゆる宣言に記述可能です。 しかし、アノテーションの目的によってはクラスだけに指定して意味のあるものや、メソッドだけに指定して意味のあるものが存在します。 例として、メタアノテーションはアノテーションに指定するためのアノテーションであり、メタアノテーションをクラスに指定することに意味はありません。 こうした問題を解決するための、アノテーションの振る舞いや制限を指定するのがメタアノテーションなのです。

メタアノテーションには、コンパイラが認識することができる標準メタアノテーションと呼ばれるものが用意されています。 この標準メタアノテーションは java.lang.annotation パッケージで宣言されていて、アノテーションの扱いを決定する重要な存在です。

java.lang.annotation.Target アノテーションは、アノテーション型の宣言にのみ利用できるメタアノテーションであり、アノテーションの対象を指定することができます。 Target アノテーションは、シングル・メンバ・アノテーションなので、value() という名前のメソッドを持ちます。

public abstract ElementType[] value

このメンバは ElementType[] 型なので、Target アノテーションは ElementType の配列で初期化されなければなりません。 ElementType 型は java.lang.annotation.ElementType 列挙型で、アノテーションの対象要素を表す定数を提供しています。
定数 解説
ANNOTATION_TYPE アノテーション
CONSTRUCTOR コンストラクタ
FIELD フィールド
LOCAL_VARIABLE ローカル変数
METHOD メソッド
PACKAGE パッケージ
PARAMETER パラメータ
TYPE クラス、インタフェース、または列挙型

アノテーションの対象がクラスなどの型なのであれば、アノテーション宣言で Target アノテーションに ElementType.TYPE を指定すればよいのです。 複数の要素を対象とするには、{ } で囲んで配列の定数として渡します。

import java.lang.annotation.*;

@Target(ElementType.TYPE)
@interface Copyright {
String value();
}

@Copyright("LeonAkasaka") //OK
public class Test {
@Copyright("LeonAkasaka") //エラー
public static void main(String [] args) {
}
}

このプログラムの Copyright アノテーションは、クラス、インタフェース、または列挙型にのみ指定できる ElementType.TYPE を対象に指定しています。 そのため、Test クラスに Copyright を指定することは問題ありませんが、main() メソッドに指定した場合はコンパイルエラーとなります。

Target アノテーションも Target アノテーションで ElementType.ANNOTATION_TYPE を設定されています。 そのため、Target アノテーションはアノテーションにしか指定できません。
アノテーションの配置

アノテーションは、他のツールからプログラムの注釈情報をプログラム的に読み込むことができる重要な機能ですが、プログラムの実行時に影響を及ぼすものではありません。 そのため、アノテーション情報を実行時にメモリに読み込むことが、必ずしも有益になるとは限らないのです。 実行時にクラスが保有する必要の無いアノテーションであれば、コンパイル時に破棄するか、クラスファイルを読み込む時にアノテーションは読み込まないようにするという方法が考えられます。

このように、アノテーションを実行時に VM に読み込ませるかどうかを指定するメタアノテーションが java.lang.annotation.Retention アノテーションです。 Retantion アノテーションはシングル・メンバ・アノテーションです。

public abstract RetentionPolicy value

java.lang.annotation.RetentionPolicy 列挙型は、アノテーションの配置方法を指定する定数が提供されています。
定数 解説
CLASS アノテーションはコンパイラによってクラスファイルに記録されます。しかし、実行時に VM に読み込まれることはありません。
RUNTIME アノテーションはコンパイラによってクラスファイルに記録され、実行時に VM に読み込まれます。
SOURCE アノテーションはコンパイル時によって破棄されます。

デフォルトで、アノテーションは CLASS が指定されています。 アノテーション情報はクラスファイルに記録されますが、実行時に読み込まれることはありません。 そのため、実行時にリフレクション API からアノテーションを取得することはできません。

SOURCE は、コンパイル時にアノテーション情報がソースから破棄されてしまいます。 このタイプのアノテーションは、コンパイラや総合開発環境のソース管理機能などに情報を通知するためのものです。

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
@interface Copyright {
String value();
}

@Copyright("LeonAkasaka")
public class Test {
public static void main(String [] args) {
}
}

このプログラムの Copyright アノテーションは、RetentionPolicy.RUNTIME の Retention メタアノテーションを持ちます。 コンパイラは、Copyright アノテーションをクラスファイルに埋め込み、VM は実行時にアノテーションをメモリにロードするでしょう。 実行時に、リフレクション API を用いてアノテーション情報を得ることができます

2009年8月7日金曜日

s2strutsとsastrutsの違い

■ S2Struts 11:38

Strutsで開発をする場合にActionやActoinFormをコンポーネント化できたり、POJOとして開発できるようになったりというStrutsの拡張フレームワーク的な印象がある。

■ SAStruts 11:38

Strutsのラッパーフレームワークで、Strutsをベースにしているが利用者はStrutsを意識して開発する必要がない。

(MVCフレームワークをより単純化したフレームワーク)

Java版のRuby On Rails


SAStrutsはStrutsをベースにしているが、利用する分にはあまりStrutsを意識する必要はない。

むしろまったく別のフレームワークと思ってもいい気がする。

(でもStrutsの知識があったほうが学習はより早い)

マイブログ リスト


Jang ki hote

自己紹介