set the channel description: Gradle-related jokes, memes, puns, etc. It is fine to be sarcastic too, but please respect the code of conduct!,

set the channel topic: Joke&Learn about the Gradle Build Tool

This is what I learned yesterday too, when doing my Java Infra as Code workshop :)

We need more fun here 🙂

fun

fun with flags

April 1st approaching 😄 👀

TIL: A meme maker, built with Gradle - https://github.com/theapache64/gh-meme-maker

Building an old Gradle project with Jenkins, configured with Pipeline and system scripts

Cuz trends gradlephant

Spotted @no frying something on the laptop. I guess he just ran Android Studio there, looks legit 😂🍳

Best plugin for Gradle sync in Android Studio https://plugins.jetbrains.com/plugin/24613-pedro-progress-bar

image.png

HELP. I AM STUCK IN A LOOP!

> A problem was found with the configuration of BuildResultFlowAction.Parameters.
      > Type 'buildlog.BuildResultFlowAction.Parameters' property 'toFileLoggingListener' has @ServiceReference annotation used on property of type 'buildlog.ToFileLoggingListener' which is not a build service implementation.
        
        Reason: A property annotated with @ServiceReference must be of a type that implements 'org.gradle.api.services.BuildService'.
        
        Possible solutions:
          1. Make 'buildlog.ToFileLoggingListener' implement 'org.gradle.api.services.BuildService'.
          2. Replace the @ServiceReference annotation on 'toFileLoggingListener' with @Internal and assign a value of type 'buildlog.ToFileLoggingListener' explicitly.

Lets do (2)

> A problem was found with the configuration of BuildResultFlowAction.Parameters.
      > Type '.buildlog.BuildResultFlowAction.Parameters' property 'toFileLoggingListener' is annotated with invalid property type @Internal.
        
        Reason: The '@Internal' annotation cannot be used in this context.
        
        Possible solutions:
          1. Remove the property.
          2. Use a different annotation, e.g one of @Inject, @Input or @ServiceReference.

Lets do (2) (although 1 is tempting --> just remove and give up 😄 )

> A problem was found with the configuration of BuildResultFlowAction.Parameters.
      > Type 'buildlog.BuildResultFlowAction.Parameters' property 'toFileLoggingListener' has @ServiceReference annotation used on property of type 'buildlog.ToFileLoggingListener' which is not a build service implementation.
        
        Reason: A property annotated with @ServiceReference must be of a type that implements 'org.gradle.api.services.BuildService'.
        
        Possible solutions:
          1. Make 'buildlog.ToFileLoggingListener' implement 'org.gradle.api.services.BuildService'.
          2. Replace the @ServiceReference annotation on 'toFileLoggingListener' with @Internal and assign a value of type 'buildlog.ToFileLoggingListener' explicitly.

............

hello - I was having some issues with hilt / workers and the famous no such method error, lead me down a rabbit hole that kind of made me want to face my fears a little in android. I find like I don't really understand generally gradle, plugins, apply, etc and tyring to find a resource that might be interesting/helpful in breaking down those things to increase understanding/expertise and reduce what im assuming are tons of unused resources and stuff in there thats not scoped properly etc and just be better in general at working in that area. Our work around ended up creating our own factory and not using the one that should be free from hilt worker....