http://itpro.nikkeibp.co.jp/article/COLUMN/20080414/298973/
ソフトウエア開発において，プロジェクト管理はガントチャート・ベースで行われることが多いでしょう。しかし，ガントチャート・ベースの管理では，詳細を報告するために作業報告書を別途作成する必要があります。
また，ガントチャート・ベース管理の問題ではありませんが，作業に必要な他の担当者や他部門との情報のやり取りは，たいていメール・ベースで行われています。必要な情報を個人が握っているので，作業の実施状況が把握しずらく，引き継ぎなどで作業の過去の経緯を知るのは容易ではありません。
要求されるシステムが複雑化し，短期間での開発が求められている昨今では，複数の会社による分散開発やオフショア開発などへシフトすると，これらの問題はより顕在化してきます。結果として，状況を問い合わせるためのコミュニケーションが発生することになります。
また，拠点が分散している場合，Microsoft Excelなどの表計算ソフトで課題や故障を管理していると，課題や故障の管理を行う際に煩雑な帳票のやり取りが発生します。バグを修正した際にソースコードのどの部分を変更したかもわかり難いです。
こうした問題を解決する手段として，作業（ここでいう作業とは，タスクとしての作業だけでなくバグ管理や課題管理を含む）を集中的に管理する，ITS（Issue Tracking System：課題追跡システム）と呼ばれるツールがあります。ITSを利用すると，下記のようなメリットが得られます。
* 作業をITSで一元的に管理することができ，検索性も向上する
* 作業履歴や情報のやり取りをITSに登録する決まりにすることで，自然と作業の経緯がわかるようになる
* Webベースで課題や作業を管理できるITSを利用すれば，分散した拠点での情報連携がスムーズになる
Tracの特徴
Tracは，スウェーデンのEdgewall Softwareが開発しているプロジェクト管理システムで，日本ではインタアクトがTracを日本語化したtrac-jaを配布しています。Tracは，以下の特徴を持ちます。
◆Webベースのインタフェースを提供
特別なソフトウエアをインストールする必要がなく，Webブラウザさえあれば，ユーザーが簡単に利用することができます。また，拠点が分散している開発でも利用できます。
◆ 構成管理ツールと連携が可能
Subversion（SVN）リポジトリへのコミットログを作業の変更履歴に追加したり，ソースコードの差分（チェンジセット）のリンクを挿入できます。これにより，バグ修正や機能追加によるリポジトリへの変更を管理できるようになります。
図2●Trac（上図）と構成管理ツール（下図）との連携
図2●Trac（上図）と構成管理ツール（下図）との連携
[画像のクリックで拡大表示]
◆チケットによるタスク管理
Tracでは，チケットという概念によりタスクを管理します。課題，故障，要件など，プロジェクトで管理したい要素をチケットとして扱うことができます。
また，チケットは次に紹介するWiki機能を利用できます。Wikiを利用したリッチテキストで，タスクの詳細やコメントをわかりやすく記述できます。こうした記述をルール化しておけば，担当者が変更になった場合でも，スムーズにタスクを引き継ぐことができます
Python
http://sourceforge.jp/projects/traclight/wiki/FrontPage
2009年8月12日水曜日
struts menuを利用したサンプルリンク集
struts menuを利用したサンプルリンク集
http://demo.raibledesigns.com/struts-menu/index.jsp
cool menu
http://dhtmlcentral.com/projects/coolmenus/
http://demo.raibledesigns.com/struts-menu/index.jsp
cool menu
http://dhtmlcentral.com/projects/coolmenus/
개발 환경 구축 pukiwiki
http://labo.kokodayo.com/wiki/dev/environment/Eclipse.html
Eclipse+Maven+SVN
http://labo.kokodayo.com/wiki/dev/environment/Maven.html
maven
Eclipse+Maven+SVN
http://labo.kokodayo.com/wiki/dev/environment/Maven.html
maven
pukiwiki intall 1 - php + apache + mysql setup
1. php + apache server install
30秒ではじめるPHP (phpdev)
何はともあれ↓ここでphpdevをダウンロードしてください。
http://prdownloads.sourceforge.net/phpdev5/phpdev423.exe
あ。既にPHPを使える環境にある人は結構です。「PHPをこれからはじめたい。でもどうやったら使えるの？」という前準備段階の人向けです。
本来、PHPを自分のパソコン上で動作させるには、大雑把に言っても、
Apacheのダウンロード
Apacheのインストール
Apacheの基本設定
PHPのダウンロード
PHPのインストール
PHPのApache用設定
MySQLのダウンロード
MySQLのインストール
MySQLの基本設定
このくらいのことは必要です。Webプログラミングを本業とする方ならば、上記のようなまっとうなインストール手順を学ぶべきだと思いますが、「ちょっと学んでみよう」という方にとっては、この複雑なインストール手順は敷居が高いと感じるでしょう。
そこで、phpdevの出番です。
phpdevのダウンロード
ダウンロードしたファイルを実行(ダブルクリック)
インストール画面右下の[Install]ボタンをクリック
完了
以上で、Apache+PHP+MySQLが全て、あなたのWindowsパソコンにインストールされます。正直、まっとうなインストール手順でやってた自分がアホらしくなりました。
アンインストールするのも簡単で、C:\phpdevフォルダをエクスプローラで丸ごと削除するだけです。
※但し、一度でもphpdevを実行した場合、メモリ中にphpdev関連のファイルが常駐していてアンインストールできない場合があります。そんなときは、一度コンピュータを再起動してから、該当フォルダを削除すればアンインストールできます。
phpdevのインストールが完了したら、C:\phpdev\2K-NT-XP-phpdev_start.batをダブルクリックするだけで、いつでもあなたのコンピュータ上で、Apache+PHP+MySQLが使える環境になります。
C:\phpdev\www以下にHTMLファイルや、PHPファイルなどのWeb関連ファイルを置けば、http://localhostで閲覧できるようになります。
phpdevは、これからPHPはじめようという人にはイチオシのフリーウェアです。
------------------------------------------------------------
출처: http://www.siela.net/php/phpdev/0301.php
インストーラが終了すると、Apache・mysqlなどがインストールされます。デフォルトでインストールした場合は、「c:\phpdev」に各ファイルがインストールされています。
・設定ファイル(httpd.conf)は「C:\phpdev\Apache\conf\httpd.conf」に格納されています。
・デフォルトルート(http://localhost/)へのパスは「C:\phpdev\www」です。
■アップデートモジュールの実行
アップデートモジュールが提供されている場合には、必ず実行します。
■phpdevの開始
「c:\phpdev\2K-NT-XP-phpdev_start.bat」(またはシステムに準じる名称のバッチ)をダブルクリックすると、自動的にApache・mysqlなどが開始されます。
URL「http://localhost/」をブラウザで開くと、Apacheが開始されたことを確認できます。(赤丸部分に「Apache」と表示があり、Apacheを通して実行されていることが分かります)
■phpinfo.phpの実行
「http://localhost/phpinfo.php」にアクセスすると、現在の設定を見ることができます。あわせて、PHPプログラムが正常に動作していることの確認にもなります。
デフォルトインストール直後の状態でも、さまざまな設定がされていることが分かります。設定値を修正する場合は、「C:\phpdev\Apache\conf\httpd.conf」などの設定ファイルの値を修正します。
※これらの初期設定は、セキュリティ的に脆弱性をもった状態になっています。初期設定の状態では必ずスタンドアロンで使用し、適切なセキュリティを設定してからネットワークに接続してください。
■Hello World!!
プログラミングではお約束の「Hello World」を表示させるプログラムを作成します。
エディタで次のコードを記述し、「hello.php」と名前を付けて保存します。
「hello.php」を「「C:\phpdev\www」内に格納し、「http://localhost/hello.php」にアクセスします。次の画面が表示されれば、記述した「Hello World」PHPプログラムが正常に動作しています。
■phpdevの終了
phpdevは通常は起動したままで問題ありませんが、Win2000上でIISと併用する場合などは、次の手順でphpdevを終了させることが必要です。
(1)「c:\phpdev\phpdev_stop.bat」が存在する場合は実行する。
(2)(1)が存在しない場合、プロンプトとして実行されている「C:\phpdev\Apache\Apache.exe」を終了する。
(3)(1)が存在しない場合、「Apache Service Monitor」が実行されていたら終了する。
(4)「コントロールパネル→管理ツール→サービス」を確認し、不要なプログラムが起動されていたら終了する。
30秒ではじめるPHP (phpdev)
何はともあれ↓ここでphpdevをダウンロードしてください。
http://prdownloads.sourceforge.net/phpdev5/phpdev423.exe
あ。既にPHPを使える環境にある人は結構です。「PHPをこれからはじめたい。でもどうやったら使えるの？」という前準備段階の人向けです。
本来、PHPを自分のパソコン上で動作させるには、大雑把に言っても、
Apacheのダウンロード
Apacheのインストール
Apacheの基本設定
PHPのダウンロード
PHPのインストール
PHPのApache用設定
MySQLのダウンロード
MySQLのインストール
MySQLの基本設定
このくらいのことは必要です。Webプログラミングを本業とする方ならば、上記のようなまっとうなインストール手順を学ぶべきだと思いますが、「ちょっと学んでみよう」という方にとっては、この複雑なインストール手順は敷居が高いと感じるでしょう。
そこで、phpdevの出番です。
phpdevのダウンロード
ダウンロードしたファイルを実行(ダブルクリック)
インストール画面右下の[Install]ボタンをクリック
完了
以上で、Apache+PHP+MySQLが全て、あなたのWindowsパソコンにインストールされます。正直、まっとうなインストール手順でやってた自分がアホらしくなりました。
アンインストールするのも簡単で、C:\phpdevフォルダをエクスプローラで丸ごと削除するだけです。
※但し、一度でもphpdevを実行した場合、メモリ中にphpdev関連のファイルが常駐していてアンインストールできない場合があります。そんなときは、一度コンピュータを再起動してから、該当フォルダを削除すればアンインストールできます。
phpdevのインストールが完了したら、C:\phpdev\2K-NT-XP-phpdev_start.batをダブルクリックするだけで、いつでもあなたのコンピュータ上で、Apache+PHP+MySQLが使える環境になります。
C:\phpdev\www以下にHTMLファイルや、PHPファイルなどのWeb関連ファイルを置けば、http://localhostで閲覧できるようになります。
phpdevは、これからPHPはじめようという人にはイチオシのフリーウェアです。
------------------------------------------------------------
출처: http://www.siela.net/php/phpdev/0301.php
インストーラが終了すると、Apache・mysqlなどがインストールされます。デフォルトでインストールした場合は、「c:\phpdev」に各ファイルがインストールされています。
・設定ファイル(httpd.conf)は「C:\phpdev\Apache\conf\httpd.conf」に格納されています。
・デフォルトルート(http://localhost/)へのパスは「C:\phpdev\www」です。
■アップデートモジュールの実行
アップデートモジュールが提供されている場合には、必ず実行します。
■phpdevの開始
「c:\phpdev\2K-NT-XP-phpdev_start.bat」(またはシステムに準じる名称のバッチ)をダブルクリックすると、自動的にApache・mysqlなどが開始されます。
URL「http://localhost/」をブラウザで開くと、Apacheが開始されたことを確認できます。(赤丸部分に「Apache」と表示があり、Apacheを通して実行されていることが分かります)
■phpinfo.phpの実行
「http://localhost/phpinfo.php」にアクセスすると、現在の設定を見ることができます。あわせて、PHPプログラムが正常に動作していることの確認にもなります。
デフォルトインストール直後の状態でも、さまざまな設定がされていることが分かります。設定値を修正する場合は、「C:\phpdev\Apache\conf\httpd.conf」などの設定ファイルの値を修正します。
※これらの初期設定は、セキュリティ的に脆弱性をもった状態になっています。初期設定の状態では必ずスタンドアロンで使用し、適切なセキュリティを設定してからネットワークに接続してください。
■Hello World!!
プログラミングではお約束の「Hello World」を表示させるプログラムを作成します。
エディタで次のコードを記述し、「hello.php」と名前を付けて保存します。
「hello.php」を「「C:\phpdev\www」内に格納し、「http://localhost/hello.php」にアクセスします。次の画面が表示されれば、記述した「Hello World」PHPプログラムが正常に動作しています。
■phpdevの終了
phpdevは通常は起動したままで問題ありませんが、Win2000上でIISと併用する場合などは、次の手順でphpdevを終了させることが必要です。
(1)「c:\phpdev\phpdev_stop.bat」が存在する場合は実行する。
(2)(1)が存在しない場合、プロンプトとして実行されている「C:\phpdev\Apache\Apache.exe」を終了する。
(3)(1)が存在しない場合、「Apache Service Monitor」が実行されていたら終了する。
(4)「コントロールパネル→管理ツール→サービス」を確認し、不要なプログラムが起動されていたら終了する。
pukiwiki
출처
http://labo.kokodayo.com/wiki/PukiWiki.html
PukiWiki †
* http://pukiwiki.sourceforge.jp/
* http://sourceforge.jp/projects/pukiwiki/
PukiWikiは Wiki(WikiWikiWeb) と呼ばれているもののひとつで、基本的に誰でも全てのページを作成・編集することができます。
また、編集には特別な知識を要することなく、簡単なルールに従うだけで整形されたHTML文書を生成できます。
* 漢字をサポートしています。日本語のページ名もOK！
* 全てのデータはテキストファイルに保存されます
* 定期的にバックアップが保存されるので、復旧も簡単
* ページ単位の凍結なども可能です
* URLを短く表現できるInterWikiをサポート
* PHPで書かれています
* ライセンスはGPL*1です
↑
リンク †
* PukiWiki-official からPukiWiki 公式サイトへ飛べます
o ご質問や御意見は、こちらへどうぞ。 :)
* Pukiwiki-dev - http://pukiwiki.sourceforge.jp/dev/
o こちらはPukiWiki開発サイトです。PukiWiki開発サイトでは、次期バージョンの開発だけでなく、現行バージョンの1.4系や1.3系の修正、セキュリティfixが行なわれています。pukiwiki.dev:開発日記で日々の作業の内容が掲載されていますので、PukiWikiを運用されている方は目を通すようお願いします。
* http://sourceforge.jp/projects/pukiwiki/
o Sourceforge のプロジェクトサマリです。PukiWikiのダウンロードはこちらからどうぞ。
↑
関連ページ †
* PukiWiki/使用プラグイン
http://labo.kokodayo.com/wiki/PukiWiki.html
PukiWiki †
* http://pukiwiki.sourceforge.jp/
* http://sourceforge.jp/projects/pukiwiki/
PukiWikiは Wiki(WikiWikiWeb) と呼ばれているもののひとつで、基本的に誰でも全てのページを作成・編集することができます。
また、編集には特別な知識を要することなく、簡単なルールに従うだけで整形されたHTML文書を生成できます。
* 漢字をサポートしています。日本語のページ名もOK！
* 全てのデータはテキストファイルに保存されます
* 定期的にバックアップが保存されるので、復旧も簡単
* ページ単位の凍結なども可能です
* URLを短く表現できるInterWikiをサポート
* PHPで書かれています
* ライセンスはGPL*1です
↑
リンク †
* PukiWiki-official からPukiWiki 公式サイトへ飛べます
o ご質問や御意見は、こちらへどうぞ。 :)
* Pukiwiki-dev - http://pukiwiki.sourceforge.jp/dev/
o こちらはPukiWiki開発サイトです。PukiWiki開発サイトでは、次期バージョンの開発だけでなく、現行バージョンの1.4系や1.3系の修正、セキュリティfixが行なわれています。pukiwiki.dev:開発日記で日々の作業の内容が掲載されていますので、PukiWikiを運用されている方は目を通すようお願いします。
* http://sourceforge.jp/projects/pukiwiki/
o Sourceforge のプロジェクトサマリです。PukiWikiのダウンロードはこちらからどうぞ。
↑
関連ページ †
* PukiWiki/使用プラグイン
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:
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.
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.
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
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
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.
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
3. settings.x: A dot (.) notated path in the settings.xml will contain the corresponding element's value. For example:false
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
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.
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
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.
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:
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.
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
* 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.
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
* 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
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
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
* 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
* 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
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
* 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.
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
...
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:
3. settings.x: A dot (.) notated path in the settings.xml will contain the corresponding element's value. For example:
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
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
...
...
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.
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
...
...
...
* 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
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
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:
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.
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.
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
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
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.
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
3. settings.x: A dot (.) notated path in the settings.xml will contain the corresponding element's value. For example:false
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
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.
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
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.
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:
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.
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
* 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.
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
* 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
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
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
* 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
* 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
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
* 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.
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
...
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:
3. settings.x: A dot (.) notated path in the settings.xml will contain the corresponding element's value. For example:
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
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
...
...
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.
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
...
...
...
...
* 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
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
...
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.
登録:
投稿 (Atom)
Jang ki hote
