@Aarav Mahajan how is your availability on the weekend, or next Monday/Wednesday? I would like to do a quick sync on the community bonding and the potential steps there

Hi @Oleg Nenashev, I actually have a sync with @rahulsom at 12:30 AM IST — it would be awesome if you could join us today for the same & discuss further steps... I will be caught up with college end semester exams from the 19th to the 31st, so the next 10 days are going to be a bit hectic.

Hello everyone, I have submitted a PR updating the Gradle documentation for this project, for now it replaces the previous placeholder text with proper content... https://github.com/gradle/community/pull/219 Thanks!

@Aarav Mahajan @rahulsom @sghill For the next week, I suggest setting a regular sync. It will be mostly for me and Aarav to be present every week, but everyone else is welcome too https://calendly.com/d/cnx6-zm2-d36/gsoc-2025-jenkins-plugins-with-gradle-sync-ups

Hello @Oleg Nenashev @sghill @rahulsom 👋 would like to clarify how we should set up the GitHub repository for our project.... 🤔 Should I create the repository under my personal GitHub account & add the four of us as collaborators with write access? Or would it be better to create a new shared GitHub org. or a private repository to support joint development & ownership??

@Aarav Mahajan This test is a good reference on how to use the JPI2 plugin.

Hi @Oleg Nenashev @sghill @rahulsom 👋 I have started a private repo

jenkins-gradle-convention-plugin

. I have sent you the invite for the same. I spent some time today, figuring out the overall structure for the project. As we are aiming for multi-module architecture, tried to implement that into 4 modules: 1. core/ : will contain the actual Gradle Convention plugin logic (Jenkins-specific DSL + tasks etc.) 2. quality/ : (Spotbugs, Checkstyle etc. would be implemented here) 3. publishing/ : will contain Maven publish + signing etc. tasks 4. integration/ : dedicated test source set for Teat Harness and other tests.... --- Kindly have a look. My thought process, is like the 'core' module would be the baseline that is necessary for all projects, and other modules are optional and independently scalable.

Hi everyone, just a quick update on my progress... I have been working on implementing the :core module for the last 2-3 days... most of the time is being spent on configuring the gradle build scripts for the build-logic module 😅

any recommendations for the GitHub repos to look into.... they can serve as a blueprint for configuring these scripts, ensuring best practices are followed... Presently, using this repo, for some of the logic/style https://github.com/android/nowinandroid

also, I have sent the private repo. collaborator invite, kindly accept that Thanks 🙂

@Aarav Mahajan @rahulsom @sghill I might be 5-10 minutes late or might have to leave the call for the same duration. Courier delivery

We talked a bit about using lazy properties for extensions, such as JenkinsPluginExtension

I have a talk tomorrow in the evening, and I'm not 100% sure how the meetup timing will be.

@Aarav Mahajan just in case, do we have anything for the asynchronous discussion?

Hi @Oleg Nenashev, I don't have anything specific for the asynchronous discussion at the moment. It would be great if you could kindly take a look at the code, pushed on GitHub... whenever you get a chance... 🙂 almost done with the :api and build-logic module, created most of the interfaces, some standard conventions etc. presently working on :core module... though Gradle is being harsh sometimes... 😅😂but working my way out... Thanks!

Example CI for a Gradle plugin: https://github.com/rahulsom/waena/blob/main/.github/workflows/build.yml Example Integration test for a Gradle plugin: https://github.com/jenkinsci/gradle-jpi-plugin/blob/main/src/test/groovy/org/jenkinsci/gradle/plugins/jpi2/V2IntegrationTest.java

Sorry I am late with trying out the plugin. Moving is hard 😞

Hello @Oleg Nenashev @rahulsom @sghill I was working on the

core

module and was about to complete it... As a takeaway, from the last meeting, I was also trying to implement some unit/integration testing.... I went through the codebase again, I felt that were we on the right track? I felt that my current approach is going towards re-inventing the wheel rather than building upon the current jpi2 plugin... Can you please go through the current state of the codebase, and offer some guidance on my current approach? I have till now completed, build-logic, api and core module (ongoing). For the last 1-2 days, I was pondering how to proceed further, and not able to make much of a progress... Though we have a meeting scheduled today, we can further discuss this... Thanks 🙂

Hi @Aarav Mahajan how is it going on your side? Anything to review/comment on?

Hi @Oleg Nenashev ! I was working on creating some examples.... I was working on enhancing the BOM management. From the last meeting, I am focusing on creating and enhancing one feature at a time rather than focusing on 2-3 at a time. I picked up BOM, as per your concern of dependency hell as seen in the Checkmarx plugin.... --- Little bit stuck, with how to showcase my convention plugin in examples. I thought about trying to get it to work on Checkmarx (to address the dependency hell), but for it a lot of work is still needed in convention plugin to get it work with these deployed production plugins... So I am scratching my head and trying to create a simple test plugin.. It would showcase the before/after applying convention plugin, specially focusing on solving the auto dependency resolve thing.... Any suggestions/tips etc.

