Пакет com.faizan.org доступен более чем из одного модуля: ProjectA, ProjectB с использованием JDK 9+ во время сборки в Eclipse 2019-12.

У меня есть 2 проекта, скажем ProjectA и ProjectB, оба содержат пакет com.faizan.org. ProjectA добавляется в путь к модулям ProjectB.

<classpathentry combineaccessrules="false" kind="src" path="/ProjectA">
    <attributes>
        <attribute name="module" value="true"/>
    </attributes>
</classpathentry>

Теперь я пишу новый класс в ProjectB, которому нужно импортировать класс из com.faizan.org из ProjectA, но получаю сообщение об ошибке Пакет com.faizan.org доступен из более чем одного модуля: ProjectA, ProjectB в eclipse 2019-12 с использованием openJdk 12 и соответствия компилятора также установлено значение 12.

Как я могу добавить внешние проекты, содержащие такое же имя пакета, в другой проект без конфликтов путей к классам? Также в некоторых случаях невозможно получить доступ к методам суперкласса.


module-info java-9 classpath superclass
person Faizan Mirza    schedule 20.02.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Простой ответ: вы не можете.

Когда вы настраиваете свои проекты Eclipse как модули Java, правила модульной системы JPMS запретить, чтобы любой модуль имел доступ к одному и тому же пакету из двух модулей (каждый пакет должен быть "уникально видимый").

Затем вам следует вернуться к вопросу, почему вам нужно иметь один и тот же пакет в обоих проектах? Если это тестирование белого ящика, рассмотрите возможность переноса тестов в тот же проект, но в отдельную исходную папку, помеченную как содержащую тесты. Затем Eclipse сделает всю необходимую разводку за кулисами, чтобы тесты были частью модуля и не частью модуля одновременно.

Если это не ради тестирования белого ящика, и вы хотите внедрить JPMS, у вас остается 2,5 варианта:

  1. Переместите весь код, который использует общий пакет, в один и тот же проект/модуль.
  2. Измените структуру пакета, чтобы избежать разделения пакета.
  3. (Используйте хитрый набор параметров JPMS, включая --patch-module и, возможно, другие, чтобы позволить JPMS просматривать отдельные проекты как один модуль — хотя это и возможно, я бы расценил это как "успешную миграцию")
person Stephan Herrmann    schedule 20.02.2020
comment
Я работаю над каким-то устаревшим проектом с указанной структурой и пытаюсь перенести стек на Java 12/13. Следовательно, мне нужно подать жалобу на сборку JDK 12 приложения, максимально сохранив структуру. Кроме того, это большое приложение, которое может потребовать больших затрат на реструктуризацию всех зависимостей. Есть ли способ добиться того же? - person Faizan Mirza; 21.02.2020
comment
Вы не показали, есть ли у вас модуль-info.java. Если вы не пометите зависимость проекта как немодулярную (переместите ее в путь к классам вместо пути к модулю), это позволит вам работать в устаревшем/немодульном режиме, где только JRE рассматривается как модульная, а не код вашего приложения. . Но это будет лишь частичный переход на Java 9+. - person Stephan Herrmann; 22.02.2020
comment
Привет, у меня нет файла module-info.java в моих модулях. Однако я ожидал, что компилятор выберет первый подходящий пакет из пути к модулям в случае совпадения имен. Однако, как было предложено, я попытался переместить свои внешние JAR-файлы в путь к классам, но все же это не помогло. У меня есть jbossallclient jar, который содержит пакет javax.management, и у jdk он тоже есть. Это приводит к следующей ошибке: Пакет javax.management доступен более чем из одного модуля: ‹unnamed›, java.management - person Faizan Mirza; 24.02.2020
comment
@FaizanMirza, оставшаяся ошибка с упоминанием ‹unnamed› такая же, как обсуждалось в stackoverflow.com/questions/51094274/ Короче говоря: наличие javax.management вне JRE по существу незаконна. Лучше всего избегать этой зависимости в первую очередь. Если вы не можете, вы будете экспериментировать с --limit-modules или, что более удобно, с помощью вкладки «Зависимости модуля» конфигурации пути сборки Java, чтобы исключить этот системный модуль. - person Stephan Herrmann; 25.02.2020
comment
@FaizanMirza, если вы видите ответ на свой первоначальный вопрос, рассмотрите возможность принятия ответа. Если у вас есть последующие проблемы, не стесняйтесь комментировать, чтобы мы могли разобраться, есть ли уже ответ на связанный вопрос (относительно ‹безымянного›), заслуживает ли он нового вопроса или подобного. - person Stephan Herrmann; 25.02.2020