Вот никак не могу понять нафига вообще нужен этот Maven?

За 6 мес. работы с Java часто его слышал, но так и не понял каков в нем смысл. Я себе клепаю потихоньку в эклипсе -- и больше ничего мне не понадобилось.

Посмотрел описание на http://www.apache-maven.ru/:

Мавен это инструмент для сборки Java проекта: компиляции, создания jar, создания дистрибутива программы, генерации документации. Простые проекты можно собрать в командной строке.

А нафига в командной строке, если есть Eclipse? Вот за все время работы с C#, мне ни разу не пришлось ничего собирать из командной строки. Ни разу. Той же тактики я придерживаюсь и в Java -- зачем лесть на рожон?

Если собирать большие проекты с коммандной строки то комманда для сбоки будет очень длинной, поэтому её иногда записывают в bat/sh скрипт. Но такие скрипты зависят от платформы. Для того чтобы избавиться от зависимости от платформы и упростить написание скрипта используют инструменты для сборки проекта.

А! Наверное они не знают что есть такая удобная штуковина как Ecipse? Т.е. походу это "старые пердуны", которые кроме командной строки ничего не знают?

Здравствуйте, LeonidV, Вы писали:

SK>>Конкретно Мейвен-то зачем нужен? Только, плз, не надо говорить, что для того, чтобы собирать проект и трекать зависимости. Для этого тулзы погибче и приятнее есть.
LV>Например? Какая конкретно еще тулза позволяет описать проект, а не процесс сборки?

Да ладно. Чуть что посложнее и билд на Maven получается таким же описанием процесса сборки. antrun, конечно, немного спасает. Но всё равно, формат и негибкость POM-ок удручает неимоверно.

Maven отвратителен. Но, увы, это стандарт, а это уже многое значит.

Здравствуйте, Курилка, Вы писали:

C>>Ну и проблема с мультимодульностью нормально не решена. Ни в maven, ни в ivy, ни в Грабле. Как будто, они не работают над реальными проектами.
К>А можешь пояснить, какую именно мультимодульность и проблему ты имеешь в виду?
Вот у меня проект из 6 модулей. Они все лежат в файловой системе рядышком. Предположим, что я поменял модуль А и теперь хочу собрать модуль Б, зависящий от него. Делать "mvn compile" на верхнем уровне не хочется из-за того, что это долго (см. пункт 1).

Казалось бы, достаточно зайти в каталог с модулем Б и запустить билд? Ан нет, фигушки. Сначала нужно зайти в модуль А, сделать там mvn install, и только потом зайти в модуль Б и там уже начать строить. Сам Maven ну никак не может догадаться, что этот модуль можно построить (он лежит локально рядом и доступен через родительский POM!!!).

Стоит ли говорить, что waf/scons прекрасно умеют делать подобное?

Кстати, ещё не хватает out-of-tree билдов. Т.е. чтоб исходники можно было на read-only носителе, к примеру, иметь. Ну да ладно, можно прожить без этого.

Здравствуйте, Аноним, Вы писали:
А>А как сэкономить время настроики проекта если в команде половина работает с Intellij IDEA?

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

• кодинг-стайл
  
• инструментарий
  
• воркфлоу (багтрекер, сорс-контроль и всё такое)

Что значит "часть команды работает в другой IDE"?! Да хоть в Зимбабве едут и там на голове пускай стоят — но если их коммиты разламывают проект в дефолтной IDE проекта, они сами себе буратины. Коммиты будут откачены билд-мастером, и назавтра эти оболтусы опять вернутся к старой задаче. Только теперь уже с необходимостью играть по официальным правилам. Не нравятся эти правила — аргументируйте, обсуждайте, влияйте. Но пока не принято новых решений — уж будьте добры, играйте в команде. Гениальность — не оправдание раздолбайству.

Здравствуйте, RomikT, Вы писали:

SK>>>Только, плз, не надо говорить, что для того, чтобы собирать проект и трекать зависимости. Для этого тулзы погибче и приятнее есть.
C>>Нету. Есть совместимые с форматом репозиториев Maven'а недоделки на всяких Groovy, которые надо нафиг закопать вместе с их авторами.
RT>А можно подробнее, за что авторов Gradle надо закопать? Я не что бы потроллить спрашиваю, а действтельно интересно.
За всё хорошее. Они сделали ещё один уродец, типа Maven'а, не решив ни одной его проблемы. Зато вместо XML'я заменили DSL'ем на Тьюринг-полном языке (это сейчас ведь модно!), который в принципе нельзя прочитать с помощью IDE. За что им отдельное "спасибо".

Какие проблемы реально стоило бы решить:
1) НОРМАЛЬНЫЙ трэкинг зависимостей и целей. Как в Scons и WAF.
2) НОРМАЛЬНЫЕ мульти-модульные локальные билды.

Поясню:

Ни в одном инструмента для Java нет трекинга зависимостей, который был ещё в старом добром make. К примеру, если я набираю "mvn install" ничего не изменив в проекте, то у меня Maven перестраивает все war/jar-файлы, запускает тесты и т.п. Хотя это нафиг не надо — ничего ведь не изменилось!!! А если нужно что-то достаточно сложное, типа генерации исходников, которые компилируются в промежуточную утиллиту, которой обрабатываются остальные исходники — это уже вообще можно вешаться. Любое изменение — и полный rebuild всего.

И это при том, что scons/waf/cmake/boost jam и прочие прекрасно работают с зависимостями. Более того, в waf/scons даже такие приятные фичи есть, как инкрементальная компиляци — если меняется A.java, то перекомпилится только A.class и всё от него зависящее. Но к сожалению, для них проекты на Java — не основное назначение, так что очень многого нужного просто-напросто нет. Я как-то пытался waf использовать, но забил.

У меня есть мнение, что так как сборка проектов на C++ — это на порядок более сложная задача, чем сборка Java, то разработчики тулзов для C++ занимаются решением проблем, а не мастурбирование на DSL'и.

Ну и проблема с мультимодульностью нормально не решена. Ни в maven, ни в ivy, ни в Грабле. Как будто, они не работают над реальными проектами.

Здравствуйте, 0K, Вы писали:

0K>А его правда используют? Чем не устраивает сборка проекта с помощью Eclipse, без всяких там Maven?

Организуйте с помощью Eclipse интеграционную сборку с реакцией на коммиты в репозиторий (плюс ночную) — и мы продолжим это увлекательное обсуждение.

Здравствуйте, StanislavK, Вы писали:

SK>Конкретно Мейвен-то зачем нужен?
1) Зависимости.
2) Зависимости.
3) Зависимости.

SK>Только, плз, не надо говорить, что для того, чтобы собирать проект и трекать зависимости. Для этого тулзы погибче и приятнее есть.
Нету. Есть совместимые с форматом репозиториев Maven'а недоделки на всяких Groovy, которые надо нафиг закопать вместе с их авторами.

SK>Интерестно, что разные люди на этот счет думают... Мне кажется, что сильно потиворечивая тулза.
Это было "противоречиво" 5 лет назад. Сейчас почти весь софт собирается Maven'ом.

Здравствуйте, LeonidV, Вы писали:

WF>>И даже в случае простого проекта Maven справляется довольно плохо. Объем скриптов огромен, много повторения, много несущественных деталей, редактировать скрипты просто неудобно. Много тонкостей, которые надо знать.
LV>У нас он со своими задачи справляется отлично. И я все равно не понимаю, зачем использовать инструмент, если он не подходит, а потом на него ругаться. Возьмите тот же gradle или buildr и делайте на нем что угодно.

Потому что это требует времени на изучение и результат всё равно не гарантирован. Плюс интеграция с IDE, и.т.д, и.т.п. Типичный Java-вей, куча выбора и ни одного нормального

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Курилка, Вы писали:

C>>>Ну и проблема с мультимодульностью нормально не решена. Ни в maven, ни в ivy, ни в Грабле. Как будто, они не работают над реальными проектами.
К>>А можешь пояснить, какую именно мультимодульность и проблему ты имеешь в виду?
C>Вот у меня проект из 6 модулей. Они все лежат в файловой системе рядышком. Предположим, что я поменял модуль А и теперь хочу собрать модуль Б, зависящий от него. Делать "mvn compile" на верхнем уровне не хочется из-за того, что это долго (см. пункт 1).
C>Казалось бы, достаточно зайти в каталог с модулем Б и запустить билд? Ан нет, фигушки. Сначала нужно зайти в модуль А, сделать там mvn install, и только потом зайти в модуль Б и там уже начать строить. Сам Maven ну никак не может догадаться, что этот модуль можно построить (он лежит локально рядом и доступен через родительский POM!!!).

Все эти проблемы легко решаются при помощи ключиков -pl -am -rf:

http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/

например имеем структуру:

\
— p1
— p2
— p3

и p2 зависит от p3

делаем из корневого:

mvn -pl p2 -am

и мавен пересоберет только p3 и p2 (в таком порядке)

Здравствуйте, 0K, Вы писали:

0K>Здравствуйте, LeonidV, Вы писали:

LV>>Для меня старые пердуны не делают разделения между IDE и платформой. Потому как в моем представлении "старые пердуны" работали лишь с Delphi, где IDE это и есть платформа.

0K>IDE -- нужна не просто для подсветки кода, но и для сборки проекта. На то она и IDE.

LV>>mvn удобен, просто удобен.

0K>А его правда используют? Чем не устраивает сборка проекта с помощью Eclipse, без всяких там Maven?

Вы наверное не в курсе, что есть проекты которые собираются автоматом, ежедневно, еженощно?

Здравствуйте, 0K, Вы писали:

0K>Вот никак не могу понять нафига вообще нужен этот Maven?

Непонятно назначение именно Maven'а, или для чего нужны сборщики проектов в целом? Под .NET вроде есть MSBuild — его тоже принципиально не использовал?

0K>За 6 мес. работы с Java часто его слышал, но так и не понял каков в нем смысл. Я себе клепаю потихоньку в эклипсе -- и больше ничего мне не понадобилось.
0K>А нафига в командной строке, если есть Eclipse? Вот за все время работы с C#, мне ни разу не пришлось ничего собирать из командной строки. Ни разу. Той же тактики я придерживаюсь и в Java -- зачем лесть на рожон?
0K>А! Наверное они не знают что есть такая удобная штуковина как Ecipse? Т.е. походу это "старые пердуны", которые кроме командной строки ничего не знают?

Значит у тебя жесткая завязка проекта на одну конкретную IDE, что очень плохо. В .NET мире это может и нормально, но в яве вообще никак. Потому что:

1)Регулярно выходят новые версии популярных фреймворков и новые фреймворки. Любая IDE банально не успевает за ними, тому же реализация поддержки новых технологий может быть реализована очень специфично.

2)Есть такая штука как Continious Integration и Build Server. Любая альфа-, бета-версия или релиз должны браться только с билдсервера. Билдсервер не только собирает проект, но и прогоняет юнит- и интеграционные тесты, может иметь свой план сборки, чтобы полученный артефакт был заточен на использование на продакшн площадке, может сразу деплоить его на нужную площадку и т.д., и т.п. Как ты подключишь Эклипс, я не знаю.

3)Заставлять всех разработчиков в команде и всех, кто будет работать над проектом за пределами твоей компании, использовать одну конкретную нравящуюся тебе IDE — это эгоистично и в корне неправильно

4)При сборке могут понадобиться операции, которые нельзя совершить в процессе сборки из Эклипсе или другой IDE. И тут либо ставим уже написанный плагин, если он есть, и боремся с его багами и особенностями. Либо пишем свой плагин и заставляем других бороться с его багами и особенностями. Либо используем сборщик проектов. Отличный пример — сборка J2ME приложения с несколькими десятками билдов с разными ресурсами и кодом на выходе.

5)Мне лень вручную выкачивать все зависимости и проверять совместимость версий. Пусть за меня это сделает мавен.

Здравствуйте, Sorc17, Вы писали:

S>>интеграционную сборку с реакцией на коммиты в репозиторий
S>Объясните нубу что это?
Есть такое сервер — Version Control System, в нем хранится исходный код и с ним работает большая команда.
Когда кто-то что-то меняет локально и доводит до ума он "коммитит" в VCS, чтобы сделать код доступным всем.
И вот я такой аболтус закомитил код, который не компилируется и ушел домой.
В результате вся команда не может продолжать работу потому что они не могут проверить свой код и как он работает с моим кодом.
Для решения этой проблемы создается билд-сервер, который собирает проект при каждом коммите.
Если сборка сломается, то все получат соответствующее письмо с именем автора последнего коммита. И я получу по шапке ещё до того как покину офис. :)

Здравствуйте, WFrag, Вы писали:

C>>Поэтому и делается сборка на нейтральной платформе, которой совершенно пофиг какая IDE.
WF>Вот это, кстати, довольно-таки плохо. Было бы гораздо веселее, если бы был некий относительно общий формат проектов для IDE. Пусть каждая IDE будет со своими расширениями, пусть комманд-лайн тул будет со своими. Но чтоб более-менее стандартные вещи описывались бы всё-таки одинаково для всех IDE.
Maven.

WF>Maven-овский POM, увы, таким форматом по многим причинам не является.
Таки является.

WF>Как пример, самый удобный вариант сборки OSGi-приложения у нас получился с Maven3+Tycho. Но это, по большому счёту, просто внедрение логики Eclipse PDE в сборочный процесс Maven-а. То есть как раз та самая идея -- Tycho учит Maven "понимать" проектные файлы Eclipse.
OSGi не нужен.

On 18.04.2011 11:25, Mr.Delphist wrote:

> Повторюсь: мне глубоко поровну, в чём у себя там товарищ пишет, на каком
> континенте находится и по какому графику работает. Мы команда, у нас
> общая цель, мы идём к ней. Но если коммиты этого человека являются
> регулярными головняками для команды, то вместо разборок "как починить"
> они будут откатываться.

"С вами невозможно спорить !" (с) Но остаётся неясной связь правильной
цели и стремление к тому, чтобы все пользовались одной и той же IDE (с
чего всё и началось).

--
WBR,
Serge.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Лупить. Затем еще раз лупить. Вплоть до отстранений/увольнений для "особо продвинутых". Пока не дойдет, что в проекте должны единообразно соблюдаться вполне определенные вещи:
MD>

MD>
• кодинг-стайл
  MD>
• инструментарий
  MD>
• воркфлоу (багтрекер, сорс-контроль и всё такое)
  MD>

MD>Что значит "часть команды работает в другой IDE"?! Да хоть в Зимбабве едут и там на голове пускай стоят — но если их коммиты разламывают проект в дефолтной IDE проекта, они сами себе буратины.

И Фар, значится, нельзя, если у тимлида любимый файл-менеджер Тотал Коммандер?
Кодинг-стайл не зависит от выбранной IDE. И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Неужели действительно одинаковы, с точностью до совместимости бинарных файлов? И можно половину файлов собрать одним компилем, а вторую — другим, и всё заработает? Блин, вы счастливые люди. Серьезно. Пора учить java.

Мы наблюдали момент просветления Удачи!

Здравствуйте, Mr.Delphist, Вы писали:

MD>Вы никогда не работали в проекте, где у двух людей разные взгляды на "нормальное форматирование"? Или когда у двух эклипсов настроены разные автоформаттеры? Осчучения феерические.
Взгляды всегда одинаковые. Последнее слово за главным на проекте, но стиль форматирования у всех всегда единый. Кто отступает от правил — пару раз скажешь, что у тебя проблема с форматированием — все, больше проблем с форматированием нет. Тоже самое с по разному настроенными автоформаттерами. Если кто выбивается — ему об этом надо сообщить, он правит, и все, больше проблем не возникает.
С форматированием я знаю только одну проблему — это когда какой то биг босс запрещает переформатировать по нормальному. И это в течение многих лет. Форматирование лесенкой, мешанина из табов и пробелов — это шедевр. Но и то можно жить при желании — вначале отформатировать нормально, сделать то, что нужно, а потом вернуть ненаглядное для шефа отсутствие форматирования. Всего лишь в 10 раз сроки затягиваются по сравнению с тем, как если б палки в колеса не вставляли, а так — и в таких условиях можно что то делать.

Здравствуйте, 0K, Вы писали:

0K>А! Наверное они не знают что есть такая удобная штуковина как Ecipse? Т.е. походу это "старые пердуны", которые кроме командной строки ничего не знают?
Для меня старые пердуны не делают разделения между IDE и платформой. Потому как в моем представлении "старые пердуны" работали лишь с Delphi, где IDE это и есть платформа.

mvn удобен, просто удобен.

Здравствуйте, LeonidV, Вы писали:

LV>Для меня старые пердуны не делают разделения между IDE и платформой. Потому как в моем представлении "старые пердуны" работали лишь с Delphi, где IDE это и есть платформа.

IDE -- нужна не просто для подсветки кода, но и для сборки проекта. На то она и IDE.

LV>mvn удобен, просто удобен.

А его правда используют? Чем не устраивает сборка проекта с помощью Eclipse, без всяких там Maven?

0K>А его правда используют?
Пользуют, еще и как.

>Чем не устраивает сборка проекта с помощью Eclipse, без всяких там Maven?

было бы очень странно собирать проект на интегрейшен сервере с помощью эклипса, ну и как минимум dependency hell никто не отменял.
система сборки != IDE, я раньше антом пользовался, в принципе все хорошо, но с зависимостями не оч удобно работать, хотя жить можно, мавен это лечит нараз. Ну а еще есть не только эклипс, я вот напрмер нетбинс пользую, кто то идею любит, а кто то вообще юзает просто какойто отдельный редактор типа джейэдит, для всего этого зоопарка единаная система сборки — как раз то что надо.

Здравствуйте, vitabrevis, Вы писали:

V>Вы наверное не в курсе, что есть проекты которые собираются автоматом, ежедневно, еженощно?

Почему же? Использовал TeamCity для автоматической сборки (для проектов VS 2010 sln править не приходилось).

Maven нужен исключительно для автоматической сборки?

Здравствуйте, 0K, Вы писали:

Если не ошибаюсь, для эклипса есть Maven-плагин
Зачем оно вообще надо — выше объяснили.

Здравствуйте, 0K, Вы писали:

0K>Здравствуйте, LeonidV, Вы писали:

LV>>Для меня старые пердуны не делают разделения между IDE и платформой. Потому как в моем представлении "старые пердуны" работали лишь с Delphi, где IDE это и есть платформа.

0K>IDE -- нужна не просто для подсветки кода, но и для сборки проекта. На то она и IDE.

LV>>mvn удобен, просто удобен.

0K>А его правда используют? Чем не устраивает сборка проекта с помощью Eclipse, без всяких там Maven?

И как же чудо-Eclipse находит зависимости? jar'ы в проект положите? И в svn добавите их? А сколько времени потребуется обновить версию одной из зависимостей? А если она сама с зависимостями? А если новую зависимость добавил ваш коллега по команде, эклипс-то её найдёт сразу?
А как сэкономить время настроики проекта если в команде половина работает с Intellij IDEA?
А как запускать автоматические тесты на линукс-сервере, который без иксов, эклипса?
Как управлять релизами?

Вам проще с IDE и без maven'a — ваш проект ещё не дорос до нужной фазы.

Здравствуйте, Skipy, Вы писали:

S>интеграционную сборку с реакцией на коммиты в репозиторий

Объясните нубу что это?

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Sorc17, Вы писали:

S>>>интеграционную сборку с реакцией на коммиты в репозиторий
S>>Объясните нубу что это?
B>Есть такое сервер — Version Control System, в нем хранится исходный код и с ним работает большая команда.
B>Когда кто-то что-то меняет локально и доводит до ума он "коммитит" в VCS, чтобы сделать код доступным всем.
B>И вот я такой аболтус закомитил код, который не компилируется и ушел домой.
B>В результате вся команда не может продолжать работу потому что они не могут проверить свой код и как он работает с моим кодом.
B>Для решения этой проблемы создается билд-сервер, который собирает проект при каждом коммите.
B>Если сборка сломается, то все получат соответствующее письмо с именем автора последнего коммита. И я получу по шапке ещё до того как покину офис.

Класс, спасибо

Здравствуйте, Blazkowicz, Вы писали:

B>И вот я, такой оболтус, закомитил код, который не компилируется и ушел домой.

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

В общем, регулярные сборки призваны снизить до минимума время от момента внесения проблемного кода в репозиторий до момента его обнаружения. Без системы тестирования ловят только ошибки компиляции, т.е. совершенное раздолбайство.

Здравствуйте, Skipy, Вы писали:

S>Код может даже компилироваться. Но вот тесты он ломает безнадежно. Такое случается гораздо чаще — полный цикл юнит-тестирования, занимает, скажем, пару часов, не все их прогоняют целиком. А есть и интеграционные тесты еще, их чаще всего на локальных машинах вообще не гоняют, они требуют окружения соответствующего.
S>В общем, регулярные сборки призваны снизить до минимума время от момента внесения проблемного кода в репозиторий до момента его обнаружения. Без системы тестирования ловят только ошибки компиляции, т.е. совершенное раздолбайство.
Ну, да. Это уже найтли билды. Но интеграционные многочасовые тесты не запускаются ведь на каждый коммит?

