しばらく書いていないと忘れてしまうのでメモ。 Gradle(Groovy)なので柔軟に書けちゃうので、これが正解というわけではないです。 基本的な設定 java, mavenプラグインを設定する。 apply plugin: 'java' apply plugin: 'maven' pom.xmlのgroupId、artifactId、versionの元ネタを設定する。archiveBaseNameは省略可能。その場合、プロジェクトのフォルダ名が使われる(参考)。archivesBaseNameの代わりに、jar.baseName でもOK。 group = 'com.github.wadahiro' archivesBaseName = 'maven-upload-sample' version = '1.0' uploadArchivesタスクを設定する。 uploadArchives
git-flow-with-maven-release-plugin.rst git-flow + maven-release-plugin用の手順 前提 プロジェクトのルートPOMに以下の設定が書かれている必要がある。 SCM情報の設定 <scm> <connection>scm:git:git@yourhost.com/your-project.git</connection> <developerConnection>scm:git:git@yourhost.com/your-project.git</developerConnection> </scm> maven-release-pluginの設定 Mavenのリリース処理をリモートにpushしないように以下の設定を追加。 <plugin> <groupId>org.apache.maven.plugins</groupId>
「javaプロジェクトを簡単に単一jarファイルで配布する - lime55の日記」から 「One-JARでアプリケーションの配布を単純化」経由で 「Google Code Archive - Long-term storage for Google Code Project Hosting.」を見つけたので試してみる。 One-Jarの仕組みをごくおおざっぱに説明すると、 Jarの中にJarが入れ子で入っている。 外側のJarのMainクラス＝外側のJarに含まれる特別なクラスローダが起動される 入れ子になっている内側のJarをロードする 入れ子のMainクラスを起動する という感じ。 これまで、「Mavenで配布用zipファイルを作成する - Sacrificed & Exploited」でいろいろな配布パッケージを作る方法を試したけど、jar一個ですむならそっちの方が楽だし。 one
Maven Central Repository へのライブラリ登録方法を4年前に書きましたが、今ではこの方法は使えません便利ライブラリ・フレームワークを書いている人はこれを参考にガシガシ登録してもらえれば幸いです。 当然ですが、全ての方法は本家maven.apache.orgに書いてあります。 ・Guide to uploading artifacts to the Central Repository はい、英語です。ナナメ読み難しいですね。 押さえておくべき点を日本語で並べます。 1. 必要なメタデータを書いておく pom.xmlはパッケージング方法やdependencyさえ書いておけばプロジェクトのビルドに差し支えありませんが、Maven Central Repoに登録するにはソースコードがどこにあるのか、ライセンスは何なのかといったビルドには直接必要ないメタデータも記載しておく必
ライブラリの依存関係やスコープを管理できたり、様々なレポートを出力できたりと、なんだかんだいってもMavenは便利です。少しでも道から外れるとpom地獄が待っていますが、幸いにしてトラウマになるような事態に出会ったことはいまのところありませんw ただ、仕事では納品後にユーザがどんな環境でビルドするからわからないからオンライン前提じゃないとビルドできないMavenは使いにくいケースが多く、場合によっては開発時はMavenを使うけどAntでもビルドできるようにしておく、みたいな不毛なことをしたりしていました。もちろんMavenのローカルリポジトリをコピーしてプロジェクトと一緒に配ればオフラインでもビルド可能な環境を作ることはできるのですが、もっとポータビリティの高い方法はないかなぁ…と思っていたところ、@shimashima35さんに簡単な方法を教えていただきました。 ポイントは-Dmaven
tamagawa ryuji @tamagawa_ryuji blogありがとうございました。改めて思ったんですけど、やっぱMavenのいい本欲しいと思いません？@kohsukekawaさんもコメントくださっているように、ずいぶんここに欧米との差があるような気がして。 @masanobuimai @lino_s #jenkinsja ikikko @ikikko @tamagawa_ryuji 欲しい！ただ、今からMavenを頑張るよりはGradle/SBTを普及させる方にいったほうがいいのかなーとも思ってます。Mavenもそれまでと比べると画期的なんですが、今はXMLの辛さもでてきてるので。
What is it? For now, the Maven Beanstalk Plugin is a wrapper for the Amazon Beanstalk API for usage from Maven Projects. Usage See the Usage page. It describes the basic usage scenarios for beanstalk usage. Another interesting aspect is being able to deal with the configuration settings in Amazon Elastic Beanstalk. Check Configurations and Configuration Templates for further information. Also, che
前のエントリの続き。今回はどのような場面にどのツールがマッチするかを、自分なりの考えをふまえて紹介します。 ちなみに、それぞれのツールの使用経験はこんな感じ。 ビルドツール 使用経験 Ant 中〜大規模プロジェクトを1件 Maven 小〜中規模プロジェクトを複数件 Gradle 趣味のサンプルコードで複数件 SBT/Scalaは使ったことがないので除外。想像ですが、SBTをJavaプロジェクトで使うとなると、Gradle的な立ち位置になるかと思ってます*1。 ソースコードにJava以外も扱いたい場合 プロダクトコードには入れず、テストコードだけでGroovyを扱いたい場合も含みます。要するに、Java以外にコンパイルしたいソースコードがあるかどうか。 このケースでは、おとなしくGroovyを標準サポートしているGradleを使ったほうがいいかと思います。 Mavenでgroovyを扱えるよ
最近はJenkinsCIが自然に使われるようになり、Javaのビルド環境もMavenで統一しておくと便利です。ですが、Mavenは結構癖が強くて使いこなすのは意外と大変で、deploy周りは結構面倒です。社内や個人的に配布したいプロジェクトをリポジトリに配布する手順をメモしておきます。尚、Sakura VPS + CentOS5.5あたりをベースにしてます。 mvn deploy Mavenを使ってプロジェクトをリポジトリにdeploy（配備）するには、「mvn deploy」コマンドを使います。deploy時には、コンパイルからテストまで行われ、最後にプロジェクトの成果物がリポジトリにdeployされます。deploy方法としては以下の方法がとれますが、ローカルファイルシステムにdeployする事はサポートされていません。 ftp ssh webdav 問題となるのは、deploy後のパ
1. Maven 3 / Tycho Eclipse and Maven coexisting in harmony Karsten Thoms 2010-05-10 © itemis AG 2010 – Alle Rechte vorbehalten 1 2. About me • Working as consultant for itemis • Over 10 years experience in Enterprise Java, Model Driven Software Development • Open Source enthusiast, MDSD evangelist • Project (co-)lead: The Fornax Platform, fit4oaw, Hybridlabs Beautifier • Committer / Contributor: E
id:jflute さんのエントリがきっかけでニーズがありそうなことがわかったので、少し前に個人的に作ったMavenプラグインを試験公開します。 どんなプラグイン? ひと言でいうと、Mavenのeclipseプラグインとdependencyプラグインを足して2で割ったような機能を提供します。eclipse+classpathを文字って「eclipath」プラグイン。(相変わらずネーミングセンスありませんね。良いアイデア募集) 具体的には、pom.xmlに記述された依存ライブラリをeclipseプロジェクト上にコピーして、.classpath にクラスパスを追加します。ついでにソースやJavadocもあれば自動的にアタッチします。 pom.xmlの依存ライブラリを.classpathに反映させるだけならば mvn eclipse:eclipse でできますが、これだと既存の .classpa
現在のmaven-release-pluginでは、フラットなディレクトリ構成のマルチプロジェクトのリリースはサポートされていない。 「フラットなディレクトリ構成のマルチプロジェクト」とは、例えば次のようなファイル構造をもつプロジェクトである。 （以下、ymir-coreはymir-projectの子であるとする） ymir | +-ymir-project | | | +-pom.xml | +-ymir-core | | | +-pom.xml これは論理的には以下の構造と同値である。 ymir-project | +-ymir-core 論理的な構造と同じようなディレクトリ構造にするとEclipseにプロジェクトをインポートできないので、Eclipseで開発している時はフラットなディレクトリ構成のマルチプロジェクトにせざるを得ない。 このマルチプロジェクトをmaven-release
maven-release-pluginを使うと成果物のリリースを簡単に行なうことができる。 リリースの前にリリースができる状態かの確認をする。これはrelease:prepareゴールに-DdryRun=trueオプションを指定することで行なう。 mvn -DdryRun=true release:prepare FAILUREしたら指示に従って問題を解消する。問題を解消したら再度上記コマンドを実行する。FAILUREしなくなったらrelease:cleanゴールを実行してから次へ。 mvn release:clean リリースができる状態であれば、リリースの準備をする。リリースの準備では次のことが自動的に行なわれる。 trunkのpom.xml中の成果物のバージョン番号をリリースするバージョンに変更した状態のソースツリーをtagsにadd trunkのpom.xml中の成果物のバージョ
1. 環境別の設定はプロファイルで 環境毎に切り替えたいっていう設定ファイルは大抵のプロジェクトにはあると思います。DB接続先設定だったり、ロギング設定、場合によってはweb.xmlの初期化パラメータとか。最近流行り？のAppEngineだとデプロイ先の設定、開発時のcronの設定とか。こういった環境毎の設定を都度都度書き換えてなんてことをやってたらバージョン管理上うまくない*1ですし、Hudson、その他自動化スクリプトからデプロイを行ったりする際に色々とうまくないです。なので、こういった設定はプロファイルを使ってサクっと切り替えられるようにしてます。 詳しいプロファイルの使い方*2についてはそのうち別エントリで書く*3！...と思います。基本的なことはTECHSCOREさんのここを参照すればかなり分かるはずです。自分はここで覚えました。ただMaven3からはprofiles.xmlの使
Apache/ Maven/ Guide to Creating Archetypes | Last Published: 2024-11-14 | Get Sources Download Creating an archetype is a pretty straight forward process. An archetype is a very simple artifact, that contains the project prototype you wish to create. An archetype is made up of: an archetype descriptor (archetype-metadata.xml in directory: src/main/resources/META-INF/maven/). It lists all the file
maven3がリリースされましたね。気が向いたのでこんぱちのーつでもざーっと眺めてみました。@shin1ogawaさんに1000万の人が喜んでくれると言われたのでものっそい久しぶりに書いてみた！間違ってたりしたらご指摘ください〜。不安な箇所もあるので。。。 元ネタ: https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html profiles.xmlが廃止 だけを書ける*1profiles.xmlが廃止されたみたい。個人的には開発者、環境ごとの設定をに書いたものがまとめられて割と好きだっただけに、この変更は残念至極。AppEngineのAppIdとかAppVersionとかもこれに書いてたのになー。 Site、Reportingなどのドキュメント系機能はCoreには含まれなくなった 個人的にはあまり興味のないところ。とい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
