Использование пользовательского типа упаковки в качестве зависимости в maven
Я создал собственный тип упаковки в своем плагине maven, чтобы я мог развертывать файлы в этом пользовательском формате.
Например. У меня есть проект, который использует этот формат для упаковки. pom.xml имеет:
<project xmlns = "http://maven.apache.org/POM/4.0.0" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>mylib</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>mybin</packaging>
....
Я могу успешно развернуть в репозиторий. Но теперь я хочу использовать это как зависимость в другом проекте.
Например. добавив что-то вроде этого:
<dependency>
<groupId>com.example</groupId>
<artifactId>mylib</artifactId>
<version>1.0-SNAPSHOT</version>
<type>mybin</type>
</dependency>
Это работает нормально, за исключением того, что формат mybin включает в себя некоторые вложенные ресурсы, такие как файлы jar), которые я хотел бы включить в путь к классам.
До сих пор я пытался программно извлечь банки из моджо и программно добавить их в проект с помощью project.getModel().addDependency(systemJarDep), но компилятор, похоже, не улавливает это.
Как это можно сделать в Maven?
У меня есть собственный формат файла, который в основном представляет собой zip-файл с вложенными ресурсами. Некоторые из этих вложенных ресурсов представляют собой файлы jar, которые я хотел бы включить в путь к классам.
Если банка внутри молнии, это не сработает...
Значит, нет API, который я мог бы реализовать в плагине, который позволил бы мне переопределить способ разрешения ресурсов? Есть ли какой-либо тип зависимости, кроме jar, который поддерживает добавление в путь к классам?
Я до сих пор не понимаю, зачем вы вставляете банки в застежку-молнию. Почему бы не объявить их в POM и позволить Maven сделать разрешение?
Файл «zip» включает в себя вложенные файлы jar, которые используются для разных платформ. Он включает файлы CSS, собственные библиотеки, собственные исходные файлы, некоторые файлы jar с скомпилированными классами и другие файлы jar с исходными кодами, которые компилируются во время выполнения. Я хочу иметь возможность поделиться зависимостью как одним красивым фрагментом <dependency>. Я не хочу, чтобы пользователям приходилось копировать и вставлять три страницы XML в свой проект, чтобы они могли использовать эту зависимость. Итак, вы говорите, что maven не может разрешить какие-либо зависимости от пути к классам, кроме файлов jar?
Никому не нужно копировать/вставлять три страницы XML. Maven автоматически разрешает транзитивные зависимости. Если у вашей зависимости есть дополнительные зависимости, Maven загружает их без дополнительной настройки.
Я не уверен, как это сработает. Мой пользовательский тип пакета включает все необходимые зависимости. Эти зависимости «построены» во время сборки моего пользовательского пакета. Итак, как мне сообщить maven об этих зависимостях? Я включил зависимость в свой собственный артефакт пакета. Есть ли другой тип упаковки, который я должен использовать для создания зависимостей?
Как уже писал Дж. Фабиан Мейер, вы должны использовать механизм Maven по умолчанию и не пытаться предотвратить его ... это усложняет использование ... Итак, наконец, вы создали свой собственный тип упаковки для упаковки разных банок в один пакет. Если это так, это означает, что вы заново изобрели велосипед. Похоже, вы должны использовать стандартные механизмы. JAR — это определенный формат, который содержит классы. zip-файл, который имеет ту же структуру, что и jar, также будет работать (но не может быть определен в Maven как зависимость), но zip-файл имеет другую структуру и не поддерживается ни Maven, ни Java (JVM).
Кроме того, то, что я читал о вашем типе, который содержит исходные файлы (Java?), Которые скомпилированы во время выполнения, звучит странно для меня, а ресурсы, такие как файлы CSS, являются обычными ресурсами, которые могут быть упакованы как обычный файл jar, который можно поместить в путь к классам в java можно просто загрузить через getResources/getRecourceAsStream...
Еще одна точка нативных библиотек? Какие нативные библиотеки? Привязка через JNI? Для каких платформ? Это приведет к тому, что вся ваша сборка зависит от платформы...
Много комментариев, предлагающих просто использовать встроенные механизмы, а не изобретать велосипед. Хотелось бы, но их недостаточно. Многие ресурсы в этом пакете (включая файлы CSS) вообще не должны находиться в пути к классам. Они просто должны быть доступны для плагина Maven для достижения определенных целей. Файлы CSS, например, не должны загружаться через getResourceAsStream().
@khmarbaise Нативные файлы — это файлы, которые будут использоваться плагином maven для создания определенных целей, таких как приложения для iOS, приложения для Android, собственные настольные приложения и т. д. Они не являются JNI. У нас есть устоявшаяся кроссплатформенная цепочка инструментов, но мы используем ANT. Сейчас пытаюсь перейти на maven. Maven гораздо менее гибкий - может не справиться с этим. Но пытаюсь.
Эта информация была бы полезна в начале, потому что iOS и т. д. Я бы предложил не пытаться через Maven ... и да, у Maven есть свои ограничения по уважительным причинам ... возможно, также способ kotlin для Android и т. д. может быть лучшим решением и...
@khmarbaise Спасибо, что нашли время помочь. «Это невозможно» по-прежнему является ответом, который помогает прокладывать путь вперед. Этот обмен был полезен для меня.
Ответы 1
Кажется, что такого рода вещи не могут быть сделаны в Maven.
Я решаю свою проблему, настраивая формат моего пользовательского типа пакета, чтобы он был самим файлом jar со всеми классами, которые мне нужны, в пути к классам непосредственно внутри него. Другие подресурсы, которые мне не нужны в пути к классам (по крайней мере, по умолчанию), связаны внутри каталога META-INF.
Это не идеально, но на данный момент приемлемое решение.
Ресурсы принадлежат корню JAR, а не каталогу META-INF. Теперь, что вы собираетесь заново изобрести maven-shade-plugin (который имеет некоторые недостатки и т. д.)
@khmarbaise Эти ресурсы не должны быть доступны в пути к классам. Это не переизобретение плагина тени. Эти ресурсы должны быть доступны только нашему плагину и использоваться для определенных целей. Если я положу их в корень банки, то мне придется проделать дополнительную работу во всех целях, чтобы их отфильтровать.
Итак, вы уже нарушаете стандарты JAR... Каталог META-INF не предназначен для ресурсов. Так что я вижу.. это зависит от вас...
@khmarbaise Исходный «устаревший» формат файла не нарушал никаких стандартов JAR, потому что это не был jar. Ограничения Maven в этой области вынудили меня переформатировать его в банку, поскольку это единственное, что понимает maven. При этом у меня нет другого выбора, кроме как «нарушить» стандарты.
Еще немного исследований и выяснилось, что включение ресурсов в META-INF вообще не нарушает стандарты JAR. На самом деле, именно здесь многорелизные jar-файлы размещают свои файлы .class для конкретной версии. nipafx.dev/multi-release-jars-multiple-java-versions
Почему вы обрабатываете файлы jar как ресурсы? Почему бы не позволить Maven разрешать их транзитивно?