Leiningen, Maven и прочая

[metaclass]

А скажите мне, почему в жабе приняты такие хитрожопости с инфраструктурой разработки?

От входа я что-то не соображу, как правильно прикрутить к кложуре jdbc, но если воспользоваться leiningen (по этим статьям: http://alexott.net/en/clojure/ClojureLein.html и http://devcenter.heroku.com/articles/clojure-web-application ), то проект создается, зависимости выкачиваются, итд.

Смущает, что непонятно, что именно при этом происходит, на низком уровне, так сказать, и что эти утилиты для сборки лезут за зависимостями в какие-то центральные репозитории. Мне как-то более привычно "скачал нужную версию, руками положил рядом в проекте и ссылаешся на нее".

Comments

[craneop.livejournal.com]

Заебись, они придумали еще один Maven.

Хитрожопость для того и создана, чтобы разработка разных проектов велась по одной и той же модели жизненного цикла (единая структура директорий в проекте, например или там фазы build), вместо ада Ant-based билдов. Плюс автоматизация разрешения зависимостей. В общем, когда осваиваешь этот инструмент, работать становится гораздо проще. Но порог вхождения определенный имеется, но это ж Java.

Автоматизация разрешения зависимостей - это очень ок, потому что этим решается проблема транзитных зависимостей, которые ручками задолбаешься решать. Управление репозиториями, версиями JAR-ок тоже достаточно логичное.

[metaclass.livejournal.com]

Эта штука, по-моему, использует мавеновские репозитории.

[craneop.livejournal.com]

Ну, логично. Там репозитории громадные и проверенные.

[metaclass.livejournal.com]

Т.е. в них положено верить?:)

[craneop.livejournal.com]

Я конкретики не помню, но процедура попадания библиотеки в public репозиторий достаточно геморная по понятным причинам.

[theiced.livejournal.com]

почему тогда эти паблик репозитории на 99.99% набиты дерьмищем?

[craneop.livejournal.com]

Например? Или ты исходишь из факта опенсорсжаба == говно? :)

[theiced.livejournal.com]

что угодно, любые либы. у всех тонны хымыыльных конфигов и все работают через жопу. плюс отдельная жопа с депами. когда 5 либ по депам вытаскивают ещё 200 - это пиздец.

[craneop.livejournal.com]

Тонны конфигов - это один pom.xml вместе с либой? :)

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

[slonopotamus.livejournal.com]

Ничего геморного

[volodymir-k.livejournal.com]

> почему в жабе приняты такие хитрожопости с инфраструктурой разработки?

???
Некоторые заморочки могут быть только при использовании многочисленных компонентов с определёнными зависимостями и определённых версий, и в контексте полного процесса разработки. Типа, с чекаутом, компиляцией-сборкой, деплойментом на тестовый сервер, запуском тестов и выдачей отчётов, с инкреметированием версии. Вот тогда да, могут быть вопросы. В тривиальных случаях 1 xml, батник и всё.

[theiced.livejournal.com]

хымыыыль. бггг. вы говноед?

[tzirechnoy.livejournal.com]

А почему Вы спрашываете? Партнёров ищете?

[volodymir-k.livejournal.com]

> Мне как-то более привычно "скачал нужную версию, руками положил рядом в проекте и ссылаешся на нее".

А вот это называется "колхоз" и гарантирует невоспроизводимость билд-окружения на другой машине в другое время. С невоспроизводимыми глюками от кривизны сборки.

[metaclass.livejournal.com]

Не, как раз с воспроизводимостью никаких проблем: есть бинарники либ, есть свои исходники под контролем версий, в любой момент все достается из репозитория, исправляется один файл конфигурации (пути к компиляторам-вспомогательным утилитам) и все собирается.

[craneop.livejournal.com]

Опять же такой нюанс. Придет новый разработчик, вы будете ему объяснять что где лежит, как делать билд и так далее. Если разработчик знает Мавен, ему ничего не надо объяснять, он посмотрит в POM и все сам поймет.

[veter-r-r.livejournal.com]

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

[sorhed.livejournal.com]

Потому что в любом джава-проекте средней руки очень много зависимостей, for good or for bad. Ну то есть штук 20 — нормально, а бывает и 50-70. Всё это опенсорсное, разумеется, постоянно обновляется, и содержит кучу транзитивных зависимостей, иногда даже с циклами.

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

(и, кроме того, есть главный вопрос: класть ли зависимости в свн/гит. Если да, то обновлять их ещё более заебёшься, если нет — это нарушает принцип «билд должен выполняться с нуля нажатием одной кнопки», а это очень хороший принцип).

[metaclass.livejournal.com]

Я кладу зависимости под svn/hg, иначе никакой веры ни во что нет.

[metaclass.livejournal.com]

Т.е. в принципе, я могу сделать свой репозиторий мавена и жить независимо от центра?

[craneop.livejournal.com]

У тебя в время билда создается репозиторий локальных зависимостей на твоей машине. Есть тулзы для проксирования репозиториев и управления ими (Nexus, например).

[sorhed.livejournal.com]

Да, именно. Правда, это the whole another can of worms, но это возможно.

[alll]

> Мне как-то более привычно "скачал нужную версию, руками положил рядом в проекте и ссылаешся на нее".

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

[altmind.livejournal.com]

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

плюс так повелось, что в разных ветках SCM лежат pom.xml с одинаковым modelVersion. из-за чего работать в двух воркспейсах одновременно проблематично(капец как проблематично). собраные jar в локальном репозитории не различают из какой они ветки из за чего появляются невоспроизводимые на другой машине проблемы, или наоборот - все работает до того момента, пока кто-нибудь другой не вытянет себе проект.

[altmind.livejournal.com]

сложилось впечатление о maven как об очень недетерминированой, многословной, друдноотлаживаемой системе.
очень согласен с http://tonsky.livejournal.com/227837.html - для разрешения зависимостей(т.е. того, для чего мы фактически используем mvn) столько boilerplate, сколько есть в pom.xml, не нужно.

[zmila.livejournal.com]

я примерно так и делал :)
лейном создал пустой проект. когда нужно какая-то либа, в тот проект записываю зависимость, lein deps, потом из папки lib этого пустого проекта ручками беру либу и кладу её в воркин-фолдер, где все мои рабочие проекты, и дальше про лейн забываю, всё остальное эклипсом делаю

но запланировал почотче освоить этот лейн, он кроме создания болванки и выкачивания зависимостей ещё кучу полезностей делает. ну и комманд-лайн, как некоторым нравится :)