Как правильно предоставить arg для многих файлов * .jar в аргументе -cp для компиляции в Unix? - PullRequest
0 голосов
/ 30 декабря 2018

У меня есть git-репозиторий, который загружает файлы .java на рабочий сервер, когда выполняется передача в определенную ветку.(Работает) Я использую Debian 9 с пакетом openJDK.(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 старше соответствующего файла ItemActionPacketListener.java в / server / src / com / ruse / net / packet / impl/

  • Я выполняю эту команду в каталоге / 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

Вот изображение структуры папки: folder structure

Для справки, воткоманда, которую я использую для запуска сервера (работает)

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

Iпопытался предоставить аргументы -cp или -classpath, которые яОднако по-разному javac не может ссылаться на файлы .jar во время компиляции.

Вот различные команды javac, которые я пробовал:

  • javac -путь к классу "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

нахоion: класс 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 не существует

import org.jboss.netty.buffer.ChannelBuffer;

                        ^

src / com / ruse / util / Misc.java: 750: ошибка: не удается найти символ

   public static String readString(ChannelBuffer buffer) {

                                   ^

символ:класс ChannelBuffer

расположение: класс Разное

src / com / ruse / world / content / dialog / DialogueManager.java: 6: ошибка: пакет com.google.gson не существует

import com.google.gson.Gson;

                 ^

1 Ответ

0 голосов
/ 30 декабря 2018

Отдельный не ответ: вы говорите о реальном проекте и требованиях.

В реальном мире вы не запускаете javac вручную.Вместо этого вы используете систему сборки, такую ​​как maven или gralde.Вы определяете структуру проекта, которая включает в себя необходимые библиотеки.

И тогда вы позволяете системе сборки делать все неприятные детали.Все остальное означает: вы тратите усилия, чтобы создать свою собственную несовершенную систему сборки.

Итак: не изобретайте велосипед!Эта проблема решена, и все, что вы придумали, будет менее мощным и намного более подверженным ошибкам, чем такие зрелые системы сборки.

Обновление: когда ваша команда предпочитает следовать менее эффективным стратегиям, а у вас нетКакое-либо кредитное плечо, тогда лучшим вариантом будет подавать пример.Нравится: создать рабочую настройку сборки и определение проекта, используя gradle.Затем покажите своим товарищам по команде, насколько хорошо эта установка работает с Eclipse.Как вы можете использовать его, чтобы сохранить полный контроль над тем, что строит, когда и как.

Люди часто нервничают по поводу изменений, но они часто открыты, когда вы можете показать им преимущества рабочего решения!

...