Флэш Потрошитель этот | тот | 1.0

Пишет develar, спасибо ему, и храни господь его велосипеды:

Так сложилось, что среди флешеров есть миф что мавен это что-то сложное и трудно поддерживаемое. Данный пост не евангелиста, который будет убеждать вас в обратном и насколько мавен в действительности улучшает вашу жизнь и облегчает процесс разработки — нет, данный пост это вопрос, сбор мнения тех, кто уже понял что это и зачем конкретно ему. Если вы не пользуетесь мавеном или поняли, что вам он не нужен — не тратьте время на чтение, далее будут только два вопроса к непосредственно пользователям связки инструментов maven+flexmojos+idea.

Читать дальше: Стоит ли улучшать интеграцию flexmojos с IntelliJ IDEA?

Я контрибьютор проекта flexmojos и не вижу каких-то реальных проблем, могущих оправдать текущее отношение к flexmojos. Да, есть ряд тонких моментов, обусловленных тем, что мы (авторы flexmojos) зажаты меж двух сторон — с одной стороны компилятор Adobe (имеющий плохую архитектуру, а также отсутствие какой-либо работы по переосмысливанию (с соответствующим рефакторингом) той кучи возможностей, что была запихнута в него за долгое время жизни flex), а с другой ядро мавена 2.x (не очень рассчитаное на то, что плагин будет не просто добавлять некоторые возможности для java, а поддержку нового языка (со своими scopes и прочим)). В частности, именно поэтому flexmojos до сих пор не поддерживает транзитивность для flex. Большинство, думаю, также знают о моем форке (к сожалению, Марвин откатил данный патч, что и послужило причиной форка), который решает проблему транзитивности (в качестве платы привнося еще ряд тонких нюансов).

Как пример такого нюанса, могущего сразу испортить впечатление от flexmojos, является глупое необоснованное и непродуманное решение политики подключения тем в flex 4 — в официальной ветке flexmojos данный вопрос все еще не решен (как я могу судить по http://juick.com/develar/757553) (в моем форке (и sdk опубликованном моим дескриптором) проблема решена, но это показатель, насколько Adobe плевала на грамотную архитектуру компилятора даже в flex 4)).

Таким образом, я могу утверждать, что на данный момент нет никаких обоснованных технических причин могущих вызвать у вас проблемы при работе с flexmojos (на 100% с моим форком, но и с официальным тоже (с той лишь поправкой, что для официального вам придется зачастую публиковать sdk своим дескриптором)). И проблема лишь в том, что на данный момент нет единого документа, который описывал бы все тонкости — сейчас они разбросаны по блогам разработчиков и в jira. Прав ли я? Действительно ли у вас проблемы с мавеном только из-за непонимания его принципов работы (а изучить их вы не можете, ибо цельного документа нет) или же есть иные технические причины (философские (вытекающие из того факта, что мавен это ООП программа, декларативная, а не процедурная как ант) меня не интересуют — их я исправить как программист не могу)?

Выше был первый вопрос. Далее будет второй вопрос, задать который меня заставила Jetbrains. Как вы, наверняка, знаете, Jetbrains это автор такой IDE как IntelliJ IDEA. Ветераны помнят, что было во времена flexmojos 2.x-3.0 — ничего. Что есть сейчас благодаря их заинтересованности в поддержке flexmojos? А сейчас есть то, что процесс настройки рабочего места (от голой машины до запущенной флешки в браузере) в моей компании состоит из 4 пунктов.

Обрисую процесс создания проекта (то есть набор файлов исходного кода + конфигурация по сборке и развертыванию) посредством обсуждаемых инструментов (maven + flexmojos + idea):
1) создаете POMs (по окончанию на любой машине со 99% вероятностью и предсказуемым результатом проект собирается и развертывается). При этом настройка сборки flex в разы быстрее и легче, чем средствами от Adobe (потому что описываете вы все не процедурно, а декларативно, для примера можете почитать о некоторых плюшках flexmojos).
2) создаете проект в IntelliJ IDEA просто указав ей на корневой POM проекта (получаете проект в IDE с работающими инспекциями, анализом и прочим — то есть за один клик получаете полноценный проект в среде, ничем не отличающийся от вручную созданного).

С первым пунктом все ясно и по нему единственная сложность это как же все таки написать POM (собственно, этому был посвящен первый вопрос).
А вот второй пункт и был причиной написания этой статьи (первый так, для довеска).
Пользователь мавена спросит — кто будет компилировать проект? IDE или мавен? Вопрос не праздный, ибо все мы знаем насколько быстр компилятор. Единственное спасение — инкрементальная компиляция. IntelliJ IDEA использует fcsh (там есть еще один способ, но в рамках этой статьи его можно считать равным и не описывать), который использует стандартный flex-config. Значит, кто-то их должен создать.

