既にわかっている人は十分過ぎるほどわかっているでしょう。
自分は Maven にあまり詳しくないので、とりあえず
わかったことをまとめてみようかなと。そして、疑問も...
MavenとEclipseを連携させるやり方は大きく二つ。
A. Mavenと連携するEclipseプラグイン
B. MavenのEclipseゴール
とにかく複数人プロジェクトでの横展開を見据えた時の
特徴に着目していきたいと考えます。
A は、代表的なところで、M2Eclipse と Q4E かな。
どっち使う？ってところでなかなかややこしいですよね。
個人的には、「比較的軽いかな」という体感があって、
Q4E の方をメインに使っています。M2Eclipse にすると
体に伝わるほど重たさを感じるので。もちろん、その分
M2Eclipse の方が色々なことしてくれている裏返しかも
しれませんが、そもそも使いこなせていないので。
一方で、DBFlute の Example では、一応両方の環境で
動くようにはしてあります(してないのもあるかもですが)。
例えば、MySQLやPostgreSQLなどのDBFluteExampleは、
o org.devzuz.q.maven...mavenClasspathContainer
o org.maven.ide....MAVEN2_CLASSPATH_CONTAINER
の両方を .classpath に設定しています。
実際に自分の環境ではどっちの環境でもチェックアウトするだけで
クラスパスが自動的に解決されてコンパイルされます。
ただまあ正直、この辺のギャップをどうしてした欲しいなと
切に願うばかりです。どのプラグインだろうが共通の設定で
解決されるとかであれば、各人が好きなのを使えばいいって
話になるのに。
とまあ、重いやら勝手に色々されるやらデファクトは何？やら
ありますが、こちらの方式だとディベロッパーへの横展開は
至って分かりやすいものですね。
.settings も .classpath も .project もみんなコミット
対象にして、プラグインさえあれば、チェックアウトするだけで
もう環境できあがりって感じで。
Eclipse の設定も Eclipse 上で設定して、みんなで共有。
この方式でそれらファイルを SVN-Ignore にするってあまり
イメージ湧かないですが、そうやってる人もいるのかな!?
B は、専用のプラグインは一切利用しないので、なによりも
軽いってところがポイントになります。ツールを使うことによって
逆に発生してしまう変なトラブルもあまりないし。
ただ、マニュアルな感じの分、選択肢が多くなるのかなと。
まずは、Eclipseのワークスペースに M2_REPO を追加します。
Mavenのコマンドで追加する場合は、Eclipseを再起動。
Eclipse上で手動で追加することもできます。
M2Eclipseプラグインが入っていると、最初から追加されてたり。
どうせ、Mavenコマンドを後で叩くなら、スクリプトに組み込んで
しまうのが楽かなと。既に追加されている状態で追加しても、
別にエラーになるわけではないので、Eclipseゴールと一緒に。
そして、EclipseゴールとEclipse環境ファイルの管理。
これがなかなかみんなどうしてるんだろうと思いをめぐらすところ。
{1}
.settings, .classpath, .project は SVN-Ignore で、
チェックアウト直後、もしくは、pom.xml が修正されたら
「mvn eclipse:clean eclipse:eclipse」
と、完全にEclipse環境を作り直す。
このやり方だと、フォーマッタ定義(コードスタイル)など、
.settings 配下に設定を保存するタイプの設定が、pom.xml の
修正の度に全て破棄されてしまいます。
(.settings 配下に設定を保存するプラグインもあるかと)
一人プロジェクトならいいですが、横展開を考えると、pom.xml を
変更する度にそれら設定をディベロッパーに何度もやらせるのは
非現実的かなと。pom.xml でその辺の設定まで細かくできれば
まだしもですが、既にフォーマッタ定義のことはブログに書いた通り。
-> Maven、Eclipseゴールでフォーマッタ定義できない？
そもそも eclipse:clean をしたくなるときっていつだろう？
少なくとも毎回する必要はないと思えるのですが...
{2}
.settings, .classpath, .project は SVN-Ignore で、
チェックアウト直後、もしくは、pom.xml が修正されたら
「mvn eclipse:eclipse」
と、一度作ったEclipse環境は破棄しない。
でも、コミットもしないので、各ディベロッパーは一番最初の
環境構築時に決められた設定を手順に沿って設定していく必要あり。
設定を間違えても誰もチェックする人はいない。
"1" よりは、横展開しやすくなりました。
{3}
.classpath と .project は、SVN-Ignore で、
チェックアウト直後、もしくは、pom.xml が修正されたら
「mvn eclipse:eclipse」
と、誰かが一度作ったEclipse設定だけはみんなで共有する。
この場合、仮に eclipse:clean を入れるにしても、
誰か一人がEclipse設定を整えて再度コミットするので、
若干意味があるかどうか疑問ですが、横展開に確実性はある。
{4}
.settings, .classpath, .project 全部コミット対象で、
「mvn eclipse:eclipse」
と、一人の人がEclipseゴールを叩いてコミットして、
他の人はチェックアウトしたらコンパイルできる状態だけど、
依存ライブラリがいないので、結局 Maven コマンドは叩く。
そのときは、Eclipseゴールじゃなくて、何か違うゴールで
いいのかな!? (mvn compile でいいのかな...)
ざっくりと 4 パターン出してみましたが、
とにかく複数人プロジェクトでの横展開を見据えた時の、
SVN-Ignore 設定、eclipse:clean の必要性の有無、
その辺の管理をどうしていくのがいいのか悩んでる感じです。
個人的には、素直に "3" あたりで特に違和感はないかなと。
(.classpath だけが SVN-Ignore とかでもいいのかな!?)
どういう風にやるのか効率が良いのか？
どういう風にやるのが一般的なのか？
それとも一般解なんてものはどこにもないのか？
まだ探ってる感じですね。
そもそも A 方式と B 方式とどっちにする？
ってところも半々に分かれるところなのかもですね。
そして、こうした要素をあらためてまとめてみると、
「Javaって複雑なんですね」
って言われてもなんともいいようがない感じで...
(言い訳すら思い付かない)
Mavenは何年経っても悩ましいもの。
って変に結論付けたくはないんだけど、
まだまだ悩むところなのかな。