Здравствуйте, 0K, Вы писали:

0K>Вот никак не могу понять нафига вообще нужен этот Maven?
У меня из мавен проектов:
1) Делается сборка на CI сервере, прогоняются все тесты, собираются метрики, проверяется покрытие тестами, проверяются соответствие code convention;
2) Делается деплой на тестовый прямо из GUI CI сервера, делается production сборки прямо с CI сервера, для деплоя которых достаточно нажать одну клавишу, и все обновится как положено;
3) Запуск интеграционных тестов, проверка всего функционала, эмуляция клиента;
4) Есть куча разных таргетов, сборка проекта с различными опциями, в результате получается именно нужный мне war с нужными значениями в конфигах, именно нужным набором jar в либах;
5) Создание базы делается тоже мавен таргетом, как и обновление;
6) Новичку, подключенному к проекту, достаточно сказать url к исходникам. Он сразу же откроет это в IDE, все зависимости скачаются, никаких проблем со сборкой у него не будет;
7) Генерация кода для обращения к чужим вебсервисам на основе WSDL.
8) Про то, насколько стало подключить стороннюю либу (или собственную) через зависимости, даже говорить не буду. Мне не надо качать никакой спринг и хибернейт, за меня все самостоятельно скачается, положится куда надо.

Все это я с равным успехом могу делать как из командной строки, так и непосредственно из IDE, так как там есть maven plugin.

Для "простого программиста" maven удобен тем, что управляет зависимостями. Вот взять Hibernate. Он требует помимо своих .jar-ников ещё десяток других, и ещё другой десяток опциональны. Ещё Spring есть, с такими же аппетитами. Если тупо в lib скидывать всё, то в конечном счёте может получиться хаос, в котором уже никто не разберётся. А в maven всё попроще выходит, подключил hibernate нужной версии и всё, остальное само подтянется.

Ещё для командной разработки maven удобен тем, что не привязывает разработчика к определённой IDE. Например я предпочитаю Idea. Делать два набора файлов проекта в одном проекте? Их надо будет синхронизировать, да и вообще неудобно это. А так — все изменения делаются в конфигах maven-а, а остальные IDE их подхватывают.

CI на мой взгляд тут не при чём, можно и Eclipse-овские проекты собирать из командной строки.

Здравствуйте, 0K, Вы писали:

0K>Вот никак не могу понять нафига вообще нужен этот Maven?

Че-то народ флудит, а на вопрос так и не ответил
Конкретно Мейвен-то зачем нужен? Только, плз, не надо говорить, что для того, чтобы собирать проект и трекать зависимости. Для этого тулзы погибче и приятнее есть.
Интерестно, что разные люди на этот счет думают... Мне кажется, что сильно потиворечивая тулза.

Здравствуйте, StanislavK, Вы писали:

SK>Конкретно Мейвен-то зачем нужен? Только, плз, не надо говорить, что для того, чтобы собирать проект и трекать зависимости. Для этого тулзы погибче и приятнее есть.
Например? Какая конкретно еще тулза позволяет описать проект, а не процесс сборки?

Здравствуйте, WFrag, Вы писали:

WF>Да ладно. Чуть что посложнее и билд на Maven получается таким же описанием процесса сборки. antrun, конечно, немного спасает. Но всё равно, формат и негибкость POM-ок удручает неимоверно.
antrun это костыль в maven. Если вам надо не хватает какого-то действия сборки, maven way — написать mojo (то есть свой плагин). Причем mojo еще можно хорошенько протестировать.
Если у вас сборка какая-то мега необычная, то maven не тот инструмент, который вам нужен. Из классических — ivy, из новых — gradle и ему подобные.

WF>Maven отвратителен. Но, увы, это стандарт, а это уже многое значит.
Это далеко не стандарт и даже не рекомендация/спецификация. Никто вам его не навязывает (ну или не навязывает тому, кто навязывает вам, ну или не навязывает ... ). Выбор того или иного инструмента в проект — это обязанность лица, принимающего решения. Который сначала должен хорошенько подумать, прежде чем что-то решить.

Я думаю, что 90% или даже 99% проектов спокойно описываются maven'ом без каких-либо проблем. Особенно если они пишутся с 0, а не переводятся с ant'а, например.

И еще раз подчеркну — если вы отходите описания проекта и переходите к описанию сборки, то вам нужно как минимум протестировать различные варианты поведения. В случае описания проекта, тестировать приходится значительно меньше.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, Аноним, Вы писали:
А>>А как сэкономить время настроики проекта если в команде половина работает с Intellij IDEA?

MD>Лупить. Затем еще раз лупить. Вплоть до отстранений/увольнений для "особо продвинутых". Пока не дойдет, что в проекте должны единообразно соблюдаться вполне определенные вещи:

Глупость. Каждый выбирает тот инструмент, который ему удобней. Задача тех.лида (как руководителя) сделать так, чтобы его подчиненным было удобно. Единая система управления задачами, единая СУВ — это для удобства программиста. Но где ему конкретно работать (ОС) и на чем писать код (IDE), да даже какой профайлер использовать — это уже личное дело человека. Java как раз ценна тем, что в отличие от решений Apple/MS предоставляет свободу выбора программистам. maven (или подобная технология) — еще один кирпичик в фундамент этой свободы.

Здравствуйте, LeonidV, Вы писали:

LV>antrun это костыль в maven. Если вам надо не хватает какого-то действия сборки, maven way — написать mojo (то есть свой плагин). Причем mojo еще можно хорошенько протестировать.
LV>Если у вас сборка какая-то мега необычная, то maven не тот инструмент, который вам нужен. Из классических — ivy, из новых — gradle и ему подобные.

Проблема в том, что в проекте обычно не нужен maven way. Нужен надёжный, повторяемый билд с автоматическими тестами, развёртыванием, и.т.д.

LV>Это далеко не стандарт и даже не рекомендация/спецификация.

Де-факто -- это всё-таки стандарт.

LV>Никто вам его не навязывает (ну или не навязывает тому, кто навязывает вам, ну или не навязывает ... ). Выбор того или иного инструмента в проект — это обязанность лица, принимающего решения. Который сначала должен хорошенько подумать, прежде чем что-то решить.

Вне зависимости от этого, Maven -- довольно таки отвратительный инструмент.

LV>Я думаю, что 90% или даже 99% проектов спокойно описываются maven'ом без каких-либо проблем. Особенно если они пишутся с 0, а не переводятся с ant'а, например.

Это какие-то простые проекты. Даже такая банальная вещь, как подсчёт покрытия тестами делается в Maven довольно нетривиально (если надо посчитать покрытие по интеграционным тестам, например, а не по каждому модулю в отдельности).

LV>И еще раз подчеркну — если вы отходите описания проекта и переходите к описанию сборки, то вам нужно как минимум протестировать различные варианты поведения. В случае описания проекта, тестировать приходится значительно меньше.

Да, это так. Но просто собрать JAR-у достаточно только для очень простого проекта. Обычно требуется ещё запуск автоматических тестов на разных окружниях, подсчет покрытия, отчеты.

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

Здравствуйте, Mr.Delphist, Вы писали:

MD>Что значит "часть команды работает в другой IDE"?!
То и значит. Удивительно, но только в Дельфе и заражённой её C# язык и IDE — это одно и то же.

Поэтому и делается сборка на нейтральной платформе, которой совершенно пофиг какая IDE.

Здравствуйте, WFrag, Вы писали:
WF>Да, это так. Но просто собрать JAR-у достаточно только для очень простого проекта. Обычно требуется ещё запуск автоматических тестов на разных окружниях, подсчет покрытия, отчеты.
Ага, это, конечно, простой проект. Который требует проверку на различных окружениях. Вот у нас в проектах одно окружение.

WF>И даже в случае простого проекта Maven справляется довольно плохо. Объем скриптов огромен, много повторения, много несущественных деталей, редактировать скрипты просто неудобно. Много тонкостей, которые надо знать.
У нас он со своими задачи справляется отлично. И я все равно не понимаю, зачем использовать инструмент, если он не подходит, а потом на него ругаться. Возьмите тот же gradle или buildr и делайте на нем что угодно.

Здравствуйте, Cyberax, Вы писали:

C>Поэтому и делается сборка на нейтральной платформе, которой совершенно пофиг какая IDE.

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

Maven-овский POM, увы, таким форматом по многим причинам не является.


Как пример, самый удобный вариант сборки OSGi-приложения у нас получился с Maven3+Tycho. Но это, по большому счёту, просто внедрение логики Eclipse PDE в сборочный процесс Maven-а. То есть как раз та самая идея -- Tycho учит Maven "понимать" проектные файлы Eclipse.

Здравствуйте, Cyberax, Вы писали:

WF>>Вот это, кстати, довольно-таки плохо. Было бы гораздо веселее, если бы был некий относительно общий формат проектов для IDE. Пусть каждая IDE будет со своими расширениями, пусть комманд-лайн тул будет со своими. Но чтоб более-менее стандартные вещи описывались бы всё-таки одинаково для всех IDE.
C>Maven.

Чушь. В Eclipse он до сих пор работает весьма плохо. На большом проекте работать невозможно.

В NetBeans работает более-менее, но уровень интеграции убог. По факту, NetBeans не вникает в суть проекта, а просто запускает команды Maven-а. Это ОЧЕНЬ медленно. Типичный use-case, передеплой war-ки, работает медленно. Eclipse, к примеру, в этом плане гораздо лучше.

Это совсем не то, чего хотелось бы.

WF>>Как пример, самый удобный вариант сборки OSGi-приложения у нас получился с Maven3+Tycho. Но это, по большому счёту, просто внедрение логики Eclipse PDE в сборочный процесс Maven-а. То есть как раз та самая идея -- Tycho учит Maven "понимать" проектные файлы Eclipse.
C>OSGi не нужен.

Я считаю, в плане модульности, зависимостей и репозиториев OSGi на голову выше Maven-а. И в плане понятия "артефакт" и его метаданных OSGi тоже гораздо приятнее.

Здравствуйте, WFrag, Вы писали:

C>>Поэтому и делается сборка на нейтральной платформе, которой совершенно пофиг какая IDE.

WF>Вот это, кстати, довольно-таки плохо. Было бы гораздо веселее, если бы был некий относительно общий формат проектов для IDE. Пусть каждая IDE будет со своими расширениями, пусть комманд-лайн тул будет со своими. Но чтоб более-менее стандартные вещи описывались бы всё-таки одинаково для всех IDE.

Согласен с Cyberax — maven тут нормально справляется, у нас используется Eclipse, NetBeans, IDEA под Windows, Mac OS, Ubuntu.

