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.
Top comments (1)
Great work and thanks for the transparency. Devil's advocate: since Gradle limits blocked parallel downloads, did you explore a separate prefetch/sync task or a remote cache/mirror for IDE artifacts to cut wall time? With IPV already handling parallelism, does adding the Worker API risk double orchestration/overhead? Also, until the IPV changes merge, are users stuck with split reporting (Problems API vs existing verifier output)? Some before/after numbers would help show the wins.