Search code examples
javacompilationjavacdebian-stretch

How do I properly provide arg for many *.jar files in -cp argument for compilation on Unix?

I have a git repository which pulls down .java files to a production server when a push is made to a specific branch. (Working) I'm running Debian 9 with the openJDK package. (jdk 1.8.0)

I've decided to compile the new .java files on the server, then execute them. My issue is that while specifying the -cp arg as "lib/*.jar", during compilation I get: error package jar.example.class does not exist import jar.example.class;

And so forth for each reference to any information referenced from another .lib file.

Important: The closest I've gotten is this command, which produces no output but does not compile the entire project.

  • javac -classpath "bin:lib/*.jar" -d "bin/" "src/com/ruse/GameServer.java"

For example: in /server/bin/com/ruse/net/packet/impl/ the .class file is older than the corresponding ItemActionPacketListener.java file in /server/src/com/ruse/net/packet/impl/

  • I am running this command in the /home/rsps/server directory.
  • The .jar files exist in /home/rsps/server/lib folder.
  • The .src files exist in /home/rsps/server/src folder.
  • The .bin files are expected to output in /home/rsps/server/bin folder.
  • The "main" class is void Main found in src/com/ruse/GameServer.java

Here's an image of the folder structure: folder structure

For reference, here is the command I have been using to run the server (which works)

  • java -server -Xmx2148m -classpath bin:lib/* com.ruse.GameServer

I've tried providing the -cp or -classpath arguments in different ways, however, javac seems to fail to reference the .jar files during compilation.

Here are the various javac commands I've tried:

  • javac -classpath "lib/*.jar" -d "bin/" "src/com/ruse/GameServer.java"

  • javac -sourcepath /home/rsps/server/src/.java -classpath classes: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"

I expected the output to be the fresh .class files, however the actual results have all been a variation of below:

  • javac -classpath "lib/*.jar" -d "bin/" "src/com/ruse/GameServer.java"

results in:

symbol: class ChannelBuffer

location: class PacketBuilder

src/com/ruse/world/World.java:11: error: package com.google.common.util.concurrent does not exist

import com.google.common.util.concurrent.ThreadFactoryBuilder;

                                   ^

src/com/ruse/util/Misc.java:26: error: package org.jboss.netty.buffer does not exist

import org.jboss.netty.buffer.ChannelBuffer;

                        ^

src/com/ruse/util/Misc.java:750: error: cannot find symbol

   public static String readString(ChannelBuffer buffer) {

                                   ^

symbol: class ChannelBuffer

location: class Misc

src/com/ruse/world/content/dialogue/DialogueManager.java:6: error: package com.google.gson does not exist

import com.google.gson.Gson;

                 ^
Solution

  • A distinct non answer: you are talking about a real world project and requirements.

    In the real world, you don't invoke javac manually. Instead you use a build system like maven or gralde. You define a project structure which includes the required libraries.

    And then you let the build system do all the pesky details. Anything else means: you spending efforts to create your own deficient build system.

    So: do not reinvent the wheel! This problem is solved, and whatever you come up with will be less powerful and much more error prone than such mature build systems.

    Update: when your team prefers to follow less efficient strategies, and you don't have any leverage, then the best option is to lead by example. Like: create a working build setup and project definition using gradle. Then show your team mates how nicely that setup works with eclipse. How you can use it to keep full control of what gets build, and when and how.

    People are often nervous about changes, but they are often open when you can show them the advantages of a working solution!