maven - сборка зависимых проектов на локальной машине (а-ля ci)

В проектах, с которыми встречалсжя, обычно в корневом поме прописана сборка связанных проектов через modules. При запуске сборки корневого пома, запускаются все чайлды.

 <modules>
        <module>core</module>
        <module>client</module>
        <module>mail</module>
 </modules>

его, нет т.к. проекты мягко говоря слабосвязанны, кроме того у разработчиков лежат зачастую черти где

Поставь нексус и скинь settings.xml всем. Проекты инсталлятся в нексус. Зачем их собирать локально?

Имхо какая-то странная идея. Тестировать работоспособность проекта надо либо с +- стабильными версиями других проектов (а они и так в репозитории уже собранные лежат), либо, если проекты тесно связаны - с теми, которые напрямую как зависимости в pom-e указаны.

Ой ля,

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

- есть проектик юзающий эту либу

в процессе был найден баг\понадобилось допилить фичу - ковыряю либу, запускаю сборку/тесты, запускаю свой проект сморю - если все норм, заливаю на общий сервер

общий пом тут вообще никак, а сервер сборки займется тестированием с остальными проектами

Поставь нексус и скинь settings.xml всем

топик не читай, быстрей отвечай, да? специально для тебя повторю

есть ci-сервер, репозиторий

нексус - это maven-репозиторий, т.е. его аналог уже есть

Вообще такие фокусы - это очень сильно bad practice. По хорошему надо править баг, заливать в свн, собирать билдсервером и выкладывать в репозиторий библиотеку с пофикшеным багом и м.б. новым номером версии. После чего уже пересобирать свой проект с новой версией библиотеки.

По факту конечно приходится периодически нарушать ради быстрого фикса этот процесс. В таком слуаче собирается библиотека, делается ей install, после чего она автоматом кладется в локальный репозиторий (который ~/.m2). Своему проекту делается clean package и обтестируйся наздоровье. Но эта ситуация довольно нечастая. А если частая - то что-то с процессом разработки не так.

Вообще такие фокусы - это очень сильно bad practice. По хорошему надо править баг, заливать в свн, собирать билдсервером и выкладывать в репозиторий библиотеку с пофикшеным багом и м.б. новым номером версии. После чего уже пересобирать свой проект с новой версией библиотеки.

После чего непротестированная библиотека (юнит тесты не панацея тем более для gui) окажется у всей команды.

Так что «херовая практика» это то что ты предлагаешь.

В таком слуаче собирается библиотека, делается ей install, после чего она автоматом кладется в локальный репозиторий (который ~/.m2). Своему проекту делается clean package и обтестируйся наздоровье.

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

После чего непротестированная библиотека (юнит тесты не панацея тем более для gui) окажется у всей команды.

С фига ли она окажется у всей комманды? У остальных останется стабильная версия. У тебя в пом-е зависимость меняется на что-то типа <version>x.x.x-bBUILD_NUMBER</version> где пофикшен конкретно твой баг. И мучайся с ней сам.

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

Что такое промежуточные проекты и почему их нет в прямом графе зависимостей?

С фига ли она окажется у всей комманды? У остальных останется стабильная версия. У тебя в пом-е зависимость меняется на что-то типа <version>x.x.x-bBUILD_NUMBER</version> где пофикшен конкретно твой баг. И мучайся с ней сам.

Там волшебное слово SNAPSHOT, для многих либ, версия меняется при смене api.

Что такое промежуточные проекты и почему их нет в прямом графе зависимостей?

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

Там волшебное слово SNAPSHOT, для многих либ, версия меняется при смене api.

Вот это то и есть bad practice. Либо проекты сильно связаны и тогда разрабатываются вместе, в рамках одного проекта. Либо они связаны слабо и тогда для разработки одного проекта всегда используется стабильная версия другого.

в один клик нету ибо это никому не надо.

чел коммитает в свн или чего там у вас стоит, билд сервер (какой-нить Hudson или другой) собирает и прогоняет тесты по всем проектам, на которые нацелен. в случае проблем со сборкой и тестами чел получат анальное письмо.

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

Либо они связаны слабо и тогда для разработки одного проекта всегда используется стабильная версия другого.

И всегда протухшая, ага. Это и есть bad practice, милок. Ког у тебя тухнет еще до релиза.

И всегда протухшая, ага. Это и есть bad practice, милок. Ког у тебя тухнет еще до релиза.

Мдя. Даже растерялся - чего бы на такую глупость ответить. Мсье никогда не участвовал в разработке серьезных систем?

не путай тухлый интерпрайз и серьезные ситемы.