BlazkowiczЙуный джавистЪА что если настроить инкрементальный билд на сервере? Тогда на сервере можно делать svn up + там же инкрементальный билд.
Не столько инкрементальный билд, сколько continuous integration. Когда TeamCity или Jenkins всё то же самое делает в фоновом режиме, совершенно не важно, хоть час проект собирается, хоть два.

естественно Jenkins, вы не до конца поняли всю пичаль:(

Инкрементальный, неинкрементальный - пофиг - это время. Когда в команде 30+ человек и 20 проектов, то каждый коммит - это пересборка, если с тестами - это ппц, а если изменения в domain - ...... билдятся все.
А кастомер хочет как - поправь мне две опечатки, добавь страничку. Ну делов то - метод в контроллере, новая jsp и две правки в существующих страницах. и сидишь ждешь 1.5 часа - пока все соберется и задеплоится, попутно отвечая на тупые вопросы кастомера - почему так долго.
Просить второй сервер для второго дженкинса - 500 тыщ бумажонок, с обоснованием, графиками, обсуждениями, настройкой сервера, открыванием портов для фарволла - привет энтерпрайз, короче бесит оч сильно.

Valery Shiskinзабыл ник,

Боже мой. Как же это ты несешь все в себе.

я постиг дзен, веришь нет - я уже ничему не удивляюсь, самое интересное - я уже начал различать ситуации когда надо реально срочно, а когда можно забить - и никто не заметит. У меня рабочий имейл - вообще прикольная тема - стоят фильтры urgent, very urgent, extremely urgent. ASAP - тупо идет в корзину:) Как оно все существует до сих пор и не накрылось медным тазом - для меня загадка из загадок.

Йуный джавистЪА кастомер хочет как - поправь мне две опечатки, добавь страничку. Ну делов то - метод в контроллере, новая jsp и две правки в существующих страницах. и сидишь ждешь 1.5 часа - пока все соберется и задеплоится, попутно отвечая на тупые вопросы кастомера - почему так долго.

Обычно сборка ява проекта - скомпилировать сорцы и запаковать их в зип. Компилировать можно инкрементально, запаковки в зип можно тоже избежать, если сервер позволяет деплоить прямо из папки. Мне кажется, можно при желании добиться быстрой пересборки.


Ну канеш:) Затраты времени на компиляцию - это секунды, инкрементальный билд тут явно не спаситель.
А в сборке еще бывает - генерация стабов для веб-сервисов по wsdl, инструментация, компилирования swf из флекса, ассемблинг. вынос статических ресурсов, автогенерирование кода и тд - итп. Добавь к этому модульность, поиск депенденси и запуск тестов, я не говорю даже про всякие кловеры, кобертуры, чекстайлы и файндбаги. Ну и билд сервер это конечно абсолютно отдельная машина, которая не имеет сетевого соединения с другими серверами(тест, qa и продакшен).

Вообще вся эта ява-инфраструктура является тяжелым кошмаром. Если бы специально старались сделать все неудобно и через жопу, то все равно не достигли бы такого эффекта как в яве.
Например, взять хотя бы мавен. За каким-то хером он вставляет в собранный джар файлик с датой. В результате, даже если сорцы не поменялись, джары получаются бинарно разными, что несовместимо с инкрементальной сборкой. Получается, что люди, которые разработали билд-тул, ВООБЩЕ НИЧЕГО не понимают в сборке.
Я для себя давно сделал вывод, что если в проекте используется мавен, спринг, хибернейт или jsf, то проект скорее всего какая-то гниль бессмысленная, и надо его всячески избегать.


Плата за статическую типизацию. Ну ты скажи как сделать лучше для java? Если бы не было мавена - я бы застрелился, ты просто не представляешь какие тут объемы кода.

Йуный джавистЪты просто не представляешь какие тут объемы кода.

Затраты времени на компиляцию - это секунды

