Вспомогательные средства для производства:
- Renderlnterface
- Построение изображения;
- RenderEnglne для печати.
StudioCHent
Рабочая станция в месте продажи. Технологический процесс. Пользовательский интерфейс. Загрузка изображений. Запись DVD.
StudioServer
С этими файлами манифестов нам необходим лишь механизм их разбора и выполнения полезных действий. Для этого я написал программу с неоригинальным названием Launcher.
Launcher
Я видел много настольных приложений Java, которые комплектуются громадными сценариями командного процессора для поиска JRE, настройки переменных окружения, построения пути к классам и т. д. Отвратительно!
Launcher получает имя модуля, разбирает файлы манифестов и строит транзитивное замыкание зависимостей модуля. Launcher следит за тем, чтобы модуль не включался дважды, и разрешает множество частичных упорядочений в полное упорядочение. На рис. 4.3 изображен полный граф зависимостей системы StudioClient. Эта система объявляет зависимости StudioCommon и Common, но Launcher включает только одну копию.
Чтобы избежать «загрязнения» путей к классам в управляющей среде (ANT на сборочной машине, JRE на рабочей станции), Launcher строит собственный загрузчик классов из объединенных путей. Все классы приложения загружаются этим загрузчиком, поэтому Launcher использует его для создания экземпляра инициализатора. Launcher передает конфигурационный путь инициализатору, который создает все объекты контекстов приложений. После конструирования контекстов приложение готово к работе.
В ходе работы над проектом мы несколько раз перерабатывали структуру модулей. Количество изменений в файлах манифестов и Launcher при этом было минимальным. В конечном итоге мы получили шесть сильно различающихся конфигураций развертывания, причем все они поддерживались одной структурой.
Модули имеют сходную структуру, но они не обязаны быть идентичными. Это было одним из побочных преимуществ нашего подхода. Каждый модуль может «спрятать» ту информацию, которая не представляет интереса для других модулей.
Related posts: