-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
Comments
Interesting suggesting. I guess it makes sense to create a |
What exactly should be configured using that object? The Enterprise Groovy conventions? |
Yeah, the Groovy compiler settings. |
Groovy compiler settings and Enterprise Groovy conventions are two different things :-) |
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? |
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. |
OK, let's take step back. What's missing in EG that Kordamp may be better suited to provide? |
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 What can be improved is the way how conventions.groovy
but can we do better? Can we simply set the system properties for
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 |
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 |
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. |
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:
|
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
The text was updated successfully, but these errors were encountered: