我有一个使用多个.groovy文件的大型Groovy应用程序（~2000行）。 我该如何处理生成的类文件？

Question

When the application is completely self contained within one .groovy file there are no .class files generated. However, when I separate out the classes into separate files and place them in packages, I end up with hundreds of generated .class files (most are from all of the closures compiling to bytecode separately).

What is the best approach for managing the file system when all of these files are generated and end up cluttering the folder?

1. Should I leave everything in one file? That's the cleanest approach to the file system but I end up with a large .groovy file and no separation of logic.
2. Should I package everything into a jar? That would work but it cuts down on the flexibility of having a script run directly with small changes as necessary.
3. Do I just ignore the .class files?

Answer 1

Option #2 is best, provided you use a build tool like Gradle . Our DevOps team uses Groovy, and delivers self-contained zip files.

As an simple example, look at this project .

It delivers warO.zip , which unzips to:

warO.jar
jars/groovy-all-1.6.4.jar
jars/guava-collections-r03.jar
jars/guava-base-r03.jar

Because the manifest is set with main class and classpath, the user can then execute with:

java -jar warO.jar

Your user audience will love it. They don't even need Groovy installed, just the JRE.

Regarding the dev cycle, it is true that edits to the script are not quite as fast, but by adding Gradle tasks (or simple scripts), it is easy to automate the steps to build, deploy locally, and execute.

Answer 2

Building an executable jar with your scripts and embedded Groovy is simple with Gradle .

The advantage is verification that the scripts are compilable and unit tested before deployment to a production environment.

Here's an example:

scripts/src/main/groovy/script1.groovy

println "Hello World!"

def aTestableMethod() {
    1 + 1
}

---

scripts/src/test/groovy/script1Test.groovy

import org.junit.Test
import static org.junit.Assert.*

class Script1Test {
    @Test
    public void checkATestableMethod() {
        def script1 = new script1()
        assertEquals 2, script1.aTestableMethod()
    }
}

---

scripts/build.gradle

apply plugin: 'groovy'
repositories {
    mavenCentral()
}
dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.2.2'
    testCompile 'junit:junit:4.11'
}
jar {
    from {
        configurations.compile.collect {
            it.isDirectory() ? it : zipTree(it)
        }
        configurations.runtime.collect {
            it.isDirectory() ? it : zipTree(it)
        }
    }
    manifest {
        attributes 'Main-Class': 'script1'
    }
}

---

To build and execute:

 $ gradle build $ java -jar build/libs/scripts/scripts.jar Hello World! 

---

The Groovy Environment Manager (GVM) makes it easy to install and manage Groovy and related tools including Gradle .

Answer 3

First of all, if you compile the .groovy file, you would get the same .class files.

That out of the way, I want to mention an alternative, but I don't advise using that.

Groovy is very well able to compile dependent .groovy files at runtime. The first requirement is that the files follow the java conventions for packages. For example if you have the class Foo in package bar in a .groovy file the file must be in ./bar/Foo.groovy and the root directory "." must be on the classpath.

The second requirement is that Groovy must be able to clearly recognize the class as class and that it cannot be a property. So for example "def a = Foo.class" alone, is not clear, since Foo could be a property. A "import bar.Foo" makes things clear. Same for usage of the class in class-, interface-, field- or method-headers, as well as in catch clauses and new-instance expressions.

The third requirement is that a GroovyClassLoader is used for looking up the class.

If you use the groovy command from the command line, then this is the case. The groovy command will put the current directory on the classpath as well.