WF>Maven-овский POM, увы, таким форматом по многим причинам не является.
Каким? Есть конечно косяки в интеграции, но работать особо не мешает.

Здравствуйте, WFrag, Вы писали:

WF>>>Вот это, кстати, довольно-таки плохо. Было бы гораздо веселее, если бы был некий относительно общий формат проектов для IDE. Пусть каждая IDE будет со своими расширениями, пусть комманд-лайн тул будет со своими. Но чтоб более-менее стандартные вещи описывались бы всё-таки одинаково для всех IDE.
C>>Maven.
WF>Чушь. В Eclipse он до сих пор работает весьма плохо. На большом проекте работать невозможно.
Это исключительно проблемы Eclipse, она сама по себе работает весьма плохо, без всяких Maven.

WF>В NetBeans работает более-менее, но уровень интеграции убог. По факту, NetBeans не вникает в суть проекта, а просто запускает команды Maven-а. Это ОЧЕНЬ медленно. Типичный use-case, передеплой war-ки, работает медленно. Eclipse, к примеру, в этом плане гораздо лучше.
Опять же, не умеете использовать. У меня в IDEA компиляция веб-проекта — это секунда, без всяких там "передеплоев".

Да, с использованием Maven.

C>>OSGi не нужен.
WF>Я считаю, в плане модульности, зависимостей и репозиториев OSGi на голову выше Maven-а. И в плане понятия "артефакт" и его метаданных OSGi тоже гораздо приятнее.
OSGi не нужен. Ибо нафиг эта вся зависимость с модулями не сдалась.

Здравствуйте, Cyberax, Вы писали:

WF>>Чушь. В Eclipse он до сих пор работает весьма плохо. На большом проекте работать невозможно.
C>Это исключительно проблемы Eclipse, она сама по себе работает весьма плохо, без всяких Maven.

Eclipse вычеркиваем...

WF>>В NetBeans работает более-менее, но уровень интеграции убог. По факту, NetBeans не вникает в суть проекта, а просто запускает команды Maven-а. Это ОЧЕНЬ медленно. Типичный use-case, передеплой war-ки, работает медленно. Eclipse, к примеру, в этом плане гораздо лучше.
C>Опять же, не умеете использовать. У меня в IDEA компиляция веб-проекта — это секунда, без всяких там "передеплоев".

NetBeans вычеркиваем...

Клёво, остаётся только IDEA, да?

C>Да, с использованием Maven...

И сколько тон XML-я быо написано?

Здравствуйте, GarryIV, Вы писали:

WF>>Вот это, кстати, довольно-таки плохо. Было бы гораздо веселее, если бы был некий относительно общий формат проектов для IDE. Пусть каждая IDE будет со своими расширениями, пусть комманд-лайн тул будет со своими. Но чтоб более-менее стандартные вещи описывались бы всё-таки одинаково для всех IDE.

GIV>Согласен с Cyberax — maven тут нормально справляется, у нас используется Eclipse, NetBeans, IDEA под Windows, Mac OS, Ubuntu.

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

У нас вот есть профиль для запуска JBoss, деплоя на него приложения и прогон тестов. Если деплой падает, как остановить JBoss, используя тот же плагин? Фиг знает. Хотя все базовые примитивы-то есть, запуск, деплой, останов, статус выполнения операций. И такие моменты возникают постоянно, как только выходишь за границы простой JAR-ки.

Зависимости на тестовые классы другого плагина? Та же фигня, работают чёрти-как.

Недавно человек на этом форуме спрашивал, как считать покрытие интеграционными тестами. Обычная, казалось бы, задача, а делается весьма нетривиально.

WF>>Maven-овский POM, увы, таким форматом по многим причинам не является.
GIV>Каким? Есть конечно косяки в интеграции, но работать особо не мешает.

Начиная с мелочей, вроде названия проекта, версии и зависимостей и заканчивая более крупными понятиями ("что есть веб-проект", например). Когда ты привыкший, ты их уже не замечешь.

Здравствуйте, WFrag, Вы писали:

WF>>>Вот это, кстати, довольно-таки плохо. Было бы гораздо веселее, если бы был некий относительно общий формат проектов для IDE. Пусть каждая IDE будет со своими расширениями, пусть комманд-лайн тул будет со своими. Но чтоб более-менее стандартные вещи описывались бы всё-таки одинаково для всех IDE.

GIV>>Согласен с Cyberax — maven тут нормально справляется, у нас используется Eclipse, NetBeans, IDEA под Windows, Mac OS, Ubuntu.

WF>Смотря что считать "нормально справляется". Может, у меня требования какие-то завышенные. Просто тошнит от огромного количества XML-я, особенно когда он пишется чтобы реализовать какую-то простейшую вешь.

Не знаю, может мне проекты какие-то простые попадаются или еще что, но не такое уж огромное количество XML получается.
Имел опыт храниения настроек проекта в sln (VS) , ipr (IDEA) и ant — этого врагу не пожелаешь.

WF>У нас вот есть профиль для запуска JBoss, деплоя на него приложения и прогон тестов. Если деплой падает, как остановить JBoss, используя тот же плагин? Фиг знает. Хотя все базовые примитивы-то есть, запуск, деплой, останов, статус выполнения операций. И такие моменты возникают постоянно, как только выходишь за границы простой JAR-ки.
ИМХО тут нужно что-то другое, не maven. Или мавен но с расширениями инкапсулиующими все эти "если-то-иначе" (antrun?).

WF>Зависимости на тестовые классы другого плагина? Та же фигня, работают чёрти-как.
Тут да, с тестoвыми зависимостями все плохо.

WF>Недавно человек на этом форуме спрашивал, как считать покрытие интеграционными тестами. Обычная, казалось бы, задача, а делается весьма нетривиально.

WF>>>Maven-овский POM, увы, таким форматом по многим причинам не является.
GIV>>Каким? Есть конечно косяки в интеграции, но работать особо не мешает.

WF>Начиная с мелочей, вроде названия проекта, версии и зависимостей и заканчивая более крупными понятиями ("что есть веб-проект", например). Когда ты привыкший, ты их уже не замечешь.
А что с названиями? Вроде как то все называется, в IDE отображается?
Знать бы мне самому, что ты понимаешь под "веб проект" .

Здравствуйте, WFrag, Вы писали:

WF>>>Чушь. В Eclipse он до сих пор работает весьма плохо. На большом проекте работать невозможно.
C>>Это исключительно проблемы Eclipse, она сама по себе работает весьма плохо, без всяких Maven.

WF>Eclipse вычеркиваем...

WF>>>В NetBeans работает более-менее, но уровень интеграции убог. По факту, NetBeans не вникает в суть проекта, а просто запускает команды Maven-а. Это ОЧЕНЬ медленно. Типичный use-case, передеплой war-ки, работает медленно. Eclipse, к примеру, в этом плане гораздо лучше.
C>>Опять же, не умеете использовать. У меня в IDEA компиляция веб-проекта — это секунда, без всяких там "передеплоев".

WF>NetBeans вычеркиваем...

WF>Клёво, остаётся только IDEA, да?
А может это у Eclipse c NetBeans интеграция c maven УГ?

C>>Да, с использованием Maven...

WF>И сколько тон XML-я быо написано?
Доберуть до работы, посчитаю объем pom.xml и заодно % от общего объема кода проекта. Но и так могу сказать, что это какие-то жалкие доли процента.

Здравствуйте, GarryIV, Вы писали:

GIV>Не знаю, может мне проекты какие-то простые попадаются или еще что, но не такое уж огромное количество XML получается.
GIV>Имел опыт храниения настроек проекта в sln (VS) , ipr (IDEA) и ant — этого врагу не пожелаешь.

Спорить не буду. Maven -- это движение в правильном направлении.

WF>>Начиная с мелочей, вроде названия проекта, версии и зависимостей и заканчивая более крупными понятиями ("что есть веб-проект", например). Когда ты привыкший, ты их уже не замечешь.
GIV>А что с названиями? Вроде как то все называется, в IDE отображается?

Например, когда говоришь человеку заглянуть в проект с одним названием, а он у него в IDE с другим. Потому что в Eclipse название проекта может совсем никак не совпадать с name/artifactId. Это путает.

GIV>Знать бы мне самому, что ты понимаешь под "веб проект" .

Если не углуюбляться в лингвистику и философию, допустим, это проект, результатом сборки которого является .war. В это понятие входит множество таких вещей как "откуда брать исходники?", "с каким classpath их компилировать?", "куда их складывать?".

И небольшой пример в тему: был у нас простой проект, собирался в WAR. Настроили maven-war-plugin так, чтобы он в манифест вписывал определенный заголовок. Ничего лишнего -- maven-war-plugin входит в стандартный packaging war, т.е никаких дополнительных плагинов не добавляли. Вроде как всё "декларативно", в стиле Maven.

Казалось бы, если Maven -- это общий язык для разных IDE, они должны автоматически сами сообразить, что при сборке WAR-а им нужно прописать определенный заголовок в манифест. Так вот фиг. IDEA собирала WAR, но не вписывала туда этот заголовок.

Конечно, понятно, почему так, но это, собственно, и говорит, что это нифига не общий язык.

Здравствуйте, GarryIV, Вы писали:

WF>>Клёво, остаётся только IDEA, да?
GIV>А может это у Eclipse c NetBeans интеграция c maven УГ?

И это, конечно, тоже. Но это не идёт в плюс Maven-у, увы. Даже учитывая то, что интеграцию не они пишут.

WF>>И сколько тон XML-я быо написано?
GIV>Доберуть до работы, посчитаю объем pom.xml и заодно % от общего объема кода проекта. Но и так могу сказать, что это какие-то жалкие доли процента.

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

Здравствуйте, WFrag, Вы писали:

WF>>>Чушь. В Eclipse он до сих пор работает весьма плохо. На большом проекте работать невозможно.
C>>Это исключительно проблемы Eclipse, она сама по себе работает весьма плохо, без всяких Maven.
WF>Eclipse вычеркиваем...
Мне тут подсказывают, что генерация elcipse-проектов из Maven вполне неплохо работает.

C>>Опять же, не умеете использовать. У меня в IDEA компиляция веб-проекта — это секунда, без всяких там "передеплоев".
WF>NetBeans вычеркиваем...
WF>Клёво, остаётся только IDEA, да?
Видимо.

C>>Да, с использованием Maven...
WF>И сколько тон XML-я быо написано?

cyberax@cybnet:~/work/app/prj% find . -name pom.xml | xargs cat | grep -v versionId | wc
1319 1542 41876

Если без учёта явного перечисления зависимостей зависимостей, то примерно так:

cyberax@cybnet:~/work/app/prj% find . -name pom.xml | xargs cat | grep -v version | grep -v dependency | grep -v artifact | grep -v group | wc
587 803 15636

В эти 587 строк входит создание web-приложения с GWT, компиляция stanalone'ового SWING-приложения, сборка WebStart'ового архива в проекте, разбитом на 6 модулей. Т.е. примерно 100 строк на модуль в среднем.

Так что сильно большое количество XML в POM-файлах сильно преувеличено.

Здравствуйте, WFrag, Вы писали:

WF>У нас вот есть профиль для запуска JBoss, деплоя на него приложения и прогон тестов. Если деплой падает, как остановить JBoss, используя тот же плагин? Фиг знает. Хотя все базовые примитивы-то есть, запуск, деплой, останов, статус выполнения операций. И такие моменты возникают постоянно, как только выходишь за границы простой JAR-ки.
В этом случае, берёшь и допиливаешь плугин, деплоишь в свой локальный репозиторий и наслаждаешься. Исходники большинства плугинов открыты, собираются тем же maven'ом.

WF>Зависимости на тестовые классы другого плагина? Та же фигня, работают чёрти-как.
То есть?

WF>Недавно человек на этом форуме спрашивал, как считать покрытие интеграционными тестами. Обычная, казалось бы, задача, а делается весьма нетривиально.
Хех. А как это сделать на альтернативах?

WF>>>Maven-овский POM, увы, таким форматом по многим причинам не является.
GIV>>Каким? Есть конечно косяки в интеграции, но работать особо не мешает.
WF>Начиная с мелочей, вроде названия проекта, версии и зависимостей и заканчивая более крупными понятиями ("что есть веб-проект", например). Когда ты привыкший, ты их уже не замечешь.
Что в названиях проекта-то не так?

Здравствуйте, WFrag, Вы писали:

GIV>>Знать бы мне самому, что ты понимаешь под "веб проект" .
WF>Если не углуюбляться в лингвистику и философию, допустим, это проект, результатом сборки которого является .war. В это понятие входит множество таких вещей как "откуда брать исходники?"
Решается с помощью <source> директивы в <build>. Плюс <resource> для ресурсов.

WF>"с каким classpath их компилировать?"
Зависимости.

WF>"куда их складывать?".
А чем стандартное расположение не нравится? Ну если не нравится кардинально, то <target> в <build>.

WF>Казалось бы, если Maven -- это общий язык для разных IDE, они должны автоматически сами сообразить, что при сборке WAR-а им нужно прописать определенный заголовок в манифест. Так вот фиг. IDEA собирала WAR, но не вписывала туда этот заголовок.
WF>Конечно, понятно, почему так, но это, собственно, и говорит, что это нифига не общий язык.
Файлите баг в IDEA, а пока не запилили — явно вызываете стадию на этапе компиляции.

Здравствуйте, Cyberax, Вы писали:

SK>>Только, плз, не надо говорить, что для того, чтобы собирать проект и трекать зависимости. Для этого тулзы погибче и приятнее есть.
C>Нету. Есть совместимые с форматом репозиториев Maven'а недоделки на всяких Groovy, которые надо нафиг закопать вместе с их авторами.

А можно подробнее, за что авторов Gradle надо закопать? Я не что бы потроллить спрашиваю, а действтельно интересно.
Как раз начал в последнем проекте использовать Gradle и пока могу сказать, что он заметно удобнее maven'а. Может из-за небольшого срока использования я не заметил какой-то существенный недостаток?

Здравствуйте, WFrag, Вы писали:

WF>И небольшой пример в тему: был у нас простой проект, собирался в WAR. Настроили maven-war-plugin так, чтобы он в манифест вписывал определенный заголовок. Ничего лишнего -- maven-war-plugin входит в стандартный packaging war, т.е никаких дополнительных плагинов не добавляли. Вроде как всё "декларативно", в стиле Maven.

WF>Казалось бы, если Maven -- это общий язык для разных IDE, они должны автоматически сами сообразить, что при сборке WAR-а им нужно прописать определенный заголовок в манифест. Так вот фиг. IDEA собирала WAR, но не вписывала туда этот заголовок.

WF>Конечно, понятно, почему так, но это, собственно, и говорит, что это нифига не общий язык.

Да, мне тоже в текущем проекте пришлось после импорта проекта из мавена пару вещей настроить в IDE, чтоб она собирала правильный ear (например использовала application.xml, который генерится мавеном). Да и вообще приходится писать pom'ы так чтоб IDE их понимали как следует. Было бы супер, чтоб этого всего делать не надо былоб, кто спорит.

Здравствуйте, Cyberax, Вы писали:

C>Ну и проблема с мультимодульностью нормально не решена. Ни в maven, ни в ivy, ни в Грабле. Как будто, они не работают над реальными проектами.

А можешь пояснить, какую именно мультимодульность и проблему ты имеешь в виду?

Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, RomikT, Вы писали:

RT>>А можно подробнее, за что авторов Gradle надо закопать? Я не что бы потроллить спрашиваю, а действтельно интересно.
C>За всё хорошее. Они сделали ещё один уродец, типа Maven'а, не решив ни одной его проблемы. Зато вместо XML'я заменили DSL'ем на Тьюринг-полном языке (это сейчас ведь модно!), который в принципе нельзя прочитать с помощью IDE. За что им отдельное "спасибо".
Есть такое дело. Хотя непосредственных недостатков я от такого решения пока не увидел. Да и прочитать с помощью IDE билд скрипты gradle не так уж и нереально, достаточно запустить фазу сборки configure, после чего в памяти будет построена модель не менее удобная, чем maven'овский pom.

C>Какие проблемы реально стоило бы решить:
C>1) НОРМАЛЬНЫЙ трэкинг зависимостей и целей. Как в Scons и WAF.
C>2) НОРМАЛЬНЫЕ мульти-модульные локальные билды.

C>Поясню:

C>Ни в одном инструмента для Java нет трекинга зависимостей, который был ещё в старом добром make. К примеру, если я набираю "mvn install" ничего не изменив в проекте, то у меня Maven перестраивает все war/jar-файлы, запускает тесты и т.п. Хотя это нафиг не надо — ничего ведь не изменилось!!! А если нужно что-то достаточно сложное, типа генерации исходников, которые компилируются в промежуточную утиллиту, которой обрабатываются остальные исходники — это уже вообще можно вешаться. Любое изменение — и полный rebuild всего.
В gradle трекинг зависимостей есть — если исходники не изменились, пересобираться ничего не будет. Зависимости поддерживаются как таски, так и на файлы (для генерируемых файлов gradle знает какой task их генерит).

C>И это при том, что scons/waf/cmake/boost jam и прочие прекрасно работают с зависимостями. Более того, в waf/scons даже такие приятные фичи есть, как инкрементальная компиляци — если меняется A.java, то перекомпилится только A.class и всё от него зависящее. Но к сожалению, для них проекты на Java — не основное назначение, так что очень многого нужного просто-напросто нет. Я как-то пытался waf использовать, но забил.
waf/scons инкрементальную компиляцию для Java поддерживает? Интересно, надо посмотреть как они это реализовали.

C>Ну и проблема с мультимодульностью нормально не решена. Ни в maven, ни в ivy, ни в Грабле. Как будто, они не работают над реальными проектами.
Присоединяюсь к вопросу Курилки, о какой именно проблеме идёт речь?

Здравствуйте, RomikT, Вы писали:

C>>За всё хорошее. Они сделали ещё один уродец, типа Maven'а, не решив ни одной его проблемы. Зато вместо XML'я заменили DSL'ем на Тьюринг-полном языке (это сейчас ведь модно!), который в принципе нельзя прочитать с помощью IDE. За что им отдельное "спасибо".
RT>Есть такое дело. Хотя непосредственных недостатков я от такого решения пока не увидел. Да и прочитать с помощью IDE билд скрипты gradle не так уж и нереально, достаточно запустить фазу сборки configure, после чего в памяти будет построена модель не менее удобная, чем maven'овский pom.
Нафиг мне модель в памяти? Мне нужно, чтобы IDE могла управлять и читать нормально описание проектов. Для Maven это уже более-менее работает.

RT>В gradle трекинг зависимостей есть — если исходники не изменились, пересобираться ничего не будет. Зависимости поддерживаются как таски, так и на файлы (для генерируемых файлов gradle знает какой task их генерит).
Будет. Плугины не занимаются трекингом зависимостей. Всё ровно как в Maven'е с небольшими дополнениями в виде упорядочивания задач.

C>>И это при том, что scons/waf/cmake/boost jam и прочие прекрасно работают с зависимостями. Более того, в waf/scons даже такие приятные фичи есть, как инкрементальная компиляци — если меняется A.java, то перекомпилится только A.class и всё от него зависящее. Но к сожалению, для них проекты на Java — не основное назначение, так что очень многого нужного просто-напросто нет. Я как-то пытался waf использовать, но забил.
RT>waf/scons инкрементальную компиляцию для Java поддерживает? Интересно, надо посмотреть как они это реализовали.
Scons точно поддерживает. Делается-то без проблем, всё ровно как и для C++ — разбираем import'ы и строим зависимости. Отдельные вопросы с внутренними и анонимными классами, но это мелочи.

C>>Ну и проблема с мультимодульностью нормально не решена. Ни в maven, ни в ivy, ни в Грабле. Как будто, они не работают над реальными проектами.
RT>Присоединяюсь к вопросу Курилки, о какой именно проблеме идёт речь?
Ответил.

Здравствуйте, Cyberax, Вы писали:

RT>>А можно подробнее, за что авторов Gradle надо закопать? Я не что бы потроллить спрашиваю, а действтельно интересно.
C>За всё хорошее. Они сделали ещё один уродец, типа Maven'а, не решив ни одной его проблемы.

mvn:site он тоже не умеет.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, RomikT, Вы писали:

C>>>За всё хорошее. Они сделали ещё один уродец, типа Maven'а, не решив ни одной его проблемы. Зато вместо XML'я заменили DSL'ем на Тьюринг-полном языке (это сейчас ведь модно!), который в принципе нельзя прочитать с помощью IDE. За что им отдельное "спасибо".
RT>>Есть такое дело. Хотя непосредственных недостатков я от такого решения пока не увидел. Да и прочитать с помощью IDE билд скрипты gradle не так уж и нереально, достаточно запустить фазу сборки configure, после чего в памяти будет построена модель не менее удобная, чем maven'овский pom.
C>Нафиг мне модель в памяти? Мне нужно, чтобы IDE могла управлять и читать нормально описание проектов. Для Maven это уже более-менее работает.
Так я про то и говорю. Чтение gradle скрипта это запуск фазы configure, после чего становятся известны все такси, наборы зависимостей, параметры компилятора и т.п. Это, конечно, процесс посложнее, чем чтение мавеновского pom, но всё вполне реально.

