From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

This is not enough information to even start helping you. But, it looks like you might have some issues connecting to your remote repository.

i tried gradle online and offline via toggle offline mode and invalidates catches in android studio but still i am getting this error.

<@URQ797WRW> i have just shared One Screen shot so could you please go through it and help me ??

have you verified that the dependency you’re looking for is actually available in the repository (jitpack)?

It is, but it is somewhat broken.
But well, JitPack is a broken-by-design service anyway.

But in this concrete case, your build searches for a `jar` when only an `aar` was built: <https://jitpack.io/com/github/agorabuilder/rtm-sdk/1.4.9/build.log>
And even if it would search for an `aar`, it is actually not present: <https://jitpack.io/com/github/agorabuilder/rtm-sdk/1.4.9>

so for this should i change the sdk version or anything else ?

How should that help if the repository does neither contain a jar, nor an aar?
Besides that you maybe better ask someone who is familiar with android development.

yup... but same code working in my other teammate system and i face this issue

Maybe he has the dependency cached and that's why it works, while JitPack is broken, which is not very unlikely.
Make him try with `--refresh-dependencies` and see whether it still works for him.

it's not regarding jitpack , jar and aar , The issue was something else but thanx for your support

Why are you asking in the Gradle community slack? I don't see any Gradle problem. Something is wrong with your Android values file. Maybe better ask in some Android community. Or scroll up to maybe see a more detailed error message

You are probably running Gradle with java 8, and the plugins are compiled for Java 11.

you can run `gradle wrapper` in any (even empty) project and copy it over if your current project has configuration issues

but if you can find out which plugins are requiring Java 11, maybe complain to them? Gradle still supports running on Java 8 and ideally so should plugins

Some indeed do not and for some it also seems ok. grgit plugin for example, because it uses a recent version of JGit which also just supports Java 11 now.
But for most plugins it would be nice if they supported Java 8, yes.

Right, in my case it was for quarkus which supports Java 11.. so I'm not sure this would be useful 

For such things I usually have in the task class a
```@Optional
@InputFiles```
getter that calculates the dependencies from the input file and returns the files. If the calculation is really triggered multiple times (don't remember right now) you could add a simple hash based cache.

This way it is calculated as late as possible, only when someone actually needs the information.

Thanks for the quick answer.
Regarding the cache: that sounds like a good idea to prevent multiple calls to the file-reading logic.
But I do not think that the annotated getter solves the main problem that the file-reading logic is triggered in the configuration phase. Indeed it seems to behave the same as registering the transitive files lazily from within the constructor, meaning that the input-file still will be evaluated in the configuration phase (probably due to implict-dependency calculation) and not only for up-to-date-checks right before executing the task.
Here a small example how the getter looks like together with the input file property:
```    @InputFile
    @PathSensitive(PathSensitivity.NAME_ONLY)
    public Provider&lt;Path&gt; getInputFile() {
        return this.inputFile;
    }

    public void setInputFile(final Path inputFile) {
        this.inputFile.set(inputFile);
    }

    @Optional
    @InputFiles
    public Provider&lt;ConfigurableFileCollection&gt; getAdditionalInput() {
        return this.inputFile.map(inputFile -&gt; {
            final List&lt;Path&gt; calculatedAdditionalPaths = new ArrayList&lt;&gt;();
            // read additional input paths from inputFile
            System.out.println("-&gt; Calculation called");
            return getProject().files(calculatedAdditionalPaths);
        });
    }```
The output of the project configuration:
```...
All projects evaluated.
Selected primary task 'build' from project :
-&gt; Calculation called 
Tasks to be executed: ...```
I also tried it in a non-lazy fashion, but there was no difference.

Do you maybe know how to avoid that call of the getter during configuration phase?

I don't remember when Gradle queries them.
But your getter is only executed when someone needs the input files.
Where the call comes from you can easily find out by setting a breakpoint in your getter and look at the stacktrace.

Yes, its queried by the TaskDependencyResolver, that I already knew, but I try to exclude the calculation from that query somehow, because I know that the task has no implicit dependency to another tasks output (at least for that property), because I calculate that input myself. I only want that input to be considered during up-to-date checks.

I'm not sure, but I don't think you can influence that except maybe with really dirty hacks like looking at the execution stack.
But why do you actually care, especially when you do the caching thing?
Also isn't the task dependency resolver just quering the inputs if the task is in the execution plan already, so the inputs need to be queried anyway?

Yes, that's true, it is only querying them if it's in the execution plan, therefore it may indeed be an acceptable solution. The only disadvantage I can think of then is that a dry-run might be slower, because of the file-evaluation which is triggered. But I guess that's something I can live with.
Thanks for the support.

We use our custom distribution in combination with buildSrc without a problem. :thinking_face:

ok thanks, at least i have confirmation that it _should_ work now

not aware of any way to prevent buildSrc - it’s a built-in, implicit project.

yeah. I am trying an includeBuild as well and it still not working. something weird must be going on. im on gradle 6.9.2, so maybe thats part of it

i have a plugin declared in buildSrc / included build, and I can't import it in my main build.gradle, nor can I apply it via plugin ID. I also noticed with the included build, that it evaluates _after_ the regular subprojects. when I upgrade to gradle 7, it looks like it switches and properly evaluates the included build first (I am using `includeBuild` in the `pluginManagement` block

ok back on gradle 6.9.2  (not custom) and buildSrc, I got everything to work

Not sure if it's related, but I just reported <https://youtrack.jetbrains.com/issue/IDEA-293734/IDEA-runs-Gradle-Sync-for-buildSrc-for-on-the-wrong-daemon-when-|this> to IDEA team

For us, `init.d` scripts defined in a Custom Distribution are not run when running Gradle sync `buildSrc:prepareKotlinBuildScriptModel`, if there is already a "regular" (not customized) daemon running for the same Gradle version

Could you still supply the output?
That you don't see more useful information doesn't mean someone else also does not see useful information. :wink:
Can you m3aybe even provide a build scan?

Hm, if the stacktrace of the NPE really is missing, that reminds me about the strange feature to omit stacktraces in certain situations.
Try to add `-XX:-OmitStackTraceInFastThrow` to the daemon args to get it back if that is really that thing I remember.

Thanks, indeed with the option I get a stacktrace for the NPE:
```Caused by: java.lang.NullPointerException
        at org.gradle.api.internal.artifacts.dependencies.DefaultImmutableVersionConstraint.of(DefaultImmutableVersionConstraint.java:118)
        at org.gradle.internal.component.external.model.DefaultModuleComponentSelector.newSelector(DefaultModuleComponentSelector.java:172)
...```
Also I managed to attach a debugger to the build and caught the NPE, turns out I had a typo in the platform definition
```api("org.apache.xmlgraphics:batik-transcoder.1.14")
vs.
api("org.apache.xmlgraphics:batik-transcoder:1.14")```
Correcting that it works just fine :tada:
Thanks for the pointers :pray:

yw, but you should probably nevertheless report it.
Imho every  NPE is a bug.
 A message "cannot parse 'org.apache.xmlgraphics:batik-transcoder.1.14'" or whatever would have been much more helpful :-)

