Vagrant+CentOS7でのネットワーク不具合

Vagrant+VirualBox+bento/centos-7.2でネットワークの不具合があるので対処法をメモ。
VagrantVirtualBoxも最新のものを使っている。現象としては、Vagrantfileに

config.vm.network "private_network", ip: "192.168.33.10"

と記述しているのに、ホスト側からゲスト(192.168.33.10)へのpingタイムアウトしてしまうというもの。

実際、SSHでログインしてネットワーク設定を見てみると、192.168.33.10に割り当てられたNICが存在しない。
vagrant destroy
して再度upなど、様々試して見たけど、全く効果がない。これ、CentOS6系では全く問題ない。いろいろ調べてみると、CentOSは7からネットワークの扱いが変更になったこと(ネットワークだけではないけど)が原因らしい。実際、CentOS7、CentOS7.1で試したが現象は7.2と同様だった。
最終的にたどり着いたのが、ここのページ。どうもバグらしい。このページのやり取りの中に書かれているが、

service network restart

でネットワークを再起動するといいらしい。実際にやってみた。

確かに、NICがひとつ増えて、192.168.33.10が割り当てられている。これで、無事pingも通るようになった。
ただ、これ、仮想マシンを再起動するたびに行わないといけない。次はupどきに自動で上記コマンドが実行される方法を探してみようっと。

Gitでリモートmasterブランチの巻き戻し

GitHubの有料のプライベートリポジトリ数が無制限になったのを機に、いままでVPS上で管理していたSubversionリポジトリをちまちまGitHubに移している。幸い、インターネット上でアクセス可能なSubversionリポジトリなら、GitHub自動でインポートしてくれる機能がある。これを使えば、簡単にリポジトリの移管ができる。しかも、コミット履歴や、タグ、ブランチもそのまま移管してくれて、非常に便利。
ところで、あるプロジェクトのリポジトリを移管して少し困ったことが起こった。簡単に言うと、リモート上のmasterブランチをあるコミットポイントまで巻き戻したいのだ。これだけなら簡単なのだが、現時点のソースコードも別ブランチとして残しておきたいのだ。図にすると、

の状態を

にしたいのだ。手順としては、以下のようになる。

  1. ブランチを作成してpushする。この時点で、ローカルもリモートも

    のようになる。
  2. リモートのmasterブランチを削除する。この時点で、リモートは

    のようにhogeブランチのみになる。
  3. ローカル上でmasterブランチを指定のポイントまで巻き戻す。これは、例えば、指定ポイントのコミットIDが「84fds587」とするなら、
    % git reset 84fds587
    で可能。これで、ローカル上では

    が実現できたことになる。
  4. 最後に、このmasterブランチをリモートにpushすれば、できあがり。

Gitでリモートリポジトリを巻き戻す - @tmtms のメモの記事が参考になった。

MacでPleiades All in One Eclipse Mars

最新版のEclipse Mars(4.5)を使おうと思って、ダウンロードしてみた。Windows版はPleiades All in OneのFull Editionを使用すれば問題ない。Mac版は自分で作らないといけないので、MacでPleiades All in One Eclipse - Archit!!の方法でやろうとしたら、Marsではできない。というのは、Mac版Marsのtarファイルをダウンロードして解凍すると、なんと、フォルダではなく.appファイルになるのだ。
そこで、慌てずに、.appファイルを右クリックし、「パッケージの内容を表示」を選択して、中身を見てみると、なんのことはない、今までフォルダになっているのがそのまま.app内に入っただけ。そのまま
Contents > Eclipse
と中に入っていけば、「dropins」、「features」、「plugins」と各フォルダがある。これらのフォルダに対して、MacでPleiades All in One Eclipse - Archit!!の方法で、pleiades内のplugins、features、dropinsのフォルダ内のものをコピーする。さらに、今回からは「configuration」フォルダのものもコピーする。
もう1点注意しなければならないのは、eclipse.iniの記述。以下の3点を行う。

  1. 最終行に以下の2行を追記する。
    -Xverify:none
    -javaagent:../Eclipse/dropins/MergeDoc/eclipse/plugins/jp.sourceforge.mergedoc.pleiades/pleiades.jar
  2. 起動スプラッシュをPleiadesのものに変更するために、以下の2行をコメントアウトする。
    #-showsplash
    #org.eclipse.platform
  3. ファイルのエンコードも指定しておこう。
    -Dfile.encoding=UTF-8

設定後、もし心配なら、以下のコマンドでクリーン起動を行っておこう。

/Applications/Eclipse.app/Contents/MacOS/eclipse -clean

AndroidStudioを1.5にあげたらビルドエラー

AndroidStudioを起動したら、1.5が可能ですとメッセージがでたのでアップデートしてみた。
そして、あるプロジェクトを開いたら、以下のようなエラーメッセージが表示されてビルドできない。

Error:/Applications/Android Studio.app/Contents/gradle/gradle-2.4/lib/plugins/gradle-diagnostics-2.4.jar (No such file or directory)

これは、どうも、Gradleの参照バージョンに原因があるらしい。修正方法は以下の通り。

gradle-wrapper.propertiesの修正

gradle/wrapper/gradle-wrapper.propertiesのdistributionUrlを以下に修正。

distributionUrl=https\://services.gradle.org/distributions/gradle-2.8-all.zip

build.gradleの修正

プロジェクト直下のbuild.gradleのdependenciesのclasspathを以下に修正。

dependencies {
   classpath 'com.android.tools.build:gradle:1.5.0'
}

その後、BuildメニューからClean Projectを行えばよい。
なお、不思議なのだが、これはMacOSで起こる現象で、Windowsでは確認していない。

この件は、こちらが参考になった。

Android StudioとSVNでエラー

Android開発において、Eclipseがサポートされなくなったので、Android Studioに乗り換え中。長年Eclipseを使ってきているので、ギリギリまで乗換えを引き伸ばしていたが、サポートされなくなってしまったのなら、仕方がない。まあ、Eclipse+ADTはJava6 - Archit!!にも書いたが、Eclipseの場合はADTがJava6環境でないとダメなので、メリットは大きい。
Eclipseで作ったプロジェクトを移植しつつ、Android Studioでのワークフローを構築中なのだが、Subversion連携中に以下のエラーがでた。

Cannot run program "svn" (in directory "…"): CreateProcess error=2, …

他の作業はわりとすんなりいったのだが、ここで躓いた。いろいろ調べてみたのだが原因は単純。

設定画面の
Version Control > Subversion
のGeneralタブにおいて、「Use command line client」のチェックボックスが入っているとエラーが起きる。なので、このチェックをはずせばよい。
Android StudioSubversionの1.6と1.7に関しては標準でサポートしている。この場合は内部のSVNクライアントを使うので問題なくサーバとやり取りができる。ところが、Subversionの最新版は1.8である。もし、1.8でサーバとやり取りしたい場合は別途クライアントをインストールする必要があり、その場合は、このチェックを入れてインストールしたクライアントを指定するのだ。
結局、このチェックボックスがデフォルトでチェックされていることが問題なのだ。

Eclipse+ADTはJava6

新しいMacBookPro(Yosemite)のEclipse+ADTでAndroidのプロジェクトを作ると、エラーが起きた。

いつもは、Windowsでプロジェクトを作成し、それをSVNからチェックアウトするという開発スタイルだったのだが、ある時、MacBookPro上でプロジェクトを作る必要があって、そこで初めて気づいた。ちなみに、古いMacBook(Mountain Lion)は全く問題なくプロジェクトが作成できる。
あーだこーだ、と調べたり実験した結果、原因がはっきりした。
MacBookProにインストールされているJava VMのバージョンの問題だった。新しいMacということで、OracleからJava7をダウンロードしてインストールしてある。これが問題。
Androidの開発者サイトを読むと、開発環境要件としてちゃんと「JDK6」と書かれている。そりゃあ、あかんわ。
そこで、Java6をインストールすることに。Java VMはひとつのマシンに混在可能なので、Java7は残したままインストールすることにした。Java6はOracleからは提供されていないので、ここから本家Apple提供のものをインストールする。
次に、ひとつのマシンにひとつのJava VMなら問題ないのだが、混在する場合はEclipseがどのVMを使って起動するかを指定してあげる必要がある。ちゃんとJava6で起動していればいいのだが、先にJava7をインストールしているので、そちらが優先になってしまう。

これは、Eclipseメニューから「Eclipseについて」を選択し、Eclipseについてウインドウから「インストール詳細」ボタンをクリックし、インストール詳細ウインドウの「構成」タブをクリックする。ずらずらと出てきたシステムプロパティーの中から「-vm」をさがせば、このEclipseがどのVMで起動しているかを確認できる。
これを、新たにインストールしたVMに変更する場合は、Eclipse.appのコンテキストメニューを表示させ(右クリック)、パッケージの内容を表示を選択。
Contents > MacOS
と開いて、eclipse.iniをテキストエディタで開いて以下の項目を先頭に追記する。

-vm
/Library/Java/Home/bin/java

2行目は新たに追加したJava VMのパス。インストールマシンによってパスが変わる可能性があるので、ここはターミナルなどで確認したほうがいい。
これで、無事解決した!

Elipse(Kepler)+TomcatでThreadPoolExecutor内で止まる

Eclipse(Kepler)とTomcatプラグインを使って開発をしていると、Tomcatの起動中に頻繁にThreadPoolExecutorクラスの922行目でとまってしまう。まるでそこにブレイクポイントを置いたかのような現象である。当然、こんなところにブレイクポイントを打った覚えはないし、ブレイクポイントリストにも出てこない。これは、以前のEclipse、たとえばJunoでは確認できなかった現象。
これは、設定で回避できる。設定画面を表示させ、
Java > デバッグ
で「キャッチされない例外で実行を中断」のチェックボックスをはずす。
tomcat - Remove java exception breakpoints when debugging Liferay in eclipse - Stack Overflow が参考になった。