nyaload

Журнал Пушыстого

Журнал Пушыстого

Entries by tag: maven

Java: нет сходимости
nyaload
_winnie
Обычно решение проблемы создает некоторые новые проблемы. Мы их начинаем решать. Ряд в конце концов сходится. В случае Java он сходится очень медленно, как геометрическая прогрессия с фактором 0.95. Каждое новое решение порождает новые проблемы, для которых нужен новый инструмент со своими проблемами. Spring, Maven, Hibernate ... веб-сервисы для репозиториев мавена... IDE с рефакторингом, мерж рефакторингов в репозитории, вакансии для новых Java-программистов которые пишут ещё больше Java-кода... Тесты для тестирования кода решающего проблемы... Билд-фермы для паралельного запуска тестов, что бы за пару часов хотя бы тесты проворачивались...

Перманентно висящие демоны из-за долгого старта JVM... Динамическая перезагрузка jar демонов...

Перенос логики в XML-файлы... Такого же объема или больше, как java-код для написания этой логики.

Есть всякие clojure и scala, но из-за вот этой вот культуры обмазывания слоями решения проблем от решения проблем не хочется даже близко подходить к тому, что почему-то работает на платформе JVM.
Tags: ,

maven jar hell
nyaload
_winnie
maven теперь остался в том месте, где он хорошо справляется - разрешать зависимости библиотек, скачивать их из интернета, и исходники к ним качать.
К сожалению, даже тут он справляется на "хорошо", а не на "отлично". На 4 с плюсом, но не на 5.

Во-первых, когда при diamond-dependency-hell нужны библиотеки разных версий - он тупо выбирает самую большую, из-за этого возникают никогда не тестировавшиеся комбинации библиотек. Ну это ладно, похоже для java это неизбежное зло.

Во-вторых, мейтейнеры библиотек часто в библиотеках с разными именами используют одинаковые классы. Например, asm-3.1.jar в зависимостях hibernate и asm-all-3.3.1.jar.

В проекте используется три XML-парсера (org.xml.sax), лежащие в трёх следующих файлах, и выбирается рандомный из них. А они выдают разный порядок атрибутов из xml-тега, мля.
/usr/lib/jvm/java-6-sun-1.6.0.24/jre/lib/rt.jar
vendor/jars/xml-apis-1.3.04.jar
vendor/jars/gnujaxp-1.0.0.jar

Read more...Collapse )

maven hibernate
nyaload
_winnie
Хибернейт создан для того, что бы мавен смог разрулить его зависимости, а мавен сделан для того, что бы разрулить зависимости хибернейта.

Хибернейт насмехается над старой системой настройки либ "укажем для либы список её jar-ников", похлопывая себя по большому теплому пузу.

иллюстрация зависимостей jar-ников общих для xalan/hibernate/commons-configuration/slf4j-log4j. В прямоугольники сгруппированны jar-ники, факторизованные по набору модулей проекта, их использующих.
иллюстрация зависимостей jarCollapse )

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

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

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

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


Например, из программирования графики - "Сделали клевые тени, сделали красивую воду, починили баг «тени не отражаются в воде», FPS упал в четыре раза"

Или вот maven для Java. Обычно в программах сборки всегда есть много разных способов сделать одно и тоже. Одно поэффективней, другое попроще. Когда же я пытаюсь что-то сделать с maven - я обычно сначала обчитываю несколько страниц с гугля, официальную документацию, что-то с блогов и stack overflow, нахожу баг в их баг трекере (со статусом Open или "будет починено в maven3"), плюю и обмазываю maven слоем питон-скриптов. Очень сложно составлять кроссворды с maven. Самое обидное, что эта сложность ничего не даёт, ни эффективности, ни работающей автомагии. Исключение - менеджмент зависимостей внешних библиотек и jar-hell, но это опять же решение проблемы созданной на пустом месте, когда для склеивания строчек и чтения файла надо скачивать библиотеку от гугля или apache foundation, и есть 100 разных версий логирования, загрузки файлов и склеивания строк.

build(?) tool.
nyaload
_winnie
Помимо того что maven при стирании *.java не стирает *.class, он ещё и не пересобирает зависимый *.class если в *.class другого модуля изменилась сигнатура вызываемого метода. Эм, получается что надёжная не-clean-сборка вообще в принципе невозможна.

Enterprise Language Solutions
nyaload
_winnie
Сегодня прочитал строку из файла. Взял библитеку commons-io (благодаря maven она скачалась сама, никакого гемороя!), добавил в обще-проектный файл используемую версию библиотеки (1.4), добавил зависимость от библиотеки в том модуле, где я считываю строку из файла (всего две xml-ки).

