Comments 7
Я думаю maven может спать спокойно пока я могу открыть помку в идее и у меня настроенный проект, чего не добиться с помощью того же GradleFX.
Уговорили, на днях сделаю статью о том, как готовить Flex в печи Maven под соусом FlexMojos и при этом не вылить содержимое кастрюли на себя:) Всё-таки предыдущая статья про Ваш опыт с FlexMojos полна неверных решений:) Хотя признаю, документация у FM разбросана по всему интернету и ей никто не занимается на текущий момент.
Уговорили, на днях сделаю статью о том, как готовить 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, если надо например проверить наличие какой-либо переменной (задана или нет) и в соответствии с этим выполнить то или иное действие.
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 о статье, если у вас уже есть положительный опыт, было бы здорово сравнить. Кстати, какие именно решения не верны (не для придирок, а просвящения чтоб)? У меня там есть вопросы и, честно говоря, я надеялся, что будет обсуждение, на котором ответы на них всплывут. Обсуждения зачастую интереснее читать, чем многие статьи. Из пожеланий к содержанию, можно взять хотя бы мой план изучения, он покрывает часть типовых задач.
Maven имеет смысл применять в командах, которые придерживаются его идеологии сразу и привыкли к ней. Лучше для гетерогенных проектов. Переводить проект с ant на maven — maven-antrun-plagin самое простое на первый взгляд решение. Только вопрос дальнейшей поддержки уже двух систем сборки. А переводить правильно может оказаться очень-очень сложно, а иногда и невозможно (например наличие fla с внутренней логикой, которая используется в связанном проекте). Использовать maven для flex/flash без использования ant может оказаться невозможным. Сразу встает вопрос о двух системах сборки.
С ant на gradle переводить очень просто, даже практически не надо.
Присоединяюсь к FSB о статье, если у вас уже есть положительный опыт, было бы здорово сравнить. Кстати, какие именно решения не верны (не для придирок, а просвящения чтоб)? У меня там есть вопросы и, честно говоря, я надеялся, что будет обсуждение, на котором ответы на них всплывут. Обсуждения зачастую интереснее читать, чем многие статьи. Из пожеланий к содержанию, можно взять хотя бы мой план изучения, он покрывает часть типовых задач.
печально, но похоже этот плагин не умеет acompc.
Sign up to leave a comment.
Сборка flex/as3 проекта с использованием gradle