You're right, of course :wink: filed <https://github.com/gradle/gradle/issues/20527>

Wasn't it `jvmArgs("-Dbinding.${binding.get()}=true")`?

Or actually what you really want `systemProperty("binding.${binding.get()}", "true")`

Any `allprojects { ... }` and `subprojects { ... }` block introduces project coupling and should be avoided where possible.

The simple truth is, that you shouldn't do it.
Whenever you inject configuration from outside, you maybe introduce coupling and for sure make the build logic intransparent.

The most idiomatic way is, that you have a convention plugin that all projects apply or that all other convention plugins apply and apply your plugin there.

Is that generally true even for the root project?  The config-on-demand docs state:
```. Coupling of the root project to subprojects does not impact configuration on-demand, but using the allprojects and subprojects in any subproject's build.gradle file will have an impact.```

I'm trying to divine what the boundaries of this space are. :slightly_smiling_face:

It definitely introduces coupling.
It might not be a problem if the root project is always configued and configured first.
But even if it would work, it still makes the build less transparent.

No, that's just a 10 years old dump that guy imported to GitHub, not the official project. The official project is maintained and even used in Java itself: <https://asm.ow2.io/|https://asm.ow2.io/>

<https://gitlab.ow2.org/asm/asm> perfect ! TU <@URQ797WRW>

After some manual tests (without Gradle), the problem seems to be solved if the directory containing the class files compiled from scala sources is added to the "--patch-module sosl=..." directive. Gradle does not do it by itself. How do I modify my build script to add it?

Do you hard require that the tests run with JPMS?
Iirc, if you don't have a `module-info.java` in the tests I think they should run on the class path and thus not require the modules to be together.

The main/java does contain a file module-info.java but not scala/main (should it also have a module-info.java file even if I want those java and scala code to be in the same module?). test/antlr and test/java do not contain module-info.java files

No, it should not have one.
Hm, I thought if `test/java` does not contain one the tests are run on the class path and thus modules should not be relevant

I agree and code generated from Java sources or ANTLR sources seem to be fine (JUnit runs find them) but not code générated form scala sources

tmpJUnit.sh

I'm experimenting with the attached bash script (an adapted copy of the command rum by Gradle) to see what minimal command find the scala classes.

Still I was correct, if you don't have a `module-info.java` in the `src/test/java` it should not run on the module path but on the class path as documented here: <https://docs.gradle.org/current/userguide/java_testing.html#sec:java_testing_modular>
If this is no longer the case it is probably a regression and you should report it.

What's the recommended way to report a bug/regression?

Open the issue tracker and click "New issue"?

<https://github.com/gradle/gradle/issues/>

If I run `./gradlew test` the production Java code does not even compile

On my computer `./gradlew clean test` compiles (there are some code quality warning warnings so) and fails at task ":Core:test". What special setting could I have ?

I don't know, your build is probably not properly configured

`./gradlew --version` returns "Gradle 7.4.2"

Right, I'm working on the modularization branch `git clone --branch Modularization <https://gitlab.com/sosl/sosl.git>` (which was created a bit late and is expected to replace master)

Yes you said that initially, that is what I have checked out

I did a fresh clone of that branch and `./gradlew clean test` compiles and only fails on task ":Core:Test". I do not see what to test that would be specific to my system. Any idea?

Besides that you shouldn't always use `clean`, this is Gradle, not Maven where it was more or less mandatory to get reliable buils, I have no idea.

I'm on Windows unfortunately.
Somehow the compile classpath is fucked up:
```--class-path D:\Sourcecode\other\others\sosl\Core\build\classes\java\main:D:\Sourcecode\other\others\sosl\Core\build\classes\scala\main:D:\Sourcecode\other\others\sosl\Core\build\resources\main:D:\Sourcecode\other\others\sosl\Core\build\classes\java\test:D:\Sourcecode\other\others\sosl\Core\build\classes\scala\test:D:\Sourcecode\other\others\sosl\Core\build\resources\test```
It does not use the proper path separator

