如何在-cp参数中正确地为许多*.jar文件提供arg以便在UNIX上进行编译？

Question

我有一个git存储库，当对特定分支进行推送时，它将.Java文件下拉到生产服务器。（工作）我正在运行带有openJDK包的Debian9。（jdk 1.8.0)

我决定在服务器上编译新的.Java文件，然后执行它们。我的问题是，当将-cp参数指定为“lib/*.jar”时，在编译过程中我得到：错误包jar.example.class不存在import jar.example.class；

对从另一个.lib文件引用的任何信息进行引用，以此类推。

重要：我得到的最接近的命令是这个命令，它不产生输出，但不编译整个项目。

• javac-classpath“bin:lib/*.jar”-d“bin/”“src/com/ruse/gameserver.java”

例如：在/server/bin/com/ruse/net/packet/impl/中，.class文件比/server/src/com/ruse/net/packet/impl/中相应的ItemActionPacketListener.java文件旧

• 我正在/home/rsps/server目录中运行此命令。
• .jar文件存在于/home/rsps/server/lib文件夹中。
• .src文件存在于/home/rsps/server/src文件夹中。
• .bin文件应输出到/home/rsps/server/bin文件夹中。
• “Main”类是void Main，在src/com/ruse/gameserver.java中找到

作为参考，这里是我一直用来运行服务器的命令（它可以工作）

• Java-server-xmx2148m-classpath bin:lib/*com.ruse.gameServer

我尝试过以不同的方式提供-cp或-classpath参数，但是，javac似乎无法在编译期间引用.jar文件。

下面是我尝试过的各种javac命令：

>

javac-classpath“lib/*.jar”-d“bin/”“src/com/ruse/gameserver.java”

javac-sourcepath/home/rsps/server/src/.Java-classpath类：lib/.jar-d bin

javac-classpath“lib/*.jar”-d“bin/”-sourcePath“src/”“src/com/ruse/gameserver.java”

javac-cp“lib/：lib/*”-d“bin/”-sourcePath“src/”“src/com/ruse/gameServer.java”

javac-cp.：/lib/*.jar：-d“bin/”“src/com/ruse/gameServer.java”

我希望输出是新鲜的.class文件，但实际结果都是以下的变化：

• javac-classpath“lib/*.jar”-d“bin/”“src/com/ruse/gameserver.java”

结果如下：

符号：类ChannelBuffer

位置：类PacketBuilder

src/com/ruse/world/world.java:11:错误：包com.google.common.util.concurrent不存在

导入com.google.common.util.concurrent.ThreadFactoryBuilder；

                                   ^

src/com/ruse/util/misc.java:26:错误：包org.jboss.netty.buffer不存在

导入org.jboss.netty.buffer.ChannelBuffer；

                        ^

src/com/ruse/util/misc.java:750:错误：找不到符号

   public static String readString(ChannelBuffer buffer) {

                                   ^

符号：类ChannelBuffer

地点：类杂项

src/com/ruse/world/content/dialogueManager.java：6：错误：包com.google.gson不存在

导入com.google.gson.gson；

                 ^

Answer 1

一个明显的非答案：您正在谈论一个真实世界的项目和需求。

在现实世界中，您不会手动调用javac。相反，您使用像maven或Gralde这样的构建系统。定义一个包含所需库的项目结构。

然后让构建系统处理所有讨厌的细节。任何其他的东西都意味着：你花费了大量的精力来创建你自己的缺陷构建系统。

所以：不要推倒重来！这个问题解决了，无论你想出什么，都不会像这样成熟的构建系统那样强大，更容易出错。

更新：当你的团队更喜欢遵循效率较低的策略，而你又没有任何杠杆作用，那么最好的选择就是以身作则。比如：使用Gradle创建一个工作的构建设置和项目定义。然后向您的团队成员展示该设置在Eclipse中的工作效果。如何使用它来完全控制生成的内容，以及何时和如何生成。

人们经常对变化感到紧张，但当你能向他们展示一个工作解决方案的优点时，他们往往是开放的！