Строчки, которые надо добавить в xml можно скопировать из online-репозитория maven в браузере, а не писать самому, всё для удобства программиста.
    <dependency>
      <groupId>commons-io</groupId>
      <artifactId>commons-io</artifactId>
      <version>${commons-io-version}</version>
    </dependency>


Добавил в исходный файл два import,
import org.apache.commons.io.FileUtils;
import java.io.File;
. Более того, второй import мне редактор сам написал, а первый я скопировал тоже из интернета. Всё само пишется, никакого ручного труда.

Ну и дальше уже можно одной строкой прочитать файл:
String info = FileUtils.readFileToString(new File("cfg/info.txt"))

maven magen
nyaload
_winnie
Сегодня количество магии в maven зашкалило.

Не знаю как это получилось, в мой локальный репозиторий майвен положил задефейсенный HTML. После чего задеплоил его в местный общий репозиторий.

Библиотеки вроде как берутся из местного repo, а не из интернета, вирусов AVZ и касперский у меня на компе не нашли. Может бага в плагине и дейфейс сайта поддержки плагина. Может я или кто-то из коллег подцепил нечто, что сейчас притихло. Этот "hacked by" ищется в инете на 15000 страничках, но неясно как и зачем оно "задефейсило" бинарные jar-файлы.

скриншот задефейсенного jarCollapse )

Детей без родителей надо убивать.
nyaload
_winnie
Какие системы сборки умеют корректно удалять результирующие файлы, для которых уже нет источников? Без clean && rebuild-all, а оставляя билд инкрементальным.

maven явно пишет в документации, что не умеет корректно определять что jar надо перепаковать, и поэтому пакует всегда. Наверное, потому что на Java так сложно сравнить равны ли два списка, и потому что сборку java->class перепоручает javac который не умеет удалять .class для которых нет исходников. Зачем тогда называться сборщиком, если перепоручаешь сборку другому посредственному сборщику, у которого прямая обязанность - компиляция, а не инкрементальная сборка.

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

Если "make" != "make clean; make", то от такого make у меня батхёрт.

maven-archiver: Checking for timestamps will offer a performance gain on the cost that you get inaccurate results from time to time. In particular, removal of source files won't be detected.

(no subject)
nyaload
_winnie
Ага. По умолчанию в jar-файлы запихиваются timestamp скомпилированных java-файлов. Из-за этого-то бинарные дифы и отличаются. Пидарасы.
И файлик кладётся pom.properties в jar, "#Generated by Maven Fri Nov 12 21:02:43 MSK 2010". Пидарасы. Гуглить по "addMavenDescriptor false" (я выкинул целиком дескрипторы, из-за даты).
Tags: ,

Run Maven, Use Maven, Write Maven, Improve Maven, Develop Maven
nyaload
_winnie
maven делает всё, но очень хреново.

Резолв версий библиотек: в теории хорошо, но на практике сторонние либы ставят слишком точные версии зависимостей и содержат копии классов чужих библиотек внутри, в результате в проекте оказывается несколько разных версий библиотек. Вообщем, полуавтоматический резолв версий - это единственное за что его можно терпеть, лучше так, чем совсем руками. Ну и клёво что они скачиваются из одного места, не надо прыгать по sourceforge и apache.org. Но это минор.

Компиляция: Работает тупо медленно, я уже писал об этом, не пытается за один os.stat/листинг директории выяснить про файл всё, спрашивает атрибуты по кусочкам, лезет в папки где исходников быть не может (.svn). IDEA пересборку проводит в 50 раз быстрей при типичных изменениях.
Не умеет многопоточную сборку. Спрашивается, зачем связывать пользователя по рукам и ногам, и не использовать это для оптимизации.

"Линковка"-сборка в jar: По мистическим причинам пересобирает jar когда это не надо. jar получаются бинарно разные, одну причину точно вижу - всовывает туда имя пользователя и компьютера, и самого себя, типа "собрано мавеном". Блин, да работай ты как простой зип, приходится деплоить 100 мегабайт jar, хотя исходники не поменялись.

Вывод логов - максимально grep-unfrendly, невозможно регулировать уровни INFO/WARNING.

Лезет в сеть (слава богу, в местный репо) за библиотеками. Можно настроить на офлайн, но блин, чую библиотеки вне контроля версий чувствую ещё станут поводом для ада.
Tags: ,

?

Log in