kordamp / kordamp-gradle-plugins

A collection of Gradle plugins
https://kordamp.org/kordamp-gradle-plugins/
Apache License 2.0
138 stars 25 forks source link

[groovy] Static compilation by default using Enterprise Groovy #453

Open musketyr opened 3 years ago

musketyr commented 3 years ago

it would be great to add a simple flag to enable static compilation for all the groovy files

see https://medium.com/agorapulse-stories/how-to-compile-groovy-statically-by-default-980816119534

aalmiray commented 3 years ago

Interesting suggesting. I guess it makes sense to create a groovyCompiler DSL element (outside of the config element) that provides typed accessors/mutators for these settings. This element would be added when applying the org.codehaus.gradle.groovy-project. WDYT?

musketyr commented 3 years ago

What exactly should be configured using that object?

The Enterprise Groovy conventions?

aalmiray commented 3 years ago

Yeah, the Groovy compiler settings.

musketyr commented 3 years ago

Groovy compiler settings and Enterprise Groovy conventions are two different things :-)

aalmiray commented 3 years ago

I'm well aware of that. I think Enterprise Groovy oversteps boundaries which is why I explicitly mentioned Compiler settings 😉 , which is what EG offered in the beginning, isn't it?

musketyr commented 3 years ago

If you take a closer look then Enterprise Groovy actually has very little common with the compiler settings. The convention script is only used to set system properties for a global AST transformation.

aalmiray commented 3 years ago

OK, let's take step back. What's missing in EG that Kordamp may be better suited to provide?

musketyr commented 3 years ago

The plugin is currently broken but let's snooze this conversation for a week or two if @virtualdogbert is able to fix it :-)

Or maybe you would be able to find a fix - the issue arises when the plugin tries to add enterprise-groovy to that compileOnly dependencies.

https://github.com/virtualdogbert/enterprise-groovy-plugin/blob/master/src/main/groovy/com/virtualdogbert/EnterpriseGroovyPlugin.groovy#L67

What can be improved is the way how enterprise-groovy is configured. The original plugin uses the convention script to set the convention properties into the system properties.

conventions.groovy

Map conventions = [
        disable                     : false,
        whiteListScripts            : true,

        disableDynamicCompile       : false,
        dynamicCompileWhiteList     : [],

        compileStaticExtensions     : [],
        limitCompileStaticExtensions: false,

        defAllowed                  : true,
        skipDefaultPackage          : false
]

System.setProperty('enterprise.groovy.conventions', "conventions=${conventions.inspect()}")

but can we do better? Can we simply set the system properties for compileGroovy GroovyCompile task skipping the need for the convention script completely? In that case we could add a following to the config

config {
    groovy {
        enterprise {
            disable = false
            whiteListScripts  = true
            disableDynamicCompile = false
            dynamicCompileWhiteList  = []
            compileStaticExtensions  = []
            limitCompileStaticExtensions = false
            defAllowed = true
            skipDefaultPackage = false
        }
    }
}

If we cannot customize the system properties for the compile task then we could try to generate the contention file on the fly.

We will still have to find a way how to add the enterprise-groovy dependency to the compileOnly configuration if enabled.

aalmiray commented 3 years ago

I see. Let's wait a bit then. However based on your example there's nothing specific to Kordamp in that configuration thus the EG DSL element may very well be located outside of the config DSL element, in which case it makes more sense for EG to provide such element, isn't it?

virtualdogbert commented 3 years ago

Hey, @musketyr I'll get on the fix tomorrow, I think all that's needed to make it work with more recent versions of Gradle it to up the Gradle version it's built with. I'm also thinking of updating it to Groovy 3. The other issue is I have to figure out how to set it up to deploy to maven central.

I'm curious what bounds does Enterprise Groovy overstep? Until now I was unaware of Kordamp. The point of Enterprise Groovy was to be more flexible than what is provided by the compiler scripts, and provide optional enforcement.

The only reason I set config in the compiler script is that it was the only way I could find to get to make that config accessible to a global AST transform, which is what the underlying library is. The Gradle plug-in that wraps that library just gives you an easy way to apply it, and set-up its config.

musketyr commented 3 years ago

Thanks, @virtualdogbert, for joining the conversation!

For me, Enterprise Groovy is very easy to use without a need to know any details about how the conventions files work. The main benefit for me is is that it shows me how to disable the particular toxic feature of Grails GORM.

Kordamp here, on the other hand, is a way how to centralize the configuration (and also how to easily externalize it into XML, YAML, TOML, ...). Also it a tool from which I expect to give me the best practices out of the box. That's the reason why I would love to have the enterprise groovy integration bundled out of the box.

I think I found a way how to apply the properties without the need for the convention script but I haven't tested it yet. I'm afraid it would have to be added twice due to the possibility of fork:


compileGroovy {
    String conventionsString = "-Denterprise.groovy.conventions=conventions=${conventions.inspect()}"
    options.compilerArgs.add(conventionsString)
    groovyOptions.forkOptions.jvmArgs.add(conventionsString)
}