2009-04-23 2 views
3

Я пытаюсь настроить общую систему аутентификации на сервере сборки. У нас есть несколько Maven проектов, который объявляет, как развертывание должно быть сделано в отношении различных групп, которые мы (каждая команда имеет свой собственный пользовательский аутентификации/пароль):Аутентификация сервера Maven в качестве свойств профиля

<profile> 
    <id>release-profile</id> 
    <distributionManagement> 
    <repository> 
     <id>rep-releases</id> 
     <name>rep-releases</name> 
     <url>http://somewhere-releases</url> 
    </repository> 
    <snapshotRepository> 
     <id>rep-snapshots</id> 
     <name>rep-snapshots</name> 
     <url>http://somewhere-snapshots</url> 
    </snapshotRepository> 
    </distributionManagement> 
</profile>  

Тогда я объявляю в settings.xml при авторизации объявленных сервера следующим образом:

<servers> 
    <server> 
    <id>rep-releases</id> 
    <username>${release.user.name}</username> 
    <password>${release.user.password}</password> 
    </server>  
    <server> 
    <id>rep-snapshots</id> 
    <username>${release.user.name}</username> 
    <password>${release.user.password}</password> 
    </server>  
</servers> 

Наконец, в зависимости от проектов, которые я хочу, чтобы развернуть у меня есть несколько профилей, определенными в settings.xml сервера сборки:

<profile> 
    <id>dep-team1</id> 
    <activation> 
    <activeByDefault>false</activeByDefault> 
    </activation> 
    <properties> 
    <release.user.name>team1-user</release.user.name> 
    <release.user.password>team1-password</release.user.password> 
    </properties> 
</profile> 

Проблема заключается в том, что при выполнении Deploy проекта я получил ошибку аутентификации (HTTP 401), как следующее:

Error deploying artifact: Failed to transfer file: http://......./my-project-0.2-20090423.123247-3.pom. Return code is: 401 

Если я изменяю проверку подлинности сервера, заменив свойства с пользователем/паролем команда, все работает нормально.

Не теги < серверы > < сервер > принимает значения как свойства?

Как другие устанавливают свою систему сборки, чтобы достичь того же?

Благодарим за помощь.

Edit: Я использую Hudson, решение для меня может быть установить несколько раз Maven2 и продублированы настройки (кроме пользователя/пароль) для каждой команды и связать каждый проект с хорошей установки Maven. Должен признаться, что это решение не очаровывает меня ...

ответ

1

Самый простой и наиболее прямой метод, если у вас есть несколько команд и, следовательно, несколько AUTH схем, просто использовать другой идентификатор в распределении. Таким образом, вместо rep-releases/rep-snapshots вы можете иметь team1-repo/team2-repo (обычно нет смысла разделять auth между выпуском и моментальными снимками ... особенно если вы используете repo manager с хорошими элементами управления безопасностью)

Затем в настройках вашей строительной машины просто укажите пользователя и пароль для каждой команды для сервера сборки.

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

Другая мысль - почему одна и та же машина сборки должна войти в систему как другой человек при создании сборки?Должна ли эта сборная машина иметь в основном полный доступ?

+0

Вы правы Брайан, самый простой способ добиться того, что мы хотим, - это, вероятно, предоставить полные права на сборку, по крайней мере, для доставки всех репозиториев моментальных снимков. Каждая команда сохраняет свои собственные полномочия для выпуска. Думаю, мы пойдем так. Благодарю. –

0

Прежде всего, я не вижу, как профиль dep-team1 подключен к тегу distributionManagement - кажется, что профиль активации должен быть активным.

Во-вторых, у меня есть элемент моего профиля, структурированный немного по-другому (см., В нем нет тега распределения управления). Не уверен, если это делает разницу .:

<profile> 
    <id>release-profile</id> 
    <repositories> 
    <repository> 
     <id>central</id> 
     <url>http://central</url> 
     <releases><enabled>true</enabled></releases> 
     <snapshots><enabled>true</enabled></snapshots> 
    </repository> 
    </repositories> 
</profile> 

Вот управление распределением:

<project> 
    <distributionManagement> 

    <repository> 
     <id>releases</id> 
     <url>http://myurl/releases</url> 
    </repository> 

    <snapshotRepository> 
     <id>snapshots</id> 
     <url>http://myurl/snapshots</url> 
    </snapshotRepository> 

    </distributionManagement> 
</project> 
+0

1. Если вы не используете maven для доставки своего проекта, конечно, вам не нужен какой-либо тэг distributionManagement. 2. Конечно, в моем процессе доставки активируются все необходимые профили. –

+0

Я использую maven для доставки моего проекта, и он работает. Первоначально у меня была ошибка «ошибка размещения артефактов», но потом я понял это. Мой элемент управления распределением не является частью профиля, а скорее частью проекта (что более логично, кстати). –

+0

У нас есть сотни проектов в нашей компании, и несколько R & D выбрасывают мир, поэтому настройки в профилях облегчают обмен между командами. Но все это помогает в правильном разрешении входа/прохождения сервера со свойствами. –

Смежные вопросы