Hi @Oleg Nenashev @rahulsom @sghill, Actually I am facing an issue with generateLicenseInfo task in jpi plugin. I tried disabling it in JpiPluginAdapter.kt, https://github.com/aaravmahajanofficial/jenkins-gradle-convention-plugin/blob/main/convention-plugin/src/main/kotlin/internal/JpiPluginAdapter.kt it didn't fix the issue. I saw that this issue was also fixed earlier https://github.com/jenkinsci/gradle-jpi-plugin/issues/185. --- I was thinking whether I should integrate https://github.com/jk1/Gradle-License-Report instead? Thanks! ---- I am using Gradle 9.0.0 (gradle = "9.0-rc-1"). --- PS C:\Users\aarav\Desktop\jenkins-gradle-convention-plugin> ./gradlew clean build --no-daemon --no-configuration-cache To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/9.0.0-rc-1/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation. Daemon JVM discovery is an incubating feature. Daemon will be stopped at the end of the build

Task test plugingenerateLicenseInfo FAILED

FAILURE: Build failed with an exception. * What went wrong: Execution failed for task 'test plugingenerateLicenseInfo'.

groovy/util/XmlParser

* Try:

Run with --stacktrace option to get the stack trace.

Run with --info or --debug option to get more log output.

Run with --scan to generate a Build Scan (Powered by Develocity).

Get more help at https://help.gradle.org.

BUILD FAILED in 27s 30 actionable tasks: 26 executed, 4 up-to-date

This issue happens when I enable the :test-plugin build in settings.gradle.kts

Hi @Oleg Nenashev @sghill @rahulsom, I am facing one more issue, when I apply my convention plugin in the test plugins, the build fails at the execution phase around 75-80%, with an error. I am trying to fix this since yesterday night... I tried changing the to

googlejavaformat, eclipse()

but the issue persists with them as well..... Also some other dependencies are also similarly... > Task test pluginspotlessJava FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task 'test pluginspotlessJava'. > Resolved to an empty result: com.palantir.javaformatpalantir java format2.27.0 * Try: > Run with --stacktrace option to get the stack trace. > Run with --info or --debug option to get more log output. > Run with --scan to generate a Build Scan (Powered by Develocity). > Get more help at https://help.gradle.org. BUILD FAILED in 28s 45 actionable tasks: 41 executed, 4 up-to-date --- Upon digging in and researching about this, found that:

the JPI Plugin artifact transformation system is intercepting the Palantir dependency resolution and redirecting it to an empty configuration, like it applies special handling to dependencies (creating empty JPI variants) and when Spotless tries to use the Palantir/Google formatter, it can't access the actual implementation because it's been transformed...