RT>>В gradle трекинг зависимостей есть — если исходники не изменились, пересобираться ничего не будет. Зависимости поддерживаются как таски, так и на файлы (для генерируемых файлов gradle знает какой task их генерит).
C>Будет. Плугины не занимаются трекингом зависимостей. Всё ровно как в Maven'е с небольшими дополнениями в виде упорядочивания задач.
Gradle docs: Skipping tasks that are up-to-date. Для встроенных тасков работает автоматически, для своих настраивается. Правда, дальше не-up-to-date таски уже выполняются целиком, инкрементальной компиляции нет.

C>>>Ну и проблема с мультимодульностью нормально не решена. Ни в maven, ни в ivy, ни в Грабле. Как будто, они не работают над реальными проектами.
RT>>Присоединяюсь к вопросу Курилки, о какой именно проблеме идёт речь?
C>Ответил.
Спасибо, отвечу там.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Курилка, Вы писали:

C>>>Ну и проблема с мультимодульностью нормально не решена. Ни в maven, ни в ivy, ни в Грабле. Как будто, они не работают над реальными проектами.
К>>А можешь пояснить, какую именно мультимодульность и проблему ты имеешь в виду?
C>Вот у меня проект из 6 модулей. Они все лежат в файловой системе рядышком. Предположим, что я поменял модуль А и теперь хочу собрать модуль Б, зависящий от него. Делать "mvn compile" на верхнем уровне не хочется из-за того, что это долго (см. пункт 1).

C>Казалось бы, достаточно зайти в каталог с модулем Б и запустить билд? Ан нет, фигушки. Сначала нужно зайти в модуль А, сделать там mvn install, и только потом зайти в модуль Б и там уже начать строить. Сам Maven ну никак не может догадаться, что этот модуль можно построить (он лежит локально рядом и доступен через родительский POM!!!).
Это была основная причина выбора Gradle — у меня ожидается довольно большое количество модулей (ибо OSGi).
С Maven действительно пришлось бы постоянно собирать всё, с Gradle такой проблемы нет. Он сначала соберёт все изменившиеся зависимости, а потому уже и текущий модуль.

C>Кстати, ещё не хватает out-of-tree билдов. Т.е. чтоб исходники можно было на read-only носителе, к примеру, иметь. Ну да ладно, можно прожить без этого.
В интернете пишут, что buildDirName=file('/tmp/myBuild') вполне работает. Сам не проверял.

Здравствуйте, octo47, Вы писали:

O>Здравствуйте, Cyberax, Вы писали:

O>Все эти проблемы легко решаются при помощи ключиков -pl -am -rf:
O>делаем из корневого:
O>

O>mvn -pl p2 -am

O>и мавен пересоберет только p3 и p2 (в таком порядке)

Да, есть такая возможность. Правда, получается слегка многословно (модули обычно называются чуть длиннее чем p2).
К тому же, если я хочу сделать mvn test текущему модулю, то, как я понимаю, maven запустит тесты и у зависимостей, и обойти это никакой возможности нет. Или есть?

Здравствуйте, RomikT, Вы писали:

RT>Здравствуйте, octo47, Вы писали:

O>>Здравствуйте, Cyberax, Вы писали:

O>>Все эти проблемы легко решаются при помощи ключиков -pl -am -rf:
O>>делаем из корневого:

RT>Да, есть такая возможность. Правда, получается слегка многословно (модули обычно называются чуть длиннее чем p2).
RT>К тому же, если я хочу сделать mvn test текущему модулю, то, как я понимаю, maven запустит тесты и у зависимостей, и обойти это никакой возможности нет. Или есть?

напрямую этого действительно нет. к сожалению. но можно сделать (дольше будет и писанины поболе)

mvn -pl p2 -am && mvn -pl p2 test

хотя никто не мешает сделать скрипт или алиас (в зависимости от ОС), которые будет
примерно таким

mvn -pl $1 -am && mvn -pl $1 test

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

Здравствуйте, octo47, Вы писали:

C>>Казалось бы, достаточно зайти в каталог с модулем Б и запустить билд? Ан нет, фигушки. Сначала нужно зайти в модуль А, сделать там mvn install, и только потом зайти в модуль Б и там уже начать строить. Сам Maven ну никак не может догадаться, что этот модуль можно построить (он лежит локально рядом и доступен через родительский POM!!!).
O>Все эти проблемы легко решаются при помощи ключиков -pl -am -rf:
O>http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/
Не помогает если надо запустить какой-то плугин, который есть только в этом модуле.

Здравствуйте, RomikT, Вы писали:

C>>Нафиг мне модель в памяти? Мне нужно, чтобы IDE могла управлять и читать нормально описание проектов. Для Maven это уже более-менее работает.
RT>Так я про то и говорю. Чтение gradle скрипта это запуск фазы configure, после чего становятся известны все такси, наборы зависимостей, параметры компилятора и т.п. Это, конечно, процесс посложнее, чем чтение мавеновского pom, но всё вполне реально.
Это невозможно в общем, из-за того, что скрипты в Gradle могут в рантайме всё менять.

C>>Будет. Плугины не занимаются трекингом зависимостей. Всё ровно как в Maven'е с небольшими дополнениями в виде упорядочивания задач.
RT>Gradle docs: Skipping tasks that are up-to-date. Для встроенных тасков работает автоматически, для своих настраивается. Правда, дальше не-up-to-date таски уже выполняются целиком, инкрементальной компиляции нет.
Зависимость задач — это не то. Нужно уметь строить полный граф зависимостей, архитектура Gradle для этого не подходит.

Здравствуйте, RomikT, Вы писали:

C>>Казалось бы, достаточно зайти в каталог с модулем Б и запустить билд? Ан нет, фигушки. Сначала нужно зайти в модуль А, сделать там mvn install, и только потом зайти в модуль Б и там уже начать строить. Сам Maven ну никак не может догадаться, что этот модуль можно построить (он лежит локально рядом и доступен через родительский POM!!!).
RT>Это была основная причина выбора Gradle — у меня ожидается довольно большое количество модулей (ибо OSGi).
RT>С Maven действительно пришлось бы постоянно собирать всё, с Gradle такой проблемы нет. Он сначала соберёт все изменившиеся зависимости, а потому уже и текущий модуль.
Я пробовал, у меня не получилось — та же проблема, что и с Maven.

C>>Кстати, ещё не хватает out-of-tree билдов. Т.е. чтоб исходники можно было на read-only носителе, к примеру, иметь. Ну да ладно, можно прожить без этого.
RT>В интернете пишут, что buildDirName=file('/tmp/myBuild') вполне работает. Сам не проверял.
В Maven'е теоретически тоже. На практике, результаты другие.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, octo47, Вы писали:

C>>>Казалось бы, достаточно зайти в каталог с модулем Б и запустить билд? Ан нет, фигушки. Сначала нужно зайти в модуль А, сделать там mvn install, и только потом зайти в модуль Б и там уже начать строить. Сам Maven ну никак не может догадаться, что этот модуль можно построить (он лежит локально рядом и доступен через родительский POM!!!).
O>>Все эти проблемы легко решаются при помощи ключиков -pl -am -rf:
O>>http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/
C>Не помогает если надо запустить какой-то плугин, который есть только в этом модуле.

Для исходной задачи (install) решение работает. Для все-собрать-запустить-assembly не работает.
Вообще это проблема не мавена как такового (теоретически это можно разрулить плагином), а в его
идеологии: запускаем не плагины, а фазы.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Что значит "часть команды работает в другой IDE"?!
C>То и значит. Удивительно, но только в Дельфе и заражённой её C# язык и IDE — это одно и то же.

[off] Не ведитесь на ник — я ещё и асм с TCL знаю [/off]

Здравствуйте, Mr.Delphist, Вы писали:

MD>>>Что значит "часть команды работает в другой IDE"?!
C>>То и значит. Удивительно, но только в Дельфе и заражённой её C# язык и IDE — это одно и то же.
MD>[off] Не ведитесь на ник — я ещё и асм с TCL знаю [/off]
А Smalltalk?

Здравствуйте, LeonidV, Вы писали:

LV>Глупость. Каждый выбирает тот инструмент, который ему удобней. Задача тех.лида (как руководителя) сделать так, чтобы его подчиненным было удобно. Единая система управления задачами, единая СУВ — это для удобства программиста. Но где ему конкретно работать (ОС) и на чем писать код (IDE), да даже какой профайлер использовать — это уже личное дело человека. Java как раз ценна тем, что в отличие от решений Apple/MS предоставляет свободу выбора программистам. maven (или подобная технология) — еще один кирпичик в фундамент этой свободы.

Как-то у меня то ли от не-джавного экспириенса, то ли от MS-козней, пока что статистика иная: все эти "светочи демократии", "непризнанные гении" и прочие альтернативные товарищи являются элементом из столь любимой на RSDN серии "не нужен".

Повторюсь: мне глубоко поровну, в чём у себя там товарищ пишет, на каком континенте находится и по какому графику работает. Мы команда, у нас общая цель, мы идём к ней. Но если коммиты этого человека являются регулярными головняками для команды, то вместо разборок "как починить" они будут откатываться. Потому что мы перестаем идти к цели. Потому что начинаем обслуживать гениальность одного (или нескольких) человека вместо интересов Заказчика.

Снова повторюсь: в проекте должны быть правила. Они не от хорошей жизни, не самые лучшие, но без них будет анархия. Обычно есть два и более способа сделать что-либо, но для целостности решения надо выбрать какой-то один в качестве стандарта, и чётко ему следовать. Товарищам несогласным могу порекомендовать попытаться закоммитить что-нибудь гениальное в тот же Spring или иной опен-сорц взрослого масштаба. Ой, Вас не пустили в транк? Ой, Вашу гениальность не оценили? Дурацкие там правила, оказывается, да? Наверное, и весь проект тоже дурацкий?
Отличие проекта на работе от опенсорсного проекта — у Вас есть куда более весомая возможность влиять на процесс. Аргументируйте, аргументируйте и еще раз аргументируйте своё предложение. Накапливайте статистику (только не будьте занудой) — и всё обязательно получится!

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, RomikT, Вы писали:

