hibernate like technology as a persistence layer for groovy? - groovy

I was wondering if there is like a persistence layer for groovy that is integrated on the ide to generate code automatically based on your database structure?

Just use Hibernate, as you would for a Java project.
Groovy can call java, and you can use the cross-compiler to compile both sources when you build your project.
The Hibernate tools will not spit out Java (so the code will be more verbose than the Groovy replacements), but as you won't need to write the code, this doesn't matter ;-)

Related

Sonar multi language project with non compiled code

I'm trying to setup a sonar scan for a project. This projects uses a free framework (Apache OFBiz) which is a multi language framework (java, JavaScript, xml, groovy, freemarker)
It is also a multi module projects with several subprojects.
I used the gradle sonar task with a local setup and sonarqube.
// build.gradle
sonar {
properties {
property "sonar.exclusions", "**/bin/**, **/org/apache/**"
property "sonar.test.exclusions", "**/src/test/**"
property "sonar.scm.disabled", true
}
}
subprojects {
apply plugin: 'org.sonarqube'
sonar {
skipProject = false
properties {
property "sonar.inclusions", "**/src/**"
}
}
}
Sonaqube gradle plugin is used in the version 3.5.0.2730 and i have the groovy plugin locally installed and running.
Sonarqube locally is version 9.7
So far, I've managed to run a Java scan that suits me in terms of coverage (ignore standard framework and scan client specific java code).
There is also some groovy analysis, but only in the compiled code.
What I would like to do is the following:
I would like to know if it is possible to scan non-compiled groovy code (that uses domain specific syntax)
I couldn't find any topic relevant to that question
I would like to know if it is possible to scan all the languages in the project, and if so, what would be the best way to do it? In a single run? one run per language?
I managed to find some topics, but nothing that is less than one or two years old.

Is there any SAST tool for Workfusion code?

Currently I'm involved in a project for implementing security code reviews for Workfusion bots. Workfusion can handle a mix of Java and Groovy code embedded in XML files or standalone code.
My team is trying to assess if it's possible to use any free/opensource Static Application Security Tool for it. I'm currently exploring the posiblity of creating a plugin for Spotbugs.
I was able to run reviews successfully with Java code + Maven with Spotbugs and FindSecBugs plugins, but I haven't figured out how to extend Spotbugs in order to parse the XML files, extract the embedded Groovy scripts and analyze them.
Do you know any static application security tool for Workfusion or could suggest any approach to extend any other SAST tool?
The main requirement for Find Security Bugs to work is the ability to compile the code.
If you have access to the class files, FindSecurityBugs should work. If the code is evaluate at runtime, you'll need to compile the snippet which is not an easy task if the script have access to a special context with initialized objects.

When to do Nashorn over Java Hooks?

I have a java application that does text processing.
Nashorn could be used to add customization just like hooks. So When should I use Nashorn and when should I use hooks? (assuming language doesn't matter)
It should be possible to write your hooks assuming java lambdas. This would allow Nashorn functions or Java functions to be used for your hooks. If you direct your question to nashorn-dev with specifics you will get more specific details.

difference between Groovy JDK API Documentation and groovy api Documentation

I am new to groovy I want to know the exact difference between Groovy JDK API Documentation and groovy api Documentation. I want to know the purpose of those api
Groovy adds additional methods to some JDK library classes (e.g String, File). These additional methods are known as the Groovy JDK and are documented here. All the methods that are available when using JDK classes in a Java program are also available when using them from a Groovy program.

Packaging a Groovy application

I want to package a Groovy CLI application in a form that's easy to distribute, similar to what Java does with JARs. I haven't been able to find anything that seems to be able to do this. I've found a couple of things like this that are intended for one-off scripts, but nothing that can compile an entire Groovy application made up of a lot of separate Groovy files and resource data.
I don't necessarily need to have the Groovy standalone executable be a part of it (though that would be nice), and this is not a library intended to be used by other JVM languages. All I want is a simply packaged version of my application.
EDIT:
Based on the couple of responses I got, I don't think I was being clear enough on my goal. What I'm looking for is basically a archive format that Groovy can support. The goal here is to make this easier to distribute. Right now, the best way is to ZIP it up, have the user unzip it, and then modify a batch/shell file to start it. I was hoping to find a way to make this more like an executable JAR file, where the user just has to run a single file.
I know that Groovy compiles down to JVM-compatible byte-code, but I'm not trying to get this to run as Java code. I'm doing some dynamic addition of Groovy classes at runtime based on the user's configuration and Java won't be able to handle that. As I said in the original post, having the Groovy executable is included in the archive is kind of a nice-to-have. However, I do actually need Groovy to be executable that runs, not Java.
The Gradle Cookbook shows how to make a "fat jar" from a groovy project: http://wiki.gradle.org/display/GRADLE/Cookbook#Cookbook-Creatingafatjar
This bundles up all the dependencies, including groovy. The resulting jar file can be run on the command line like:
java -jar myapp.jar
I've had a lot of success using a combination of the eclipse Fat Jar plugin and Yet Another Java Service Wrapper.
Essentially this becomes a 'Java' problem not a groovy problem. Fat Jar is painless to use. It might take you a couple of tries to get your single jar right, but once all the dependencies are flattened into a single jar you are now off an running it at the command line with
java -jar application.jar
I then wrap these jars as a service. I often develop standalone groovy based services that perform some task. I set it up as a service on Windows server using Yet Another Java Service and schedule it using various techniques to interact with Windows services.

Resources