И вот тут наши позиции с Jetbrains разнятся. flexmojos поддерживает создание configuration report (-DconfigurationReport=true, это не работало нормально до моего сотрудничества с Jetbrains, но ветераны могут быть спокойны — сейчас с этим все нормально). Тонкий нюанс тут в том, как будут адресоваться зависимости (то есть library path) — при mvn compile -DconfigurationReport=true адресация будет в проекте (то есть все внутренние библиотеки проекта будут адресоваться в рамках проекта, а не в локальный репозиторий), а при mvn install на локальный репозиторий (отмечу, что это не баг, равно как не "фича", это нормально и следует из самой природы мавена). Другими словами, между 1 и 2 пунктом вы должны собрать проект сначала как mvn install (ибо сложный проект никогда не соберется только лишь как compile в первый раз — idea и flexmojos тут не причем, это проблемы ядра мавена) и потом как mvn compile -DconfigurationReport=true.

Также сейчас IDEA в качестве источника знаний о проекте использует и POM, и flex-config. То есть я лукавил немного во втором пункте — без flex-config инспекции будут работать лишь частично (к примеру, манифесты компонентов и директивы условной компиляции будут подхвачены только из flex-config). Во что это выливается — у вас есть проект из 50 модулей, вы правите некий POM на предмет добавления нового компонента в манифест и нажимаете re-import — MXML у вас будет невалиден до тех пор, пока вы не сгенерируете flex-config.

Что хотели и хотят в Jetbrains — скрыть от пользователя и избавить его от знания двух абзацев выше. То есть чтобы пользователь мог просто после второго пункта (и после reimport) просто работать. Были реализованы два заклинания (а Марвин их принял, они есть в официальной ветке) для генерации flex-config без сборки — то есть IDEA прямо на этапе reimport проекта может получить flex-config без полноценного запуска компилятора (то есть почти мгновенно). Как бы смешно ни звучало — но даже как автор этих заклинаний я не в курсе работают ли они сейчас корректно и довольно ли этим пользователи — потому что этим не пользуюсь и считаю ненужным.

POM не меняется столь часто, чтобы вам надоело запускать mvn compile -DconfigurationReport=true.

Рассмотрим пример. Команда из 5 человек. Я, как ответственный за сборку проекта, меняю POM и коммичусь. Коллеги, 4 человека, обновляют из VCS проекта и... да, IntelliJ IDEA предлагает сделать re-import проекта. Могут ли коллеги быть уверены, что тех действий, которые произведет IDEA, будет достаточно, чтобы актуализировать вашу рабочую копию проекта (rsl, wars и прочее — то есть не только ее проектные файлы, но и все остальное что нужно не только IDE)? Должны ли коллеги в проекте из 50 модулей перед reimport пойти в настройки и выставить 50 галочек Use IDE Builder; молиться, чтобы fcsh смог все собрать и за время меньшее, чем то же сделает flexmojos; опять поставить галочки только напротив тех 3 модулей с которыми они работают? Ответ очевиден — они просто svn up && mvn compile -DconfigurationReport=true.

Рассмотрим другой пример, на примере одного разработчика без коммита. Предположим, что я вношу три изменения в POM (меняю директивы условной компиляции, тасую зависимости), между которыми также правлю код. Если я нажму re-import, но flex-config не создам, то в процессе правки кода у меня будет работать навигация по коду и классы находиться в правильных модулях, но вот директивы условной компиляции работать не будут (то есть IDEA будет отображать их как ошибку). Удобно ли вам понимать почему так и почему re-import не приводит к полной актуализации? Ответ неочевиден. C одной стороны, будут экономиться микросекунды на генерацию flex-config, с другой стороны, как я могу судить по своим коллегам, это вводит в шок тех, кто не понимает почему так. С другой стороны, POM опять же правится ответственным товарищем понимающим это, в процессе такой правки POM его больше интересует чтобы reimport отрабатывал за наносекунды и всего лишь работала навигация по проекту (чтобы удостовериться, что тасовка зависимостей прошла правильно), по-любому (если изменение POM повлекло за собой инвалидацию кучи модулей, их проще собрать надежно не IDE Builder, а мавеном + проблема отсутствия профилей для галочек) придется делать полный билд mvn compile -DconfigurationReport=true.

А если так — то зачем тогда нужна эта генерация на лету? В этом и есть второй вопрос. Скажите, нужно ли оно вам? Я понимаю, что в простом проекте это может быть удобно, но, опять же, выполнить mvn compile -DconfigurationReport=true совсем не трудно (тем более, что сейчас из-за отсутствия профилей для этих галочек Use IDE Builder, все равно зачастую приходится запускать flexmojos билд проекта).

В зависимости от ваших ответов я либо пойду на встречу с Jetbrains для решения означенных проблем, либо не пойду — так как меня (и моих коллег) сейчас все устраивает.

Пишет rost: комменты не по теме вырезаются в silent mode.