Skip to content
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

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

Open
musketyr opened this issue Mar 5, 2021 · 11 comments
Open

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

musketyr opened this issue Mar 5, 2021 · 11 comments
Assignees
Labels
enhancement New feature or request

Comments

@musketyr
Copy link
Contributor

musketyr commented Mar 5, 2021

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
Copy link
Collaborator

aalmiray commented Mar 5, 2021

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?

@aalmiray aalmiray self-assigned this Mar 5, 2021
@aalmiray aalmiray added the enhancement New feature or request label Mar 5, 2021
@musketyr
Copy link
Contributor Author

musketyr commented Mar 5, 2021

What exactly should be configured using that object?

The Enterprise Groovy conventions?

@aalmiray
Copy link
Collaborator

aalmiray commented Mar 5, 2021

Yeah, the Groovy compiler settings.

@musketyr
Copy link
Contributor Author

musketyr commented Mar 5, 2021

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

@aalmiray
Copy link
Collaborator

aalmiray commented Mar 5, 2021

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
Copy link
Contributor Author

musketyr commented Mar 5, 2021

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
Copy link
Collaborator

aalmiray commented Mar 5, 2021

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

@musketyr
Copy link
Contributor Author

musketyr commented Mar 6, 2021

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
Copy link
Collaborator

aalmiray commented Mar 6, 2021

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
Copy link

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
Copy link
Contributor Author

musketyr commented Mar 8, 2021

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)
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants