https://gradle.com/ logo
Join Slack
Powered by
Is publishing possible with configuration cache th...
# community-support
m
Is publishing possible with configuration cache these days? I'm using 
9.6.1
but got hit with
Copy code
cannot serialize object of type 'org.gradle.api.publish.maven.internal.publication.DefaultMavenPublication', a subtype of 'org.gradle.api.publish.Publication', as these are not supported with the configuration cache.
Am I holding it wrong?
✅ 1
I've read github.com/gradle/gradle/issues/24329 but I'm unsure if this covers my issue or if it's a new one
Ah wait, that looks like a KGP issue
generatePomFileForKotlinMultiplatformPublication
v
That's surprising to me. I thought KMP should at least be CC compatible by now even if not yet IP compatible
🙏 1
m
Yea, I just found out it's self inflicted pain. I'm customizing the pom file in a lambda and that lambda cannot be serialized.
Now how do I fix this is an interesting problem....
m
is the lambda capturing the publication? If possible, only capture primitives instead e.g. instead of this:
Copy code
somethingLambda {
	doStuffWith(myPublication.name)
}
do this:
Copy code
val publicationName = myPublication.name
somethingLambda {
	doStuffWith(publicationName)
}
it's a pretty common footgun with config cache, it's far too easy to capture a 
Project
, AGP variant or some other heavy object :/
👆 1
m
Hot take but lambdas should never be an input to a task, this is way too dangerous. Either have the user provide their own task or provide a plugin mecanism and a separate classloader
v
Why should a lambda not a task input? The code of the lambda is part of the runtime classpath of the task and thus it is part of its inputs. As well as the things it captures, which is also task inputs.
You would need to forbid all 
doLast
and 
doFirst
to not have it and that would be bad for usability if you cannot do ad-hoc task actions
m
Yes, let's do this
Then we don't have to invalidate our whole build whenever a plugin changes
I agree it's "convenient" but there has to be better options
"convenient" as in... until you shoot yourself in the foot
v
Even if we would forbid the runtime api, a plugin change would still have the same effect
Oh, you mean that even a plugin cannot do 
doFirst
or 
doLast
m
Yes, if we can make it easy to define tasks, we don't need 
doFirst
and 
doLast
anymore. This is just "convenient" right now because users need to monkey patch existing tasks, etc...
v
But even then that wouldn't change much. A "proper" task class could still call something from any class in another plugin and be it just some helper function. You would need to throw over board all the current architecture and hardly isolate all task classpaths.
m
Yes, that's what I want 🙂
v
That would probably make builds much slower and also make Gradle much harder to use. 🤷‍♂️
m
Isolate all the tasks
I think it can be much faster actually
m
the provider api has map so youll always have a way to have lambdas as inputs to a property
m
No need to instrument all the build to catch the CC inputs, etc...
v
Well, feel free to open a FR for that if none exists, but I somehow doubt this will come 🤷‍♂️
m
Yea, I doubt it too 😄
v
No need to instrument all the build to catch the CC inputs, etc...
Sure you would have still that
m
@madisp don't get me started on doing arbitrary code in providers 😄
@Vampire if I can have this I will be 80% happy (isolating the workers, not the tasks)
v
Yeah, that would really be nice to have. Send them a PR that implements it. 😄
m
I'll do this when I retire 😄
p
You could also use the internal serializable lambda, but I would not recommend it.
m
That sounds both scary and beautiful @Philip W
v
No need to? The lambdas are serializable. As long as you don't capture unsupported things.
p
@Vampire are you sure? If you compile them “with Gradle” eg in build logic or scripts, they are serializable. But not in regular binary plugins published as jar.
m
That's the 
"-Xsam-conversions=class"
right? I'm not sure that's still needed these days
v
-Xsam-conversions=class
is only for Kotlin, that would be that Kotlin SAM Lambdas are not compiled like Java Lambdas, but like classes. But since Gradle 8.1 normal Java lambdas and also Kotlin Lambdas without that option should work just fine.
https://docs.gradle.org/8.1/release-notes.html
Support of Java lambdas
Gradle can now restore user-provided lambdas from the configuration cache. Using anonymous classes to implement Single Abstract Method (SAM) interfaces is no longer necessary. This also applies to Kotlin code: there is no more need to configure the Kotlin compiler to generate classes instead of lambdas during SAM conversion.
This release also improves error reporting for lambdas that capture unsupported types, like 
Configuration
.
👍 1
m
Yet the flag is still set when compiling 
gradle.kts
files
v
Should work without though, according to that release notes entry. 🤷‍♂️
Maybe it works more performant with the flag?
m
Maybe!
2 Views
Open in Slack
PreviousNext
Powered by