Google Summer of Code with Kotlin 2025
この記事には、Google Summer of Code with Kotlin 2025のプロジェクトのアイデアリストと、貢献者向けガイドラインが含まれています。
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に興味があるのか、その経験を説明してください。
- オープンソースプロジェクトに参加している場合、貢献履歴を参考にしてください。
- GitHub、Twitterアカウント、ブログ、または技術的または科学的出版物のポートフォリオがある場合、それらも参考にしてください。
- 試験や休暇などの他のコミットメントによるGSoCのタイムラインとの競合を明らかにしてください。
ありがとうございます!皆様からの応募をお待ちしております!
プロジェクトのアイデア
ビルドサーバープロトコル: Kotlinサポートの追加 [難易度: 高, 350時間]
Kotlinチームは、公式のKotlinサポートをGradleやMavenのビルドシステムだけでなく、他のあらゆるビルドシステムにも拡大し、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, and 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, and the Google team
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, and the Uber team
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, and the Uber team
新しい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 Central公開プラグインが複数実装されており、例えば、Maven Publish Pluginや、すでに新しいAPIを採用しようとしているNew Maven Central Publishingなどがあります。応募時またはコミュニティボンディング期間中に、潜在的な貢献者はこれらの実装をレビューし、既存のプラグインの更新を提案するか、新しいプラグインを構築またはフォークするかを決定する必要があります。成果物には、Maven Central公開用の既存プラグインの新しいバージョン、またはGradle用の新しいプラグインが含まれます。実装はKotlinまたはJavaで行われ、適切なテストカバレッジとドキュメントがあることを想定しています。追加の成果物には、プラグインの使用を簡素化するためのKotlin DSL拡張や、Declarative Gradle拡張が含まれる場合があります。
期待される成果物
- 更新されたMaven Central公開プラグイン、または新しいプラグイン
望ましいスキル
- Kotlin
- Gradle
- Mavenリポジトリ
メンター候補
Oleg Nenashev, and the Gradle team
主要なGradleプラグインにおける設定キャッシュとロック競合の改善 [難易度: 易〜高, 90時間〜350時間]
Gradleは、設定キャッシュを大幅に拡張してパフォーマンス、特にAndroid StudioとIntelliJ IDEAの同期パフォーマンスをさらに向上させる新機能であるIsolated Projectsに取り組んでいます。開発者体験の観点から、これはGradleで最も期待されている機能の1つです。
Isolated Projectsの問題の1つは、Gradleコアにおけるロック競合であり、プラグインが並列実行の妨げとなることがあります。ロック競合を減らしたいと考えており、特にJava、Kotlin、Android、Kotlin Multiplatformエコシステムにおける主要なGradleビルドツールプラグインでその傾向が顕著です。貢献者は、自身の興味と希望するプロジェクト規模に基づいて成果物を選択できます。
潜在的な成果物には以下が含まれますが、これらに限定されません:
- Configuration Cache ReportツールをGradle Profilerに組み込む(または「それに対応するGitHub Actionsを実装する」)
- 様々なプロジェクトでGradleといくつかの人気のあるGradleプラグインをプロファイリングし、GHAでテストスイートを自動化する
- 設定キャッシュの有無にかかわらず、ロック競合を軽減できる潜在的な領域とプラグインを特定する
- その際に、ターゲットプラグインにおける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時間]
Gradleビルドシステム用のプラグインであるIntelliJ Platform Gradle Pluginは、IntelliJベースのIDE向けプラグインのビルド、テスト、検証、公開のための環境設定を簡素化します。このプラグインは、IntelliJ Platformに導入される絶え間ない変更に対応しながら、ビルド、テスト、検証の各ステップを管理します。IntelliJ Platform Gradle Pluginは、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, and the Uber team
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, and the Uber team
Kotlin向けGradleコード品質プラグインのためのクリーンで実用的なレポート [難易度: 易〜中, 90時間〜175時間]
Gradleは最近、Gradleおよびサードパーティプラグインが問題と警告を統一された方法で伝播できるようにする新しいProblems APIを導入しました。このAPIは、クリーンで実用的なエラー報告を提供し、コンソール出力、専用HTMLレポート、接続された可観測性ツールに対してより深い洞察を提供します。IntelliJ IDEAやAndroid StudioなどのIDEも、GradleのAPI統合ツールを介して詳細にアクセスでき、コードエディターで直接警告を表示できます。Javaコンパイル、依存関係解決エラー、非推奨警告など、いくつかのコア機能とプラグインはすでにProblems APIを採用しています。Kotlin向けのコード品質プラグインにもこのAPIを採用してほしいと考えています。これにより、Gradleを使用している10万人以上のKotlin開発者の開発者体験が大幅に向上するでしょう。
このプロジェクトでは、Ktlint、Detekt、Diktat、ArchUnit、Checkstyle for Kotlinなど、いくつかのKotlinコード品質プラグインを選択し、Problems APIと統合することを貢献者に推奨します。また、KotlinDSLで定義されたGradleビルドに対する同様の分析を統合することもできます。
期待される成果物
- 挙げられたプラグインにProblems API統合を実装する
望ましいスキル
- Kotlin
- Gradle
- パフォーマンス分析
メンター候補
Oleg Nenashev, Balint Hegyi, Reinhold Degenfellner