Debug logs (Trim down version): 2025-07-08T004635.684+0530 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.modulecache.ResolvedArtifactCaches] Reusing in-memory cache for repo 'MavenRepo' [26c913274550a0b2221f47a0fe2d2358]. 2025-07-08T004635.684+0530 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.modulecache.ResolvedArtifactCaches] Reusing in-memory cache for repo 'Gradle Central Plugin Repository' [2f8748e965ecb2135dad092e9ef808de]. 2025-07-08T004635.684+0530 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.modulecache.ResolvedArtifactCaches] Reusing in-memory cache for repo 'Google' [d4e342018b23d58be902a60e67105aa1]. 2025-07-08T004635.685+0530 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.modulecache.ResolvedArtifactCaches] Reusing in-memory cache for repo 'MavenRepo2' [26c913274550a0b2221f47a0fe2d2358]. 2025-07-08T004635.685+0530 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.modulecache.ResolvedArtifactCaches] Reusing in-memory cache for repo 'jenkins' [7289ca9cee0a5776290616868868d0cb]. 2025-07-08T004635.685+0530 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.DependencyGraphBuilder] Visiting configuration jenkins-gradle-convention-plugintest plugin1.0.0-SNAPSHOT(spotless-511660163). 2025-07-08T004635.689+0530 [DEBUG] [org.gradle.internal.resolve.caching.CrossBuildCachingRuleExecutor] Found result for rule [DefaultConfigurableRule{rule=class org.jenkinsci.gradle.plugins.jpi.JpiVariantRule, ruleParams=[]}] and key com.palantir.javaformatpalantir java format2.27.0 in cache 2025-07-08T004635.689+0530 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver] Attempting to resolve component for com.palantir.javaformatpalantir java format2.27.0 using repositories [MavenRepo, Gradle Central Plugin Repository, Google, MavenRepo2, jenkins] 2025-07-08T004635.689+0530 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleComponentRepository] Using cached module metadata for module 'com.palantir.javaformatpalantir java format2.27.0' in 'MavenRepo' 2025-07-08T004635.689+0530 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver] Using com.palantir.javaformatpalantir java format2.27.0 from Maven repository 'MavenRepo' 2025-07-08T004635.689+0530 [DEBUG] [org.gradle.internal.component.model.LoggingAttributeMatchingExplanationBuilder] Candidate {org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-api} doesn't have attribute org.gradle.dependency.bundling 2025-07-08T004635.689+0530 [DEBUG] [org.gradle.internal.component.model.LoggingAttributeMatchingExplanationBuilder] Candidate {org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-api} doesn't have attribute org.gradle.jvm.environment 2025-07-08T004635.689+0530 [DEBUG] [org.gradle.internal.component.model.LoggingAttributeMatchingExplanationBuilder] Candidate {org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-runtime} doesn't have attribute org.gradle.dependency.bundling 2025-07-08T004635.689+0530 [DEBUG] [org.gradle.internal.component.model.LoggingAttributeMatchingExplanationBuilder] Candidate {org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-runtime} doesn't have attribute org.gradle.jvm.environment 2025-07-08T004635.689+0530 [DEBUG] [org.gradle.internal.component.model.LoggingAttributeMatchingExplanationBuilder] Candidate {org.gradle.category=documentation, org.gradle.depen dency.bundling=external, org.gradle.docstype=sources, org.gradle.status=release, org.gradle.usage=java-runtime} attribute org.gradle.category value {org.gradle.category=documentation, org.gradle.status=release} doesn't requested value library --- Kindly help me with this. I also tried clearing the local cache, build cache, rebuilding everything, but all went in vain.

I tried by downgrading the dependencies but nothing helped much. Otherwise the dependencies are working fine, the project builds successfully, when I don't include the test-plugin build in settings.gradle.kts. --- You can checkout the repo for the files that have the spotless or plugins logic: QualityExtension.kt, QualityManager.kt. Kindly check, if I am applying the JPI2 correctly, in JpiAdapter.kt, libs.versions.toml

@rahulsom @sghill https://plugins.gradle.org/plugin/org.jenkins-ci.jpi2 is the final location for JPI2, right? Or just an experimental one?

Hi @Oleg Nenashev @sghill @rahulsom, Should I completely ignore the JPI folder now, and focus only on the files in the new JPI2 folder? I was actually first using src/main/groovy/org/jenkinsci/gradle/plugins/jpi/JpiExtension.groovy for like mapping the properties between convention plugin and JPI plugin. In my opinon, I see that few of the properties like maskedClassesFromCore, testJvmArguments, generatedTestClassName, etc. are not present in JPI2 folder anymore. If this is the case, I don't need to expose those properties anymore in my convention-plugin as well and don't bother about them?

Hi @Oleg Nenashev @sghill @rahulsom , Yesterday I went through this old developer mailing list discussion again regarding the Gradle JPI Plugin https://groups.google.com/g/jenkinsci-dev/c/lHQAiEepBiw?pli=1 . But I didn't really get it, what are the real limitations of Gradle JPI Plugin, or what are the things that really need to be fixed at the first place for my project. What does actual "feature-parity" mean here as per the comment by Basil https://groups.google.com/g/jenkinsci-dev/c/lHQAiEepBiw/m/aidom5VDAgAJ ? Can you please guide me in this regard, like what are the major feature/fix I should be working on? I am not able to get complete idea on the major issues that JPI plugin has presently. After reading this conversation, I thought one issue is manifest/metadata generation, but after running through the codebase of both maven-hpi-plugin and gradle-jpi-plugin, I saw they are almost producing the same result or is there any problem in that? It would be very helpful, if you can give me a list of fixes/feature that you feel are missing, I can work on next and add it to my convention-plugin and don't deviate from my path. What are things that I don't need to bother about and are already in good shape? Till now, I have integrated BOM, (some advanced features like version selection, conflict resolution are left), integrated most of the quality tools as well like pmd, spotless, etc. with almost zero-config defaults. I have also applied for the publish request at the Gradle Plugin Portal. Thanks!

@Aarav Mahajan option to consider for the reference implementation of the plugin: https://github.com/jenkinsci/gradle-daemon-plugin

Sorry for dropping early @Aarav Mahajan @rahulsom. I am around in the chat if needed

Hi @Oleg Nenashev, as the evaluation meeting is tomorrow (18th Friday), can I send you the video by today evening or so?