New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document a warning against static state in Gradle plugins #6818

Open
big-guy opened this Issue Sep 19, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@big-guy
Member

big-guy commented Sep 19, 2018

Gradle attempts to reuse classloaders between build invocations to keep classes "hot" (since Gradle 2.4). This has implications for how Gradle plugins (and their dependencies) are written. Specifically, Gradle plugins, tasks, extensions, etc should in general not keep static state because it can cause problems like resource leaks and make it seem like configuration changes are being ignored.

This leads to other bad advice like:

  • Don't use the daemon at all
  • Delete your GRADLE_USER_HOME
  • Stop/restart the daemon when changing configuration

This would be appropriate in our Gradle guides on plugin development and/or the user manual.

Context

Given a plugin like this:

class MyPlugin implements Plugin<Project> {
    static String prop = System.getProperty("myproperty", "default")
    void apply(Project project) {
       project.logger.lifecycle("myproperty is " + prop)
    }
}

apply plugin: MyPlugin

When you run gradle help, this produces the message "myproperty is default".
When you run gradle help -Dmyproperty=somethingelse, this produces the message "myproperty is default". (surprising!)
When you then stop the daemon and run gradle help -Dmyproperty=somethingelse, this produces the message "myproperty is somethingelse". This is the message you'll get until you stop the daemon/use another daemon.

@mkobit

This comment has been minimized.

Show comment
Hide comment
@mkobit

mkobit Sep 19, 2018

Contributor

I've seen this a lot with people also expecting environment variable changes to take effect through some tasks that eventually exec with inheritance from System.getenv().

SOME_VAR=new_var ./gradlew doThing

I know something got changed in 4.10 to fix this, but if there is a similar recommendation for that, it would also be useful.

Contributor

mkobit commented Sep 19, 2018

I've seen this a lot with people also expecting environment variable changes to take effect through some tasks that eventually exec with inheritance from System.getenv().

SOME_VAR=new_var ./gradlew doThing

I know something got changed in 4.10 to fix this, but if there is a similar recommendation for that, it would also be useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment