Почему Maven не может сгенерировать декларацию вашего модуля

Не беспокойство

Прежде всего, это не касается зависимости. Зависимость — это ссылка на файл и когда его использовать (время компиляции? Время выполнения?), А не как .

Нет места в POM

Затем из всех элементов зависимости есть только один, который может использоваться для управления более детальным использованием JAR: scope . Однако модель POM modelVersion 4.0.0 имеет строгий набор областей действия. Хотя POM заполнен инструкциями по сборке для Maven, после установки или развертывания он также является метафайлом с информацией о зависимостях для других инструментов сборки и IDE, поэтому новые области действия могут запутать или сломать такие продукты.

По той же причине введение нового XML-элемента для зависимостей было бы проблематичным; это будет конфликтовать с XSD, и другие инструменты еще не готовы к этому. Так что в объявлении зависимостей POM нет места для модульной информации, и в краткосрочной перспективе не следует ожидать нового определения POM только для Jigsaw.

Так как насчет его настройки с помощью maven-compiler-plugin?

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <!-- <version>xyz</version> --> <configuration> <!-- example --> <modulePath> <!-- by dependency? --> <dependency>com.foo.bar:library</dependency> <!-- by module? --> <module>library</module> </modulePath> </configuration> </plugin> 

Но как насчет транзитивных зависимостей, в данном случае зависимостей библиотеки ? Эти зависимости также должны быть разделены на оба пути. Вам нужно настроить это?

В качестве альтернативы мы можем захотеть разрешить информацию о построении зависимости, чтобы определить, где разместить ее зависимости, но это невозможно, поскольку такого рода информация не всегда существует. Даже когда такой JAR-файл был создан с помощью Maven, попытка реверс-инжиниринга контента из JAR в эффективные конфигурации плагинов часто невозможна (подумайте о влиянии нескольких блоков исполнения).

Чтение дескриптора модуля

Так что, если POM — это не тот путь, откуда мы можем получить информацию? Лучше сосредоточиться на файлах внутри JAR как есть, например, module-info.class … (объявление скомпилированного модуля, называемое дескриптором модуля ).

Таким образом, ключевой файл выглядит как файл информации module-info как он точно определяет требования. Когда такие инструменты, как ASM, могут прочитать дескриптор модуля, maven-compiler-plugin может извлечь эту информацию и решить для каждой зависимости, соответствует ли он требуемому модулю. Для нашего проекта должен быть module-info.java чтобы Maven знал, где разместить наши зависимости. Для этого его нужно проанализировать перед компиляцией, что уже возможно с QDox .

Таким образом, со всеми module-info.class внутри JAR и module-info.java нашего проекта можно решить, к module-info.java из них принадлежит каждый JAR; либо путь к классу, либо путь к модулю. Это делает объявления модуля и дескрипторы компонентом для успешной сборки. Но остается вопрос, не может ли это быть и результатом ?

Модуль декларации генератора

Анализируя все дескрипторы модулей, используемые в этом проекте, мы видим, что должна быть возможность разделить все JAR-файлы по пути к модулю и пути к классам. Но возможно ли создать декларацию модуля для нашего проекта?

Для требований в src/main/java/module-info.java мы можем продвинуться довольно далеко. Мы могли бы сказать, что все зависимости с областями, которые compile или provided являются требованиями, конечно, нет, но для runtime (что означает только во время выполнения ) это зависит. Но есть и требования, которые не сопоставлены с JAR. Вместо этого они ссылаются на модуль java или jdk (например, java.sql , java.xml или jdk.packager ). Они должны быть настроены для генератора или код должен быть проанализирован заранее.

Требование также может иметь дополнительные модификаторы. С помощью предложения requires static оператора вы можете указать, что модуль является обязательным при компиляции, но необязательным при выполнении. В Maven вы бы отметили такую ​​зависимость как optional . С помощью модификатора transitive процесса вы указываете, что проектам, использующим этот модуль, не нужно добавлять переходный модуль в свой собственный файл объявления модуля. Таким образом, transitive оказывает никакого влияния на этот проект, он только помогает другим проектам, использующим этот как зависимость. Такая информация может быть предоставлена ​​только в качестве конфигурации.

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

А как насчет экспортированных и открытых пакетов? Может показаться, что они могут быть выведены из анализа кода. Однако анализ java-файлов в качестве источников на этом этапе пока невозможен. Анализ файлов классов в виде двоичных файлов означает двойную компиляцию: сначала только путь к классу, чтобы получить все классы для анализа, а затем путь к модулю и путь к классу, которые являются фактической компиляцией. Там нет никакого возможного решения.

В конце каждая строка в объявлении модуля является выбором разработчика. Имеет ли смысл добавлять конфигурацию в POM, которая уже во многом похожа на файл объявления предполагаемого модуля?

Самое близкое, что мы могли бы получить — это шаблон, подобный следующему. Давайте использовать Velocity и назовем шаблон module-info.java.vm .

 open module MN { #set ( $requiredModules = ... ) ## these must somehow be available in the context ## requires {RequiresModifier} ModuleName ; #set( $transitiveModules = ["org.acme.M1", "org.acme.M2"] ) #foreach( $requiredModule in ${requiredModules} ) #if( $transitiveModules.contains( $requiredModule.name ) ) transitive #end #if( $requiredModule.optional ) static #end ${requiredModule.name} ; #end requires java.sql; requires java.xml; requires jdk.packager; ## exports PackageName [to ModuleName {, ModuleName}] ; exports com.acme.product; exports com.acme.service; ## opens PackageName [to ModuleName {, ModuleName}] ; ## uses TypeName ; ## provides TypeName with TypeName {, TypeName} ; } 

Преобразование этого в module-info.java требует, вероятно, отдельного шаблонного плагина maven, потому что это выходит за рамки задачи компиляции maven-compiler-plugin и копирования ресурсов с помощью дополнительной задачи фильтрации maven-resource-plugin. Это зависит от разработчика, если такой шаблон с некоторым синтаксическим синтаксисом лучше читать и поддерживать по сравнению с простым старым (новым) файлом объявления модуля.

Некоторые, возможно, слышали о jdeps, инструменте, доступном начиная с JDK8, который может анализировать зависимости. Он также имеет возможность генерировать файл объявления модуля, но не так, как мы этого хотим. Jdeps использует только скомпилированные классы, поэтому он должен использоваться после фазы compile . Эта функция была введена для разработчиков, чтобы иметь для начала module-info.java , но после того, как он сгенерирован, он должен настроить и поддерживать его.

Вывод

Если бы существовал генератор декларации модуля, ему все равно потребовалось бы немало конфигурации, чтобы получить правильно полученный файл. Это не будет меньше работы, чем просто запись файла напрямую. Все вместе, написание и ведение декларации модуля самостоятельно дает гарантию, что она всегда будет такой, как вы ожидаете.

Конечно, некоторые небольшие проекты с открытым исходным кодом будут появляться и пытаться сгенерировать объявление модуля в любом случае, но это будет работать только для подмножества проектов, что означает, что мы не можем предоставить его для Maven.

Я более надеюсь, что IDE решат это за вас. Например, если вы добавляете зависимость в POM, вы можете получить возможность добавить ее как требование к объявлению модуля. Или что они предоставляют мастера, показывающего все зависимости и пакеты из вашего проекта, давая вам возможность, что добавить в файл объявления модуля.

Однако эта часть истории заканчивается, но я здесь, чтобы сказать вам, что в настоящее время Maven не будет писать декларацию вашего модуля для вас.