Hello! I will setup and announce the channel within a few days, but you can start documenting it in your plugins and inviting friends 😄

🎉

Added the Slack channel to the site: https://github.com/GradleUp/gradleup.github.io/pull/13

set the channel description: GradleUp is an umbrella GitHub organization focusing on simplifying Java, Kotlin and Android development with Gradle. On our menu: Gradle plugins, developer tools and best practices. More info: https://gradleup.com/

For the site, I plan to detach the blog engine and to drop my current text. I am still not sure whether we want a standalone engine, or maybe it is better to just have a dev.to org (or so). Cc @Martin as the most active writer

IMHO https://github.com/GradleUp/shadow/releases/tag/8.3.0 should have been 9.0 as a major breaking change. Would we be interested in documenting SemVer as a recommended versioning strategy for GradleUp components?

Would it make sense to add GradleUp to https://community.gradle.org/events/hacktoberfest/2024/? We have quite a lot of the open issues across active repos, and many active maintainers, so maybe it could boost contributions

🧵 We got new default issue templates for the org. I hope they are not too wordy, any feedback is appreciated

And we're live! 🐘 🎈 https://blog.gradleup.com/whats-up-gradleup

How can I shadow a subproject targeting JVM 21 in the root project targeting JVM 17?

Dependency resolution is looking for a library compatible with JVM runtime version 17, but 'project :*****:fancy-mod-loader' is only compatible with JVM runtime version 21 or newer.

Hi i currently maintain ktlint-gradle with @Jonathan Leitschuh. We are considering moving under an org with ktlint, but if that doesn't work out, this will be my next plan

Working on a better Dev Container for Gradle development and GitHub Actions steps 🤓

So, the problem of jgit by default forking, while overriding that behavior requires modifying a mutable static variable... I'm wondering if there would be any interest in a pre-shaded upload of jgit for just this problem? so that every plugin out there that wants access to git doesn't have to do this for themselves. Possibly could include a plugin for a shared git service too. Does gradleup have any interest in this?

if you folks are interested, I'd like to move some of my plugins under gradleUp, this pair and magik

Any idea about migrating DelegatingTestRunner and related logic to Junit 5? I'm migrating Shadow to using Junit 5 https://github.com/GradleUp/shadow/blob/main/src/test/groovy/com/github/jengelman/[…]s/shadow/docs/internal/snippets/junit/DelegatingTestRunner.java

@Giuseppe Barbieri For "Github International", is there a special meaning for that? Or should it be something like "Turn your GitHub into a Maven repo with some MAGIK (MAven repository on GitHub, written In Kotlin)"

Out of curiosity, does the adoption of https://github.com/GradleUp/shadow have any impact on the future of https://github.com/GradleUp/gr8? Like, will Gr8 be replaced with an alternative implementation that uses Shadow instead of R8, or will Gr8 continue to be maintained?

Welcome to review https://github.com/GradleUp/shadow/pull/1012.

This message was deleted.

maybe not appropriate for this channel, but is it time for us to migrate to a gradleup shadow release? not certain on the state...

Welcome to review - https://github.com/GradleUp/shadow/pull/1044 - https://github.com/GradleUp/shadow/pull/1036

It's out here https://github.com/GradleUp/shadow/releases/tag/9.0.0-beta1

hopefully this is an ok place to ask questions about gradleup plugins. I have plugin semver (which is not libs.semver, it's the project that contains the code below) which is consuming my git plugin. My git plugin depends on jgit and exposes it as api (which is naughty so has to be shaded). when I configure my shadeded dependencies like this, both the git plugin and jgit are being shaded into the semver plugin which I don't want. The git plugin on the other hand should be shading jgit. [semver plugin & guava] -> [git plugin & jgit]

dependencies {
  api(libs.semver)
  api(projects.git)
  compileOnlyApi(libs.jspecify)
  implementation(libs.commons.lang)
  implementation(libs.guava)
  implementation(libs.java.tools)
  implementation(libs.vavr)
  shadow(libs.jspecify)
  shadow(libs.semver)
  shadow(libs.vavr)
  shadow(projects.git)
}

tasks.withType<ShadowJar>().configureEach {
  archiveClassifier.set("")
  relocate("com.google.common", "com.xenoterracide.gradle.semver.guava")
  relocate("com.xenoterracide.tools.java", "com.xenoterracide.tools.java")
  dependencies {
    exclude { it.moduleGroup == "io.vavr" }
    exclude { it.moduleGroup == "org.jspecify" }
    exclude { it.moduleGroup == "org.slf4j" }
    exclude { it.moduleName == "com.xenoterracide.gradle.git" }
    exclude { it.moduleName == "semver4j" }
  }
  minimize()
}

hey, small bit of feedback for the website. The GUP! logo on the homepage is pretty low res and looks grainy. It'd be nice to make it an SVG, so it looks more professional?

hey, I have a library request. KGP recently added a util for helping write Gradle Plugin integration tests using the Kotlin DSL. https://github.com/JetBrains/kotlin/tree/1d06a898db8f1e1616c1b733db0f3efbfe8647ba/libraries/tools/kotlin-gradle-plugin-integration-tests#-buildgradlekts-injections-from-main-test-code Instead of having to create a

build.gradle.kts

file for tests and then manipulate the file via string processing (which is difficult, hard to understand, lacking IDE support), you can instead create or modify a build script directly in the

@Test

function. Tests can also extract info out from the build script (much better than having to log information and then parse it!), and are debuggable. It could be extracted into a separate library so we can use it in any Gradle plugin.

I'm trying to use https://github.com/GradleUp/gr8 first time, but I'm running into an R8 "CIRCULAR REFERENCE"

RuntimeException

(stacktrace in thread). Any hints?

Forwarding from #C06T03MSEAX, as I believe #C07GJEMUZDH could be a better fit.