Путаница в профилях Maven; путаница с аутентификацией на основе пользователя для внутреннего репо - PullRequest
Новая
       11

Путаница в профилях Maven; путаница с аутентификацией на основе пользователя для внутреннего репо

0 голосов
/ 27 февраля 2012

Рассмотрим этот сценарий.У меня есть среда разработки проектов для небольших предприятий.В качестве репозитория артефактов мы используем archiva.

В общем, я хотел бы настроить профили PROJECT-SPECIFIC, а именно потому, что тесты будут отличаться для каждого проекта.

Однако,Единственное, что мне хотелось бы иметь постоянной, - это профиль в моем файле settings.xml, который по умолчанию активен и используется для разработки.Нужно ли, чтобы члены моей команды вручную редактировали этот файл и помещали туда свои учетные данные ARCHIVA (система ldap), чтобы они могли получить доступ к внутреннему репо?

Стоит ли просто не вводить пароль для него?Моя другая альтернатива - использование мастер-пароля для шифрования «общего» пароля, чтобы никто не мог его увидеть, но все они имели бы общий доступ «только для чтения» к внутреннему репо для зависимостей моментальных снимков и прочего.Однако тогда им также понадобится файл security-settings.xml, содержащий зашифрованный мастер-пароль, и разве это не противоречит цели этой системы?

наконец: могут ли одновременно быть активными несколько профилейили это не нужно?Например, если у меня по умолчанию активен профиль разработчика (который содержит настройки репозитория артефактов, зашифрованные учетные данные svn для выпусков), а затем я указываю разные профили в определенных файлах POM, могу ли я выбрать только ОДИН профиль?Допустим, я хочу использовать Bamboo for CI, и есть несколько «тестовых» профилей, которые используют плагин surefire и еще много чего.Будут ли эти профили сосуществовать с профилем DEV activeByDefault, который существует в файле settings.xml, или одновременно может быть активирован только один профиль?Все, что нужно CI - это информация SCM, так что технически ему не нужен доступ к внутреннему архивному репо, поэтому я предполагаю, что если бы я использовал тестовый профиль (автоматически используя CI), ему ничего не требовалось бы из профиля.

Я в замешательстве.Я так близок к созданию полностью управляемой среды сборки, просто пытаюсь сгладить эти несколько проблем.Спасибо.

1 Ответ

0 голосов
/ 27 февраля 2012

Однако единственное, что я хотел бы иметь постоянным, - это профиль в мой файл settings.xml, который по умолчанию активен, используется для развитие. Нужно ли, чтобы члены моей команды вручную редактировали этот файл? и поместите туда свои учетные данные ARCHIVA (система ldap), чтобы они могут получить доступ к внутреннему репо?

Да, им придется редактировать этот файл для пользователя pr. Из документа:

Элементы пароля и пароля могут быть выведены в будущем, но на данный момент они должны быть установлены в виде обычного текста в файле settings.xml. Должен ли я просто не ставить пароль? Моя другая альтернатива использует мастер-пароль для шифрования «общего» пароля, чтобы никто не мог видеть это, все же они все имели бы общий доступ "только для чтения" к внутреннему репо для снэпшот-зависимостей и прочего. Однако тогда они также нужен файл security-settings.xml, содержащий зашифрованные мастер-пароль, и разве это не противоречит цели этой системы?

Почему бы не добавить открытый ключ пользователя в Archiva и выполнить аутентификацию таким образом? 

<servers>
    <server>
      <id>server001</id>
      <username>my_login</username>
      <privateKey>${user.home}/.ssh/id_dsa</privateKey>
      <passphrase>some_passphrase</passphrase>
      ...
    </server>
  </servers>

наконец: может ли быть активным несколько профилей одновременно или ненужный?

Да, несколько профилей могут быть активными. Вы можете использовать mvn help: активные профили для просмотра списка активных профилей.

...