[java]maven в чём смысл

Перефразирую: так в чём смысл java, кроме высокоуровневого ООП, да и то польза от него сомнительная?

Мне тоже сначала так казалось, сейчас я ничего другого не использую. У него сила в плагинах. А вся конфигурация в одном месте, в pom.xml, почему в разных? И никаких вызовов javac нет, всё делает плагин. В общем после некоторого освоения ничего другого использовать не хочется.

А центральный репозиторий и dependency management это как LFS с дебианом сравнивать. Это вещь, без которой я не понимаю, как можно жить.

> кроме высокоуровневого ООП

А откуда в java взялось "высокоуровневое" ООП? ОО-модель в жабе вроде наоборот - упрощена до минимума, дабы каждый индус право имал.

Чем проще тем лучше. Правильные вещи должны быть простыми.

>Чем проще тем лучше. Правильные вещи должны быть простыми.

Визиторы призванные дать возможность клиенту кода определять свое полиморфное поведение для иерархии твоих классов 2 my mind очень ужасны. Фича Жавы с YetAnotherStupidCallbackInterface / YetAnotherStupidNotificationBroadcaster тоже ужасна.

От Visitor-а можно отказаться в языках с двойной диспатчеризацией.. Common Lisp-е например. Где ещё?

> Фича Жавы с YetAnotherStupidCallbackInterface / YetAnotherStupidNotificationBroadcaster тоже ужасна.

То, что нет синтаксического сахара для лямбды - плохо (в 7 будет), но на сложность модели ООП не влияет никак вообще.

>У него сила в плагинах.

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

>А вся конфигурация в одном месте, в pom.xml, почему в разных?

я имею в виду что dependency в одном месте pom.xml прописываются, настройки javac вообще в maven-compiler-plugin вынесены а сорцовые директории в <build><sourceDirectory>...</sourceDirectory>...</build>. в результате просто бегло взглянув на pom.xml я не могу со 100% вероятностью сказать с какими параметрами у меня вызывается javac, а если учесть что ещё существуют parent pom.xml файлы то вообще кажется что каша. в анте если ты обращаешься к javac то и все его настройки передаёшь ему в одной таске например <javac srcdir="${src.dir}" destdir="${classes.dir}" classpath="${classpath}" debug="on" source="1.5" target="1.5"/>

>А центральный репозиторий и dependency management это как LFS с дебианом сравнивать. Это вещь, без которой я не понимаю, как можно жить.

а смысл репозитория? можно же в проекте папку lib таскать. и не надо зависеть от того что удалённый репозиторий отвалился и нет гемороя с точным указанием версии либы, и на build скрипт не влияет. а то прописывать тонны <dependency>-кода задалбывает (особенно для не особо крупного проекта)

и ещё объясните кроме стандартных тасков типа clean, install и прочего можно ли сделать (не сильно напрягаясь) аналог антовских target-ов и если да то как? например я хочу чтобы у меня была отдельная таска которая уже собранный файл деплоила в websphere при этом она не зависит от сборки, не проверяет что .ear вообще существует и не вызывается при mvn install (не используя вебсферовский плагин для деплоя т.е. грубо говоря надо обратиться к wsadmin.sh/.bat скрипту с определённым набором параметров).

да и ещё одна вещь про репозиторий. из-за того что там есть далеко не всё есть приходится использовать например такую штуку как maven-install-plugin которая скачала кладёт файл в репозиторий например <file>${env.WAS6_HOME}/bin/ProfileManagement/plugins/com.ibm.websphere.v61.ext_ 6.1.0/runtimes/com.ibm.ws.webservices.thinclient_6.1.0.jar</file><groupId>was6</ groupId><artifactId>was6-thinclient</artifactId><version>6.1</version> а потом через dependency его же и достаёт и как я понимаю нельзя сказать просто тупо юзать вот эту библиотеку сразу же из &{WAS6_HOME}. для меня это как минимум очень странно.

