Java Groovyc*.groovy奇怪的行为

我有一大堆groovy文件，我用groovyc编译成java类文件（因为启动java要比启动groovy运行一个短脚本快一点）。所有脚本都在默认包中，但它们共享在“.support”包中定义的一些公共功能

我刚刚重新设计了它，发现了一个令人惊讶的奇怪问题——当我使用：

cd /D c:\scripts
groovyc -d c:\destPath *.groovy
cd support
groovyc -d c:\destPath *.groovy

一切都很顺利

但当我以我期望的方式编译时：

groovyc -d c:\destPath c:\scripts\*.groovy

它只会编译其中一个脚本（我相信它是按字母顺序排列的最后一个）

---

有人对此行为有解释吗？

这似乎是由于执行

groovyc

可执行文件的包装批处理脚本造成的

在Windows上，

groovyc

命令将启动名为

startGroovy.bat

的批处理脚本：

"%DIRNAME%\startGroovy.bat" "%DIRNAME%" org.codehaus.groovy.tools.FileSystemCompiler %*

我不是批处理文件方面的专家，但是如果你仔细观察一下

startGroovy.bat

，你会很容易注意到在

*

通配符上有某种黑客行为，它被作为参数传递给脚本（例如

c:\scripts\*.groovy

）：

如果通过在命令行中执行

set DEBUG=on

来打开回显，然后再次执行

groovyc

命令，您将获得批处理脚本的输出，从中可以看到通配符是如何处理的。下面是一个示例日志，其中有3个文件名为

File1.groovy

、

File2.groovy

和

File3.groovy

groovyc -d c:\destPath c:\scripts\*.groovy

样本输出：

C:\scripts>set _ARG=C:\scripts\File3.groovy 

C:\scripts>set _ARG=C:\scripts\File3.groovy 

C:\scripts>set _ARG=C:\scripts\File3.groovy 

C:\scripts>set CMD_LINE_ARGS= C:\scripts\File3.groovy 

C:\scripts>set _ARG= 

---

脚本似乎忽略了前两个文件，最终只将最后一个文件传递给

org.codehaus.groovy.tools.FileSystemCompiler

类（实际的编译器）。当

*

通配符是源文件路径中的第一个字符时，这种行为就不存在了。

在我的ubuntu框中，只有当

-d

参数最后出现或者没有脚本被编译时，这种行为才会起作用。这很有趣，我想我看到了-d必须首先出现的地方。回答很好，谢谢。听起来像是windows批处理集成中的groovy bug——我很惊讶我在任何地方都没有看到报告。我不喜欢深入研究那些groovy批处理文件，它们看起来既复杂又脆弱——但我只是认为我做错了什么。应该知道比假设更好。

C:\scripts>set _ARG=C:\scripts\File3.groovy 

C:\scripts>set _ARG=C:\scripts\File3.groovy 

C:\scripts>set _ARG=C:\scripts\File3.groovy 

C:\scripts>set CMD_LINE_ARGS= C:\scripts\File3.groovy 

C:\scripts>set _ARG=