C>>>Казалось бы, достаточно зайти в каталог с модулем Б и запустить билд? Ан нет, фигушки. Сначала нужно зайти в модуль А, сделать там mvn install, и только потом зайти в модуль Б и там уже начать строить. Сам Maven ну никак не может догадаться, что этот модуль можно построить (он лежит локально рядом и доступен через родительский POM!!!).
RT>>Это была основная причина выбора Gradle — у меня ожидается довольно большое количество модулей (ибо OSGi).
RT>>С Maven действительно пришлось бы постоянно собирать всё, с Gradle такой проблемы нет. Он сначала соберёт все изменившиеся зависимости, а потому уже и текущий модуль.
C>Я пробовал, у меня не получилось — та же проблема, что и с Maven.
Попробовал ещё раз, всё работает:

C:\Workspaces\GradleTest\m2>gradle compileJava
:m1:compileJava
:m1:processResources
:m1:classes
:m1:jar
:m2:compileJava

C:\Workspaces\GradleTest\m2>gradle clean compileJava
:m2:clean
:m1:compileJava UP-TO-DATE
:m1:processResources UP-TO-DATE
:m1:classes UP-TO-DATE
:m1:jar UP-TO-DATE
:m2:compileJava

Архив проекта: http://files.rsdn.ru/35651/GradleTest.zip

C>>>Кстати, ещё не хватает out-of-tree билдов. Т.е. чтоб исходники можно было на read-only носителе, к примеру, иметь. Ну да ладно, можно прожить без этого.
RT>>В интернете пишут, что buildDirName=file('/tmp/myBuild') вполне работает. Сам не проверял.
C>В Maven'е теоретически тоже. На практике, результаты другие.
Проверил, действительно не работает
Точнее, buildDir переопределяется правильно, но в корневом проекте всё равно создаётся папка .gradle c какими-то кэшами.

Здравствуйте, Cyberax, Вы писали:

O>>Все эти проблемы легко решаются при помощи ключиков -pl -am -rf:
O>>http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/
C>Не помогает если надо запустить какой-то плугин, который есть только в этом модуле.

Можно подробнее про хитрый плугин?
Ключ -rf советуется консольным выводом мавена при любом фейле. Работает без проблем. Жаль, что идеевский плагин его не понимает.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Mr.Delphist, Вы писали:

MD>>>>Что значит "часть команды работает в другой IDE"?!
C>>>То и значит. Удивительно, но только в Дельфе и заражённой её C# язык и IDE — это одно и то же.
MD>>[off] Не ведитесь на ник — я ещё и асм с TCL знаю [/off]
C>А Smalltalk?

Нет, лишь плюсы в какой-то мере умею

Здравствуйте, hrensgory, Вы писали:

H>"С вами невозможно спорить !" (с) Но остаётся неясной связь правильной
H>цели и стремление к тому, чтобы все пользовались одной и той же IDE (с
H>чего всё и началось).

При старте проекта утверждается дефолтный инструментарий, на котором должна быть обеспечена собираемость.
Грубый пример: если мы говорим, что базовым IDE проекта будет Visual Studio 6, то стройными рядами в лес отправятся как адепты свежайших VS20xx, так и гики Эклипса и командной строки, если их жизнедеятельность будет порождать подобные кейсы:

Кейс А:
— Вася, привет
— Привет
— Вась, тут беда с твоим коммитом — шестерка отказывается компилить файл, хотя внешне выглядит нормально
— А, понятно! Когда ж вы тоже на последнюю студию перейдёте — там юникод полностью поддерживается
— Перейдем, как Заказчик одобрит бюджет на лицензии. А пока — откатываем тебя, полностью.

Кейс Б:
— Коля
— Ась?
— Глянул твой вчерашний коммит. Там же ревью кода делать нереально — форматирование по каждому файлу переколбашено.
— Ну, у меня Эклипс. Это он автоматом так.
— Коля, откатываем. Нам ещё мержиться с двумя бранчами — давай формат не будем трогать.

Кейс В:
— Петя, салют. У меня опять плохие новости.
— Откатываете?
— Угадал Опять ты свой батничек поправил, а проекты Студии забыл
— Ты ж знаешь, я привык, у меня мейк настроен как надо, собирается в одно касание всё, удо...
— Петя, удобно. Тебе. Откатываем.

Здравствуйте, Donz, Вы писали:

D>И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.

Простите, а билд-сервер чем собирает? Сферическим компилятором? Дефолтная IDE как раз и подбирается таким образом, чтобы не конфликтовать с инструментарием билд-сервера. В идеале — должна использовать тот же самый тулсет.

Насчет code review — тоже не всё так однозначно. В одном проекте было требование не выходить за 80 символов в строке (что странно звучит для нынешних мониторов, правда?). Резон оказался прост: для code review у Заказчика был в ходу какой-то инструментарий, выполненный в консольном стиле. Все "излишки" визуально обрезались

Здравствуйте, Mr.Delphist, Вы писали:

D>>И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.
MD>Простите, а билд-сервер чем собирает? Сферическим компилятором? Дефолтная IDE как раз и подбирается таким образом, чтобы не конфликтовать с инструментарием билд-сервера. В идеале — должна использовать тот же самый тулсет.

У вас какая-то путаница. В Java мире нет жестких связей между IDE, компилятором, используемым API (можно даже подменить фундаментальную библиотеку) и какими-либо утилитами и тулзами. Все популярные IDE позволяют задать конкретный компилятор, который надо использовать. Конечный полученный байт-код не зависит от IDE, которая этот компилятор вызвала. Какие тут конфликты?
Если хотите наибольшую совместимость с окружением билд-сервера, то для этого как раз и используются сборщики проектов. Один и тот же билд-скрипт и для билд-сервера, и для локальных сборок. Из какой IDE вызывать stand-alone установленный нужной версии мавен, ант, или-что-там-еще не имеет значения. Все довольны.

MD>Насчет code review — тоже не всё так однозначно. В одном проекте было требование не выходить за 80 символов в строке (что странно звучит для нынешних мониторов, правда?). Резон оказался прост: для code review у Заказчика был в ходу какой-то инструментарий, выполненный в консольном стиле. Все "излишки" визуально обрезались

Так опять же, какая тут зависимость от IDE? Во всех средах можно настроить длину строки в символах плюс автоврапперы для различных языковых конструкций.

Здравствуйте, Mr.Delphist, Вы писали:

MD>При старте проекта утверждается дефолтный инструментарий, на котором должна быть обеспечена собираемость.
MD>Грубый пример: если мы говорим, что базовым IDE проекта будет Visual Studio 6, то стройными рядами в лес отправятся как адепты свежайших VS20xx, так и гики Эклипса и командной строки, если их жизнедеятельность будет порождать подобные кейсы.

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

MD>Кейс А:
MD>- Вася, привет
MD>- Привет
MD>- Вась, тут беда с твоим коммитом — шестерка отказывается компилить файл, хотя внешне выглядит нормально
MD>- А, понятно! Когда ж вы тоже на последнюю студию перейдёте — там юникод полностью поддерживается
MD>- Перейдем, как Заказчик одобрит бюджет на лицензии. А пока — откатываем тебя, полностью.

Значит надо обговорить версию языка и SDK, которые должны использоваться при разработке. Если Visual Studio имеет прямую зависимость от одной конкретной версии языка... То я даже не знаю, что сказать. Нет такого на яве.

MD>Кейс Б:
MD>- Коля
MD>- Ась?
MD>- Глянул твой вчерашний коммит. Там же ревью кода делать нереально — форматирование по каждому файлу переколбашено.
MD>- Ну, у меня Эклипс. Это он автоматом так.
MD>- Коля, откатываем. Нам ещё мержиться с двумя бранчами — давай формат не будем трогать.

Причем тут IDE? Во всех по умолчанию используется code style, рекомендуемый ведущим собаководом. Если хочется чего-то другого, то это обговаривается и каждый сам себе настраивает.

MD>Кейс В:
MD>- Петя, салют. У меня опять плохие новости.
MD>- Откатываете?
MD>- Угадал Опять ты свой батничек поправил, а проекты Студии забыл
MD>- Ты ж знаешь, я привык, у меня мейк настроен как надо, собирается в одно касание всё, удо...
MD>- Петя, удобно. Тебе. Откатываем.

Именно для этого существуют сборщики проектов.
Хранить в VCS файлы проектов конкретной IDE — никому ненужный геморрой. В любом случае у каждого несколько свое окружение. Я люблю проекты держать в \Donz\Projects. Кто-то в другом месте. Уже имеем не совпадение путей. У меня JDK по одному пути, у остальных по-другому. У меня сторонние утилиты лежат в одном каталоге, у Васи вообще берутся с расшаренной папки на сервере. Каждый коммит будет содержать никому ненужные конкретно твои особенности окружения.
Соответственно, каждый программист должен быть в состоянии настроить выбранную IDE.

On 18.04.2011 14:18, Mr.Delphist wrote:

> H>"С вами невозможно спорить !" (с) Но остаётся неясной связь правильной
> H>цели и стремление к тому, чтобы все пользовались одной и той же IDE (с
> H>чего всё и началось).
>
> При старте проекта утверждается дефолтный инструментарий, на котором
> должна быть обеспечена собираемость.

Ну. Этот инструментарий и называется maven
Там и кодировка исходников указывается и source и target для компиляции
и собирается всё "в одно касание". А в чём там программисты исходники
редактируют — это их личное дело.

--
WBR,
Serge.

Здравствуйте, Donz, Вы писали:

Просто сразу видно по посту, что человек разрабатыет под дотнет и там несколько другая психология, строгая что ли. Есть такая пословица — мастера узнают по инструменту. Поэтому нагибать Java разработчиков на тему IDE и форматирования это не слишком продуктивно. Если чувак не умеет настраивать эклипс, то это его проблема, что он checkstyle не проходит.

А так в принципе от тех "эффективных" лидов, которые в приказном порядке заставляют писать в определенной версии ide (к которой они привыкли), собирать батниками с их путями (к которым они привыкли) и использовать табы вместо пробелов (к которым они привыкли), надо бежать не оглядываясь.

Здравствуйте, Mr.Delphist, Вы писали:

D>>И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.
MD>Простите, а билд-сервер чем собирает? Сферическим компилятором?
Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.

MD>Насчет code review — тоже не всё так однозначно. В одном проекте было требование не выходить за 80 символов в строке (что странно звучит для нынешних мониторов, правда?). Резон оказался прост: для code review у Заказчика был в ходу какой-то инструментарий, выполненный в консольном стиле. Все "излишки" визуально обрезались
Для этого используются инспекции кода.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Mr.Delphist, Вы писали:

D>>>И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.
MD>>Простите, а билд-сервер чем собирает? Сферическим компилятором?
C>Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.

Неужели действительно одинаковы, с точностью до совместимости бинарных файлов? И можно половину файлов собрать одним компилем, а вторую — другим, и всё заработает? Блин, вы счастливые люди. Серьезно. Пора учить java.

