Что такое "Требуемые автомодули на основе имен файлов". предупреждение означает?
В моем мультимодульном проекте я создал module-info.java
только для нескольких модулей. И во время компиляции с maven-compiler-plugin:3.7.0
я получаю следующее предупреждение:
[ВНИМАНИЕ] * Определены необходимые автомодули на основе имени файла. Пожалуйста, не делайте опубликовать этот проект в общедоступном хранилище артефактов! *
Что это значит? Это потому, что у меня есть только несколько модулей с module-info.java
, а не весь проект?
Ответы
Ответ 1
Автоматическое обновление модуля
Явный модуль (т.е. один с module-info.java
) может получить доступ только к коду модулей, который он требует (игнорируя Автоматические модули - это ответ: Любой JAR, который заканчивается на пути к модулю, превращается в модуль. Если JAR не содержит объявления модуля, система модулей создает автоматический модуль со следующими свойствами:
- выводимое имя (это важный бит здесь)
- читает все остальные модули
- экспортировать все пакеты
Maven полагается на этот механизм, и после создания module-info.jar
он помещает все зависимости в путь модуля.
Автоматические имена
Существует два способа вывода имени автоматического модуля:
- запись в манифесте
- Предположим, что имя файла JAR
В первом случае имя было намеренно выбрано сопровождающим, поэтому его можно считать стабильным (например, он не изменяется, когда проект становится модульным). Второй, очевидно, нестабилен по всей экосистеме - не все настройки проекта приводят к тем же самым именам файлов их зависимостей.
Что это значит?
Причиной предупреждений является то, что некоторые из ваших зависимостей являются автоматическими модулями и не определяют их имя будущего модуля в манифесте. Вместо этого их имя происходит от имени файла, что делает их нестабильными
Стабильные имена
Итак, почему неустойчивые имена такие проблемы? Предположим, что ваша библиотека публикуется с помощью requires guava
, и мои рамки публикуются с помощью requires com.google.guava
. Теперь кто-то использует вашу библиотеку с моей картой, и им вдруг нужны модули guava и com.google.guava на их пути к модулю. Нет ничего безболезненного решения этой проблемы, поэтому ее нужно предотвратить!
Как? Например, препятствуя разработчикам публиковать артефакты, зависящие от автоматических модулей на основе файлов. 😉
Ответ 2
[ПРЕДУПРЕЖДЕНИЕ] * Определены необходимые автомодули на основе имени файла. Пожалуйста, не делайте опубликовать этот проект в общедоступном хранилище артефактов! *
Это потому, что у меня есть только несколько модулей с module-info.java, а не весь проект?
Нет, это не из-за нескольких модулей, перечисленных в module-info.java
, но сгенерированных maven-compiler-plugin
для всех автоматических модулей найденных в графе модулей.
Что это значит?
Нельзя публиковать текущий проект, вероятно, потому, что ожидается, что автоматические модули будут преобразованы в именованные или явные модули их владельцами, а затем опубликованы в репозитории, которые могут привести к изменению их имени модуля. Кроме того, здесь следует обратить внимание на то, что в соответствии с документом прогресса Maven ~ > Java+9+-+Jigsaw они все еще не полностью готовы с JDK9 совместимые версии плагинов.
Просто изобразите пример такого использования. Подумайте над этими строками -
- Я опубликовал артефакт
com-foo-bar:1.0.0-SNAPSHOT:jar
.
- От этого зависит мой проект
com-xyz:1.0.0
.
- В конечном итоге ваш проект полагается на
com-foo-bar
транзитивно через com-xyz
-
Вы планируете модулировать свой код и использовать что-то вроде
module your.module {
requires com.foo.bar;
requires com.xyz;
}
(вам нужно указать транзитивные зависимости в объявлениях модуля отдельно)
- Все работало нормально, но до тех пор, пока я решил модулизовать свои библиотеки.
- Теперь первое, что я сделал, это назвать мои модули!
-
И я сделал что-то фантастическое, чтобы явным образом изложил свои усилия следующим образом: -
module modular.com.foo.bar {}
-
Я в конечном итоге нарушаю код любой зависимой библиотеки и, в конечном счете, любой, который зависит от вашего, модульным способом.
Примечание. Я согласен с тем, что я не использую SNAPSHOT в производстве, но могут быть случаи, когда вы в конечном итоге полагаетесь на артефакт, который все еще находится в стадии разработки.
Изменить. Из комментариев @khmarbaise
Он понимал, что люди захотят публиковать в артефактах, но если они не знают о последствиях, которые вы будете избиты в будущее этим. Maven хотел бы дать понять, что ПРЕДУПРЕЖДЕНИЕ в этом случае очень серьезный, который мог бы быть НЕИСПРАВНОСТИ, но это было бы плохой пользовательский интерфейс для работы.
Идеальный способ справиться с этим состоит в том, что владельцы библиотек планируют перенести свои артефакты на JDK9, а дерево пересекается снизу вверх, и в этом случае названный/явный модуль будет единственным аспектом, существующим без необходимости автоматического имена модулей и такие предупреждения.
Ответ 3
С maven-compiler-plugin v3.7.0
это информационное сообщение. Не уверен, почему вы видите это как предупреждение...
Вот что я получаю, когда создаю свой проект на основе Java 10 с помощью module-info.java
:
[INFO] Required filename-based automodules detected. Please don't publish this project to a public artifact repository!
Ответ 4
Я получил это предупреждение, когда в своем файле module-info.java я добавил класс из самого модуля, мне пришлось сделать это для отладки моего тестового файла в NetBeans, но это явно неправильно, так как это не модуль..
module net.my.package.xy
{
requires java.logging;
requires java.naming;
requires javax.jms.api;
//THAT GENERATES THE WARNING:
exports net.my.package.xy.MyClass;
}