13/05/10 11:33:01.75
良いものは海外でも流行る。
日本限定のマイナーなフレームワークなんかつかうと
すぐにメンテ終了になってしまう
656:650
13/05/10 12:38:17.38
俺は「世界ではJava EEが標準です(ｷﾘｯ」みたいな発言を真に受けたり引用したりするのはやめれというだけで。
別に国産FWが良いと思っているわけじゃないよん。
657:デフォルトの名無しさん
13/05/10 13:07:44.12
俺が作ったフレームワークがどう考えても最高
658:デフォルトの名無しさん
13/05/11 09:13:44.19
>>656
何でやめなくちゃいけないんだ？
事実は事実のまま捉えろよ
659:デフォルトの名無しさん
13/05/11 10:26:19.98
JavaEEは最高のフレームワークです(ｷﾘｯ
ほかのフレームワークを使っている奴らは無知なだけのｶｽ
660:デフォルトの名無しさん
13/05/11 10:35:01.25
フレームワークがないと作れないやつって不幸だな
661:デフォルトの名無しさん
13/05/11 15:17:14.27
標準って用語は多重定義されてるからな
JavaEEが標準仕様なのは事実だしデファクト標準じゃないことも事実
662:デフォルトの名無しさん
13/05/11 15:41:42.22
依存性管理はそろそろデジュール標準でいって欲しいな。
そんで依存性ツリーを持たないAntプロジェクトとか撲滅して欲しい。
現状リポジトリはほぼMavenリポジトリがデファクトで、依存性解決はMavenの他に
ivyやGradle等といった複数の実装があるわけだけど、実装毎に微妙に解決した結果
が異なったりとか依存性の記法が異なるとかちょい勘弁。
って何時だよProject Jigsaw使えるようになるの。
663:デフォルトの名無しさん
13/05/17 20:56:32.32
うちなんて未だにApache Ant + CVSだよ
今年の予定がSubversionの適用とか10年遅れてるわ
664:デフォルトの名無しさん
13/05/17 21:51:50.52
もうSubversionはスキップしていいでしょw
GitやMercurialにすればよいのに。
665:デフォルトの名無しさん
13/05/18 01:26:59.84
>>663
昨年までEclipseとファイルコピーで何とかしてた俺よりましだな。
さすがに最近Git入れたけど。
666:デフォルトの名無しさん
13/05/20 08:38:34.64
CVSと用語の使い方が似ているとか長く使われて実績があるって意味ではSubversionもありはありだけど、それ以外に取り柄が無いよなぁ
分散リポジトリは概念説明からスタートだからめんどくさいとかあるのかな
構成管理担当のスキル不足で使いこなせないなんて笑えない理由だったら笑うがw
667:デフォルトの名無しさん
13/05/20 22:57:38.89
トラブルが起こらないという意味ではsubversionで十分かもな
Mavenとかだと、やれプロキシの設定だの、レポジトリが無いだの、
新しく入ったメンバーが自分で設定できないだの、
依存性が解決できないだのと、問題がつきもの
668:デフォルトの名無しさん
13/05/21 02:38:48.74
とのVCS(Subversion, Git, Mercurial, etc.)を使うかと、どのビルドツール
(Ant, Maven etc.)を使うかは基本的には直交した問題じゃないかな。
経験上ビルドツールに関してはMavenを使った方が新人対応も楽。なにせ手動で
インストールする必要のあるものを圧倒的に減らせるので開発環境の立ち上げが
楽だしメンバー間でのバージョンの同期もし易い。
Mavenの設定と言ってもひな形のsettings.xmlをコピペして社内Artifactory使う
クレデンシャルの設定だけを個々人で書き換えてもらう定型作業なので、ちゃん
と話を聞かなかったり勝手に先走る新人を除いてははまった経験もあまりない。
新人対応の面でMavenを避ける理由はあまり思いつかないかなぁ。単純に社内の
プロジェクトがAntベースか既にMavenizeされているかの問題ではないかと。
新人対応に関してはむしろVCSが問題で、GitやMercurialを使った経験のない
新人は戸惑う事が多い。updateやcommitだけしてpullやpushを忘れるのは定番
として、ブランチを切って開発するスタイルに慣れていないことが多いので。
こちらはJira等を使ったチケットベースの開発のサイクルとセットにして最初
から丁寧に手順を伝える必要がある。
669:デフォルトの名無しさん
13/05/21 04:14:23.88
手動でインストールって何のことだ
eclipseのフォルダごとコピーして終わりだわw
670:デフォルトの名無しさん
13/05/21 05:31:35.94
>手動でインストールって何のことだ
まずはScalaコンパイラやGrailsといったビルド環境。
これらはMaven Pluginが勝手にビルド環境をダウンロードしてくれるのでScala等を
インストールしてEclipseに登録したりせずともプロジェクトのビルドはすぐ出来る。
実際にScalaやGroovyでの開発担当が回ってきた場合は結局Scala等をインストールして
Eclipseにプラグイン入れないと不便だけれども、その場合もMavenを使って実行する
ビルドやテストでは必ずpomに書かれたバージョンのビルド環境が使われるのは便利。
Jenkins等でビルドするのにもJenkinsにプラグイン入れるよりMaven任せが楽だと思う。
もう一つは複数のプロジェクトで横断的に使われるフレームワークやcommons、log4j
といったライブラリのJar。これらのJarをローカルにインストールしてクラスパスを
通しておく方式は手間だし開発者間でバージョンの同期がとれない。
プロジェクトのlibフォルダにJarを放り込んでVCSで同期する方式だとプロジェクト間
で違うバージョンのJarが使われているとやはり面倒で、そのチェックも大変。
というか膨大な数のJarに依存する昨今のJavaフレームワークを依存性解決ツール無し
で使うのは無駄に大変だと思う。
671:デフォルトの名無しさん
13/05/21 08:17:14.09
え、scalaやgradleなんて何から何までeclipseプラグインが用意してくれるし、
eclipseプラグインはローカルフォルダごとコピーすればついてくるがな
672:デフォルトの名無しさん
13/05/21 09:38:09.94
GradleじゃなくてGrailsね。
Scala IDEはともかくSpringToolSuiteは手動でGrailsを落としてきてEclipseに登録する必要が
あるし、何れにしても本格的に開発するときはコマンドラインツールやIDEの支援がないと何かと
不便なので結局これらやプラグインは手動でインストールすることにはなる。
ただEclipseプラグインに頼った場合は適切に設定されたEclipse環境が無いとビルド出来ないけど、
Mavenプロジェクトは基本的にはmavenが走れば概ね無難にmvn単体でビルド出来る。これ重要。
なので素のEclipseでもm2eclipseだけ入れてもらえればあとはプロジェクトをチェックアウトする
だけで無難にEclipse上でもビルド出来る。Eclipse等とは無関係にビルドに必要な情報は全部pom
に集約されているから環境の違いによるブレが少ない。便利だと思うけれどもなぁ。
Eclipseフォルダのコピーはやらないなぁ。人によって設定も必要なプラグインも異なるし。
プロジェクト内の.projectとか.settingsの類も基本的にはバージョン管理から外す。
673:デフォルトの名無しさん
13/05/22 01:17:21.75
複数人開発するならMavenで管理するがいいと思うけど、
1人身開発だとあんまり利便性がない気がする・・・。
まあ、一人で開発してる俺みたいなのは少数派なんだろうけど。
単に開発者いないだけだし。
674:デフォルトの名無しさん
13/05/22 04:34:46.93
一人で開発する場合も依存性管理は便利だけど。
ライブラリのパッケージを手動で落としてきて展開してJarをコピったり
プロジェクトのビルドパスに登録したりとかもう今更。
Eclipseプラグインをupdateサイトからではなく手動でzip落としてきて
インストールしたり、aptの類を使わずにtarballに固執する程度には
使わないのは勿体ないなぁと思う。
確かに凝ったビルドをし出すと俄然ややこしくなるしモジュールの切り分け
などに頭を使うけど、その他の大多数の定型的なビルドに関してはMavenは
すごく楽だと思う。
675:デフォルトの名無しさん
13/06/04 23:22:07.93
Mavenはリポジトリ整理してくれ、マジで