> как раз сила пока сомнительная. зглянул на предыдущие проекты которые мавеном собираются, там во многих местах ant-plugin используется и как понимаю из-за того что многих плагинов не существует.

Никогда не было необходимости в ant plugin-е. Полагаю, что это проекты, перенесённые из ant-а (не до конца).

> я имею в виду что dependency в одном месте pom.xml прописываются, настройки javac вообще в maven-compiler-plugin вынесены

Ну да, в разных секциях файла. А как ещё можно?

> а сорцовые директории в <build><sourceDirectory>...</sourceDirectory>...</build>

А это ерунда какая то. В maven-е есть стандартный очень удобный для работы layout, и я не знаю ни одной причины от него отказываться.

> в результате просто бегло взглянув на pom.xml я не могу со 100% вероятностью сказать с какими параметрами у меня вызывается javac

А зачем?

> в анте если ты обращаешься к javac то и все его настройки передаёшь ему в одной таске например <javac srcdir="${src.dir}" destdir="${classes.dir}" classpath="${classpath}" debug="on" source="1.5" target="1.5"/>

А как в анте сделать запуск юнит-тестов? Генерацию джавадока? Новые таски писать. Иногда это вообще превращается в увлекательное программирование на XML-е. В мавене ничего делать не надо, плагины всё умеют из коробки.

> а смысл репозитория? можно же в проекте папку lib таскать

И в SVN её класть?

> и не надо зависеть от того что удалённый репозиторий отвалился

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

> и нет гемороя с точным указанием версии либы

Какого геморроя?

И как мне быть например с hibernate-ом, который требует 10 библиотек обязательных и 20 опциональных? Читать всякие readme, тратить время на сортировки и прочее или скопировать 50 мегабайтов джарок? А со spring-ом? А с maven-ом проект зависит только от этих двух библиотек а всё остальное автоматически вычисляется, в 99% случаев правильно.

> да и ещё одна вещь про репозиторий. из-за того что там есть далеко не всё есть приходится использовать например такую штуку как maven-install-plugin которая скачала кладёт файл в репозиторий например <file>${env.WAS6_HOME}/bin/ProfileManagement/plugins/com.ibm.websphere.v61.ext_ 6.1.0/runtimes/com.ibm.ws.webservices.thinclient_6.1.0.jar</file><groupId>was6< / groupId><artifactId>was6-thinclient</artifactId><version>6.1</version> а потом через dependency его же и достаёт и как я понимаю нельзя сказать просто тупо юзать вот эту библиотеку сразу же из &{WAS6_HOME}. для меня это как минимум очень странно.

Это типа для сборки проекта надо устанавливать вебсферу? Жуть какая.

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

>А как в анте сделать запуск юнит-тестов? Генерацию джавадока? Новые таски писать.

да именно так. писать таски. зато получаешь точное представление что во время билда происходит. а то тут умный мавен перегенерил мой ear-никовский application.xml в соответствии со своим видением мира и по сути либо подстраиваться, либо отучать его это делать. я к тому что много тасков он делает "про себя" сам считает что по дефолту сорцы находятся в src/java/main (кажется), сам ищет библиотеки, сам генерирует дескрипшены а в итоге по сути это жизнь упрощает не сильно, а гемороя добавляет поначалу прилично. потом возможно к его выходкам и привыкаешь.

>А это ерунда какая то. В maven-е есть стандартный очень удобный для работы layout, и я не знаю ни одной причины от него отказываться.

а я не согласен с его распределением /src/main/java /src/main/resources и т.д. я всю жизнь в корне проекта создавал папки src, resources, web, test и т.д. и не вижу ни одной причины от этого отказываться. почему они решили что они умнее и надо делать по ихнему?

>И в SVN её класть?

а в чём проблема. лишние 20-50 метров? ну дак если это рабочий svn то проблемы с трафиком вообще нет, а если это что то типа sourceforge-вского то всё равно за тебя эти 50 метров мавен из нета вытащит.

