This message was deleted.
# releases
s
This message was deleted.
m
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
j
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
r
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
j
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
@melix 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
@René 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
m
but you did not respond there.
Ah dang, why don't I get any notification from the gradle repo? 😞 I will come back to you
👍 1
t
Just to be clear, the 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. 🙂
j
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