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

Gradle Community

This seems quite annoying and impractical. I have some examples where using an "elements" (aka outgoing configuration) directly to declare dependencies is pragmatic and practical. See also <https://github.com/gradle/gradle/pull/22580>

I assume you're creating `compileClasspathCopy` via `Configuration#copy`? In `7.6` `compileClasspath` was deprecated for declaration, and you would have seen the deprecation warnings if using that. However, it seems we do not copy deprecations over when copying configurations themselves, and thus `compileClasspathCopy` was never deprecated for declaration even though it should have been.

I will get back to you with how we are going to handle this case.

As for `internalClusterTestApiElements`, how are you creating this? If you are using `JvmModelingServices#createOutgoingElements`, that API is internal and is not guaranteed to be stable

`internalClusterTestApiElements` that is the standard outgoing variant for `internalClusterTest` sourceSet. the problem seems we add dependencies directly to that configuration. I applied a workaround to let ``internalClusterTestApiElement`  extendFrom a configuration and add the deps there

Are you sure you don't have additional code which is creating this elements configuration? The JavaBasePlugin does not create elements configurations for source sets. It only creates implementation/runtimeOnly/compileOnly/compileClasspath/runtimeClasspath

<@UAFGSU86M> We are continuing progress on the PR you mentioned. I asked you to provide some some example use cases for adding dependencies directly to outgoing configurations, but you did not respond there. If you would like to continue the conversation there, your input would be appreciated: <https://github.com/gradle/gradle/pull/22580#discussion_r1026934651>

<@UAJKMRD2Q> Is `internalClusterTest` used as a feature variant or test fixture?

We have a tentative solution to these two regressions: <https://github.com/gradle/gradle/pull/23398>

&gt; but you did not respond there.
Ah dang, why don't I get any notification from the gradle repo? :disappointed: I will come back to you

Just to be clear, the <https://github.com/gradle/gradle/pull/22580#discussion_r1026934651|Lock Configuration Usage PR>, despite the branch name, will *not* be merged into 8.0.  A modified form is now targeted at 8.1.  As you can probably tell, we’re still having plenty of lively discussions about it. :slightly_smiling_face:

The bug reported in the original post has been addressed. The change should be present in the next nightly and will be present in 8.0 RC2