apache + WebDAV でMaven2リポジトリを構成するメモ - やさしいデスマーチ
最近はJenkinsCIが自然に使われるようになり、Javaのビルド環境もMavenで統一しておくと便利です。ですが、Mavenは結構癖が強くて使いこなすのは意外と大変で、deploy周りは結構面倒です。社内や個人的に配布したいプロジェクトをリポジトリに配布する手順をメモしておきます。尚、Sakura VPS + CentOS5.5あたりをベースにしてます。 mvn deploy Mavenを使ってプロジェクトをリポジトリにdeploy（配備）するには、「mvn deploy」コマンドを使います。deploy時には、コンパイルからテストまで行われ、最後にプロジェクトの成果物がリポジトリにdeployされます。deploy方法としては以下の方法がとれますが、ローカルファイルシステムにdeployする事はサポートされていません。 ftp ssh webdav 問題となるのは、deploy後のパ
CentOS に Jenkins と Maven - toyfish.blog
VirtualBox 上の CentOS 5.6 に、Jenkins と Maven を入れるメモ。WebDAV で共有リポジトリも作る。あちこちのサイトの切り貼り。 以下ほぼ全部 root でやってしまったので、そのまま "#" で書く。たぶん本当は sudo とか使ってもうちょい安全にできるはず。 JDK のインストール Oracle JDK は下記のサイトにある。 http://www.oracle.com/technetwork/java/javase/downloads/index.html "Download JDK" ボタンを押すとページ遷移。ライセンスに同意して "Accept License Agreement" のラジオボタンを選択した後、"Linux x86 - RPM Installer" のリンクを右クリックし、URL をコピーする。今回は 32 ビット版を使うが
複数プロジェクトがある場合のビルド環境 - @ikikko のはてなブログ
環境依存の情報の管理やHudsonのジョブ設計など - watawata日記に触発されて。自分もちょうど考えてることがあったのですが、140字ではとても足りないのでブログにまとめてみます。 ちなみにJava開発の話です、はい。 前提 「ビルドスクリプトは、IDE/CIに依存しないこと」が大事だと考えています。（Java開発においては）IDE上で開発する方が大多数だと思いますが、コマンドプロンプト・シェルスクリプト上でビルドできて、かつCI上でも同様に実行できること。これがビルド環境を考える上で大事なことですね。 プロジェクトの分類 ここでは、2つの要素でプロジェクトを分類します。 依存ライブラリ管理の仕組みが有るか？ IDE上で、プロジェクト間での直接参照が有るか？ 依存ライブラリの管理というのは、平たく言えばMaven/Ivyを導入しているか？ということです。IvyはAntベースで、Ma
maven3互換性まとめ - cynipeと読む
maven3がリリースされましたね。気が向いたのでこんぱちのーつでもざーっと眺めてみました。@shin1ogawaさんに1000万の人が喜んでくれると言われたのでものっそい久しぶりに書いてみた！間違ってたりしたらご指摘ください〜。不安な箇所もあるので。。。 元ネタ: https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html profiles.xmlが廃止 だけを書ける*1profiles.xmlが廃止されたみたい。個人的には開発者、環境ごとの設定をに書いたものがまとめられて割と好きだっただけに、この変更は残念至極。AppEngineのAppIdとかAppVersionとかもこれに書いてたのになー。 Site、Reportingなどのドキュメント系機能はCoreには含まれなくなった 個人的にはあまり興味のないところ。とい
ビルドシステム構築スキルの重要性 - 達人プログラマーを目指して
忙しいプロジェクトだとどうしてもおろそかにされがちなところですが、maven2やant+ivyを使ってビルドやリリースの自動化を行い、Hudsonなどの継続的結合環境上で動作させることは、開発生産性向上のために欠かせないことです。ビルド自動化はアジャイル開発なら当然必須ですが、そうでないウォーターフォールのプロジェクトであっても、是非取り入れたいことです。 そこで、意外な盲点となるのが、正しくビルドスクリプトを作成して、メンテナンスするプログラマーのスキルが非常に重要であるという点です。こういったビルドスクリプトはあくまでも最終納品物ではなく、生産性向上のためのツールという位置づけのためか、多くのプロジェクトではきちんとした工数や担当者がアサインされることなく、仕事の合間に知識のあるプログラマーがボランティアで開発するというケースも多いのではないでしょうか。しかし、最近の複雑なアプリケーシ
Mavenでビルドする際の10のTips - cynipeと読む
1. 環境別の設定はプロファイルで 環境毎に切り替えたいっていう設定ファイルは大抵のプロジェクトにはあると思います。DB接続先設定だったり、ロギング設定、場合によってはweb.xmlの初期化パラメータとか。最近流行り？のAppEngineだとデプロイ先の設定、開発時のcronの設定とか。こういった環境毎の設定を都度都度書き換えてなんてことをやってたらバージョン管理上うまくない*1ですし、Hudson、その他自動化スクリプトからデプロイを行ったりする際に色々とうまくないです。なので、こういった設定はプロファイルを使ってサクっと切り替えられるようにしてます。 詳しいプロファイルの使い方*2についてはそのうち別エントリで書く*3！...と思います。基本的なことはTECHSCOREさんのここを参照すればかなり分かるはずです。自分はここで覚えました。ただMaven3からはprofiles.xmlの使
自分用Maven Archetype - 都元ダイスケ IT-PRESS
さて、Javaで「何か作ろう」って思った時、みなさんどうします？ 書き捨てならば、どうでもいいと思うんですが、少々真面目に作っていこうかな、と思ったら、色々な開発環境整備が大変です。 Eclipse+Maven環境で開発をするのが好きな人は、とりあえず mvn archetype:generate でプロジェクトを作り、mvn eclipse:eclipse でEclipse用の基本メタデータを生成し、そしてEclipseにインポートする、なんてことをしているかもしれません。 Mavenプロジェクトとして生成 Eclipseの基本メタデータを生成 Eclipseにimport 自分用のEclipse,Checkstyle,FindBugs設定を生成 自分用好みのOSSライブラリをpomのdependencyに追加… なんていうステップが基本的な手順かな、と思ってます。ただ、これが意外とめん
構成管理 実践入門 第4章 Maven2によるビルド入門 なぜMaven2なのか？
DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> Home | Top > 構成管理 実践入門 > 第4章 Maven2によるビルド入門 > なぜMaven2なのか？ 第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 本特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その１ メインライン コードライン編その２ コードラインポリシー コードライン編その３ プライベートバージ
Maven2+Hudsonによる1clickリリース管理 - wadahiroの日記
現在関わっているとあるプロジェクトでは、maven-release-pluginを使用してリリースビルドを行っていました。maven-release-pluginを組み込んだプロジェクトをHudsonからキックすることで、リリース用のアーカイブを作成し、リポジトリにアップロードしていました。 先日、このリリース方式を少し見直したので備忘録としてここにまとめておきます。 新方式の内容 新方式では、maven-release-pluginを使用しないやり方にしてしまいました。 具体的には、Hudsonから「clean deploy scm:tag」を実行するというシンプルなやり方にしました。 リリースを行うバージョン番号は、pom.xmlに記述するのではなく、HudsonのParameterized Buildを使ってビルド時に変数として渡してあげる方式にしました。 maven-release
たまにっき。: Maven2
■ 階層構造になっているプロジェクトの mvn site いろいろ． - site.xml も親プロジェクトから引き継がれる． - プロジェクト全体で使われる poweredBy タグは親プロジェクトの site.xml に書いておくとよい． - ある子サブプロジェクトのみで使われる poweredBy プロジェクトは，そのプロジェクトの site.xml にのみ書いておけばよい． - site.xml の body/links タグも親プロジェクトのみに書いておけばよい． - site.xml の body タグに <menu ref="modules"/> を書いておくと親プロジェクトでのページで，モジュール（子プロジェクト）一覧が左の柱に作られる． - 柱の各項目は子プロジェクトであり，そのリンクの名前は子プロジェクトの pom.xml の name タグの中身となる．
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
ま!(2005-12-28)