![](https://cdn-ak-scissors.b.st-hatena.com/image/square/79a88a0602bc7a01f821ff4f11a2dc563d7ee0a3/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F68cb3ee59bc54a168fb9d097d210e713%2Fslide_0.jpg%3F12594329)
エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
パッケージ管理していなかった既存システムに後付けで Gradle を導入した話 - Speaker Deck
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
パッケージ管理していなかった既存システムに後付けで Gradle を導入した話 - Speaker Deck
※ JJUG 2019 Spring のセッション "パッケージ管理していなかった既存システムに後付けで Gradle を導入... ※ JJUG 2019 Spring のセッション "パッケージ管理していなかった既存システムに後付けで Gradle を導入した話" のスライドです (#jjug_ccc #ccc_a2)。 近代的なプロダクトでは Gradle, Maven, Ivy といったパッケージ管理ツールを既に使っていることが多いと思います。 しかし、それらのツールの登場以前からの古い Java プロジェクト等に「後から」パッケージ管理ツールを導入するための方法論や具体的手法の情報が意外と少ないように感じました。 そこで、実際に大きなプロダクトに「後から」パッケージ管理ツールを導入した事例をご紹介いたします: - パッケージ管理ツールを入れた動機 - パッケージ管理ツールを「後から」導入する際の戦略 - パッケージ管理ツールを「後から」導入するための各種の技術的手法 この情報を活かしていただくことで、パッケージ