@Jendrik Johannes I think this is worth discussing: https://github.com/gradlex-org/jvm-dependency-conflict-resolution/issues/114#issuecomment-2059357371 Should we add it to the agenda for the next meeting?

@benedikt in the build logic of our projects, we always use the prefix

org.gradlex.gradlebuild.

. IIRC you introduced this pattern and I started to adopt that in other projects as well. E.g. if my project hast the namespace

org.example

, I would use

org.example.gradlebuild

. Someone suggested to just use

org.example.gradle

instead of

org.example.gradlebuild

as the previous is shorter and the latter does not really add to it (

gradle

is the build tool after all). Are there good arguments for using

gradlebuild

instead of just

gradle

? (I think in the GradleX project it may make sense as there are so many things called Gradle, but what about other software projects?)

Does anybody recall why we’re doing this?

Announcment post for

reproducible-builds

plugin: https://gradle-community.slack.com/archives/CRA9GTYBH/p1726233765105009

I’ve looked into how the application plugin works to address https://github.com/gradlex-org/reproducible-builds/issues/7 The plugin adds an extension that provides a

executableDir

property. I think we can use that to inspect the path of the files we’re setting permissions for and then set execute permissions on the script files inside the directory.

I wouldn’t go all the way at this point adding some clever logic that inspects scripts files looking for shebangs and what not. I think making it work just the for application plugin is a good start and worthy a 1.0.1 release.

Good idea! Do you know what happens if you create a

dist

zip on Windows without the plugin? Is that broken by default or does Gradle already set (reproducible) file permissions only for the start script file by default?

Hi all. Want to add some GradleX projects? https://gradle-community.slack.com/archives/CA7UM03V3/p1727784445506889

Related to the reproducible builds topic: There are two issues now to change the default behavior for the ArchiveTask flags in Gradle 9. Feel free to upvote. https://github.com/gradle/gradle/issues/30826 (archivePreserveFileTimestamps) https://github.com/gradle/gradle/issues/30827 (reproducibleFileOrder)

I started a document on the topic of Consistent Resolution. We have some functionality for this in the jvm-dependency-conflict-resolution plugin, but there is no general agreement on how to work with this best in the context of JVM projects. I think this is an essential feature for many JVM projects and a selling point for Gradle (compared to other build systems in the JVM space). By starting this discussion, I hope to give the feature (and the problem it solves) more visibility. And eventually establish common best practices in this area. There is more on the motivation in the beginning of the document. The document is open for comments. Feedback is welcome! Global Consistent Resolution with Gradle

Finally (months later than planned and promised) I did the 1.0 release of the

java-module-packaging

plugin. See: https://gradle-community.slack.com/archives/CRA9GTYBH/p1731944734158489

Hey folks, here's the summary of what we discussed today regarding the problem with the reproducible builds plugin when combined with the application plugin: https://github.com/gradlex-org/reproducible-builds/issues/7#issuecomment-2493440639

@Louis Jacomet after you left the team meeting, Jendrik and I discussed whether we should drop Groovy/Spock in favor of Java + JUnit 5. The reason being that we pull in Groovy just to write the tests and we feel like Groovy and Spock might be a barrier for people to contribute. Outside of Gradle it's not very widely used. Do you have objections against migrating tests to Java + JUnit 5?

I can't make it next week, because we have a short vacation planned.

I've created a pull request for build parameters to fix the dependabot alerts: https://github.com/gradlex-org/build-parameters/pull/208 we can take it from there and think about making that part of the convention plugin. For the vulnerability coming from commons-io, I had a look at the exemplar code and it's really only used in five places. My thinking is to propose a PR that drops commons-io from the project so it's not going to cause problems in the future anymore.

I proposed to update the commons-io dependency in exemplar to the latest version here: https://github.com/gradle/exemplar/pull/76 but the PR failed because the dependency submission action seems to be configured incorrectly 🤷‍♂️

I'm looking at the PR to upgrade vulnerable dependencies again. During the team meeting we discussed putting this into a common plugin so we can push it to all projects. I wonder now whether we should define some kind of convention on how to use the

because

method to explain why we're upgrading a dependency. It could be useful to include • which plugin defines this version constraint • what's the reason for the constraint, e.g. a reference to the CVE For example:

org.gradlex.internal.common-constraints: work around CVE-4711, CVE-4712

Otherwise when looking at a build scan it becomes quite hard to understand where and why a constraint is added to the build. How do you deal with this in larger builds?

Hey, I can't make it to the team meeting tomorrow since we're going on vacation. Next week I can only do it after lunch. Can we move next week meetings to, say 2 PM?

Hi all. I would like to join the next GradleX meeting to re-visit the question of a potential GradleX and GradleUp merger. The GradleUp project might be renamed in the coming months, and it might be a good checkpoint FTR https://gradleup.com/

Hey @Louis Jacomet @Jendrik Johannes I was able to fix the deprecation about cross project access in

maven-plugin-development

thanks to your help. Here are the details if you're curious: https://github.com/gradlex-org/maven-plugin-development/pull/289/commits/a1d34da4a44cbee2991862787973b9902bc570c1

This raises the question whether we should have all out tests test against projects with Kotlin DSL instead of Groovy DSL: https://github.com/gradlex-org/maven-plugin-development/issues/290

Hey @Jendrik Johannes @Louis Jacomet today I finally had the time to make a proposal for testing with JUnit5 / Java: https://github.com/gradlex-org/reproducible-builds/pull/15 Let me know what you think. In this PR I did not use assertJ because it did not feel necessary. If we move forward with this I think we should invest some time to create a publish a test fixture library first.

@Jendrik Johannes @Louis Jacomet there's something weird going on in the maven-plugin-development plugin repository and possibly others. In this commit I added the wrapper sha256 to the project but I made a mistake and used the checksum of the wrapper, not the distribution, see https://gradle.org/release-checksums/ What's weird is that the build does not fail locally for me and also it doesn't fail on CI. @Zongle Wang reported this here and if you follow the link to the PR, you can see that on their fork the CI build fails because of the incorrect sha sum. I've looked into this for a while now but have no clue what's going on. Any idea?

Okay, so I did another pass with the dependency verification file in reproducible builds. I think it's now at a point where dependency updates will be relatively strait forward. PTAL the this PR: https://github.com/gradlex-org/reproducible-builds/pull/23

So I've documented our process for enabling dependency verification for reproducible builds. I was wondering whether we want to roll it out to more projects.

First Maven 😱 Plugin by GradleX (based on what I published under different coordinates a few years ago) https://github.com/gradlex-org/gradle-module-metadata-maven-plugin

First renovate PR with dependency verification enabled: https://github.com/gradlex-org/reproducible-builds/pull/24 no change to the verification metadata 🙂

Hi guys, any thoughts about maintaining https://github.com/bmuschko/gradle-docker-plugin as part of gradlex-org?

We decided at some point to pin actions only to their major version. However that makes us vulnerable to attacks like this one https://semgrep.dev/blog/2025/popular-github-action-tj-actionschanged-files-is-compromised/ I think we should reconsider our decision and maybe move to git hash based pinning of actions. Since this attack was about setting an existing tag to a compromised commit, we can prevent that when we pin to hashes. We can use renovate to update hashes.