2014-01-03 2 views
49

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

<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> 

ответ

39

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

детали проверить http://maven.apache.org/pom.html

+0

Согласно документу говорит «, что источники классификаторы и Javadoc используются для развертывания исходного кода проекта и API документации по с пакетами файлов классов ", что это значит? Я думаю, что именно поэтому мой pom.xml использует его. Зачем вам нужно развернуть документы API и исходный код вместе с упакованными классами. Разве не развертываются упакованные классы недостаточно хорошо? – pushya

+4

@pushya обычно при развертывании ваших артефактов в публичном репозитории, таком как Maven central, вы включаете javadocs и источники, чтобы среды IDE с поддержкой Maven могли выполнять правильное завершение кода и всплывающие окна JavaDoc и могут входить в код библиотеки при отладке. –

+0

@IanRoberts, которые имеют смысл сейчас. так что я могу удалить зависимости, которые имеют «SOURCE/JAVADOC», и они являются необязательными и в основном служат той цели, которая является дружественной разработчику при кодировании? – pushya

5

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

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

0

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

Например, если у вас есть другие артефакты в вашем репозитории (документы, источники ...), вы можете ссылаться на них и добавлять их в свой проект как зависимость. в этом коде, добавив <classifier>sources</classifier>, мы получаем source.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/ классификатор тега означает «Secondary Артефакт», который его «транзитивной зависимостью» будет отрезать! Таким образом, тег классификатора не только меняет «Maven Coordinate» на $ artifactId- $ version- $ classifier.jar!

0

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

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

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

Чтобы построить по-разному засекреченные версии, в pommaven-jar-plugin затем будет сконфигурирован followingly

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

Установка и приведет к файлам в чем-то репо, как это:

орг/пример/данные /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, к которому одного использования, так

<dependency> 
    <groupId>org.example</groupId> 
    <artifactId>data</artifactId> 
    <version>1.0.0</version> 
    <classifier>[openjpa|eclipselink]</classifier> 
</dependency> 
Смежные вопросы