Использовать профили maven для настроек песочницы разработчика?

Question

Я видел несколько проектов, в которых я работаю, которые используют profiles.xml и различные {username} .properties в проекте для параметров изолированной программной среды разработчика, таких как каталог развертывания для сценария развертывания, порты для запуска, какая база данных и сеть использование сервиса и т. д. Теперь, когда Maven 3 удалил поддержку profiles.xml, это заставило меня полностью усомниться в этой практике. Итак, у меня есть несколько вопросов:

1. Есть ли лучший механизм, чем профили для этого?
2. Если нет, то чувствуете ли вы {username} .properties в scm? Иногда (например) при изменении URL-адреса службы мы забываем обновить все свойства разработчиков.
3. Если наличие этих файлов свойств в scm не является плохой идеей, должно ли быть какое-то наследование профилей для параметров, общих для песочниц разработчика? Как это могло быть сделано?
4. В качестве примечания, знаете ли вы, почему Apache удалил поддержку profiles.xml в Maven 3?

Answer 1

Как вы сказали, в Maven 3 удалена только поддержка внешних файлов profiles.xml.Вы по-прежнему можете использовать профили в файле settings.xml и, как всегда, в файле pom.xml.Те проекты, которые в настоящее время имеют внешние файлы profiles.xml, должны переместить эти конфигурации в файл settings.xml локального пользователя.

1) Действительно, нет лучшего механизма, чем конфигурация профилей, для управления значениями, специфичными для среды.

2) Файлы свойств пользователя в scm зависят от содержимого, которое у вас есть, и от того, илине та информация чувствительна к другим, кто может смотреть на нее.Если вы правильно структурируете дерево исходных текстов, не должно возникнуть проблем с его сохранением в SCM.

3) В прошлом с другими проектами, над которыми я работал, мы держали отдельный каталог рядом с тегами, стволом и ветвями с SVN, называемыми конфигурациями, в которых был базовый каталог, содержащий шаблон того, чтоКонфигурационные файлы должны выглядеть как папка разработчика и директория сервера.Из базового каталога разработчики создают / разветвляют свои собственные каталоги в каталоге разработчиков, у которого есть собственная копия файлов конфигурации.Это позволило им объединить изменения в базовую версию и обновить «свою» конфигурацию.Это решило многие из этих изменений URL службы и позволило бы им делать это в свое время.

4) Понятия не имею.Может ли это быть задержкой от Maven 1, которую они хотели удалить.

О, не забывайте, с Maven 2.2 и 3.0 вы можете зашифровать значения в файле settings.xml.

Answer 2

Есть ли лучший механизм, чем профили для этого?

Нет, профили все еще идеально подходят для этого.

Если нет, то чувствуете ли вы {username} .properties в scm? Иногда (например) при изменении URL-адреса службы мы забываем обновить все свойства разработчиков.

Обычно я бы помещал специфичные для пользователя свойства в ~/.m2/settings.xml, а общие свойства - в файл pom.xml.

Если наличие этих файлов свойств в scm не является плохой идеей, должно ли быть какое-то наследование профиля для настроек, общих для песочниц разработчика? Как это могло быть сделано?

Если вы хотите воспользоваться наследованием, я бы предложил использовать maven <properties>.

В качестве примечания, знаете ли вы, почему Apache удалил поддержку profiles.xml в Maven 3?

Поддержка profiles.xml делала внутренности Maven сложными и трудными для тестирования. И поскольку использование settings.xml является приемлемой альтернативой для большинства случаев, profiles.xml было отброшено. См. следующую ветку (в частности сообщения Jazon).