Здравствуйте, 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'а. Может из-за небольшого срока использования я не заметил какой-то существенный недостаток?

Здравствуйте, 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, ни в Грабле. Как будто, они не работают над реальными проектами.

Здравствуйте, 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, ни в Грабле. Как будто, они не работают над реальными проектами.

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

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

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

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

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

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

Здравствуйте, 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') вполне работает. Сам не проверял.

Здравствуйте, 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 (в таком порядке)

Здравствуйте, 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]