Hey guys I m super excited about the Declarative Gradle proj Gradle Community #declarative-gradle

Hey guys, I’m super excited about the Declarative ...

Radosław Panuszewski

05/31/2024, 8:03 PM

Hey guys, I’m super excited about the Declarative Gradle project after your talk on KotlinConf 🔥 I would love to try it out, but I have some questions - more details in the thread 😉

❤️ 2

Radosław Panuszewski

05/31/2024, 8:03 PM

I my company (Allegro) we are moving towards the declarative builds and we kinda already have the concept of “software type”. We simply consider projects with

application

plugin to be deployable apps, while those with

java-library

to be libraries. In the CI pipeline, we inject a

init.gradle.kts

script which detects the “software type” and configures the Maven publications accordingly. As an experiment, I would love to try out how the Declarative Gradle fits into our configuration and share some feedback with you. I managed to set up a simple build with the

javaApplication

software type, but my issue is that it works only when the buildscript file is named

build.gradle.dcl

. During your KotlinConf talk, you mentioned that the new DSL will be usable also in traditional

build.gradle.kts

files for easier migration. In my case, it’s also about the IDE support - if the

org.gradle.experimental.jvm-ecosystem

plugin registered the

javaApplication

extension to be available in traditional

kts

buildscripts, I would get a basic IDE support basically for free. Would you consider introducing such a change? IMO it would make the early adopter expierience a lot smoother. I know your current top priority is Android, but I can offer my contribution in case that’s ok for you 😉 Alternatively, maybe I could install some SNAPSHOT version of the Declarative Gradle IntelliJ Plugin?

Sterling

05/31/2024, 10:13 PM

As an experiment, I would love to try out how the Declarative Gradle fits into our configuration and share some feedback with you.

Your init script would still work. Are you looking for how your init script would be replaced or how users would change their project build scripts?

During your KotlinConf talk, you mentioned that the new DSL will be usable also in traditional build.gradle.kts files for easier migration. In my case, it’s also about the IDE support - if the org.gradle.experimental.jvm-ecosystem plugin registered the javaApplication extension to be available in traditional kts buildscripts, I would get a basic IDE support basically for free.

This should be possible today, but you need to apply the appropriate plugin yourself. IOW, you can't rely on Gradle to automatically apply the right plugin by just referencing the software type. We're going to be doing more in this area over the next couple of weeks so that reusable conventions declared in a settings.gradle.dcl work for declarative and non-declarative files.

Alternatively, maybe I could install some SNAPSHOT version of the Declarative Gradle IntelliJ Plugin?

Unfortunately, I think everything is baked deep into Android Studio right now. You can get some syntax highlighting by associating .dcl to Kotlin scripts, but none of the auto-complete will work.

Radosław Panuszewski

06/03/2024, 12:05 AM

> This should be possible today, but you need to apply the appropriate plugin yourself. Thanks for the tip - applying the

org.gradle.experimental.java-application

plugin in my

build.gradle.kts

did the trick and the

javaApplication

extension is now available 🙂 Though there is a similar problem with the

settings.gradle.kts

file. The

conventions

block is usable only in the

dcl

version of the settings script. After digging into the code I see that

conventions

is not registered as Settings extension and it is only recognised in the

dcl

file due to presence of the

ConventionsInterpretationSequenceStep

in the interpretation sequence. It seems the

conventions

extension (together with nested extensions per software type) could be registered in the

SoftwareTypeRegistrationPluginTarget

via applying the visitor like below:

Copy code

class SoftwareTypeConventionRegisteringVisitor implements StaticMetadataVisitor {

    @Override
    public void visitRoot(...) {
        if (extensions.findByName("conventions") == null) {
            extensions.create("conventions", ConventionsExtension.class);
        }
    }

    @Override
    public void visitNested(...) {
        propertyMetadata.getAnnotation(SoftwareType.class).ifPresent(softwareType -> {
            ExtensionAware conventions = (ExtensionAware) extensions.findByName("conventions");
            conventions.getExtensions().create(softwareType.name(), softwareType.modelPublicType());
        });
    }
}

Actually, on branch

gh/declarative/dependencies-conventions

this visitor already exists but it only adds the software type extensions as top-level Settings extensions. Is there any reason not to have this visitor? A bunch of my additional observations: • among the published declarative-gradle plugins, one is missing:

org.gradle.experimental.declarative-common

. It effectively makes the published plugins unusable, forcing users to clone the declarative-gradle repo and connect it via

includeBuild

. Is the

declarative-common

plugin not published on purpose? If not, then you could consider publishing it 😉 •

mavenLocal()

is not accepted in

pluginManagement.repositories

for the

settings.gradle.dcl

file - it would be helpful to have it there as an alternative to

includeBuild

3 Views

Open in Slack

Previous Next