Hi everyone, I am Aarav Mahajan. I’m planning to w...

# gsoc

[Aarav Mahajan]

Hi everyone,
I am Aarav Mahajan. I’m planning to work on the Gradle convention plugin for developing Jenkins plugins project, but I am still a beginner in this area. Could anyone share insights on how to get started, key resources, or common pitfalls I should watch out for when working with Kotlin, Gradle, and Jenkins plugin development? I'm keen to understand the best practices and any advice you might have. Thanks.

[Oleg Nenashev]

Hi! Thank you for the interest. My advice would be to start from convention plugin basics, it would s the easiest starter

https://youtu.be/kFWmL5opJNk?si=PQDsKg372kV80pzm▾

https://docs.gradle.org/current/samples/sample_convention_plugins.html

[DavidGrath]

Hello, I'm also interested in this project idea. I've gone through the Google Groups and GitHub issues, and it seems like generally speaking, some groundwork has been done, but despite the milestone saying 75% of the work has been done, that there's still plenty more for Maven parity
Will documentation efforts still be appreciated, or would it make more sense to prioritize things like updated testing libraries and static analysis tools?

[Oleg Nenashev]

Documentation updates are always welcome!

[Oleg Nenashev]

but despite the milestone saying 75% of the work has been done, that there's still plenty more for Maven parity

I would not trust the milestone percentages in those regards. I doubt the task list is maintained

[DavidGrath]

Please I want to confirm if I have the basics down
So basically some key points are:
• Documentation updates
◦ For starters, it seems like the main README(https://github.com/jenkinsci/gradle-jpi-plugin/blob/main/README.md) is a good reference point.
◦ I assume one key point is to create a "tutorial style" document similar to the one for Maven (https://www.jenkins.io/doc/developer/tutorial/prepare/) with steps like gradle init and gradle server
• Creating a convention plugin
◦ I'm assuming that a basic step involves lifting out some dependencies, though I'm not sure how necessary that is
◦ I was also curious if there's anything in Gradle that serves a similar purpose as the Maven Enforcer
◦ Does this also mean that SpotBugs specifically would have to be lifted out as well? What might that entail overall?
• Migration from Groovy to Kotlin
◦ My main concern is all the tests that are currently written with Spock. Are they to be left alone or will there be some sort of higher level migration that will happen?

[DavidGrath]

@Oleg Nenashev Please what do you think?

[Oleg Nenashev]

The scope looks good overall, and thank you for the summary

My main concern is all the tests that are currently written with Spock. Are they to be left alone or will there be some sort of higher level migration that will happen?

Good point about the tests. There is Spek but not sure it coumnts as active and usable with Kotlin 2