Какова цель свойства классификатора объявлений зависимостей Mavens?

81

У меня есть файл pom.xml, и я вижу, что это 3 зависимости, на которые ссылаются, для тех же <artifactId>различий в тегах

<classifier>sources</classifier>
<classifier>javadoc</classifier>

Я удалил зависимости, которые имели, SOURCES/JAVADOCи сохранил только одну зависимость. Я протестировал свое приложение, и все работает нормально.

Какова цель использования этого тега классификатора? и почему мне нужно дважды дублировать зависимости для добавления <classifier>тега с SOURCES/JAVADOC.

<dependency>
   <groupId>oauth.signpost</groupId>
   <artifactId>signpost-commonshttp4</artifactId>
   <version>1.2.1.2</version>
   <type>jar</type>
   <scope>compile</scope>
</dependency>
  <dependency>
   <groupId>oauth.signpost</groupId>
   <artifactId>signpost-commonshttp4</artifactId>
   <version>1.2.1.2</version>
   <type>jar</type>
      ***<classifier>javadoc</classifier>***
   <scope>compile</scope>
</dependency>
<dependency>
   <groupId>oauth.signpost</groupId>
   <artifactId>signpost-commonshttp4</artifactId>
   <version>1.2.1.2</version>
   <type>jar</type>
   ***<classifier>sources</classifier>***
   <scope>compile</scope>
</dependency> 
Пушья
источник

Ответы:

65

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

Источник

Бисваджит
источник
1
Согласно документу, «что источники классификаторов и javadoc используются для развертывания исходного кода проекта и документации API вместе с упакованными файлами классов», что это означает? Я думаю, что это причина, по которой мой pom.xml использует его. Почему вам нужно развертывать документы API и исходный код вместе с упакованными классами. Разве развертывание упакованных классов недостаточно?
pushya 03
6
@pushya обычно, когда вы развертываете свои артефакты в общедоступном репозитории, таком как Maven central, вы включаете javadocs и источники, чтобы IDE с поддержкой Maven могли выполнять правильное завершение кода и всплывающие окна JavaDoc, а также могли переходить в код библиотеки при отладке.
Ян Робертс
@IanRoberts, теперь это имеет смысл. Значит, это означает, что я могу удалить зависимости, которые имеют "SOURCE / JAVADOC", и они являются необязательными и в основном служат для удобства разработчиков при кодировании?
pushya 03
1
@pushya Скорее всего, да. Попробуйте и посмотрите, что произойдет.
Ян Робертс
15

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

Предположим, вам нужны две версии артефакта: для openjpaи для eclipselink- скажем, потому что jar содержит объекты, которые необходимо специально улучшить реализацию JPA.

У вас может быть другая обработка этих сборок, определенных в профилях Maven, и используемые профили также имеют свойство <classifier /> .

Для того, чтобы построить по- разному объявление версии, в затем будет сконфигурирован followinglypommaven-jar-plugin

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-jar-plugin</artifactId>
   <version>3.0.2</version>
   <configuration>
       <classifier>${classifier}</classifier>
   </configuration>
</plugin>

Установка обоих приведет к тому, что файлы в репо будут примерно такими:

org / example / data / 1.0.0 / data-1.0.0.pom
org / example / data / 1.0.0 / data-1.0.0-openjpa.jar
org / example / data / 1.0.0 / data-1.0. 0-eclipselink.jar

Теперь вопрос только в том, какой из classifierних использовать, например, для OpenJPA:

<dependency>
   <groupId>org.example</groupId>
   <artifactId>data</artifactId>
   <version>1.0.0</version>       
   <classifier>openjpa</classifier>
</dependency>

а для EclipseLink вы должны переключить классификатор как:

<classifier>eclipselink</classifier>
пирхо
источник
Где я могу найти объяснение этого синтаксиса: <classifier> [openjpa | eclipselink] </classifier>
Алан Снайдер
@AlanSnyder, это был просто «ярлык ленивого программиста», а не какой-то реально работающий синтаксис. Я отредактировал эту часть, чтобы было понятнее. [openjpa|eclipselink]был просто «селектором» для выбора любого из них.
pirho
7

Пример для классификатора
В качестве мотивации для этого элемента рассмотрим, например, проект, который предлагает артефакт, ориентированный на JRE 1.8, но в то же время также артефакт, который все еще поддерживает JRE 1.7. Первый артефакт может быть оснащен классификатором jdk18, а второй - jdk14, чтобы клиенты могли выбирать, какой из них использовать.

Еще один распространенный вариант использования классификаторов - необходимость прикрепления вторичных артефактов к основному артефакту проекта. Если вы просмотрите центральный репозиторий Maven, вы заметите, что источники классификаторов и javadoc используются для развертывания исходного кода проекта и документации API вместе с упакованными файлами классов.

Vishal Sahasrabuddhe
источник
3

Он позволяет различать два артефакта, которые принадлежат одному POM, но были созданы по-разному, и добавляются к имени файла после версии.

Например, если у вас есть другие артефакты в вашем репозитории (документы, источники ...), вы можете ссылаться на них и добавлять их в свой проект в качестве зависимости. в этом коде, добавив, <classifier>sources</classifier>мы получаем sources.jar из репозитория.

    <dependency>
    <groupId>oauth.signpost</groupId>
    <artifactId>signpost-commonshttp4</artifactId>
    <version>1.2.1.2</version>
    <type>jar</type>
    ***<classifier>sources</classifier>***
    <scope>compile</scope>
    </dependency> 

на самом деле это позволяет вам определять ваши зависимости с более высоким уровнем детализации.

Мистер Кью
источник
0

Согласно следующему: https://blog.packagecloud.io/eng/2017/03/09/how-does-a-maven-repository-work/ тег классификатора подразумевает «Вторичный артефакт», который его «транзитивная зависимость» будет отрезан! Таким образом, тег классификатора не только изменяет "Maven Coordinate" на $ artifactId- $ version- $ classifier.jar!

Чжу Фэй
источник