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

当应用程序完全包含在一个.groovy文件中时，不会生成.class文件。但是，当我将这些类分离到单独的文件中并将它们放在包中时，最终生成了数百个.class文件（大多数文件来自单独编译为字节码的所有闭包）

当所有这些文件都已生成并最终导致文件夹混乱时，管理文件系统的最佳方法是什么

我应该把所有的东西都放在一个文件里吗？这是最干净的方法 但是我最终得到了一个大的.groovy文件，没有 逻辑分离

我应该把所有东西都装进罐子里吗？那个 可以，但会降低脚本的灵活性 直接运行，必要时进行小更改

我是否忽略了.class文件

选项2是最好的，前提是您使用像这样的构建工具。我们的DevOps团队使用Groovy，并提供自包含的zip文件

作为一个简单的例子，请看

它提供

warO.zip

，可将拉链解压缩到：

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

由于清单是使用主类和类路径设置的，因此用户可以使用以下命令执行：

java-jarwaro.jar

你的用户观众会喜欢它的。他们甚至不需要安装Groovy，只需要安装JRE

---

关于开发周期，对脚本的编辑确实没有那么快，但通过添加Gradle任务（或简单脚本），可以轻松地自动化构建、本地部署和执行的步骤。

使用脚本和嵌入式Groovy构建可执行jar非常简单

其优点是在部署到生产环境之前验证脚本是可编译的并经过单元测试

下面是一个例子：

scripts/src/main/groovy/script1.groovy

println "Hello World!"

def aTestableMethod() {
    1 + 1
}

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

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

---

scripts/src/test/groovy/script1Test.groovy

println "Hello World!"

def aTestableMethod() {
    1 + 1
}

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

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

---

脚本/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'
    }
}

---

要构建和执行：

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

---

---

使安装和管理Groovy及相关工具变得容易，包括。

首先，如果编译.Groovy文件，您将获得相同的.class文件

顺便提一下，我想提一个替代方案，但我不建议使用它

Groovy非常能够在运行时编译依赖的.Groovy文件。第一个要求是文件遵循包的java约定。例如，如果在.groovy文件的包bar中有类Foo，则该文件必须位于./bar/Foo.groovy中，并且根目录“.”必须位于类路径上

第二个要求是Groovy必须能够清楚地将类识别为类，并且它不能是属性。因此，例如“defa=Foo.class”本身并不清楚，因为Foo可能是一个属性。“import bar.Foo”让事情变得清晰。在类、接口、字段或方法头中，以及在catch子句和新实例表达式中使用类的情况也是如此

第三个要求是使用GroovyClassLoader查找类

---

如果从命令行使用groovy命令，则情况就是这样。groovy命令也将把当前目录放在类路径上

您应该保持逻辑的分离，并使用您的构建工具（gradle或其他工具）创建一个“/target”文件夹，以将生成的类收集到该规范化文件夹中。我一直在考虑使用gradle进行构建，但考虑到.groovy文件可以直接执行，它为工作流添加了一个步骤。我想我不能两全其美（直接从文本灵活执行和干净部署）。谢谢你的建议。我同意，我认为从长远来看，清洁部署更灵活、更可靠。谢谢你。事实上，我已经开始使用渐变方法，它在创建uber jar时工作得很好。这是一个项目，如果你很好奇的话，它仍然是一个正在进行的工作，因为我正在从一个本地svn repo过渡到github。我昨天开始使用这种方法，但后来改为使用gradle，所有工作都很好，与jar输出一样。谢谢你的意见！这不包括我的源代码（即src/org…）。我尝试了很多不同的build.gradle配置，但似乎缺少了一些基本的东西（我曾经是一名.Net开发人员）。总之，它完美地完成了我所有的依赖项和元内容，但遗漏了实际的代码，有什么想法吗？