Yeah, you are blindly destroying this in `buildSrc`

If you need such strange manipulations, at least use `File.pathSeparator` instead of a hard-coded `':'`

And you also have hard-coded paths at certain places like:
```--class-path /home/gleguern/office/atelier[...]```

Sorry for the mess. The build is a bit out of shape now as I am testing various solutions to fix it. I should have cleaned it up before asking for help. I'll do that now.

With regard to the root problem, my current guess is that Gradle moved to a different solution for whitebox testing (based on reads and opens JPMS arguments) which is not compatible with the fact that scala does not put its compiled class files in the same root directory as Java (ANTLR put them in the same root directory). I'll investigate if that is due to my build setting or the defaults.

It is the default and it must be like that

ANTLR doe snot put its class files anywhere as it does not generate class files

It generates Java source files and you most probably configured the generated directory as Java source directory

That way the java compile task compiles them along into the same directory

The scala compile task is a totally different task though and it is a horrible failure if different tasks share output directories

As you can see from the docs I linked you to, the white-box testing should still be done that way, unless the docs have a bug.
The question is why your tests are not run on the class path but on the module path.
But my first guess would actually be that you misconfigured something somewhere.
Maybe you should try to make a small MCVE. Often that helps to find the home-made problem, and if not, it is good to have one to report the upstream problem anyway.

I did an MCVE (`git clone --branch JPMS <https://gitlab.com/mko-mcve/mcve-gradle-junit-scala-jpms.git>`). There is indeed probably something broken in my build. There are however 2 points that were "incorrectly" handled by Gradle natively: inverting the dependency between scala and java sources; adding the scala classes to the classpath and "reading" them. Plus a non-obvious constraint of not sharing packages between java and scala which is linked to the fact that scala and java classes are not in the same repository.

In that MCVE, I wrote a dirty hack in "fix.java-depends-on-scala.gradle" to invert the native Gradle dependency from Scala sources to Java Sources. Is there a proper/clean way to invert that dependency without creating a circular dependency?

Regarding `conf.java-depends-on-scala.gradle`, actually everytime you write `dependsOn` you are doing something wrong, or at least it is a code smell.
Explicit task dependencies via `dependsOn` are almost always just a work-around or at least non-idiomatic.
It is always better to for example configure outputs of one task as inputs for another task and get implicit task dependencies or similar.

In case of language dependencies / order, the plugins by default just assume a certain order / dependency direction,
in the common convention-over-configuration tactic of Gradle, nothing "to be fixed" there.
But the documentation also shows how to chang this order properly at <https://docs.gradle.org/current/userguide/building_java_projects.html#sub:compile_deps_jvm_lang>
You actually almost got it properly, you just make an unnecessary filecollection of a filecollection, it works properly, it is just unnecessary.

Regarding "Do not declare Scala and Java sources in the same packages" and `fix.jpms.gradle`, both is totally unnecessary if you do JPMS properly.
What you need is javac argument `--patch-module mcve.gradle_junit_scala_jpms=${sourceSets.main.scala.classesDirectory.get()}` so that the classes already compiled from Scala
are seen by the compiler as part of the module, this way it even works when the Java and Scala classes are in the same package.
Btw. the project as is does not compile here, with replacing the whole `fix.jpms.gradle` with just adding the `--patch-module` it compiles and even works if I put the Scala file to the same package as the Java file.

Thanks for the help. I finally got the MCVE (<https://gitlab.com/mko-mcve/mcve-gradle-junit-scala-jpms/-/tree/JPMS>) working properly in a 'clean' and 'automated' way.

if you have `src/main/java/module-info.java` then I think it'll force using JARs (but this has other effects as well)

Have you tried using something like:
```implementation(projects.b) {
    attributes { 
        attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, objects.named(LibraryElements.JAR))
    }
}```

Oh! I don't really know what the above does, I guess there is some mechanism by which I tag an artifact with attributes and so on? Quite interesting

In any case it does do what I want yes. I had to change objects.named(LibraryElements.JAR) to objects.named(LibraryElements, LibraryElements.JAR) to make it work.

I see there is documentation on this stuff so I will go have a read, thanks!

Ah, indeed, if you're using the Groovy DSL; `objects.named(LibraryElements.JAR)` is Kotlin.
As for the documentation, it's <https://docs.gradle.org/current/userguide/variant_model.html#sec:variant-aware-matching|here> and <https://docs.gradle.org/current/userguide/variant_attributes.html#sec:standard_attributes|here>. You can run `./gradlew :b:outgointVariants` to see the variants of project B, and then choose the appropriate attribute to alter the variant selection (in this case, per dependency, rather than per-configuration as it's emphasized in the docs)

I'd say go check out the link in the output and see if everything is set up. However, off the top of my head:
1. Make sure JAVA_HOME is setup directly. Since you're on Windows, Java versions can get funky - just make sure the OS is using the same version as Android Studio (unless you have other Java projects on your system)
2. Check to make sure ANDROID_SDK_ROOT is set properly in your environment variables as well.
3. Try to just cd into the Android folder and run Gradlew clean - the error may be more...useful.

Updated variables for a bunch of other stuff: <https://stackoverflow.com/a/46976475>
AVD may also be the issue here