такого что я уже выкачал hibernate со всеми библиотеками и знаю что с ними всё работает + воркароунды если что то не работает, а так лежит у меня в папке lib какой нибудь asm.jar и чёрт его знает какой он там версии и какую надо в dependency прописывать.

>И как мне быть например с hibernate-ом, который требует 10 библиотек обязательных и 20 опциональных?

в идее есть такая замечательная кнопочка как fix problem. она за тебя эти 10 библиотек и закачает.

>Это типа для сборки проекта надо устанавливать вебсферу? Жуть какая.

типа да. а где вы ещё предложите брать вебсферовские библиотеки

>> Фича Жавы с YetAnotherStupidCallbackInterface / YetAnotherStupidNotificationBroadcaster тоже ужасна.

>То, что нет синтаксического сахара для лямбды - плохо (в 7 будет), но на сложность модели ООП не влияет никак вообщ

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

> почему они решили что они умнее и надо делать по ихнему?

Ну они не телепаты. Есть дефолтное расположение, его можно при желании поменять. У меня такого желания не возникало, мне их вариант нравится, но менять то можно.

> а в чём проблема. лишние 20-50 метров?

Я считаю, что в svn-е должны лежать только файлы, относящиеся к проекту. Внешние библиотеки правильнее хранить в специальном репозитории. Хотя вопрос спорный, конечно.

> а так лежит у меня в папке lib какой нибудь asm.jar и чёрт его знает какой он там версии и какую надо в dependency прописывать.

Никакую не надо прописывать, у hibernate-а в pom-ке всё уже прописано.

Есть ещё такая чудесная команда mvn dependency:tree, мне сильно помогает с зависимостями разобраться.

> в идее есть такая замечательная кнопочка как fix problem. она за тебя эти 10 библиотек и закачает.

В эклипсе такой кнопочки нет. А что она делает? Кстати, раз идея, в ней же по слухам чудесная интеграция с maven-ом, по идее вообще проблем быть не должно?

> типа да. а где вы ещё предложите брать вебсферовские библиотеки

Ну если это ant, то в каталоге ./lib

>Внешние библиотеки правильнее хранить в специальном репозитории.

тут я в принципе согласен, но с ant-ом так не сделаешь. жалко что нельзя прикрутить мавеновский репозиторий к анту.

>Ну они не телепаты. Есть дефолтное расположение, его можно при желании поменять. У меня такого желания не возникало, мне их вариант нравится, но менять то можно.

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

>В эклипсе такой кнопочки нет. А что она делает? Кстати, раз идея, в ней же по слухам чудесная интеграция с maven-ом, по идее вообще проблем быть не должно?

интеграция не плоха, но ant-овской уступает. а кнопочка просто идёт в инет и из того же мавеновского репозитория качает эти 10 библиотек для работы с hibernate

>Ну если это ant, то в каталоге ./lib

а если maven то положить в репозиторий один раз а потом всю жизнь доставать?

>Никакую не надо прописывать, у hibernate-а в pom-ке всё уже прописано.

http://img291.imageshack.us/img291/2021/mavenjw7.jpg - пример того что нагенерил мавен по зависимостям и того что реально нужно проекту

> а если maven то положить в репозиторий один раз а потом всю жизнь доставать?

Вообще то пакет скачивается 1 раз, потом он лежит в ~/.m2/repository.

> пример того что нагенерил мавен по зависимостям и того что реально нужно проекту

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

>Ну если уверены, что библиотека из зависимостей не нужна - её можно исключить, синтаксис сейчас не вспомню, но можно.

синтаксис то прост - в <dependency> добавить <excludes>, просто это как раз пример того что мне в мавене и не нравится. вместо того что бы просто написать хочу вот эту и эту библиотеку, приходится писать хочу вот эту и эту библиотеку но при этом будь любезен при портировании этой библиотеки не подключай ещё вот эту, эту и эту. в результате появляется много лишних строк кода. да и изначально не понятно кто из hibernate, hibernate-annotations, hibernate-entitymanager,... тащит за собой ненужные библиотеки. хотя mvn dependency:tree тут как раз и должна помочь.