Здравствуйте, LeonidV, Вы писали:
SK>>Конкретно Мейвен-то зачем нужен? Только, плз, не надо говорить, что для того, чтобы собирать проект и трекать зависимости. Для этого тулзы погибче и приятнее есть. LV>Например? Какая конкретно еще тулза позволяет описать проект, а не процесс сборки?
Да ладно. Чуть что посложнее и билд на Maven получается таким же описанием процесса сборки. antrun, конечно, немного спасает. Но всё равно, формат и негибкость POM-ок удручает неимоверно.
Maven отвратителен. Но, увы, это стандарт, а это уже многое значит.
Здравствуйте, Аноним, Вы писали: А>А как сэкономить время настроики проекта если в команде половина работает с Intellij IDEA?
Лупить. Затем еще раз лупить. Вплоть до отстранений/увольнений для "особо продвинутых". Пока не дойдет, что в проекте должны единообразно соблюдаться вполне определенные вещи:
кодинг-стайл
инструментарий
воркфлоу (багтрекер, сорс-контроль и всё такое)
Что значит "часть команды работает в другой IDE"?! Да хоть в Зимбабве едут и там на голове пускай стоят — но если их коммиты разламывают проект в дефолтной IDE проекта, они сами себе буратины. Коммиты будут откачены билд-мастером, и назавтра эти оболтусы опять вернутся к старой задаче. Только теперь уже с необходимостью играть по официальным правилам. Не нравятся эти правила — аргументируйте, обсуждайте, влияйте. Но пока не принято новых решений — уж будьте добры, играйте в команде. Гениальность — не оправдание раздолбайству.
Re[4]: В чем удобство Maven (зачем оно нужно)? Ну и зачем?
Здравствуйте, 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.
Sapienti sat!
Re[6]: В чем удобство Maven (зачем оно нужно)? Ну и зачем?
Здравствуйте, WFrag, Вы писали: WF>Да, это так. Но просто собрать JAR-у достаточно только для очень простого проекта. Обычно требуется ещё запуск автоматических тестов на разных окружниях, подсчет покрытия, отчеты.
Ага, это, конечно, простой проект. Который требует проверку на различных окружениях. Вот у нас в проектах одно окружение.
WF>И даже в случае простого проекта Maven справляется довольно плохо. Объем скриптов огромен, много повторения, много несущественных деталей, редактировать скрипты просто неудобно. Много тонкостей, которые надо знать.
У нас он со своими задачи справляется отлично. И я все равно не понимаю, зачем использовать инструмент, если он не подходит, а потом на него ругаться. Возьмите тот же gradle или buildr и делайте на нем что угодно.
Здравствуйте, LeonidV, Вы писали:
WF>>И даже в случае простого проекта Maven справляется довольно плохо. Объем скриптов огромен, много повторения, много несущественных деталей, редактировать скрипты просто неудобно. Много тонкостей, которые надо знать. LV>У нас он со своими задачи справляется отлично. И я все равно не понимаю, зачем использовать инструмент, если он не подходит, а потом на него ругаться. Возьмите тот же gradle или buildr и делайте на нем что угодно.
Потому что это требует времени на изучение и результат всё равно не гарантирован. Плюс интеграция с IDE, и.т.д, и.т.п. Типичный Java-вей, куча выбора и ни одного нормального
Здравствуйте, Cyberax, Вы писали:
C>Поэтому и делается сборка на нейтральной платформе, которой совершенно пофиг какая IDE.
Вот это, кстати, довольно-таки плохо. Было бы гораздо веселее, если бы был некий относительно общий формат проектов для IDE. Пусть каждая IDE будет со своими расширениями, пусть комманд-лайн тул будет со своими. Но чтоб более-менее стандартные вещи описывались бы всё-таки одинаково для всех IDE.
Maven-овский POM, увы, таким форматом по многим причинам не является.
Как пример, самый удобный вариант сборки OSGi-приложения у нас получился с Maven3+Tycho. Но это, по большому счёту, просто внедрение логики Eclipse PDE в сборочный процесс Maven-а. То есть как раз та самая идея -- Tycho учит Maven "понимать" проектные файлы Eclipse.
Здравствуйте, WFrag, Вы писали:
C>>Поэтому и делается сборка на нейтральной платформе, которой совершенно пофиг какая IDE. WF>Вот это, кстати, довольно-таки плохо. Было бы гораздо веселее, если бы был некий относительно общий формат проектов для IDE. Пусть каждая IDE будет со своими расширениями, пусть комманд-лайн тул будет со своими. Но чтоб более-менее стандартные вещи описывались бы всё-таки одинаково для всех IDE.
Maven.
WF>Maven-овский POM, увы, таким форматом по многим причинам не является.
Таки является.
WF>Как пример, самый удобный вариант сборки OSGi-приложения у нас получился с Maven3+Tycho. Но это, по большому счёту, просто внедрение логики Eclipse PDE в сборочный процесс Maven-а. То есть как раз та самая идея -- Tycho учит Maven "понимать" проектные файлы Eclipse.
OSGi не нужен.
Здравствуйте, 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...
Здравствуйте, 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-я быо написано?
В эти 587 строк входит создание web-приложения с GWT, компиляция stanalone'ового SWING-приложения, сборка WebStart'ового архива в проекте, разбитом на 6 модулей. Т.е. примерно 100 строк на модуль в среднем.
Так что сильно большое количество XML в POM-файлах сильно преувеличено.
