Friends - IntelliJ
dbfluteとは直接無関係ながらも、同時に利用するととても便利なライブラリを紹介します。
- dbflute と IntelliJ
- Inspections設定の共有
- フォーマッター設定の共有
- gitignore戦略は？
- .ideaディレクトリへの意識
- dbflute な Live Template
dbflute と IntelliJ
dbfluteは、利用上において特に IntelliJ に依存してはいません。ですが、IntelliJ 上で dbflute の利用を支援するための情報や設定のExampleなどが提供されています。
Inspections設定の共有
警告ノイズたち
以下、代表的な警告ノイズです。
- 一行だけの Lambda が Expression Style にできるよ
- その Lambda が Method Reference にできるよ
- その Behavior のインスタンス変数、初期化されてないよ
特に dbflute の場合、Lambda の中がたまたま一行でも、すぐに追加される可能性高いですし、cb.query() の一行は横に長くなりがちなので、最初から Block Style で書きたいと思う人も多いです。 また、op -> op.likePrefix() など、Lambda引数の型をあまり意識せずに短く書きたいことも多く、無理に Method Reference にしたくないと思う人も多いです。
つまり "余計なお世話警告" になってしまいっていて、これらが警告ノイズとなり本質的な警告を見逃してしまう可能性があります。 IntelliJの設定を調整して、心地よい警告ライフを過ごしたいものです。
IntelliJでこれらを OFF にする方法は、Twitterで "jflute intellij" で検索してください。
ただ、警告を調整したら、必ずチーム内で共有しなければなりません。警告の設定が人によってズレてると結局その警告は機能しないからです。
jfluteお手製の警告調整済xml
大変だと思うので、警告調整済みの IntelliJ の .idea ディレクトリに配置する xml を用意しています。
- dbflutespection.xml
- 調整されたInspectionsのProfileの設定
- profiles_settings.xml
- このプロジェクトで dbflutespection を使うと決めている
- misc.xml
- EntryPointsManagerでDIのアノテーションが設定されている
これら設定ファイル、オープンソースとして公開されています。 (コピーして使ってOKです。また更新するかもしれませんので、時々ウォッチを。ちなみに、LastaFluteのExampleですがそこ関係ありません)
三つのファイルをコピーして構成どおりの場所に配置し、バージョン管理システム(git)のコミット対象にして共有すれば、チームメンバーみな調整済みの同じ警告設定になります。
もし、シングルプロジェクトなら... (プロジェクトルート直下に)
e.g. IntelliJのInspectionsに関する設定ファイルの構成 (シングルプロジェクト) @Directory
[project-root] // if single project
|-src/main/java
|-src/test/java
|-...
|-.idea
| |-inspectionProfiles
| | |-dbflutespection.xml
| | |-profiles_settings.xml
| |-misc.xml
| |-...
|-...
もし、マルチプロジェクトなら... (リポジトリルートの直下に)
e.g. IntelliJのInspectionsに関する設定ファイルの構成 (マルチプロジェクト) @Directory
[repository-root] // if multi project
|-...
|-.idea
| |-inspectionProfiles
| | |-dbflutespection.xml
| | |-profiles_settings.xml
| |-misc.xml
| |-...
|-maihama-dockside
|-maihama-hangar
|-...
もし、少し合わないところや、さらにOFFにしたい警告があるようであれば、これを土台にさらに設定を調整しても良いでしょう。 (dbflutespection という Profile 名も変更してしまって構いません)
misc.xml は、すでに存在しているかもしれません。misc というからにはいろいろなものが入るのでしょう。 LastaFluteのExampleからコピーして利用するときも、そのまま利用できるとは限りません。 MavenProjectsManager の設定値がプロジェクト構成に寄って変わると思われるので、 すでに存在している場合は自分のプロジェクトに合わせて適切にマージをしましょう。
そして、gitignoreの設定も調整しましょう。
フォーマッター設定の共有
残念なデフォルトフォーマット
当然、人によって違うかもしれませんが、IntelliJのデフォルトのコードフォーマットを残念と思う人は多いです。 ただ、それは Eclipse も同様なので、やはりちゃんと調整してを共有するのが吉です。
IntelliJであれこれ調整する方法は、Twitterで "jflute intellij" で検索してください。
フォーマットを調整したら、必ずチーム内で共有しなければなりません。フォーマットの設定が人によってズレてると100%カオスだからです。
保存したら自動でフォーマット
フォーマッターをしっかり設定しても、フォーマットする人としない人が混ざるとただの差分地獄になります。 やるからにはしっかり使ってもらう施策が必要です。ショートカットキーを浸透させるのも手ですが、そもそもフォーマットを自動化してしまうのも手です。 ここでは、後者の方法を紹介します。
IntelliJに、Save Actions というプラグインをインストールして設定すると、保存(ctrl+S)するときに自動的にフォーマットがかかるようになります。 (厳密には、IntelliJは自動で保存がされるので、その場合はフォーマットされません。明示的な保存(ctrl+S)をしたときにフォーマットされます)
- Save Actionsプラグインのjarファイルをダウンロード
- Preferences の Plugins にて、そのjarファイルをimport
これは、チームメンバーみなに入れてもらわないといけません。
また、フォーマッターを使っているプロジェクトと使っていないプロジェクトを兼務している場合に、使っていないプロジェクトで勝手にフォーマッターがかかってしまうとよくありません。 メニューの File - Other Settings - Default Settings の Save Actions にて、activate を OFF にしましょう。 こうすると、Save Actionsの設定がされていないプロジェクトで勝手に Save Actions が有効になってしまうのを防ぐことができます。
もろもろの Save Actions の調整方法は、Twitterで "jflute intellij" で検索してください。
jfluteお手製のフォーマット調整済xml
大変だと思うので、Save Actionsの設定も含めて、フォーマット調整済の IntelliJ の .idea ディレクトリに配置する xml を用意しています。
さらに、こちらのフォーマット設定は、dbfluteが提供している Eclipseの "dbflute Style" なフォーマッターとほぼ同じになるように調整されていますので、IntelliJ, Eclipse どちらでフォーマットしてもほぼ同じになるようになっています。("IDEはお好きように" という開発スタイルがしやすいように)
- codeStyleConfig.xml
- コードスタイルのコンフィグ (Project.xmlを参照)
- codeStyleSettings.xml
- 調整されたプロジェクトのコードフォーマットの設定
- saveactions_settings.xml
- Save Actinosの設定
これら設定ファイル、オープンソースとして公開されています。 (コピーして使ってOKです。また更新するかもしれませんので、時々ウォッチを。ちなみに、LastaFluteのExampleですがそこ関係ありません)
二つのファイルををコピーして構成どおりの場所に配置し、バージョン管理システム(git)のコミット対象にして共有すれば、チームメンバーみな調整済みの同じフォーマット設定になります。 また、Save Actionsプラグインが入っていれば、保存(ctrl+S)で自動的にフォーマットがかかります。
もし、シングルプロジェクトなら... (プロジェクトルート直下に)
e.g. IntelliJのフォーマッターに関する設定ファイルの構成 (シングルプロジェクト) @Directory
[project-root] // if single project
|-src/main/java
|-src/test/java
|-...
|-.idea
| |-codeStyles
| | |-codeStyleConfig.xml
| | |-Project.xml
| |-inspectionProfiles
| | |-...
| |-saveactions_settings.xml
|-...
もし、マルチプロジェクトなら... (リポジトリルート直下に)
e.g. IntelliJのフォーマッターに関する設定ファイルの構成 (マルチプロジェクト) @Directory
[repository-root] // if multi project
|-...
|-.idea
| |-codeStyles
| | |-codeStyleConfig.xml
| | |-Project.xml
| |-inspectionProfiles
| | |-...
| |-saveactions_settings.xml
|-maihama-dockside
|-maihama-hangar
|-...
そして、gitignoreの設定も調整しましょう。
gitignore戦略は？
個人設定とプロジェクト設定が混じった.idea
ちょっと困ったことに、個人設定とプロジェクト設定が混じって.idea配下に保存されます。
ゆえに、.ideaをignoreすれば良いわけでもなく、commitすれば良いわけでもないのが痛いところ。 しっかり個別個別に調整しないといけません。
jfluteお手製のgitignore
Inspectionsやフォーマッターの設定などを考慮したgitignore設定がこちらです。
e.g. IntelliJのgitignore戦略 @gitignore
# IntelliJ IDEA
**/.idea/*
!**/.idea/codeStyles
!**/.idea/inspectionProfiles
!**/.idea/encodings.xml
!**/.idea/misc.xml
!**/.idea/saveactions_settings.xml
**/*.iml
/out
びっくりマークを使って、git対象のものを指定しています。(以前は、ひたすら除外を指定する方式でしたが、後からこういった指定の仕方ができることがわかりました。yu1roありがとう！)
"**/" にしているのは、マルチプロジェクトなどで階層化されている場合に、下の階層の.ideaディレクトリも対象にできるようにするためです。 シングルプロジェクトやアプリプロジェクト直下なら不要ではありますが、場所によって書き方を変えるとややこしいので、気にせず付けておいて良いでしょう。
ただ、"/out" は、IntelliJとは無関係なoutというディレクトリが問答無用でignoreになってしまうとややこしいだろうということで、直下だけにしています。
gitignoreの場所は、それぞれの現場の慣習があるので、いい感じに取り込んでもらえればですが、Exampleではこのような配置を想定しています。
もし、シングルプロジェクトなら... (プロジェクトルート直下に)
e.g. gitignoreファイルの構成 (シングルプロジェクト) @Directory
[project-root] // if single project
|-src/main/java
|-src/test/java
|-...
|-.idea
|-.gitignore
|-...
もし、マルチプロジェクトなら... (リポジトリルート直下に)
e.g. gitignoreファイルの構成 (マルチプロジェクト) @Directory
[repository-root] // if multi project
|-...
|-.idea
|-.gitignore
|-...
|-maihama-dockside
|-maihama-hangar
|-...
.ideaディレクトリへの意識
.ideaディレクトリの扱いは、少し気をつけないといけません。
マルチプロジェクトのジレンマかな？
IntelliJでプロジェクトを開く時、どこを基点にして開くか？の選択肢があります。 開く基点をチームメンバーで統一などをしないのであれば、ルートごとに .idea を配置しないと共有できません。
例えば、マルチプロジェクトのmaihamaプロジェクトにて、複数のアプリプロジェクトをまるごとimportするために、 リポジトリのルートで開くとします。その場合は、[リポジトリのルート]/.idea が参照されます。
ですが、とある一つのアプリプロジェクトだけをimportする場合は、その開いたアプリプロジェクトのルートの.ideaが参照されます。
e.g. IntelliJのマルチプロジェクトのときの.ideaさんたち @Directory
[repository-root]
|-.idea // リポジトリのルートで開いたときに利用される
|-maihama-base
|-maihama-dockside
| |-.idea // docksideプロジェクトのルートで開いたときに利用される
|-maihama-hangar
| |-.idea // harngarプロジェクトのルートで開いたときに利用される
|-...
どちらで開かれるかわからないのであれば、両方(というかすべて)に .idea を配置しておかないといけません。 つまり、何か設定の変更をしたときに、すべての.ideaを修正しないといけません。 ほとんどがコピーで済むので、実際には手間はそこまでかかりませんが、忘れてズレてしまいそうですし、misc.xmlは厳密に同じにはならないように思います(MavenProjectsManager周り)。
基本的には、必ずリポジトリルートで開く、というのを手順化した方が良さそうです。
シングルプロジェクトでも変わらずジレンマかな？
では、シングルプロジェクトであれば気にしなくて良いかというと、必ずしもそうではありません。
結局、そのシングルプロジェクトを、リポジトリルート直下ではなく、ひとつフォルダを経由して配置している場合、マルチプロジェクトと同じ話になります。
e.g. IntelliJのシングルプロジェクトでも気をつけないといけないとき @Directory
[repository-root]
|-.idea // リポジトリのルートで開いたときに利用される
|-harbor
| |-.idea // harborプロジェクトのルートで開いたときに利用される
とにもかくにも、ちゃんと狙った場所の.ideaが有効になっているかどうか？を気にしてプロジェクトを開くようにしないといけません。
Import Projectのジレンマかな？
.ideaを予め配置してgit管理にした後、他の人がそのプロジェクトを IntelliJ で開こうとするとき、多くの方が "Import Project" を使うと思います。
ただ、Import Project 経由で開こうとすると、最後に ".ideaを上書きしますか？" と聞かれます。Noの場合は先に進めないので、OKで上書きするしかありません。そうすると、せっかく仕込んでいた .idea の設定ファイルたちがデフォルトの設定で上書きor削除されてしまいます。それに気付いて Revert して元に戻せばいいですが、気づかずにそのまま削除コミット(変更コミット)してしまう可能性もあります。
気付くしかありません。
手順の中に、import直後の.ideaの差分は必ず Revert すること、という風に入れておきましょう。
"Import Project" ではなく、"Open" で開けば上書きされないのですが、自分で Maven の import などをしないといけないので、多くの人が "Import Project" を使うでしょう。
dbflute な Live Template
dbfluteが提供している Eclipse の Editor Templates の IntelliJ 版を提供しています。
メニューの File - Import Setttings... で以下の jar ファイルを指定して Live Templates だけ選択して import すれば利用できます。 (Live Templates 以外を選択すると、ご自身の設定が上書きされる可能性があります)
裏技は使えませんが、アンスコで始まる系の補完はほとんどそのまま利用できます。_ll, _li をぜひ活用していきましょう！Eclipseよりも使いやすくなっている部分もあります。
Deco, Hakiba, thank you for your migration from Eclipse.
