Открыть список
Как стать автором
Обновить

Комментарии 7

Я думаю maven может спать спокойно пока я могу открыть помку в идее и у меня настроенный проект, чего не добиться с помощью того же GradleFX.
Уговорили, на днях сделаю статью о том, как готовить Flex в печи Maven под соусом FlexMojos и при этом не вылить содержимое кастрюли на себя:) Всё-таки предыдущая статья про Ваш опыт с FlexMojos полна неверных решений:) Хотя признаю, документация у FM разбросана по всему интернету и ей никто не занимается на текущий момент.
сделайте, будет интересно. Хорошо бы туда так же pure as3 проекты добавить, как в этой статье.
Ок:) Будет проще если тут напишут пожелания к статье, чтобы охватить как можно больше интересов разных людей.
Лично мне был бы интересен способ реализации на maven следующего функционала, аналогичного ant (т.е. что-то типа переходим с ant на maven), я с maven не работал, и могу написать ниже что-то «не в духе идеологии maven», но насколько я понимаю, maven должен уметь делать все то, что делает ant:
1. версионирование (как в ant через build.number файл с передачей версии в mxmlc через параметры компиляции)
2. полный доступ к параметрам mxmlc, comc, adl, asdoc (свой конфиг, DEFINE параметры компиляции, external, include библиотеки и т.п.)
3. указание какой sdk собирать (например через путь к sdk)
4. утилитные возможности — локальное копирование файлов (с построением списка по маске) для формирования билда с набором статики, scp копирование билда на сервер
5. вообще возможности «скриптования» в maven, если надо например проверить наличие какой-либо переменной (задана или нет) и в соответствии с этим выполнить то или иное действие.
А кто бы спорил, если уже есть. Вопрос, когда еще нет и стоит выбор. В java maven очень хорошо работает. Но для сборки flex/flash его зачастую применить не просто, если проект не новый. Gradle в этом серьезно проще. Первый опыт я тоже делал в IDEA, а второй полностью в AkelPad и его вполне достаточно. Я искал инструмент, который можно было бы использовать просто, желательно из коробки, на мой взгляд, с maven это получилось сложнее, с gradle проще. Проблема flex для maven, слабая поддержка стандарта разработки, даже со стороны Adobe, отсутствие публичных репозиториев, обязательная поддержка локального репозитория (публичных-то нет). Т.е. сделать сложный проект с зависимостями от публичных библиотек, потом выложить его на GitHub, например, и чтобы он у меня собрался с первого раза, как обычно бывает с java проектами, это не просто.

Maven имеет смысл применять в командах, которые придерживаются его идеологии сразу и привыкли к ней. Лучше для гетерогенных проектов. Переводить проект с ant на maven — maven-antrun-plagin самое простое на первый взгляд решение. Только вопрос дальнейшей поддержки уже двух систем сборки. А переводить правильно может оказаться очень-очень сложно, а иногда и невозможно (например наличие fla с внутренней логикой, которая используется в связанном проекте). Использовать maven для flex/flash без использования ant может оказаться невозможным. Сразу встает вопрос о двух системах сборки.
С ant на gradle переводить очень просто, даже практически не надо.

Присоединяюсь к FSB о статье, если у вас уже есть положительный опыт, было бы здорово сравнить. Кстати, какие именно решения не верны (не для придирок, а просвящения чтоб)? У меня там есть вопросы и, честно говоря, я надеялся, что будет обсуждение, на котором ответы на них всплывут. Обсуждения зачастую интереснее читать, чем многие статьи. Из пожеланий к содержанию, можно взять хотя бы мой план изучения, он покрывает часть типовых задач.
Кстати, наверняка есть более признанные способы применения gradle, если на них кто-нибудь укажет, будет здорово. Первый блин вышел не совсем комом, но наверняка, комочки присутствуют.
Это была одна из тайных целей написания обеих статей.
печально, но похоже этот плагин не умеет acompc.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.