JavaやNodeJSには多数のビルドツールがあります。ものによってはビルドツールではなくタスクランナーとかワークフローとか名前が付いてるかもしれませんが些細なことです、ここでは以下のようなツールのことをまとめてビルドツールと呼びます： Apache Ant Apache Maven Gradle Bazel yarn pnpm 一方で言語公式のビルドツールを用意している言語もあります。これによってプロジェクトごとに異なる技術を学ぶ必要性が減りますし、一貫性のある開発体験を得ることができます。javac javadoc のような単純なコマンドしか提供しないJavaとは異なる方針を言語として持っていることは明らかでしょう。 では言語のエコシステムにビルドツールがたくさんあることはモダンではなく不便なのでしょうか？そんなことはないだろうというのが自分の考えです。もちろん欠点がないとは言いません
考慮する点 成果物のデプロイ ビルドの成果物（artifct）をアップロードすること。アップロードと公開は分けて考えることに注意。デプロイ先にはいくつか候補がある： GitHub Packages (旧GitHub Package Registry) Maven Central Repository Docker HubなどのDocker Registry GitHub Packagesはコンテナも.jarもまとめて置けるが、コミュニティ標準の場所ではないので利用する際にひと手間必要になる。プライベートプロジェクトの場合は積極利用することになりそう。FOSSなら基本的にMaven Centralに置くことになる*1。プロジェクトによっては.jarファイルとしてではなくコンテナとしてデプロイすることもあるだろう。 リリースノートの作成 CHANGELOG.mdやsrc/site以下のファイル
最近Java周りでもsemantic-releaseの利用機会が増えています。Gradle pluginとMaven pluginが生まれ、特に後者はyarn*1で実行されるため既存のプラグインとも組み合わせやすく、JavaScriptと比較しても遜色ない状態と言えそうです。 2019年3月時点で、Java特にMavenがどのようにsemantic-releaseを活用できるのか、まとめてみます。 semantic-releaseとは プロジェクトにおいて以下の制約を導入することで、リリース作業をより一段階自動化する仕組みです。 Semantic Versioningを使ったバージョン番号の付け方 Conventional Commit Messagesを使ったコミットコメントの書き方 すでにJavaコミュニティにおいてもSemantic Versioningは標準となっているため、実際に
今年はビルド周りで自分の常識がいろいろ変わった年だったので、既存の知見もあわせてまとめます。 Mavenのバージョンを固定する Travis CIは不定期にビルド用仮想マシンを更新しますが、そのタイミングでの最新のMavenを仮想マシンに入れるようです。このブログ投稿時だと3.5.2が入っています。 Build Environment Update History - Travis CI もっと新しいバージョンを使う、あるいはMavenのバージョンを固定するには、Maven Wrapperを使うと良いでしょう。Travis CIはプロジェクトルートディレクトリにmvnwスクリプトがある場合はそれを優先的に使います。 mvnコマンド指定時の注意点 script や install、deploy などのフェーズで mvn コマンドを明示的に実行する場合、 -B オプションを忘れないようにします
Using Toolchains in Your Project There are two essential components that you need to configure in order to use toolchains: the maven-toolchains-plugin in your project POM, the toolchains.xml file on the building machine. The maven-toolchains-plugin is the one that sets the toolchain to be used by the toolchain-aware plugins in your project. For example, you want to use a different JDK version to b
Set this to true to allow incomplete project processing. By default, such projects are forbidden and Mojo will fail to process them. Incomplete project is a Maven Project that has any other packaging than "pom" and has no main artifact packaged. In the majority of cases, what user really wants here is a project with "pom" packaging and some classified artifact attached (typical example is some ass
eller さんが、ライブラリの作者はSLF4J のバインディングのみならず API も compile スコープの依存先から除くべきという趣旨のことを書いていました。前半はその通りだけど後半は違うのでは？と思い、そのようにコメントしたのですが、もう少し詳細を書いておきます。 SLF4J を使うライブラリについて、僕の考えは次のとおりです。 実装のバインディング (Logback とか slf4j-log4j12 とか) に compile スコープで依存してはいけない slf4j-api に compile スコープで依存するべき 1 は eller さんと同意見ですが、 2 については相違しています。このように考える理由は次の通りです。 slf4j-api に依存することで、「このライブラリは SLF4J を使うよ」ということが明確になる これは字義通りです。 slf4j-api に依
2020-07-22更新: 以下の投稿で情報をアップデートしています。 https://blog.kengo-toda.jp/entry/2020/07/21/223136 いつも購読させていただいている id:teppeis さんのブックマークに以下のエントリが流れてきて、なるほどこいつはたしかに厄介だと思いました。 javaのロガーが多すぎて訳が解らないので整理してみました - 文系プログラマによるTIPSブログ ただSLF4Jが最も先進的かつ著名なインタフェースである以上、配布側としてはSLF4Jを使いつつ問題を解決したいところです。他のインタフェースを使ったりオレオレ実装を使ったりしてしまうと、それこそユーザの自由度を奪ってしまう形になります。 実際、SLF4Jを配布パッケージに含めないという簡単な解決法がありますので、簡単に紹介します。悲劇を繰り返さないためにライブラリ開発者がす
PMDは「枯れた技術」だと思うしネット上にも日本語情報は多いですが、わりと古いものが多い気がするし1箇所にまとまってたほうが便利だと思うのでまとめてみます。 なお著者のスペックの都合上、SBTのようなナウでヤングなビルドツールは対象にしていませんすみません。ご存知でしたらぜひ教えてください。 PMDとは PMDはJavaコードを分析して潜在的なバグを探すツールです。コピペ検知ツールCPDを含んでいます。開発への基本的な適用方法としては以下の2パターンがあるでしょう。 ビルド手順に組み込む 潜在的なバグが見つかった段階でビルドを中断する（あるいは警告する） 常時監視によるエンバグ予防に 不定期に実行する クセや課題の確認に使う、ブラッシュアップの参考にする 潜在バグ一掃タスク、品質向上月間などに 第3者の視点で自動的にコードを確認するPMDは、スキルの異なる複数人数による開発で強力な支援ツー
Are you using Maven's site feature? How about GitHub Pages? If you're using both of them, GitHub's site-maven-plugin helps you to host your site on Pages. MavenのsiteとGitHub Pagesを使っている方に朗報です。GitHub社がsiteをPagesにデプロイするMavenプラグインを公開しており、とても簡単に利用することができます。 Settings At first, write <plugin>...</plugin> in your pom.xml. まずpom.xmlにプラグインを利用する旨を宣言します。 <plugin> <groupId>com.github.github</groupId> <artifact
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
