This message was deleted.

Well, not the first line, but the first line in the closure. The if statement. I can supply the full stacktrace if it helps, or anything else. Just looking for any guidance on this.

If I’m not mistaking,

mainClassName

change name in mid 6.x. (see my sample here: https://docs.nokee.dev/samples/jvm-application-with-jni-library/)

project.mainClassName is actually something that my code adds (if it doesn't exist already)

Good point, you may want to print the entire stack trace (

--stacktrace

) . I would expect the

mainClassName

to be an extra property in the way you are accessing it. I don’t remember all the details, but I have a vague memory that

mainClassName

from the

application

plugin was accessible directly on the

project

that is assuming you are indeed applying the

application

plugin. The deprecation and removal of that property would align with what you are seeing. Gradle has a funny way of dealing with extensions and extra properties. Sometime

project.<name>

is convoluted. Gradle won’t complain but it will return something that is not what you expect. You could try grabbing your

mainClassName

directly from

project.extensions

or

project.extensions.extraProperties

to see if that is the case.

I'll post the entire stacktrace, but it is a doozy. Heheh, I'm familiar with how the Application plugin was doing that. Check out this code, and it might be more clear what I'm doing. My plugin actually simulates the old way the Application plugin worked. in apply:

project.convention.plugins.MockApplicationConvention = new MockApplicationConvention()

and

class MockApplicationConvention {
    private String mainClassName = 'unspecified'

    String getMainClassName() {
        return this.mainClassName
    }

    void setMainClassName(String mainClassName) {
        this.mainClassName = mainClassName
    }
}

And I've been using that since even before Gradle 6. And the weirrrrddd thing is this all works just fine and dandy in Gradle 7+. But no longer works in Gradle 6....

I see the code is in Groovy, there may be a Groovy 3 vs 2.5 issue. I remember seeing something about that but it depends on which Gradle you use for building.

Hmmm.... I did recently switch to building the plugins using Gradle7.......

It can, maybe this will help: https://docs.gradle.org/current/userguide/upgrading_version_6.html#changes_to_groovy_and_groovy_dsl

The overall gist of that first paragraph makes me think that G6 is actually more permissive than G7, and so something that works in G6 might not work in G7, but the vice versa would not really be an issue....

You can refer to this (https://github.com/gradle-plugins/toolbox/blob/main/subprojects/gradle-plugin-deve[…]src/main/java/dev/gradleplugins/GradleRuntimeCompatibility.java) for the Groovy runtime in Gradle version if that can help.

Thanks @daniel

You could try downgrading to G6 and see if that solves it. I also know that plugin convention is a feature that should be essentially deprecated. It would be best to use an extension or extra properties. Gradle still use plugin convention internally but it’s not something they want to keep.

Oh I'm aware 🙂 I don't like conventions either, and that is the only place I use it, I use extensions everywhere else. I might switch that to an extension eventually, but I have a large internal userbase who are resistant to buildscript API changes (when I do make them, I usually end up having to change every single project's buildscript myself)

You could create the extension and wrap it in the convention until the migration is over 🙂