Nexus, Server-side.

Nexus

Стремясь достичь высокой модульности и реюзабельности кода, мы дробим проект на кучу мелких модулей, и получаем кучу swc файлов. Естественно, оперировать ими вручную было бы хреново -- попробуйте подключить к проекту 30 swc, лежащих в разных местах. К счастью, делать это совершенно не нужно -- обо всем заботится Maven. Все swc файлы лежат в локальном репозитории ( ~/.m2/repository ) и легко подключаются куда угодно указанием зависимости.

Однако проблема решается только на уровне одного разработчика. В команде все немного сложнее. Тут выходит, что каждый разработчик должен скомпилировать на своей машине все артефакты, которые ему нужны. К примеру, если Вася сделал изменения в какой-то внутренней библиотеке, которая используется в 5 проектах, то другие разработчики, работающие по этим 5 проектам, должны иметь у себя сорцы этой библиотеки, чтобы их обновить и перекомпилировать. А ведь гораздо проще было бы получить измененную swc и использовать ее.

Эту проблему решает Nexus -- сервер артефактов. Это такое же хранилище артефактов, как и ~/.m2/repository, но только оно не локальное, а общее внутри локальной сети компании (ну и при необходимости доступно извне). При наличии у команды Nexus-сервера, Вася делает mvn deploy для своей библиотеки, и swc становится доступным для других разработчиков. Теперь им нет надобности иметь у себя сорцы этой swc и компилировать ее.

Nexus решает еще одну проблему -- кеширует внешние публичные артефакты. К примеру, каждому разработчику в команде нужен как минимум com.adobe.flex.framework:flex-framework и несколько других зависимостей. Без Nexus каждый разработчик отдельно скачает из инета все эти артефакты. С Nexus они скачаются один раз, и будут доступны всем разработчикам из локальной сети.

Это две основные причины, по которым команде разработчиков нужен Nexus. Конечно, там есть и другие фишки. Например, навороченные права доступа и полномочия пользователей. Но это все интересно только крупным компаниям. Небольшим командам достаточно двух вышеупомянутых.

Особых проблем с Nexus нет: читаем доки, скачиваем, запускаем, настраиваем. Если пользуетесь форком Flexmojos от Develar, то добавляем репозиторий http://repository.flyti.org/, иначе репозиторий http://repository.sonatype.org/content/groups/flexgroup/. Впрочем, можно добавить оба :)

Создаете репозиторий mycompany, где будут хранится ваши артефакты. Анонимный доступ к нему наверняка нужно будет закрыть, ибо ваши артефакты, конечно, не публичные.

У всех разработчиков в ~/.m2/settings.xml добавляем профайл:

<profile>
	<id>nexus</id>

	<repositories>
		<repository>
			<id>public</id>
			<url>http://192.168.0.102:8081/nexus/content/groups/public</url>
			<releases> <enabled>true</enabled> </releases>

			<snapshots> <enabled>false</enabled> </snapshots>
		</repository>
		<repository>
			<id>thirdparty</id>

			<url>http://192.168.0.102:8081/nexus/content/repositories/thirdparty</url>
			<releases> <enabled>true</enabled> </releases>
			<snapshots> <enabled>false</enabled> </snapshots>

		</repository>
		<repository>
			<id>flashdevs</id>
			<url>http://192.168.0.102:8081/nexus/content/repositories/mycompany</url>
			<releases> <enabled>true</enabled> </releases>

			<snapshots> <enabled>true</enabled> </snapshots>
		</repository>
	</repositories>
	<pluginRepositories>

		<pluginRepository>
			<id>public</id>
			<url>http://192.168.0.102:8081/nexus/content/groups/public</url>
			<releases> <enabled>true</enabled> </releases>

			<snapshots> <enabled>true</enabled> </snapshots>
		</pluginRepository>
	</pluginRepositories>
</profile>

Делаем этот профайл активным.

