Всем привет,

Интересует ваше мнение относительно settings.xml и декларации репозиториев в нем. Есть ли смысл это делать? По поводу зеркал например, у меня нет сомнений что нужно, а по поводу репозиториев имеются.
С т.з. непрерывной интеграции это не очень хорошо - появляется зависимость от окружения. Если у разработчика settings.xml "чист", то сборка не пройдет, т.к. не будут найдены некоторые зависимости. Придется на каждой машине, где необходимо собирать проект настраивать settings.xml. Таким образом, сборка в одну команду будет невозможна. 
Я вообще придерживаюсь мнения, если что-то можно добавить под сурс контроль, то это нужно делать. Т.е. сделать сборку максимально переносимой. Но конечно есть разумные ограничения, например добавлять JDK под сурс контроль обычно не имеет смысла, точно так же  результаты сборки проекта (jar, отчеты и т.п.). 

А как у вас обстоят дела с этим?

Придерживаюсь точно такого же мнения, это увеличит количество пререквизитов для запуска проекта, что не может быть хорошо. Но такие вещи, как Sonar-настройки хранятся в settings.xml, ибо они не обязательны для разработчиков и у каждого все равно будет своя конфигурация.

У нас все хранится в settings.xml - репозиторий, который находится на стороне заказщика, подключается именно таким образом. Но с другой стороны, мы только одним проектом занимаемся, поэтому и весь environment настроен под этот самый проект. 

Stolzen, а локально как собираете? все правят свои settings.xml? Я так понимаю, что CI у вас нет?

Старовъръ, понятно, спасибо.

А в чем разница между зеркалом и репозиторием? 

У нас есть pdf-файл, в котором описан процесс установки environment, в котором приведен весь файл settings.xml и написано - скопируйте его в ~/.m2/ и замените пароль на свой - примерно так.

Что такое CI? 

Continuous integration

LSD, в pom.xml можно объявлять основные url на репозитории, а зеркала в settings.xml позволяют эти url переопределить.

Например в pom.xml проекта объявлен java.net репозиторий:


Проект я хочу собирать дома и на работе. На работе желательно тащить зависимости с местного nexus-прокси (это быстрее и экономит трафик компании), а дома c внешки. Поэтому на рабочей машине я пропишу в settings.xml что-то типа:  


Тоже самое, если я поеду в командировку, в другом офисе будут другие url в зеркалах, на местные прокси (http://nexus.nizhniy-novgorod.mycompany.com/maven/download.java.net/). При этом файлы настроек проекта менять не нужно.

powerOn, я немного о другом. 

У билда есть некие требования к build environment, версия Maven, JDK и т.д. Репозитории сами по себе никому не интересны интересны артефакты которые в них находятся. В каждом конкретном build environment будет своя специфика. У кого-то прямой выход в сеть, у кого-то кеширующий Nexus, а у кого-то Nexus в который артефакты кладутся руками после проверки контрольных сумм и заполнения формуляра   И наличие нужных версий артефактов в сконфигурированных репозиториях это один из prerequisites для этого билда. И прописывать такие вещи в самом билде, на мой взгляд неразумно.

LSD, я согласен, что можно отнести эти настройки и к build environment, так же как JDK и прочее. Но ценой более длительной настройки этого окружения и ошибок, которые можно при этом допустить. Кроме того, если одно из требований к этому окружению изменится, то вносить изменения придется на всех вовлеченных машинах. 
Почти идеально поставить тулы из коробки, выкачать ревизию и запустить одну команду в консоли что бы получить сборку. Т.е. минимизировать телодвижения и количество пунктов где возможна ошибка.

Добавление дополнительных репозиториев усложняет конфигурирование локальных прокси-репозиториев (если конечно не использовать <mirrorOf>*</mirrorOf>). А все это может быть из-за одного артефакта, который уже давно есть в 3rd-party 

Мы используем <mirrorOf>*</mirrorOf> и общую группу репозиториев. Когда нам не хватает какого-то артефакта, просто добавляем еще одну проксю и эту проксю в общую группу. Т.е. другим разработчикам не надо у себя ничего менять, когда добавляется репозиторий.

LSD, понятно. Спасибо всем за ответы. Есть над чем подумать.