Нет ли тут противоречия?
Есть статья http://www.javaworld.com/javaworld/jw-11-2005/jw-1107-build.html про инкрементальный билд.
Смысл в том, что после выполнения каждый таски делаешь touch для некоторого служебного файла, таким образом помечая время последнего запуска таска. Потом сравниваешь дату исходника с датой этого файла, если первая меньше второй, то таск можно пропустить.
Ну если советуешь так хотя бы сам прочитай:)
In this article, my main focus in this scenario is when a developer works on his local working directory: He changes the project and wants to obtain feedback and see the results as fast as possible. Before ending with a task and committing it to the codebase, he wants to do a couple of fast incremental builds. By using techniques introduced in this article, he will quicken these builds and consequently save time.

Где ты кстати такое старье выкопал?
С локальными билдами проблем никаких нет. Городить такое на билдсервере - это ахтунг. Я повторюсь, ты не представляешь какие сложные бывают графы депенденси. Как настроить инкрементальный билд - если поменялись только xsd? Короче не вариант.
И еще раз, компиляция(javac) в типичном билде занимает секунды, а автогенерация, инструментация, скачивание депенденси и тесты - отжирают львиную долю времени.

Йуный джавистЪПлата за статическую типизацию. Ну ты скажи как сделать лучше для java?

В оракл PLSQL тоже статическая типизация и компиляция в нейтив код, но там все работает.

Классное сравнение) Так пиши на нем.

А попутно ответь как это все дело развернуть на кластер, как задеплоить бранч, рефакторинг тоже наверняка очень удобен?

Йуный джавистЪТесты, чекстайлы и файндбаги не вижу смысла на каждый билд запускать, пусть делаются в фоне или ночью.

Так и делается, за исключением тестов. Представь что у тебя 20 приложений, многие зависят друг от друга и деплой занимает дохера времени. Любой баг в модуле domain может положить весь qa-процесс на полчаса, не говоря какая это морока в принципе + недовольство кастомера, который шлет панические письма если сервер недоступен

Йуный джавистЪА попутно ответь как это все дело развернуть на кластер
Клиент оракла вообще не знает, кластер там или одиночный инстанс, все абсолютно прозрачно.
как задеплоить бранч
Если структуры таблиц не отличаются, то берешь и деплоишь. Если отличаются, то ты и в яве бранч не задеплоишь.
рефакторинг тоже наверняка очень удобен
Да, удобен.
Имелась ввиду кластеризация серверов приложений и ограниченность кластеризации Oracle.

Причем тут структура таблиц? Хранимки у тебя разные в бранче.
Ну если рефакторинг удобен - то ок, непонятно что ты в теме про java делаешь)

Йуный джавистЪС локальными билдами проблем никаких нет. Городить такое на билдсервере - это ахтунг.

В чем принципиальная разница?
Я повторюсь, ты не представляешь какие сложные бывают графы депенденси.

Ант умеет работать с графами любой сложности.
Как настроить инкрементальный билд - если поменялись только xsd? Короче не вариант.

Ява классы перегенерятся из этих xsd, потом ant перекомпилирует только то что зависело от этих классов. Потом инструментатор отинструментирует тоже только то, что поменялось. Потом можно уже деплоить.
скачивание депенденси

В http есть такая штука как etag. Если мавен не умеет им пользоваться, то тогда, это печально.
Принципиальная разница между локальным билдом и билдом на билд сервере в том, что локально я знаю что изменилось, и в большинстве случаев я разрулю это и без билда всех проектов, хотя иногда могут быть и осечки. А билдсервер должен выдавать гарантированный билд, который без всяких проблем может быть задеплоен на тестовый сервер и гарантированно не свалится.
Ну ты бы еще makefile предложил вместо мавена, а че ява девелоперы такие ява девелоперы, придумали мавен, когда есть замечательный ант(я просто не хочу повторять что сказано до меня уже сотни раз и вступать в холивар, если не знаешь недостатков анта - то просто погугли).
Сложность с инкрементальным билдом - что ты должен знать что может быть поломано в результате любого коммита(xsd, flex файл, конфиг автогенератора) и учитывать это в билд процессе, и на каждый случай надо возиться с этой настройкой и постоянно отлавливать косяки, нет спасибо.
А мавен таки знает про etag, просто когда у тебя число зависимостей около 60(это только снапшоты) - он должен залезть по урлу и проверить etag.

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