Что такое "Требуемые автомодули на основе имен файлов". предупреждение означает?

В моем мультимодульном проекте я создал 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;
}