Ответ 1
Возможно, я ошибаюсь, но если целью классификатора является "отличать артефакты, созданные из одного и того же POM, но отличающиеся по содержанию", то я вижу очень хорошую причину not, чтобы использовать их для scala версий: версии scala не просто бинарные несовместимы, они вполне могут быть исходными несовместимыми. Например, при обновлении scala от 2.7 до 2.8 мне пришлось внести некоторые существенные изменения в базу кода. Если бы я хотел сохранить одновременно версию scala 2.7 и 2.8, мне понадобилось бы создать параллельную ветвь, и обе ветки определенно не имели бы тот же исходный код.
Когда я читаю "из того же POM", я понимаю, что это означает и из того же исходного кода, что явно не относится к этим двум ветвям кода.
Еще одна важная причина заключается в том, что классификатор по существу представляет собой одну строку, которая уже используется для многих вещей. Более или менее стандартные классификаторы включают "источники", "javadoc" или "ресурсы". Значения этих классификаторов одинаковы в проекте scala и полностью ортогональны к версии scala, как я попытаюсь показать.
Документация Maven предлагает использовать такие классификаторы, как "jdk15" или "jdk14", чтобы указать, какая версия jvm была скомпилирована двоичным артефактом. Учитывая, что Java-код имеет обратную совместимость, в принципе артефакты с обоими классификаторами ( "jdk15" или "jdk14" ) скомпилированы из одного и того же исходного кода. Вот почему вам не нужно дублировать классификаторы для артефакта "sources", или, другими словами, вам не нужен классификатор с именем "sources-jdk14" и "sources-jdk15". Но вы не можете применить такое же обоснование к версии scala: учитывая, что вам может понадобиться другой исходный код для компиляции с scala 2.7 или scala 2.8, вам действительно понадобятся два разных артефакта с классификаторами, такими как "sources- scala2.7" или "source-scala2.8". Таким образом, у нас уже есть составные классификаторы. Что касается бинарных артефактов, вам также не нужно будет различать только целевую версию jvm (помните, вы можете скомпилировать ваш код scala для таргетинга на разные версии jvm), а также версию scala, с которой она была скомпилирована. Таким образом, вы получите что-то вроде "jdk14-scala2.7" или "jdk14-scala2.8" или "jdk15-scala2.7" или "jdk15-scala2.8". Еще один набор составных классификаторов. Таким образом, исходное сообщение состоит в том, что версия scala представляет собой отдельный способ классификации артефактов, который полностью ортогонален всем существующим классификаторам. Да, мы могли бы действительно использовать составные классификаторы, как указано выше (например, "sources-scala2.7" ), но тогда мы не будем использовать стандартные классификаторы, что само по себе достаточно запутывает, но также потребует изменить все инструменты вокруг классификаторов: что, если я использую инструмент построения, который не знает о scala (только java), но знает, как автоматически публиковать артефакт "источник"? Нужно ли мне модифицировать этот инструмент сборки, чтобы он знал, что вместо этого будет опубликован артефакт "sources-scala2.7"? С другой стороны, если я кодирую версию scala в имени артефакта (base) и предоставляю ее инструменту построения, все работает как обычно, и я получаю артефакт с "исходным" классификатором.
В целом и вопреки непосредственной интуиции, кодировка версии scala в имени позволяет интегрировать лучше в существующую экосистему java build.