Kotlin との Google Summer of Code 2025
この記事では、Google Summer of Code with Kotlin 2025 向けのプロジェクトのアイデア一覧と、コントリビューター向けガイドラインを掲載しています。
Kotlin リソース:
- Kotlin GitHub リポジトリ
- Kotlin Slack と #gsoc Slack チャンネル
ご質問がある場合は、[email protected] 宛にお問い合わせください。
Google Summer of Code (GSoC) 向け Kotlin コントリビューターガイドライン
はじめに
Kotlin 言語に慣れてください:
- 公式Kotlin ウェブサイトが手始めに最適です。
- 言語をより深く理解するために、公式ドキュメントを読んでください。
- JetBrains Academyの Kotlin コース、または Android チームのトレーニングオプションをご覧ください。
- 最新のニュースや開発状況を把握するために、Kotlin XまたはKotlin Blueskyアカウントをフォローしてください。
- チュートリアル、ヒント、最新の更新情報については、Kotlin YouTube チャンネルをご確認ください。
Kotlin オープンソースコミュニティについて知りましょう:
- 全般的なKotlin 貢献ガイドラインを確認してください。
- 他の開発者と交流し、質問の助けを得るために、Kotlin Slack チャンネルに参加してください。
- 質問したり、GSoC チームからサポートを受けたりするために、#gsoc チャンネルに参加してください。
応募方法
- プロジェクトのアイデアを確認し、取り組みたいものを選択してください。
- Kotlin に慣れていない場合は、Kotlin ウェブサイトの入門情報を読んでください。
- GSoC コントリビューター向けガイドラインを参照してください。
- GSoC ウェブサイトから応募してください。
- 提案されたプロジェクトに関連する動作するコードサンプルを作成することをお勧めします。また、特に自信のあるコードサンプルがあれば、それも提示してください。
- Kotlin に興味を持った理由と、Kotlin での経験を記述してください。
- オープンソースプロジェクトに参加している場合は、貢献履歴を参照してください。
- GitHub、X (旧 Twitter) アカウント、ブログ、または技術的・科学的出版物のポートフォリオがある場合は、それらも参照してください。
- 試験や休暇など、他の予定による GSoC のスケジュールとの競合があれば申告してください。
ありがとうございます!皆様からのご応募を心よりお待ちしております!
プロジェクトのアイデア
Build Server Protocol: Kotlin サポートの追加 [難易度: 高, 350時間]
Kotlin チームは、Gradle や Maven のビルドシステムだけでなく、他のあらゆるビルドシステムに対しても公式の Kotlin サポートを拡大し、最小限の労力で JetBrains IDE でネイティブにサポートしたいと考えています。一方で、JetBrains 以外の IDE でも基本的な Kotlin サポートを提供したいと考えており、そのようなサポートの一環として、Kotlin をサポートするあらゆるビルドシステムから Kotlin 固有の情報を取得できるようにすることが挙げられます。
これらの要件に対する解決策となるのが、ビルドシステムと IDE の間に抽象化レイヤーを提供するBuild Server Protocol (BSP) です。
このプロジェクトの目標は、BSP プロトコルを使用してユーザープロジェクトから IntelliJ IDEA に必要なすべての情報を取得し、プロジェクト内の Kotlin コードを操作できるようにするプロトタイプを実装することです。このプロトタイプの範囲を限定するため、ユーザープロジェクトは Gradle を使用して自動的にビルドされます。
望ましいスキル
- Kotlin の知識
- Gradle プラグインの記述方法の理解
- ボーナス: IntelliJ IDEA 用プラグインの記述方法の理解
メンター候補
Yahor Berdnikau、Bálint Hegyi、Reinhold Degenfellner
応募者への課題
課題 #1。 このプロジェクトに興味を持った理由は何ですか?
課題 #2。 練習課題: 特定のタスクを公開する Gradle プラグインを作成してください。このタスクは、Kotlin Gradle Plugin が存在する場合に、すべての Kotlin ソースの構造を取得し、それらを出力する必要があります。テストを含めると、さらに良いでしょう。
Firebase の Vertex AI を使用した Gemini 向け Kotlin Multiplatform での Android および iOS ターゲットのサポート [難易度: 中, 175時間]
このプロジェクトは、Firebase の Vertex AI を使用した Gemini を、少なくとも Android と iOS でサポートするオープンソースの Kotlin Multiplatform (KMP) ライブラリを作成することを目的としています。既存のサービス向けに KMP ライブラリを作成する上でのベストプラクティスを実演し、適切な本番環境での実装(例えば、適切な API キー管理、ユーザー管理 API キーのサポート、クライアントのスロットリングなど)に焦点を当てます。
期待される成果物
- 既存の Google サービスをサポートする新しい Kotlin Multiplatform ライブラリ
- サンプルコードとドキュメント
望ましいスキル
- Kotlin
- Kotlin Multiplatform
- モバイル開発 (Android および iOS)
メンター候補
Matt Dyor、および Google チーム
Bazel での Kotlin Multiplatform サポートの追加 [難易度: 高, 350時間]
Bazel の Kotlin サポートは進化していますが、適切な Kotlin Multiplatform (KMP) の統合は依然として課題です。このプロジェクトは、依存関係解決の問題に対処し、rules_kotlin
および rules_jvm_external
の互換性を強化し、クロスプラットフォームビルドを可能にすることで、Bazel の KMP サポートを改善することを目的としています。
主な改善点は、プラットフォーム固有の依存関係の処理 (expect/actual メカニズム)、Gradle メタデータサポートの改善、および Bazel での KMP の開発者エクスペリエンスをよりスムーズにすることに焦点を当てます。
期待される成果物
- Bazel における Kotlin Multiplatform の依存関係解決の強化
rules_kotlin
およびrules_jvm_external
との統合の改善- シームレスなマルチプラットフォーム開発のための、Bazel での動作する KMP ビルド設定
望ましいスキル
- Kotlin Multiplatform および Gradle
- Bazel ビルドシステム
- 依存関係解決戦略
メンター候補
Shauvik Roy Choudhary、および Uber チーム
Kotlin 言語サーバー (LSP) [難易度: 高, 350時間]
Language Server Protocol (LSP) は、自動補完、定義への移動、リファクタリングなど、さまざまなエディターや IDE 間でコードインテリジェンス機能を有効にする、広く採用されている標準です。現在、公式の Kotlin LSP サーバーは存在しませんが、コミュニティではその需要が非常に高まっています。公開で維持され、コミュニティ主導の実装は、コード移行、AI 搭載コード支援、さまざまな開発環境へのシームレスな統合など、幅広いユースケースをサポートできます。
このプロジェクトは、主要な LSP 機能との互換性を確保し、開発環境全体での Kotlin のアクセシビリティを広げる、Kotlin LSP の実装を開発することを目的としています。
期待される成果物
- Kotlin LSP の実装を開発
望ましいスキル
- Kotlin
- Language Server Protocol (LSP)
- IDE 向けのプラグインまたは拡張機能開発
メンター候補
Shauvik Roy Choudhary、および Uber チーム
新しい API を備えた Gradle 用 Maven Central 公開プラグイン [難易度: 中, 175時間]
Maven Central は、JVM に焦点を当てたライブラリやプロジェクトを公開するための、最も人気のある Maven リポジトリの 1 つです。これは Apache Maven や Gradle ベースのオープンソースプロジェクトで活発に使用されており、Sonatype Nexus v2 に基づいていますが、新しいバージョンへの移行を待っています。現在、オープンソースプロジェクトの新しい Maven Central インスタンスへの移行が進行中であり、これは非常に異なる API 実装を持ち、ビルドツールプラグインでの特別なサポートが必要です。新しい Maven Central 公開 API と互換性のある Gradle プラグインを開発することは、Gradle を使用してビルドするライブラリ作者が新しいプロセスでスムーズな経験をするのに役立ちます。
現在、Gradle には、例えばMaven Publish Pluginや、すでに新しい API の採用を試みているNew Maven Central Publishingなど、Maven Central 公開プラグインが複数実装されています。応募またはコミュニティボンディングのフェーズ中に、潜在的な貢献者はこれらの実装をレビューし、既存のプラグインの更新を提案するか、新しいプラグインを構築するか、フォークするかを決定する必要があります。成果物には、既存の Maven Central 公開プラグインの新しいバージョン、または Gradle 用の新しいプラグインが含まれます。実装は Kotlin または Java で行われ、適切なテストカバレッジとドキュメントを持つことを想定しています。追加の成果物として、プラグインの使用を簡素化するための Kotlin DSL 拡張機能や、Declarative Gradle 拡張機能が含まれる場合があります。
期待される成果物
- 更新された Maven Central 公開プラグイン、または新しいプラグイン
望ましいスキル
- Kotlin
- Gradle
- Maven リポジトリ
メンター候補
Oleg Nenashev、および Gradle チーム
主要な Gradle プラグインにおける Configuration Cache とロック競合の改善 [難易度: 易〜高, 90時間〜350時間]
Gradle は、Configuration Cache を大幅に拡張し、特に Android Studio および IntelliJ IDEA の同期パフォーマンスを向上させる新機能であるIsolated Projectsに取り組んでいます。開発者エクスペリエンスの観点から、これは Gradle で最も期待されている機能の 1 つです。
Isolated Projects の問題点の 1 つは、Gradle コアにおけるロック競合であり、プラグインが並列実行の妨げとなる場合があります。特に Java、Kotlin、Android、および Kotlin Multiplatform エコシステム向けの主要な Gradle Build Tool プラグインにおいて、ロック競合を削減したいと考えています。貢献者は、自身の興味と希望するプロジェクト規模に基づいて成果物を自由に選択できます。
潜在的な成果物には以下が含まれますが、これらに限定されません:
- Configuration Cache Report ツールを Gradle Profiler に組み込む(または「そのための GitHub Action を実装する」)
- さまざまなプロジェクトで Gradle およびいくつかの人気のある Gradle プラグインをプロファイリングし、GHA でテストスイートの自動化を行う
- Configuration Cache の有無にかかわらず、ロック競合を削減できる潜在的な領域とプラグインを特定する
- 可能であれば、対象プラグインにおけるConfiguration Cache 互換性の他の領域にも貢献する
- 発見された改善点の一部を実装する
期待される成果物
- Gradle 用 Kotlin DSL の拡張性機能を実装し、一般的なプロジェクト統合のサポートを改善する
望ましいスキル
- Kotlin
- Gradle
- Java
- パフォーマンス分析
- プロファイリング
メンター候補
Oleg Nenashev、Laura Kassovic
Jenkins プラグイン開発用 Gradle コンベンションプラグイン [難易度: 易〜高, 90時間〜350時間]
Gradle で実装された Jenkins プラグインは 50 以上あります。Gradle JPI plugin がありますが、これは Jenkins のホスティング要件に完全に準拠しておらず、更新が必要です。このプロジェクトのアイデアでは、Jenkins 向けの Gradle 開発者フローを回復し、Apache Maven フロー(Parent POM、Plugin Compatibility Tester、Jenkins Bill of Materials など)と機能的に同等にし、Gradle で Jenkins プラグインを開発する人々の開発者エクスペリエンスを向上させることを目指します。
貢献者は、自身の興味と希望するプロジェクト規模に基づいて成果物を自由に選択できます。
潜在的な成果物には以下が含まれますが、これらに限定されません:
- Gradle JPI プラグインを刷新し、ホスティングのベストプラクティスに準拠させる
- Gradle JPI プラグインのコードベースを Groovy から Kotlin に移行する
- Jenkins プラグイン Parent POM の主要機能をカバーする新しい Jenkins プラグイン用コンベンションプラグインを、Kotlin および Kotlin DSL で実装する。これには、プラグインのビルドだけでなく、Jenkins のベストプラクティスに従ったテストと静的解析も含まれます。
- 更新されたプラグインやコンベンションプラグインを、最も人気のある Gradle プラグイン (Gradle プラグイン自体を含む) に採用する
- Gradle プラグインを Plugin Compatibility Tester および Bill of Materials に統合する
- Jenkins プラグイン向けに更新された Gradle 開発フローを文書化する
期待される成果物
- 更新された Gradle JPI プラグイン、および/または Jenkins 用の新しいコンベンションプラグイン。Jenkins Update Center および Gradle Plugin Portal で公開されます。
望ましいスキル
- Kotlin DSL
- Kotlin
- Gradle
- Jenkins
- Java
メンター候補
Oleg Nenashev、Stefan Wolf
Kotlin DSL および Declarative Gradle ドキュメントサンプルテストフレームワーク [難易度: 易〜中, 90時間〜175時間]
Gradle を含む多くのプロジェクトでは、多数の Kotlin DSL サンプルとコードスニペットが存在します(例については Gradle Docs を参照)。これらのスニペットは簡潔さのために不完全なコードを表すことが多いため、複数のバージョンに対してそれらをテストすることは特定の課題を提起します。私たちは、GitHub Actions または TeamCity 上の単体テストフレームワーク (Kotest または JUnit 5) 内でこれらのサンプルの検証を簡素化するテストフレームワークを構築したいと考えています。将来的には、Declarative Gradle サンプルについても同様のことに興味があります。
期待される成果物
- Gradle 用 Kotlin DSL の拡張性機能を実装し、一般的なプロジェクト統合のサポートを改善する
望ましいスキル
- Kotlin
- Gradle
- Java
- 静的解析
メンター候補
Oleg Nenashev、Laura Kassovic
IntelliJ Platform Gradle プラグイン – Gradle レポート作成と並列検証 [難易度: 中, 175時間]
IntelliJ Platform Gradle プラグインは、Gradle ビルドシステム用のプラグインであり、IntelliJ ベースの IDE 用プラグインのビルド、テスト、検証、および公開のための環境設定を簡素化します。このプラグインは、IntelliJ Platform で導入される絶え間ない変更に対応しながら、ビルド、テスト、検証のステップを管理します。
IntelliJ Platform Gradle プラグインは、JetBrains、サードパーティ開発者、および外部企業によって、JetBrains ツールとのワークフローを統合するために使用されています。
期待される成果物
- 詳細で構成可能な検証タスクレポートを提供するために、Gradle Reporting を導入する。
- Gradle Worker API を活用して、複数の IntelliJ Platform バージョンに対して
verifyPlugin
タスクの並列実行を可能にし、タスク実行時間を短縮する。 - プラグイン開発ワークフローをさらに改善するための追加の Gradle 強化策を検討する。
望ましいスキル
- Kotlin
- Gradle
- IntelliJ Platform
メンター候補
Jakub Chrzanowski、JetBrains
より多くの Kotlin OpenRewrite レシピを追加する [難易度: 中, 175時間]
OpenRewrite は、コード移行とリファクタリングを構造化された方法で自動化するための強力なフレームワークです。OpenRewrite は Java に対する強力なサポートを持っていますが、Kotlin エコシステムは、開発者がコードベースをシームレスに移行するのを助ける、より包括的な OpenRewrite レシピセットから恩恵を受けるでしょう。
このプロジェクトは、Java ベースの AutoValue クラスをイディオム的な Kotlin データクラスに移行する、ベストプラクティスに従って Kotlin コードを現代化する、Kotlin バージョン間でのよりシームレスな移行を可能にするなど、より多くの自動変換を追加することで、Kotlin OpenRewrite レシピコレクションを拡大することを目的としています。これらのレシピは、Kotlin 開発者が最小限の手作業で、クリーンで最新かつイディオム的なコードベースを維持するのに役立ちます。
期待される成果物
- Kotlin コード移行のための新しい OpenRewrite レシピの開発
望ましいスキル
- Kotlin
- OpenRewrite フレームワーク
- Java から Kotlin への移行戦略
メンター候補
Shauvik Roy Choudhary、および Uber チーム
Bazel の rules_jvm_external
への BOM サポートの追加 [難易度: 高, 350時間]
Bazel の rules_jvm_external
は、外部 Java 依存関係を宣言するための構造化された方法を提供しますが、現在、Bill of Materials (BOM) ファイルに対する適切なサポートを欠いています。BOM ファイルは、開発者が個々のバージョンを指定する必要なく、Maven および Gradle で依存関係を一貫した方法で管理するために広く使用されています。このプロジェクトは、BOM サポートを追加することで rules_jvm_external
を強化し、開発者が Bazel 内で BOM ベースの依存関係解決を使用できるようにすることを目的としています。このプロジェクトには、既存のオープンソース活動に貢献するか、rules_jvm_external
に直接 BOM サポートを実装するかのいずれかが含まれる可能性があり、広く使用されている依存関係管理アプローチとの互換性を確保します。
期待される成果物
- Bazel の
rules_jvm_external
における BOM サポートの実装 - Bazel ユーザーの依存関係解決と使いやすさの改善
- Bazel での BOM サポートの使用に関するドキュメントと例
望ましいスキル
- Starlark (Bazel のスクリプト言語)
- Bazel ビルドシステム
- 依存関係解決戦略
メンター候補
Shauvik Roy Choudhary、および Uber チーム
Kotlin 用 Gradle コード品質プラグイン向けのクリーンで実用的なレポート [難易度: 易〜中, 90時間〜175時間]
Gradle は最近、Gradle およびサードパーティプラグインが問題や警告を統一された方法で伝播できるようにする新しいProblems APIを導入しました。この API は、クリーンで実用的なエラーレポートを提供し、コンソール出力、専用の HTML レポート、接続された可観測性ツールへのより深い洞察をもたらします。IntelliJ IDEA や Android Studio などの IDE も、Gradle の API 統合ツールを介して詳細にアクセスし、コードエディターで直接警告を表示できます。Java コンパイル、依存関係解決エラー、非推奨警告など、いくつかのコア機能とプラグインはすでに Problems API を採用しています。私たちは Kotlin 用のコード品質プラグインにもこの API を採用してもらいたいと考えており、これにより、Gradle を使用する 100,000 人以上の Kotlin 開発者の開発者エクスペリエンスが大幅に向上するでしょう。
このプロジェクトでは、貢献者に Ktlint、Detekt、Diktat、ArchUnit、または Kotlin 用 Checkstyle など、いくつかの Kotlin コード品質プラグインを選択し、それらを Problems API と統合することを提案します。また、Kotlin DSL で定義された Gradle ビルドに対して同様の分析を統合することにも取り組むことができます。
期待される成果物
- 上記のプラグインに Problems API 統合を実装する
望ましいスキル
- Kotlin
- Gradle
メンター候補
Oleg Nenashev、Balint Hegyi、Reinhold Degenfellner