Gradle 3.4-rc-1: "Resolving configuration 'apiElements' directly is not allowed"

[dependency-check]

Gradle 3.4-rc-1: "Resolving configuration 'apiElements' directly is not allowed"

[stefanneuhaus]

As a workaround you can configure dependency-check to skip these configurations. Add the following to your build.gradle:

dependencyCheck {
    skipConfigurations=["apiElements", "implementation", "runtimeElements", "runtimeOnly", "testImplementation", "testRuntimeOnly"]
}

[jeremylong]

I've run checked a few projects with Gradle 3.4-rc-1 and I have not seen this issue come up. Any chance you can provide an example build.gradle that causes this issue? I'm also wondering if this is a dependencyCheck issue or something that needs to be reported to the gradle team?

[stefanneuhaus]

You have to apply the "java" plugin in order to reproduce the issue:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath('org.owasp:dependency-check-gradle:1.4.5')
    }
}

apply plugin: 'org.owasp.dependencycheck'
apply plugin: 'java'

With 3.4 they introduced a couple of configurations that cannot be resolved directly. A simple fix would be to hard-code a blacklist of these configurations, but this seems very fragile. I am currently looking for a more robust and elegant solution.

[stefanneuhaus]

I have provided a PR for a fix: #33

Since Gradle 3.3 the Configuration class was extended by the information whether it can be resolved: Configuration.isCanBeResolved()

Since Gradle 3.4 e.g. some configurations of the Java Plugin make use of it.

[stefanneuhaus]

After analyzing thew issue I suppose that the Gradle change was done on purpose. I brought up the question in the Gradle Forum whether the change should be mentioned as Breaking Change in the Release Notes.

[jeremylong]

@stefanneuhaus thanks for the research (and PR) on this one! I truly appreciate it.

[johnscancella]

I just upgraded to 3.4 and using version 1.4.5 of this plugin I am still seeing the issue. What version is this fix in?

[jeremylong]

The fix has been implemented but we have not yet published a new release. I'll try to do this on saturday. Jeremy

…

On Feb 28, 2017 7:18 PM, "John Scancella" ***@***.***> wrote: I just upgraded to 3.4 and using version 1.4.5 of this plugin I am still seeing the issue. What version is this fix in? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0qwl3q8QZ0bic5SHIJ3WVzcLT_6CzUks5rhLlmgaJpZM4L000F> .

[johnscancella]

@jeremylong thanks so much! I love your plugin, keep up the great work!

[dodgex]

Hey there, I'd like to know if there is a new ETA for the 1.4.6 release containing this fix.

Thanks in advance! :)

[jeremylong]

I just pushed 1.4.5.1 - I was trying to hold off for 1.5.0 but there are changes in the core engine that are taking longer then I hoped.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.