Google Summer of Code 2025 Final Report (Kotlin Foundation)

Victoria Chuks — Fri, 29 Aug 2025 13:30:36 +0000

IntelliJ Platform Gradle Plugin - Gradle Reporting and Parallel Verifications

As part of Google Summer of Code 2025, I had the amazing opportunity to improve the IntelliJ Platform Gradle Plugin (referred to as IPGP in this report) with support from my mentor Jakub Chrzanowski. IPGP is a Gradle plugin that simplifies configuring your environment for building, testing, verifying, and publishing plugins for IntelliJ-based IDEs. It does all this whiles keeping up with the frequent changes in the IntelliJ Platform. The plugin is used by JetBrains internally, by third-party developers, and by external companies to integrate their workflows with JetBrains tools.

This project aimed to improve IPGP by bringing it closer to Gradle standards and optimizing developer workflows.

🏢 Organization

Contributor: Victoria Alajemba
Mentor: Jakub Chrzanowski
Organization: Kotlin Foundation

🎯 Project Goals

Introduce Gradle Reporting API to provide detailed, configurable verification task reports. Done ✅
Utilize Gradle Worker API to enable parallel execution of the verifyPlugin task against multiple IntelliJ Platform versions, reducing execution time. Done ✅
Explore additional Gradle enhancements to further improve plugin development workflows. Done ✅

🚚 Final Project Deliverables

1. Worker API for VerifyPluginTask

Problem: The verifyPlugin task verifies plugins against one or more IntelliJ IDE versions. Prior to the GSOC program is was assumed that the verification against multiple IDE versions happened sequentially.

Approach: Initially implemented Worker API to enable concurrent verification against multiple IDEs. Upon discovering that IntelliJ Plugin Verifier (IPV) already utilized concurrency, further investigation revealed that the main bottleneck was downloading IDE dependencies, not the verification work itself.
We then pivoted to explore whether dependencies for the verifyPlugin task could be downloaded in parallel. This research covered renaming dependencies to avoid conflicts, experimenting with dependency substitution and forced versioning, exploring the ResolutionResult API, and even experimenting with Worker API and other custom parallel execution strategies. Ultimately, Gradle does not allow parallel resolution of configurations.

Outcome: Worker API integration was prototyped but abandoned due to Gradle dependency resolution constraints.

Status: Closed

Notes: Research on parallel dependency resolution

2. Reporting API in `VerifyPluginTask`

Problem: To align closely with Gradle standards, VerifyPluginTask should create its report using Reporting API.

Approach: Integrated Reporting API for VerifyPluginTask. A ReportingContainer was introduced with support for HTML, Markdown, and Plain reports. These were exposed through the IntelliJPlatformExtension, allowing users to configure which reports to generate and where to store them.

Outcome: Functionally complete, but blocked by limitations in the IntelliJ Plugin Verifier, which only accepts a single output directory. Before PR can be merged, IPV needs to be updated to allow each report's output location to be configured.

Status: Draft

Notes: Reporting API research notes

3. Problems API in `VerifyPluginTask`

Problem: Make use of Gradle's problems reporting tool to enforce rich reporting of issues in a user friendly manner.

Approach: Integrated the Problems API, Gradle’s newer structured issue-reporting system. Issues reported now include details, solutions, contextual file locations, and links to documentation displayed in a consistent manner across different environments.

Outcome: Verification issues are now reported in a more maintainable way with more info for developers to quickly see what's wrong whether they're in the console, an IDE, viewing a BuildScan or the Problems report.

Status: Merged

Notes: Problems API integration notes

4. Reporting API in VerifyPluginProjectConfigurationTask

Problem: Gradle task that validates certain configurations of the plugin's project lacked standardized reports.

Approach: Integrated the Reporting API into VerifyPluginProjectConfigurationTask.

Outcome: Demonstrated that the Reporting API works well in simpler validation contexts where PV’s output restrictions do not apply.

Status: Merged

5. Documentation Contribution

Problem: Gradle’s Reporting API lacked practical usage documentation for plugin developers.

Approach: Authored a new Gradle Cookbook entry explaining how to wire the Reporting API into plugin tasks.

Outcome: Provides practical examples and guidance on using the Reporting API.

Status: Merged

🚧 Project Status Overview

Deliverable	PR Link	Status
Worker API for `VerifyPluginTask`	#1948	Closed
Reporting API for `VerifyPluginTask`	#1996	Draft
Problems API in `VerifyPluginTask`	#1987	Merged
Reporting API in `VerifyPluginProjectConfigurationTask`	#2016	Merged
Gradle Cookbook Documentation	#58	Merged

🎓 Key Learnings

Throughout this project, I gained a deep understanding of several critical concepts that are essential for not only proper plugin development in the Gradle ecosystem but also as a software engineer:

Gradle Build Lifecycle: I learned when Gradle tasks are configured and executed. This knowledge was crucial for correctly integrating the new APIs and understanding the timing of dependency resolution.

Gradle's Worker API and Dependency Resolution: I explored the Worker API for parallel execution and delved into the intricacies of Gradle's dependency resolution process. This research, including the use of detachedConfiguration in IPGP to resolve dependencies, taught me the technical limitations of parallelizing certain build phases in Gradle and the importance of thorough investigation.

Codebase Navigation: I was originally a bit afraid of the IPGP codebase, but in a few weeks I became familiar with the internal structure and flow. Very grateful to Jakub for this 🙌🏾.

One of my most valuable takeaways was that research is an essential part of development, even if it doesn't lead to a final implementation. The time spent investigating parallel dependency resolution was not a failure; it provided crucial insights that prevented wasted effort and clarified the true bottlenecks in the build process.

🔮 Future Work

Follow-up with community on merging the open PRs.
Hopefully contribute to improvements in the IntelliJ Plugin Verifier to allow configurable report directories.
Continue writing documentation to support adoption of Gradle APIs.

Forem: Victoria Chuks

Google Summer of Code 2025 Final Report (Kotlin Foundation)

IntelliJ Platform Gradle Plugin - Gradle Reporting and Parallel Verifications

🏢 Organization

🎯 Project Goals

🚚 Final Project Deliverables

1. Worker API for VerifyPluginTask

2. Reporting API in `VerifyPluginTask`

3. Problems API in `VerifyPluginTask`

4. Reporting API in VerifyPluginProjectConfigurationTask

5. Documentation Contribution

🚧 Project Status Overview

🎓 Key Learnings

🔮 Future Work

🔗 Additional Links

Forem: Victoria Chuks

Google Summer of Code 2025 Final Report (Kotlin Foundation)

IntelliJ Platform Gradle Plugin - Gradle Reporting and Parallel Verifications

🏢 Organization

🎯 Project Goals

🚚 Final Project Deliverables

1. Worker API for VerifyPluginTask

2. Reporting API in VerifyPluginTask

3. Problems API in VerifyPluginTask

4. Reporting API in VerifyPluginProjectConfigurationTask

5. Documentation Contribution

🚧 Project Status Overview

🎓 Key Learnings

🔮 Future Work

🔗 Additional Links

2. Reporting API in `VerifyPluginTask`

3. Problems API in `VerifyPluginTask`