Далее создаем аккаунты на Nexus сервере для каждого разработчика, указываем нужные роли. С этим у меня сперва были затруднения. Но там для примера уже создан пользователь Deployment User с нужными ролями. И вам нужно создавать такие же аккаунты, как этот.

Дальше каждый разработчик добавит в ~/.m2/settings.xml свой логин и пароль к Nexus

<servers>
	<server>
		<id>mycompany</id>

		<username>Yura</username>
		<password>123456</password>
	</server>
</servers>

Еще нужно прописать настройки distributionManagement. У нас они одинаковые для всех проектов, так что я прописал их в flex super pom

<distributionManagement>
	<snapshotRepository>
		<id>mycompany</id>
		<url>http://192.168.0.102:8081/nexus/content/repositories/flashdevs</url>

	</snapshotRepository>
</distributionManagement>

Но если они разные в разных проектах, то тогда это нужно указывать в главном pom проекта.

Немного про Server Side

Эта часть для вас, вероятно, будет малоинформативна. Ибо она не про Java :)

Типичный back end для флекс-приложений -- это Java-сервер на базе какого-либо BlazeDS или чего-нибудь иного. Но мы еще не доросли до Java, у нас все проще.

Серверная часть у нас -- это Server Side ActionScript под Flash Media Server и PHP. И то и другое -- интерпретируемые языки, не требующие компиляции и упаковки. Стало быть, тут и Maven применить негде :)

Но все-таки кое-что нужно делать. Итак, исходники серверных частей хранятся в проекте, далеко от FMS application root и web server root. А работать они должны в оных рутах. Значит их нужно туда доставлять. К тому же, их еще нужно немного конфигурировать под специфические условия на машине конкретного разработчика.

Для этой цели у нас давно написаны и успешно используются Ant-скрипты. Однако с Ant-скриптами есть два небольших неудобства. Во-первых, настройки, которые им нужны (путь к FMS appliction root и Web server root) у нас уже заданы для Maven в ~/.m2/settings.xml, а для Ant их нужно продублировать. Во-вторых, эти настройки у каждого разработчика отличаются, поэтому их опять нужно дублировать. В итоге в наших проектах сейчас можно увидеть такое:

project
- ant
  - deploy_www_yura.xml
  - deploy_www_vasya.xml
  - deploy_www_petya.xml
  - deploy_fms_yura.xml
  - deploy_fms_vasya.xml
  - deploy_fms_petya.xml

Хочется избегнуть дублирования и найти иной способ. Лучше всего, чтобы deploy-www и deploy-fms были в одном экземпляре, общие для всех разработчиков, а нужные настройки брались из конфигов Maven.

Чесно говоря, я пока ничего не делал в этом направлении. Ибо некогда, а оно и так работает. Но зато я думал, в каком направлении надо копать. И тут вижу три варианта.

1. У Maven есть стандартный goal resources:resources, с помощью которого он копирует ресурсы у нужное место, при этом парсит в них параметры, если надо. Технически это именно то, что нужно. Но идеологически, выдавать сорцы за ресурсы, это все-таки хак.

2. Maven может исполнять ant-скрипты внутри себя c помощью maven-antrun-plugin. Наверняка при этом можно использовать параметры Maven как параметры Ant (но я не уверен). Этот вариант кажется мне самым правильным. Но не окажется ли он более медленным, чем уже имеющиеся Ant скрипты? Попробую, узнаю.

3. Ну и самое низкоуровневое решение -- exec-maven-plugin. С его помощью можно запустить что угодно, любую командную сроку, в том числе и Ant-скрипты.

В общем, буду пробовать в более спокойные времена, когда не окажется более важных дел :)

На этом мои практические познания в Maven и Flexmojos исчерпаны, и тему можно закрывать (временно). В дальшейшем, по мере освоения каких-то новых сторон, буду их описывать. Вот, к примеру, Flexmojos и AIR -- интересная, но не исследованная сторона :)