MD>Неужели действительно одинаковы, с точностью до совместимости бинарных файлов? И можно половину файлов собрать одним компилем, а вторую — другим, и всё заработает? Блин, вы счастливые люди. Серьезно. Пора учить java.

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

Здравствуйте, Mr.Delphist, Вы писали:

MD>>>Простите, а билд-сервер чем собирает? Сферическим компилятором?
C>>Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.
MD>Неужели действительно одинаковы, с точностью до совместимости бинарных файлов?
Ага.

MD>И можно половину файлов собрать одним компилем, а вторую — другим, и всё заработает?
Можно, и я так делаю постоянно (встроеный комиплятор в IDE — это Eclipse'овый, а Maven использует javac).

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, Cyberax, Вы писали:

C>>Здравствуйте, Mr.Delphist, Вы писали:

D>>>>И корректность коммита должна определяться не сборкой в дефолтной (опять же любимой тимлидом) IDE, а сборкой билд-сервера плюс ручным code review.
MD>>>Простите, а билд-сервер чем собирает? Сферическим компилятором?
C>>Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.

MD>Неужели действительно одинаковы, с точностью до совместимости бинарных файлов? И можно половину файлов собрать одним компилем, а вторую — другим, и всё заработает? Блин, вы счастливые люди. Серьезно. Пора учить java.

Я ж говорю, человек запуганный майкрософтом

C>Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.

о кстати такой вопрос эксперту.

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

Здравствуйте, keenn, Вы писали:

C>>Аллё! В Java все компиляторы примерно одинаковы. Совершенно пофиг чем компилировать .java в .class.
K>о кстати такой вопрос эксперту.
K>а разные компиляторы же могут создавать байт-код под разные jvm машины (с различной оптимизацией под то да под это)?
Байт-коду пофиг для какой он JVM. И оптимизаций в нём тоже почти что и нет (за исключением тривиальных типа dead code elimination).

C>Байт-коду пофиг для какой он JVM. И оптимизаций в нём тоже почти что и нет (за исключением тривиальных типа dead code elimination).

ясненько. т.е. все специализации только на уровне jvm. сенкс

Здравствуйте, keenn, Вы писали:

C>>Байт-коду пофиг для какой он JVM. И оптимизаций в нём тоже почти что и нет (за исключением тривиальных типа dead code elimination).

K>ясненько. т.е. все специализации только на уровне jvm. сенкс

Ну вообще-то не все так категорично — небольшие тонкости все таки есть между компилятором в eclipse и javac. Например вот это @Annotation("",) не скомпилится на javac, а на ecj нормально. Но в общем случае инструкции байткода стандартны.

Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, LeonidV, Вы писали:

WF>Да ладно. Чуть что посложнее и билд на Maven получается таким же описанием процесса сборки. antrun, конечно, немного спасает. Но всё равно, формат и негибкость POM-ок удручает неимоверно.

WF>Maven отвратителен. Но, увы, это стандарт, а это уже многое значит.

Дружище!! Дай пожму твою руку!

Здравствуйте, Mr.Delphist, Вы писали:

MD>- Коля, откатываем. Нам ещё мержиться с двумя бранчами — давай формат не будем трогать.
Представляю какая колбаса у вас в коде творится . Просто отформатировать нормально проблемы если, а уж про рефакторинги простейшие наверно даже забыть можно. Хотя б 200 тысяч то разработчикам платите то, в компенсацию за нервную работу, подозреваю что с постоянными авралами и срывами сроков ?

Здравствуйте, elmal, Вы писали:

MD>>- Коля, откатываем. Нам ещё мержиться с двумя бранчами — давай формат не будем трогать.
E>Представляю какая колбаса у вас в коде творится . Просто отформатировать нормально проблемы если, а уж про рефакторинги простейшие наверно даже забыть можно.

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

On 19.04.2011 11:35, WFrag wrote:

> Когда в проекте несколько IDE, настроить их все так, чтобы они
> форматировали *абсолютно* одинаково, может оказаться не самой простой
> задачей. А без этого, личности, которые переформатируют исходники перед
> коммитом, будут постоянно перетягивать одеяло между собой.

Настроить можно (по крайней мере Эклипс и Идею единообразно под
требования заказчика настраивали без проблем). Личность, кстати, можно
заменить машиной.

Перетягивание одеяла возможно только если у кого-либо есть вредная
привычка форматировать перед коммитом исходники всего модуля (или
директорию) целиком. Как правило лечится однократной поркой негодяя на
конюшне.

--
WBR,
Serge.

Здравствуйте, hrensgory, Вы писали:

H>On 19.04.2011 11:35, WFrag wrote:

>> Когда в проекте несколько IDE, настроить их все так, чтобы они
>> форматировали *абсолютно* одинаково, может оказаться не самой простой
>> задачей. А без этого, личности, которые переформатируют исходники перед
>> коммитом, будут постоянно перетягивать одеяло между собой.

H>Настроить можно (по крайней мере Эклипс и Идею единообразно под
H>требования заказчика настраивали без проблем). Личность, кстати, можно
H>заменить машиной.

Я специально не пытался, но, например, NetBeans и Eclipse по-разному форматируют параметры методов. Одинаково настроить не получилось

В принципе-то, конечно, один раз делаются три настройки для IDEA, Eclipse и NetBeans с максимально близкими свойствами, но это стоит времени.

Машина -- это да, разумная мысль.

H>Перетягивание одеяла возможно только если у кого-либо есть вредная
H>привычка форматировать перед коммитом исходники всего модуля (или
H>директорию) целиком. Как правило лечится однократной поркой негодяя на
H>конюшне.

А в чём проблема, если исходники уже отформатированы как надо?

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, Mr.Delphist, Вы писали:

MD>>- Коля, откатываем. Нам ещё мержиться с двумя бранчами — давай формат не будем трогать.
E>Представляю какая колбаса у вас в коде творится . Просто отформатировать нормально проблемы если, а уж про рефакторинги простейшие наверно даже забыть можно.

Вы никогда не работали в проекте, где у двух людей разные взгляды на "нормальное форматирование"? Или когда у двух эклипсов настроены разные автоформаттеры? Осчучения феерические.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, elmal, Вы писали:

E>>Здравствуйте, Mr.Delphist, Вы писали:

MD>>>- Коля, откатываем. Нам ещё мержиться с двумя бранчами — давай формат не будем трогать.
E>>Представляю какая колбаса у вас в коде творится . Просто отформатировать нормально проблемы если, а уж про рефакторинги простейшие наверно даже забыть можно.

MD>Вы никогда не работали в проекте, где у двух людей разные взгляды на "нормальное форматирование"? Или когда у двух эклипсов настроены разные автоформаттеры? Осчучения феерические.

Т.е. PM у вас нет, или он не выполняет свои обязанности?

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Здравствуйте, elmal, Вы писали:

E>>>Здравствуйте, Mr.Delphist, Вы писали:

MD>>>>- Коля, откатываем. Нам ещё мержиться с двумя бранчами — давай формат не будем трогать.
E>>>Представляю какая колбаса у вас в коде творится . Просто отформатировать нормально проблемы если, а уж про рефакторинги простейшие наверно даже забыть можно.

MD>>Вы никогда не работали в проекте, где у двух людей разные взгляды на "нормальное форматирование"? Или когда у двух эклипсов настроены разные автоформаттеры? Осчучения феерические.

К>Т.е. PM у вас нет, или он не выполняет свои обязанности?

PM — лох, TL — рулит

Здравствуйте, Aib, Вы писали:

Aib>Здравствуйте, Курилка, Вы писали:

К>>Здравствуйте, Mr.Delphist, Вы писали:

MD>>>Вы никогда не работали в проекте, где у двух людей разные взгляды на "нормальное форматирование"? Или когда у двух эклипсов настроены разные автоформаттеры? Осчучения феерические.

К>>Т.е. PM у вас нет, или он не выполняет свои обязанности?

Aib>PM — лох, TL — рулит

Т.е. описаное выше — это результат гениального тимлидерства? Неплохо...

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Здравствуйте, elmal, Вы писали:

E>>>Здравствуйте, Mr.Delphist, Вы писали:

MD>>>>- Коля, откатываем. Нам ещё мержиться с двумя бранчами — давай формат не будем трогать.
E>>>Представляю какая колбаса у вас в коде творится . Просто отформатировать нормально проблемы если, а уж про рефакторинги простейшие наверно даже забыть можно.

MD>>Вы никогда не работали в проекте, где у двух людей разные взгляды на "нормальное форматирование"? Или когда у двух эклипсов настроены разные автоформаттеры? Осчучения феерические.

К>Т.е. PM у вас нет, или он не выполняет свои обязанности?

Диалог PM с девелопером — см. выше. Иногда с такими "идейными" девелоперами приходится даже расставаться, т.к. страдает вся команда.

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Aib, Вы писали:

Aib>>Здравствуйте, Курилка, Вы писали:

К>>>Здравствуйте, Mr.Delphist, Вы писали:

MD>>>>Вы никогда не работали в проекте, где у двух людей разные взгляды на "нормальное форматирование"? Или когда у двух эклипсов настроены разные автоформаттеры? Осчучения феерические.

К>>>Т.е. PM у вас нет, или он не выполняет свои обязанности?

Aib>>PM — лох, TL — рулит

К>Т.е. описаное выше — это результат гениального тимлидерства? Неплохо...

Это я хотел сказать что это не дело пм'а следить за форматирвоанием кода на проекте

Здравствуйте, Aib, Вы писали:

Aib>Здравствуйте, Курилка, Вы писали:

К>>Здравствуйте, Aib, Вы писали:

Aib>>>Здравствуйте, Курилка, Вы писали:

К>>>>Здравствуйте, Mr.Delphist, Вы писали:

MD>>>>>Вы никогда не работали в проекте, где у двух людей разные взгляды на "нормальное форматирование"? Или когда у двух эклипсов настроены разные автоформаттеры? Осчучения феерические.

К>>>>Т.е. PM у вас нет, или он не выполняет свои обязанности?

Aib>>>PM — лох, TL — рулит

К>>Т.е. описаное выше — это результат гениального тимлидерства? Неплохо...

Aib>Это я хотел сказать что это не дело пм'а следить за форматирвоанием кода на проекте

Дело PM-а — сделать работу комманды наиболее продуктивной, в частности, разрешив проблемы, если они имеются (или делегировав полномочия подходящему члену команды). Хорошо, конечно, если есть хороший лид, и проблема не будет эскалирована выше. Но тут-то, видимо, проблема не решается вообще в принципе, и сказывается на общем результате, а ответственный за него, в первую очередь — PM.