https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# kotlin-dsl
s
This message was deleted.
c
Subprojects is a code smell and should not be used; replace with convention plug-in. The code sample is using the wrong project instance - remove “project.” qualifier
t
The end goal was to have the conventions applied to 
rootProject
without requiring much other configuration for things like dependency resolution or docker builds, which is why I'm attempting to use subprojects.
I tried without the 
project
qualifier, still getting the same results.
Seems like it's being evaluated lazily
okay, new info: I just printed out the value within the 
subprojects
block, and it IS defined. This makes me think that 
setProperty
isn't being evaluated before dependencies are pulled.
swapped artifactory -> maven plugin and it works. Thinks there's some lazy eval that doesn't play nicely.
v
Anyway, as Chris said, practically any usage of 
subprojects { ... }
or 
allprojects { ... }
is a code smell and should be avoided. It introduces project coupling, preventing more sophisticated Gradle features and also makes builds much harder to understand and maintain. Just copying a cross-configuration block from root project into a plugin is not worth being called convention plugin. They should be applied directly where their effect is intended, so in each project where it should have effect explicitly.
t
I can see how/why that is be valid, but it's extremely practical for our use case. Standardizing naming conventions for docker images, not having mismatched maven configs, etc. keeps everyone on the same page with versioning the conventions plugins. Fwiw I did get it sorted and it's working well.
If you have any suggestions on best practices, I'm totally open to hear them though! This is just the best way I know to keep drift out of our gradle configs.
c
using a convention plugin gives you all those benefits and none of the drawbacks of cross-project configuration.
t
namely it helps only having to apply to rootProject and keep it tracked from there, hence the 
subprojects
usage
otherwise we might have submodules that drift
c
nope. apply the convention plugin with ‘apply false’ in the root, and then use in the submodules w/o a version.
it’s the idiomatic approach, an evolution from the dated & problematic submodules stuff.
t
that's a great idea. definitely going to
for reference: my main issue was some strange lazy loading behavior w/artifactory
it also happened on one specific field in jib
I documented how I was able to get it to work here
c
yes. you want to use properties/providers (lazy configuration) instead of setting variables and hoping it’s at the right time.
t
For some reason applying the conventions plugin was trying to apply jib to the rootproject, even with 
apply false
but using the 
configure<JibExtension>
and excluding it from 
plugins{}
block, mysteriously works
I know it's not the same in groovy, so chalking it up to kotlin weirdness.
v
apply false is ignored in convention plugins
t
interesting, had no idea
v
It also makes no sense anyway as that would only be to add a plugin to the class path, but you already have it on the class path
Apply false should imho throw an exception instead. Iirc I have an open feature ticket for that
t
that would have been extremely helpful
v
And I of course don't mean convention plugins, I mean precompiled script plugins
t
yeah, I know the semantics are a little different
but also interesting because it's somewhat counterintuitive to do :
Copy code
import com.google.cloud.tools.jib.gradle.JibExtension
v
Not a little, but very much different
t
but if you're writing the kotlin code, it tracks a little better
v
Precompiled script plugins are the things that are precompiled and look almost like build scripts, no matter what is inside. Convention plugins are plugins that define your custom conventions, no matter whether you implement them as binary plugins, script plugins, precompiled script plugins or any other form or language.
t
ah, that makes more sense
Had that a bit twisted
v
Many have, because many people mix the terms wrongly and cause major confusion
t
TIL 🙂
v
Why is it counterintuitive to import a class?
t
originally I thought lazy properties weren't being propagated in 
subprojects
so to validate, I made this:
Copy code
package com.vyrl

import com.google.cloud.tools.jib.gradle.BuildImageTask
import org.gradle.api.Plugin
import org.gradle.api.Project
import org.gradle.kotlin.dsl.named

class JibConfigPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        val image: String = "<http://1223356.dkr.ecr.us-west-2.amazonaws.com/company/${project.rootProject.name}-${project.name}|1223356.dkr.ecr.us-west-2.amazonaws.com/company/${project.rootProject.name}-${project.name}>"
        println("Setting image to: $image")

        project.pluginManager.withPlugin("com.google.cloud.tools.jib") {
            project.tasks.named<BuildImageTask>("jib") {
                to {
                    setTargetImage(image)
                }
            }
        }
    }
}
and I saw that 
apply false
wasn't taking effect
so it wasn't that the properties weren't there, it's that jib was being applied to the rootproject, which in our conventions is a dummy project
which led to this error:
Copy code
Missing target image parameter, perhaps you should add a 'jib.to.image' configuration parameter to your build.gradle or set the parameter via the commandline (e.g. 'gradle jib --image <your image name>').
so once I was logging out outside of subprojects, I was able to see which projects jib was being applied to
and then found import + 
configure<JibExtension>
where originally I would have expected the behavior to be the same as apply false w/subprojects in our typical multimodule
now knowing that apply false doesn't work in that context, it makes a lot more sense
also +1 for getting that warning out there
overall, connecting the dots to get it to the right state is a little clunky. Would be nice if there were some warnings or explanations. I do feel a bit like I'm in my own space though because this an extremely opinionated way of making gradle "easy" for people who don't like to manage their own build files.
v
t
awesome! I threw a thumbs up on there and subscribed
👌 1
5 Views
Open in Slack
PreviousNext
Powered by