|
Java форум JavaTalks
форум программистов
|
|
|
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
a_subscriber : 342
Бывалый
|
 Авг 17, 2011 20:21 |
 |
|
есть проект над которым работают несколько программистов
у каждого есть свой локальный maven репозиторий. Но мы пришли к тому, что нам нужен общий maven репозиторий (внутри компании), который был бы доступен всем членам команды.
Т.е. допустим один программист сделал jar файл и нужно, чтобы этот jar был доступен всем членам комманды. Логично, что этот архив нужно закинуть в общий (видимый для всех) репозиторий.
Есть ли у maven-а какие-нибудь плагины для этого. Вообщем что посоветуете? |
|
|
|
 |
vimba : 147
Новичок
Откуда: Шахты
|
| Авг 17, 2011 20:33 |
| |
|
|
|
|
|
|
Skipy : 4801
Я тут живу!
Откуда: Москва, Россия
|
| Авг 18, 2011 10:29 |
| |
|
| a_subscriber писал(а): |
| Т.е. допустим один программист сделал jar файл и нужно, чтобы этот jar был доступен всем членам комманды. Логично, что этот архив нужно закинуть в общий (видимый для всех) репозиторий. |
Нет, не логично.
Логично сделать общую сборку, которая в числе прочего будет собирать и этот jar. И тогда любой, взявший код и выполнивший сборку, получит этот jar.
Не надо хранить результаты сборок, Вы тем самым увеличиваете возможность расхождения версий.
_________________
С уважением,
Евгений aka Skipy
www.skipy.ru
P.S. Я НЕ решаю задачи ЗА других! |
|
|
|
|
a_subscriber : 342
Бывалый
|
| Авг 18, 2011 12:54 |
| |
|
| Skipy писал(а): |
| a_subscriber писал(а): |
| Т.е. допустим один программист сделал jar файл и нужно, чтобы этот jar был доступен всем членам комманды. Логично, что этот архив нужно закинуть в общий (видимый для всех) репозиторий. |
Нет, не логично.
Логично сделать общую сборку, которая в числе прочего будет собирать и этот jar. И тогда любой, взявший код и выполнивший сборку, получит этот jar.
Не надо хранить результаты сборок, Вы тем самым увеличиваете возможность расхождения версий. |
не понимаю.
Нужно следующее:
- Есть два проекта
- Проект#2 использует проект#1 (указывается в <depency> в POM-e)
- Программист внес изменения в проект#1 , сделал артефакт (jar) и положил его (deploy) в центральный репозиторий.
- Эти изменения должен получить проект#2 . Для этого проект# 2 ДОЛЖЕН обратиться в центральный репозиторий за новой версией проекта#1
Если следовать этой схеме, то нужно создать центральный репозиторий через, который программисты и будут обмениваться артефактами
Если можете предложить более удобную схему, буду рад услышать. |
|
|
|
|
Skipy : 4801
Я тут живу!
Откуда: Москва, Россия
|
| Авг 18, 2011 13:30 |
| |
|
Не так.
Есть проект. Один.
Есть две его части. Вторая зависит от первой.
Каждая часть может иметь собственную сборку. Однако для сборки второй части необходимо собрать первую.
Если это делается на maven, можно организовать сборку первой части перед сборкой второй. Можно вообще сделать группирующий pom более высокого уровня, в который включить обе части проекта в указанном порядке.
Если это делается на ant - можно сначала импортировать проект первой части, собрать, потом собрать вторую.
Для такого варианта необходим только репозиторий исходников. Время сборки увеличивается настолько незначительно (ибо она инкрементальная), что этим можно пренебречь.
Ключевой момент - никакие артефакты, являющиеся результатом сборки Вашего же проекта, не должны лежать где-то отдельно. Иначе Вы будете постоянно натыкаться на ситуации, когда в проекте #1 что-то поправили, но в репозиторий не выложили. ПОС-ТО-ЯН-НО! Поверьте человеку, который по такой схеме работал.
_________________
С уважением,
Евгений aka Skipy
www.skipy.ru
P.S. Я НЕ решаю задачи ЗА других! |
|
|
|
|
a_subscriber : 342
Бывалый
|
| Авг 18, 2011 14:22 |
| |
|
| Skipy писал(а): |
Не так.
Есть проект. Один.
Есть две его части. Вторая зависит от первой.
Каждая часть может иметь собственную сборку. Однако для сборки второй части необходимо собрать первую.
Если это делается на maven, можно организовать сборку первой части перед сборкой второй. Можно вообще сделать группирующий pom более высокого уровня, в который включить обе части проекта в указанном порядке.
Если это делается на ant - можно сначала импортировать проект первой части, собрать, потом собрать вторую.
Для такого варианта необходим только репозиторий исходников. Время сборки увеличивается настолько незначительно (ибо она инкрементальная), что этим можно пренебречь.
Ключевой момент - никакие артефакты, являющиеся результатом сборки Вашего же проекта, не должны лежать где-то отдельно. Иначе Вы будете постоянно натыкаться на ситуации, когда в проекте #1 что-то поправили, но в репозиторий не выложили. ПОС-ТО-ЯН-НО! Поверьте человеку, который по такой схеме работал. |
Опишу как я понял:
Дано:
1. Программист1 (окружение: Windows, локальным мавен репозиторий, локальный репозитрой исходников (Git))
2. Программист2 (окружение: Ubuntu, локальным мавен репозиторий,локальный репозитрой исходников (Git)))
3. Центральный репозиторий исходников (Git)
4. Проект#1. Результат сборки проекта - jar
5. Проект#2. Зависит от проекта#1. Результат сборки проекта - jar
Схема работы
1. Было внесено программистом1 в проект#1 некое изменение.
2. Программист1 запустил сборку (компиляция+тесты) проекта#1.Сборка прошла успешно
3. Программист кладет (push) измения (ТОЛЬКО ИСХОДНИКИ) в центральный репозиторий исходников
4. Программист2 скачивает (pull) из центрального репозитория измения
5. Запускает сборку проекта2. Так как проект2 зависит от проекта1, то сборка проекта2 сначала запустит сборку проекта1.
6. Как результат сборки проекта1 получаем артефакт (jar), который кладется в ЛОКАЛЬНЫЙ мавен репозиторий программиста2.
7. Сборка проекта#2 берет свежий артефакт проекта#1 из локального репозитория программиста2 и завершает процесс сборки проекта2.
правильно? |
|
|
|
|
Skipy : 4801
Я тут живу!
Откуда: Москва, Россия
|
| Авг 18, 2011 15:37 |
| |
|
Да, именно так. Это наиболее оптимально. Чем меньше точек, от которых Вы зависите, тем меньше вероятность расхождений.
_________________
С уважением,
Евгений aka Skipy
www.skipy.ru
P.S. Я НЕ решаю задачи ЗА других! |
|
|
|
|
a_subscriber : 342
Бывалый
|
| Авг 18, 2011 17:10 |
| |
|
| Skipy писал(а): |
| Да, именно так. Это наиболее оптимально. Чем меньше точек, от которых Вы зависите, тем меньше вероятность расхождений. |
Можно вообще сделать группирующий pom более высокого уровня, в который включить обе части проекта в указанном порядке.
Можете привести пример такого группируещего pom-а ?
<modules>
<module>проект#1</module>
<module>проект#2</module>
</modules>
? |
|
|
|
|
Староверъ : 7620
Ктапубеп
Откуда: Elfland
|
| Авг 18, 2011 17:32 |
| |
|
| Цитата: |
| Логично сделать общую сборку, которая в числе прочего будет собирать и этот jar. И тогда любой, взявший код и выполнивший сборку, получит этот jar. |
Мм.. не очень логично  Во-первых, если проекты разрабатываются совсем независимыми командами, то общаться с кодом параллельной команды не имеет смысла. Во-вторых, время сборки каждой команды увеличивается (я говорю про локальные сборки), что очень плохо. В-третьих, что если у тебя 10 таких проектов? Я бы не советовал делать для них общую базу, сборки по часу - это как минимум скучно (да и SCM может страдать из-за потерь в производительности) 
| Цитата: |
| Не надо хранить результаты сборок, Вы тем самым увеличиваете возможность расхождения версий. |
SNAPSHOT версии всегда качаются из репа по-новой. Это раз. Два - это то, что версионность как раз будет плюсом, когда первая команда уже что-то изменила, а вторая еще нет и ее проект упадет, если не будет предыдущей версии. А первая команда может даже не подозревать, что она что-то сломала у кого-то другого.
У нас тут на работе есть .Net разработчики, у них, как ты и говоришь, есть какая-то общая база сорцов. Матюгаются на параллельную команду они часто
| Цитата: |
| Иначе Вы будете постоянно натыкаться на ситуации, когда в проекте #1 что-то поправили, но в репозиторий не выложили. ПОС-ТО-ЯН-НО! Поверьте человеку, который по такой схеме работал. |
Мм.. а у этого человека не было CI, который делал ночные сборки?
В JTalks мы недавно как раз перешли на зависимости проектов по средствам артефактов. Вроде все довольны.
_________________
JTalks Open Source Project, JT Webinars, JT Interview |
|
|
|
|
a_subscriber : 342
Бывалый
|
| Авг 18, 2011 17:49 |
| |
|
| Староверъ писал(а): |
| Цитата: |
| Логично сделать общую сборку, которая в числе прочего будет собирать и этот jar. И тогда любой, взявший код и выполнивший сборку, получит этот jar. |
Мм.. не очень логично Во-первых, если проекты разрабатываются совсем независимыми командами, то общаться с кодом параллельной команды не имеет смысла. Во-вторых, время сборки каждой команды увеличивается (я говорю про локальные сборки), что очень плохо. В-третьих, что если у тебя 10 таких проектов? Я бы не советовал делать для них общую базу, сборки по часу - это как минимум скучно
| Цитата: |
| Не надо хранить результаты сборок, Вы тем самым увеличиваете возможность расхождения версий. |
SNAPSHOT версии всегда качаются из репа по-новой. Это раз. Два - это то, что версионность как раз будет плюсом, когда первая команда уже что-то изменила, а вторая еще нет и ее проект упадет, если не будет предыдущей версии. А первая команда может даже не подозревать, что она что-то сломала у кого-то другого.
У нас тут на работе есть .Net разработчики, у них, как ты и говоришь, есть какая-то общая база сорцов. Матюгаются на параллельную команду они часто
| Цитата: |
| Иначе Вы будете постоянно натыкаться на ситуации, когда в проекте #1 что-то поправили, но в репозиторий не выложили. ПОС-ТО-ЯН-НО! Поверьте человеку, который по такой схеме работал. |
Мм.. а у этого человека не было CI, который делал ночные сборки?
В JTalks мы недавно как раз перешли на зависимости проектов по средствам артефактов. Вроде все довольны. |
в проекте учавствуют несколько человек (одна команд). И все они сидят в одной комнате. Предпологается сделать CI сервер, который и будет собирать весь проект (в котором много мелких подпроектов, которые зависят друг от друга).
Схема такая.
1.Как только программист1 внес изменения в подпроект1 он кладет изменения (исходники) в центральный репозитарий исходиников.
2. CI сервер видит , что в центральном репозитории исходников произошли изменения, берет их. Собирает весь проект в нужной последовательности. Т.е сначала подпроект1, потом подпроект2 (подпроект2 зависит о подпроекта1) и т.д. Если все успешно, то об этом в виде email-а сообщается всем программистам.
3. Программист2 работающий над подпроектом2 скачивает из центрального репозитория исходников изменения и запускает сборку подпроекта2. Его сборка сначала запускает сборку подпроекта1, а потом сборку подпроекта2.
Как такой вариант? |
|
|
|
|
Староверъ : 7620
Ктапубеп
Откуда: Elfland
|
| Авг 18, 2011 17:59 |
| |
|
|
|
|
|
|
a_subscriber : 342
Бывалый
|
| Авг 18, 2011 18:26 |
| |
|
| Староверъ писал(а): |
| Ну это как раз та схема, которую предлагает Skipy. Я уже высказал свое мнение по поводу этой схемы. |
т.е ваша схема предпологает наличие центрального мавен репозитория через который все программисты и обмениваются артефактами (например jar-ами)?
Но ведь при ЛЮБОМ изменении по проекту НЕОБХОДИМО запустить сборку на CI сервере (интеграционная сборка), чтобы гарантировать что ничего не сломалось.
Получается это именно CI сервер после успешной интеграционной сборки должен класть артефакты в центральный мавен репозиторий из которого программист2 берет свежий артефакт подпроекта1 и таким образом программисту2 не нужно запускать сборку подпроекта1.
? |
|
|
|
|
vimba : 147
Новичок
Откуда: Шахты
|
| Авг 18, 2011 19:46 |
| |
|
| Да так обычно и происходит, когда используется maven. |
|
|
|
|
kot : 102
Новичок
|
| Окт 01, 2011 8:12 |
| |
|
| Вопрос к автору топика, так к чему в итоге вы пришли? как у вас сейчас это организовано и почему? |
|
|
|
|
thelamon : 20
Новичок
|
| Окт 01, 2011 11:14 |
| |
|
Плюсану про схему с общим maven-репозиторием и автоматическим обновлением .jar-ников по snapshot-версии. Работал так в команде, никаких нареканий. Не вижу смысла принудительно всегда апдейтить сорцы dependent-проектов.
А вот CI-сервер как раз пересобирает всё по обновлению в репозитории.
Кстати, наиболее удобная модель - что как раз CI-сервер делает deploy в репозиторий в случае успешной сборки. А у программера лишь одна цель - сделать "чистый" (не фейля тесты) коммит, остальное - не его забота. Соответственно, в случае например использования IDEA другие программеры автоматически получат обновлённые .jar-ники, и IDEA перебилдит индексы. Получается абсолютно прозрачная схема. Нафига заставлять программеров принудительно обновлять сорцы какого-то чужого ненужного им проекта, и собирать его? |
|
|
|
|
|
|
Страница 1 из 2
На страницу 1, 2 След. |
Список форумов
-> Инструменты |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