As the error is a failure to load a class from the Kotlin Gradle plugin, I highly doubt it has anything to do with the Android SDK. Can you provide a build scan?

That's very fair, I'm just used to all sorts of weird results if SDK version are off :stuck_out_tongue: could be a Kotlin version issue, maybe?

Android doesn't use the `java` plugin and doesn't support the additional configurations for aggregate results

Does it mean I can’t use the jacoco report aggregation plugin for Android?

It isn't compatible: <https://github.com/gradle/gradle/issues/20375> cc <@U02AA235DGC>

This will be clarified in the plugin docs in version 7.5.  It looks like we ought to add the same note to each of the aggregation samples as well to avoid this confusion.  I’ll update them.  Thanks, <@UFDR8S97S>.

What is the suggested way of aggregating JaCoCo reports on Android projects using Gradle 7.4+?

it seems Android does not have a supported way. <https://issuetracker.google.com/issues/63481478|https://issuetracker.google.com/issues/63481478>

So I’ll give a try to <https://github.com/Kotlin/kotlinx-kover>

We've raised this with the google team. Please star this bug to follow the feature request: <https://issuetracker.google.com/issues/230818184>

It's a warning, not an error. It isn't stopping your build working. 

If you follow the instructions in the message it will tell you what needs to change before you upgrade to Gradle 8 (which hasn't been released yet). 

I tried something like that before and found that `all`/`whenObjectAdded` callbacks are executed with unconfigured object when it's added but before configure action from `create`/`register` is executed. You could overcome it by extending container and overriding one or two methods but it's a bit conterintuitive.
Another approach is to provide your own method on extension which will add to the container and execute provided configuration callback and only then execute your code to consume configured object in the container. It seems the most robust approach or so it seems.

like this?
```fun add(name: String, config: Action&lt;MyType&gt;) {
    container.add(objects.newInstance(MyType::class, name).apply { config() })
}```
will depend on the container… but it could work

I'm not sure if it's exact issue that you have but callback stacking is thing-in-itself

I could try to find my code tomorrow if you're interested, I'm half asleep right now =(

I'm definitely interested in finding the most intuitive and maintainable solution to this problem! Thank you.

I find this Gradle behavior very weird

the trick of using the object factory, configuring the object, and then adding it to the container, works

Assuming `doThing()` is a piece of default configuration logic - my go to solution is using properties all the way through in my custom extensions.
This allows for lazily providing configuration values based on other extension properties.

Something like:
```open class MyType (private val theName, objects: ObjectFactory ) : Named {

  val isTrue = objects.property&lt;Boolean&gt;().convention(false)
  val theThing = objects.property&lt;String&gt;().convention(isTrue.map { if (it) ... })
}```
However, properties can be a bit weird to handle for plugin users, as you can't simply use the `isTrue = false` syntax.
Because of this I tend to have the property as an internal which is then augmented by custom get/set to provide the interface for plugin users.

Like
```open class MyType (private val theName, objects: ObjectFactory ) : Named {

  var isTrue: Boolean
        get() = _isTrue.get()
        set(value) = _isTrue.set(value)
  internal val _isTrue = objects.property&lt;Boolean&gt;().convention(false)
  ...
}```

There was an amazing explanation posted a while back, see <https://gradle-community.slack.com/archives/CA7UM03V3/p1638287538164300|[0]> and <https://gradle-community.slack.com/archives/CA7UM03V3/p1638287538164300|[1]>

the issue is that `doThing()` registers a task. So if `ifTrue` is false, no tasks get registered. If true, they're registered. So I can't just keep pushing things down with properties

Is registering the task in any case and running it only if the extension property is true an option?
If not, then indeed `afterEvaluate`  seems the most logical/understandable place to me...

yeah, registering all with a task and then using `onlyIf` to run it only when a property is true would seem to be the sanest solution to me

I think avoiding registering a task that won't be used is a reasonable goal

reasonable goal it may be, but it's not achievable cleanly (IMO)

this seems clean enough to me
```val c = objects.newInstance(MyType::class.java, name).apply {
    config.execute(this)
}
container.add(c)```
:shrug:

you don't *know* that the collection uses the same instantiator, and it violates the expectation that `container.create("foo") { container["foo"]!! }` exists. although perhaps neither is important to you

I agree it's a fair point. This is a small project, though, and we can test to verify the functional requirements. I'd rather Gradle create an option to let us say "run the creation config immediately, that's why I used `create` _after all_", but who knows when or if that will ever happen

I also wonder if I could do this somehow with a custom factory, and there _is_ already an API for that, but it seems even more cumbersome / less maintainable

I looked through my code and that version was not committed, so no link to repo.

Basically `create(String,Action)` and `register(String,Action)` have different behavior for observer using `whenObjectAdded`/`all`.
• `create` instantiates object, adds to collection (and `all`/`whenObjectAdded` callbacks are called) and only then executes `Action` passed to callback. 
• `register` does opposite when realized, it instantiates object, executes passed `Action` (possibly decorated by `CollectionCallbackActionDecorator` which isn't applied to `create` AFAIK) and only then it is passed to `all`/`whenObjectAdded`.
So I just override `create(String,Action)` when extend `AbstractNamedDomainObjectContainer` with one that has `add` and `configureAction.execute(object)` swapped. Original funtion: <https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/AbstractNamedDomainObjectContainer.java#L79-L80>

ah, create/register differentiation strike again. How bizarre

yeah, I was quite surprised when found it

I never liked that combination of ordering for `create` on containers. I agree that it would be more natural to have the creation configuration to run first before adding to the container.
However it has been like that for ages.

But learning that `register` is different is concerning. I’ll raise that internally once more.

But to change behaviour in register too would be a breaking change. Idea about strict mode looks better with each version)

I'd prefer they change `create()`. Maybe we can get that for Gradle 8 :pray:

Changing is really unlikely given the history. However pushing forward to deprecate then remove `create` and keep the behavior of `register` sounds like a good plan. 

if you're going to make your own container, wouldn't it be more consistent to override `create(name, action) = register(name, action).get()`?

in this context, if I used `register`, would `all` still cause all elements of the container to be realized? In the current situation, I need those elements available during project configuration

`all` should realize all objects in the container, yeah. When I wanted to create tasks lazily based on items in the custom container I just registered tasks based on object names and used actual object from the container on demand in configureAction.

```// build.gradle.kts
abstract class Foo : Named
val foos = container(Foo::class)
foos.all { println("foos.all($name)") }
foos.register("bar") { println("foos.register($name)") }```
prints
```# ./gradlew
foos.all(bar)
foos.register(bar)```
for me (Gradle 7.4.2)

Yeah, name added anyway. If you add some property to `Foo` and set it in register's configureAction vs same with create difference should become apparent

So <@U019L3NM4PK> is right, there is no difference.
Actions registered on the container with `all` are executed before the configuration action for both `create` and `register`.

<@UJUMPU407> Would you be able to share a reproducer of what you did to see a difference?

With the following in a `java` project:
```configurations.all {
    println("Configuration ${this.name} can be resolved ${this.isCanBeResolved()}")
}

configurations.register("testFoo") {
    setCanBeResolved(false)
}```
it prints
&gt; Configuration testFoo can be resolved true

Changing the `all` to `configureEach` results in the same output.
Moving the action to after the `register` changes the output since it is happening _after_.

<@UAB9WQKJ4>, I'll try to find where I got bitten by it and create a reproducer.

This is a Gradle support forum, not Postgres.

You can probably have a look at the implementation of the `dependencies` task.

Thanks, `dependencies`  task uses `configuration.incoming.resolutionResult`  - using that I can get to the imported BOMs of my platform.
Potentially I could now recurse into them by using another detached configuration.

However, whats stopping me, is that I can't figure how to access the version constraints listed in a BOM itself

I don't think you need another detached configuration and I repeat my recommendation.
Look at the implementation of the `dependencies` task.
If you look at the result, you see that it shows the full tree and shows all the constraints (the lines with `(c)` in the end).
And I don't think the task makes several resolutions.

Btw. alternatively you could also publish a version catalog for the end users.
Then they can import that version catalog and just use the accessors.
Then they don't need to care whether the version catalog contains a version for that dependency or not.

I don't quite know if I am looking at this right - but to me it seems the `dependencies` tasks lists only constraints on the _actual_ dependencies of a project.

However, I want to list _all potential_ constraints of the platform the project is using.
For instance my platform is importing spring-boot-bom, cxf-bom and a few more, that's hundreds of potential dependencies which are version managed.

I'll have a look at version catalogs, although judging from <https://docs.gradle.org/current/userguide/platforms.html#sub:platforms-vs-catalog> a platform is what I really want.

You can have both. A platform that controls the dependency versions, also transitively and a version catalog they can use to declare dependencies.
That way they don't need to look up which dependencies are version controlled or not, they can simply use the accessors.

Hm, regarding the dependencies task you seem to be right.
I thought all are shown, but it indeed seems to only list the used ones.
But I'd expect the information to still be there and accessible programmatically.
But I might be wrong.

FindManagedDependenciesTask.kt

Yeah, the info has to be in there somewhere :slightly_smiling_face:
For the time being I hacked together a brutish solution which resolves the actual Maven BOMs involved and XML-parses them to extract the information.

The user can then do:
```&gt; gradlew findManaged --query=jakarta
Configuration on demand is an incubating feature.

&gt; Task :findManagedDependency
--&gt; Suche nach Dependency mit: jakarta
jakarta.inject:jakarta.inject-api:1.0.5 -&gt; use: implementation("jakarta.inject:jakarta.inject-api")
jakarta.jws:jakarta.jws-api:2.1.0 -&gt; use: implementation("jakarta.jws:jakarta.jws-api")
org.glassfish:jakarta.el:3.0.4 -&gt; use: implementation("org.glassfish:jakarta.el")
...```

regarding version catalogs, I'll look into them, though I am not quite sure how to maintain them for the 1500+ dependencies managed by the platform without going insane.

I probaby have used an artifact resolution query and a POM parser for that.
Similar to how I search for  jdk-activated profiles in Maven POMs that add dependencies to then do the needed fixups in the settings script.
I'll probably make a plugin out of it, but if you're interseted or want to adapt for your use-case:
```    val checkForJdkActivatedProfiles by tasks.registering {
        doLast {
            val pomReader = MavenXpp3Reader()
    
            fun collectAncestorPoms(pom: ResolvedArtifactResult, result: MutableList&lt;ResolvedArtifactResult&gt;) {
                val parent = FileReader(pom.file)
                    .use { pomReader.read(it) }
                    .parent
                if (parent != null) {
                    val parentPom = dependencies
                        .createArtifactResolutionQuery()
                        .forModule(parent.groupId, parent.artifactId, parent.version)
                        .withArtifacts(MavenModule::class.java, MavenPomArtifact::class.java)
                        .execute()
                        .resolvedComponents
                        .asSequence()
                        .flatMap { it.getArtifacts(MavenPomArtifact::class.java).asSequence() }
                        .filterIsInstance&lt;ResolvedArtifactResult&gt;()
                        .single()
                    result.add(parentPom)
                    collectAncestorPoms(parentPom, result)
                }
            }
    
            dependencies
                .createArtifactResolutionQuery()
                .forComponents(configurations.filter { it.isCanBeResolved }.flatMap { configuration -&gt;
                    configuration.incoming.resolutionResult.allDependencies.mapNotNull {
                        (it as? ResolvedDependencyResult)?.selected?.id
                    }
                }.distinct())
                .withArtifacts(MavenModule::class.java, MavenPomArtifact::class.java)
                .execute()
                .resolvedComponents
                .asSequence()
                .flatMap { it.getArtifacts(MavenPomArtifact::class.java).asSequence() }
                .filterIsInstance&lt;ResolvedArtifactResult&gt;()
                .map { pom -&gt;
                    val ancestorPoms = mutableListOf&lt;ResolvedArtifactResult&gt;()
                    collectAncestorPoms(pom, ancestorPoms)
                    Pair(pom, ancestorPoms)
                }
                .forEach { (bottomPom, ancestorPoms) -&gt;
                    sequenceOf(bottomPom, *ancestorPoms.toTypedArray()).forEach { pom -&gt;
                        FileReader(pom.file)
                            .use { pomReader.read(it) }
                            .profiles
                            .forEach { profile -&gt;
                                if ((profile.activation?.jdk != null) &amp;&amp; (!profile.dependencies.isNullOrEmpty())) {
                                    println("jdk activated Maven profile with dependencies found in ${pom.id}")
                                    if (pom != bottomPom) {
                                        println("ancestor of dependency ${bottomPom.id}")
                                    }
                                }
                            }
                    }
                }
        }
    }```


&gt; regarding version catalogs, I'll look into them, though I am not quite sure how to maintain them for the 1500+ dependencies managed by the platform without going insane.
Well, you can generate it from the information you just extracted. :slightly_smiling_face:

:sweat_smile: indeed, thanks so far :raised_hands:

Why are you asking this in the Gradle Community Slack? I'd recommend asking in the SonarQube forums as you have a problem with the SonarQube analysis, not with Gradle.

Because it is gradle plugin and someone might face to same issue here.

It's not. It is triggered by a Gradle plugin, but it is in the actual analyzer of SonarQube. And even if it would be in the Gradle plugin, all I say is, that it is much more likely that you get help there as there the SonarQube experts and developers are present.

Checking <https://mvnrepository.com/artifact/com.android.tools.build/gradle?repo=google> it looks like that version `7.2` doesn’t exists in these repos. You can use `7.2.0-rc01` for example or latest stable `7.1.3` , but no `7.2`.

Thanks for replying sir. I did what you said now I'm getting a different error message, it says

A problem occurred configuring project ':react-native-navigation'.
&gt; It is too late to set sourceCompatibility
  It has already been read to configure this project.
  Consider either moving this call to be during evaluation,
  or using the variant API.

This error says that you somewhere in your `build.gradle` build script set `sourceCompatibility` property but that is not allowed. I am not familiar with Android so that is all I know and I suggest you ask on the <#CJYS1DAP5|> channel.

It might also help if you show a part of build script that modifies  `sourceCompatibility` , with just an error message it’s difficult to see what could be the issue and it’s more of a guessing game.

Okay thank you sir! Ill look into it first

If build scans do not help, maybe the <https://github.com/gradle/gradle-profiler> can be useful

So I’ve spent quite a time combing through build scans on this. Gradle profiler isn’t an option here because the issue only manfiests itself in Jenkins, not on local. If I need to install gradle profiler in jenkins, that will take significantly more work, but we’ll see. There are two traits that I’ve been able to correlate so far:
• Number of tasks created during task graph calculation. The gradle docs say this is a best practice, but I’m still keeping an eye on it. 
• Time spent fingerprinting task inputs. In builds with the long task graph calculation time, I’m seeing over an hour spent on this (i assume that’s serial time, not real time). In builds with a shorter task graph calculation, I’m seeing anywhere from 30 seconds to 3 minutes spent. 

perhaps the fingerprinting is including things it shouldn’t from the CI server?  Temp files accumulating?

Oh good thinking. The amount of task inputs that are fingerprinted doesn’t seem to correlate with the serial execution time of the fingerprinting itself. I’ve also started tagging my build scans with the physical hostname to see if there’s any correlation there, and there isn’t so far.

Besides the specific gradle configuration problem, if you only face this problem on Jenkins, have you isolated what is different from the local machines that is causing this? Examples:
- Does it has less hardware available? (CPU, num of cores, memory...).
- Do you have ephemeral containers for each build or do you keep a long living one? If the latest: might your daemon be exhausted after long time running because might have some memory leaks that are forcing it to do too much garbage collection during the build?
- Other specific configuration for the agents that run your builds that might be impacting there. Like different OS or others.

There are basically 3 native support (working on bringing to only one): the old software model plugin (e.g. `cpp`, `c`,etc.), the newer plugin (e.g. `cpp-application`, `cpp-library`) and the Nokee plugin (starts with `dev.nokee.*`). Depending on what you want to do *now* the answer will be different. As the maintainer of the Nokee plugin, my preference would be those plugins but it depends on what you want to do. Please write that information in the <#CDDGUSJ7R|> channel and we can discuss more about it.

It means your are doing "something" wrong in the `android { ... }` closure. Unfortunately the error reporting there is extremely bad with Groovy DSL. One reason I exclusively use Kotlin DSL nowadays. To find the problem you needed to comment out the content and readd it line by line.

Thank you for responding. I believe my biggest issue is that I’m trying to upgrade from AGP 4.XX to 7.1.3. I think it broke a few of my packages.

It’s actually throwing that error for all the react-native packages

I uninstalled instabug-reactnative thinking that would help but it complained about the next package.

&gt; How can I switch to Kotlin DSL?
&gt; 
Basically rename the build script and append .kts and port the Groovy syntax to Kotlin syntax. But that's heavily simplified. :-D

Context - I'd like to benefit from docker layer caching for the shared caches. There's a trick you can do to get layer caching for the shared caches by copying across all the `*.gradle` etc files in one `COPY` which prevents the layer cache being invalidated unless you change one of those files:
<https://github.com/Mahoney/lidalia-shell/blob/8a1f16960ff303512d02ecc3f2caeb35ed99fae0/Dockerfile#L42-L44>

However, in order to benefit from the build cache when building locally you need to use the new `RUN --mount=type=cache,target=&lt;cache_dir&gt;` directive. If you point that at `~/.gradle/caches` then you lose all the layer caching.

GRADLE_USER_HOME <https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_environment_variables|https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_environment_variables>
-g, --gradle-user-home <https://docs.gradle.org/current/userguide/command_line_interface.html#sec:environment_options|https://docs.gradle.org/current/userguide/command_line_interface.html#sec:environment_options>

Won't that just move where the `caches` dir is?

share nothing except <https://docs.gradle.org/current/userguide/dependency_resolution.html#sub:ephemeral-ci-cache|https://docs.gradle.org/current/userguide/dependency_resolution.html#sub:ephemeral-ci-cache>

&gt; does that not accomplish what you want?
No, I don't think it does.

I'm building a multi-stage Dockerfile, so I can't mount a directory, I can only benefit from layer caching of the `/root/.gradle/caches/modules-2` directory.

I want to use the `RUN --mount=type=cache,target=&lt;cache_dir&gt;` directive so that repeat local `docker build .` calls benefit from build caching, which I think means that `&lt;cache_dir&gt;` has to be `/root/.gradle/caches` (if running `FROM` a container using the root user).

That blows away any layer cache inside `/root/.gradle/caches/modules-2`.

I might be able to benefit by running `RUN --mount=type=cache,target=/root/.gradle/caches/7.4.2` but having to duplicate the gradle version in that path is just obviously going to be a maintenance fail.

My imagination is failing me as to how unfortunately.

Not for the first time I feel like I'd really like to get a Gradle expert &amp; a Docker expert in the same room to thrash out the best way to write a multi-stage Dockerfile that builds a Gradle project efficiently both locally and on GitHub Actions or similar.

I must have spent weeks wrestling with this over the last couple of years.

&gt; My imagination is failing me as to how unfortunately.
Make a directory that you configure for that caching thing.
Move the files / directories to be cached in there.
Symlink the moved files / directories to the original places within Gradle user home

versioning depends on your needs, but it is usual to share the same version like retrofit does for example.

About hyphens, yeah, you should, I think you can even have issues with project accessor generator if you use camel case

By retrofit, you mean I could copy this:
<https://github.com/square/retrofit>

It is an example about how they are publishing a multimodule project sharing the same version and how they name their groups 

Managing different projects in the same repository is not a good idea because it means that you end up violating the package principles. The example <@U01DUV4Q882> gave (retrofit) does not violate them, because they build one project with several artifacts/modules but they always go together. Based on your project description it does not sound as if these libraries have the same lifecycle, thus, they should be packaged and released separately.

This has nothing to do with Gradle, as Gradle will happily violate the packaging principles (it is not the build tools place to have an opinion on this, and there can be good reasons to violate them [e.g. monorepos where packages are ever only used as latest]).

The Wikipedia article is a little thin on this matter, but still a starting point: <https://en.wikipedia.org/wiki/Package_principles>

These repos are generally used together, in various small groupings, or all together.

If they go together then managing them together is of course the best course of action, and also exactly what the package principles want us to do. You should then also definitely version them together and put them in the same group. Also check out <https://docs.gradle.org/current/userguide/platforms.html> (aka. BOMs in the Maven world) to ensure that they are always aligned to each other. This will also allow users to use the platform and specify the version once for all dependencies, instead of individually:
```dependencies {
  implementation(platform("glen-petersons-awesome-libs:platform:1.2.3"))
  implementation("glen-ptersons-awesome-libs:a")
  implementation("glen-ptersons-awesome-libs:b")
  implementation("glen-ptersons-awesome-libs:c")
}```
Do not forget to reference the platform in each library to ensure that they always align with each other, so that if a user does the following everything still works as expected:
```dependencies {
  implementation("glen-ptersons-awesome-libs:a:1.0.0") // references glen-petersons-awesome-libs:platform:1.0.0
  implementation("glen-ptersons-awesome-libs:b:2.0.0") // references glen-petersons-awesome-libs:platform:2.0.0
  implementation("glen-ptersons-awesome-libs:c:3.0.0") // references glen-petersons-awesome-libs:platform:3.0.0
}```
This forces Gradle to use `3.0.0` for all of them.

Spring and Spring Boot are also good examples of projects where all of this is done right. :slightly_smiling_face:

short answer: yes. there's really no such thing as a lazy configuration right now.

But there is probably no problem with using `configureEach` either, it should currently just work the same. And when the configurations are changed to being used lazily eventually, it hopefully would just immediately work lazily.

fair enough, but _will_ they ever be lazy eventually? Is that even a meaningful concept for `Configuration`s?

Wouldn't it be meaningful for any container?
To not configure the contents if they are not needed.
Why configure the configurations if you are just calling `gradlew help --task compileJava` for example?

I always wondered what "configuring a configuration" would be :upside_down_face:

For example you will need to realize all configurations to find outgoing variants and resolvable configurations. So I don't see the necessity for lazy configurations

We currently make use of the `gradle-nexus/publish-plugin` which goes through a nexus repository.

Nexus has the ability to stage a set of changes which would theoretically work. The only issue is this isn't implemented yet: <https://github.com/gradle-nexus/publish-plugin/issues/19>

We're pondering taking this up or forking the plugin but wanted to see if I'm missing something obvious or find out what others are doing.

I just declare project-local repo and publish to it via `publishAllPublicationsToLocalRepository`:
```publishing.repositories {
  maven {
    name = "local"
    setUrl(rootProject.layout.buildDirectory.dir("repo"))
  }
}```
Releases are done automatically from a tag. If you have reproducible builds it could be used instead of staging. Keep in mind that it's not really a staging though. Also it could be good for integration/functional/e2e testing (especially of the gradle plugins).

Thanks. My question is a more how to go from a local staging repo to a remote maven repository (specifically nexus) though.

It seems like the ideal use case would be to build across all the various machines and then combine all the artifacts into a single local staging folder and publish that (without the need to rebuild anything).

I see two paths.

1. Forgo the publishing plugin and just use curl or whatever to upload to maven repository. Once everything is staged including the pom files there is no additional work really other than to upload the artifacts. 
2. Create a custom <https://docs.gradle.org/current/dsl/org.gradle.api.publish.maven.MavenPublication.html|MavenPublication> based on the pre-built local directory contents (e.g. via `setArtifacts()`)
(1) may end up being the easiest I'm just not sure if I'm missing anything here or if it's more complicated than that. (2) seems like it may be hard to get the pom files correct as documentation indicates it's going to generate a pom file when we already have one at this point.

my goal is to prevent this issue from happening in CI

Well, it is basically just a warning.
Because if you don't use the accessors in that script plugin, it doesn't matter that they couldn't be generated.
And if you do use them in the script plugin, then the compilation of the script plugin will fail.

You can also put `<http://systemProp.org|systemProp.org>.gradle.kotlin.dsl.precompiled.accessors.strict=true` in your `gradle.properties` file in order to turn this into an error

you can't. like `plugins`, `pluginManagement` is special and is executed in a first pass outside of the context of the rest of the build script

you can define plugins (with versions) inside your version catalog instead

so the official solution to this plugin is:

```plugins {
    alias(libs.plugins.ktlint)
}```
but I think IDE support (at least in Android Studio) here is lacking

it's an IntelliJ IDEA/Kotlin plugin issue: <https://youtrack.jetbrains.com/issue/KTIJ-19370>

If it were a `pluginManagement { ... }` block it were right, that it is handled separately first.
I think when accessing it like `pluginManagement....` then it is done during normal settings script evaluation.

But nevertheless it is of course still hen-and-egg problem, as the version catalog is not defined in such an "evaluated before" block but in `dependencyResolutionManagement` and thus during normal settings script evaluation and thus the accessors can not yet be available during settings script evaluation.

The reason for this is, that a settings plugin can define a version catalog to be used in the project.

So yes, the `alias(libs.plugins ...` is the idiomatic way and yes, the IntelliJ Kotlin plugin still lacks of proper support for it, while it still works fine of course as far as Gradle is concerned. And in the issue ephemient linked, you can find a small work-around plugin that just suppresses these red highlightings if you really care that much about it.

oh that's a good point, `pluginManagement.*` won't be extracted, only `pluginManagement { * }`. but it still won't work for the reasons Björn mentions.

Ultimately, I decided on this workaround (in `buildSrc/build.gradle.kts`):

```dependencies {
    /**
     * Workaround for <https://gradle-community.slack.com/archives/CAHSN3LDN/p1651098827826449>
     */
    @Suppress("NAME_SHADOWING")
    fun DependencyHandlerScope.implementationGradlePlugin(id: String, version: Provider&lt;String&gt;) {
        implementation(version.map { version -&gt; "$id:$id.gradle.plugin:$version" })
    }
    implementationGradlePlugin("de.undercouch.download", libs.versions.downloadGradlePlugin)
    implementationGradlePlugin("org.jlleitschuh.gradle.ktlint", libs.versions.ktlintGradlePlugin)
}```
where `libs.versions.ktlintGradlePlugin` refers to the version in the version catalog

and my `buildSrc` plugin:

```plugins {
    id("de.undercouch.download")
    id("org.jlleitschuh.gradle.ktlint")
}```

that has a different behavior of putting those plugins into the root project classpath. I just use `plugins { alias }` and ignore the IDE error, it makes no difference.

does the IDE still pickup the classes correctly?

yes, it relies on the Gradle tooling API to get information about classpaths and such, and that works fine