<@U0QBCLV62> I'm getting tons of errors trying to ...

# gradle

[jlleitschuh]

@bamboo I'm getting tons of errors trying to upgrade a project to Gradle 4.1 from 4.0.2. Mostly related to dependency configurations missing like testCompile.

[agomez]

same answer as for me

[jlleitschuh]

So I have this:

subprojects {
    apply {
        plugin("java")
        plugin("checkstyle")
        plugin("pmd")
        plugin("findbugs")
        plugin("jacoco")
    }
    repositories {
        mavenCentral()
    }

    dependencies {
        testCompile(group = "junit", name = "junit", version = "+")
    }
}

Shouldn't testCompile be correctly resolved?

[agomez]

nop, you are applying java plugin to subprojects

[agomez]

so in this project/script testCompile doesnt exist

[jlleitschuh]

Thats what I want. I don't want it on the parent. But I want to be able to configure all the subprojects's dependencies.

[jlleitschuh]

@bamboo This is a pretty big blocker for me.

[jlleitschuh]

You should be able to configure subproject's dependencies even if that project doesn't have the java plugin applied to it.

[agomez]

i guess allprojects instead of subprojects will fix it, but that's not what you want

[bamboo]

The quick workaround is to use strings instead “testCompile”(...)

[bamboo]

right

[jlleitschuh]

The impact of this is that my 4.0.2 build file will be 100% incompatible with 4.1. Which, while I understand that GSK is in pre-release and subject to API changes, not the kind of massive build refactor that I want to have to go through.

[bamboo]

Our rationale for the change is to provide better static checking with the understanding that this also makes certain usages less convenient

[bamboo]

You should be able to provide a testCompile accessor on buildSrc

[bamboo]

it will be available to every project

[jlleitschuh]

As a user that's been working with GSK for months now I'd personally much rather get Gradle throwing a "Configuration not found in project" error over not having the static method there.
I mean sure, I can add it, but I'm working with GSK on several different projects, I don't really want to have to do that for each buildSrc. I mean I will if I have to.

[bamboo]

The good news is that configurations that were previously unaccessible will now be accessible (think api, implementation and any custom configuration created by plugins out there)

[jlleitschuh]

For the buildSrc you'd just put the extension in the root package so that all projects can access it?

So, the assumption that I'm working off of is that every project that is working with the dependency block will always have the testCompile and will almost always want to use it.

[bamboo]

Another solution would be to provide those accessors in a library and then add the library as a buildSrc dependency

[bamboo]

The library can then be reused in other projects

[bamboo]

root package should do

[jlleitschuh]

Okay, I can work with it for now. But consider my complaint officially filed 😛
Other than that the new feature with the dynamic generation seems nice.

It would be nice if I could do:

"testCompile"(group = "junit", name = "junit", version = "+")

Instead of:

"testCompile"(create(group = "junit", name = "junit", version = "+"))

[bamboo]

Ack 🙂

[bamboo]

And yes, that should work, we have an issue for that already

[mkobit]

I think https://github.com/gradle/kotlin-dsl/issues/291 may be the one you are referring to, I am hoping to take some time out the next week to help with a few of these!

[bamboo]

Yes, @mkobit, that’s the one, thanks!