Библиотека сайта rus-linux.net
Среда разработки Eclipse
Глава 6 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: Eclipse,
глава из книги "The Architecture of Open Source Applications" том 1.
Автор: Kim Moir
Перевод: Н.Ромоданов
6.4. Eclipse 4.0
Архитектуру нужно постоянно контролировать с тем, чтобы знать, является ли она по-прежнему актуальной. Есть ли возможность добавлять новые технологии? Должна ли она поощрять рост сообщества? Легко ли привлекать новых участников? В конце 2007 года участники проекта Eclipse решили, что ответов на эти вопросы не было и они приступили к разработке нового варианта видения проекта Eclipse. В то же самое время им стало понятно, что есть тысячи приложений Eclipse, которые зависят от существующего API. В конце 2008 года был создан технологический проект уровня инкубатора с целью решить следующие три конкретные задачи: сделать более простой модель программирования в Eclipse, привлечь новых участников проекта и позволить платформе воспользоваться новыми веб-технологиями, обеспечивая при этом открытость архитектуры.
Рис.6.9: Ранний вариант релиза Eclipse 4.0 SDK
Первый пробный вариант релиза Eclipse 4.0 был в июле 2010 года с целью получить обратную связь от пользователей. Он состоял из комбинации сборок SDK, которые были частью релиза 3.6, а также новых сборок, которые были разработаны в рамках технологического проекта. Как и в случае релиза 3.0, был реализован слой совместимости, с тем чтобы существующие сборки могли работать с новым релизом. Как всегда, присутствовала оговорка, что для того, чтобы обеспечить эту совместимость. необходимо использовать общедоступный интерфейс API. Такой гарантии не было, если в вашей сборке использовался внутренний код предыдущих релизов. В релизе 4.0 была предложена платформа приложений Eclipse 4 Application Platform, обладающая следующими возможностями.
6.4.1. Рабочее пространство модели
В версии 4.0 рабочее пространство модели создается при помощи фреймворка Eclipse Modeling Framework (EMFgc). Есть различие между моделью (model) и внешним видом (view), т.к. механизм, осуществляющий визуализацию, опрашивает модель, а затем генерирует код SWT. По умолчанию используются средства визуализации SWT, но допустимы другие решения. Если вы создаете пример приложения 4.x, то для модели рабочего пространства, используемого по умолчанию, будет создан файл XMI. Модель можно изменять и рабочее пространство будет мгновенно обновляться в соответствие с изменениями в модели. На рис.6.10 приведен пример модели, созданной для примера приложения 4.x.
Рис.6.10: Модель, созданная для примера приложения 4.x
6.4.2. Стиль каскадных стилевых страниц
Eclipse был выпущен в 2001 году, еще до эпохи появления многофункциональных интернет-приложений, внешний вид которых можно изменяться с помощью CSS. В Eclipse 4.0 есть возможность использовать стили для более простого изменения внешнего вида приложения Eclipse. По умолчанию таблицы стилей CSS можно найти в каталоге css в сборке org.eclipse.platform.
6.4.3. Внедрение зависимостей
Примерами моделей программирования сервисов являются реестр расширений Eclipse и сервисы OSGi. В соответствие с соглашением, в модели программирования сервисов имеются поставщики и потребители сервисов. За налаживание отношений между поставщиками и потребителями несет ответственность брокер.
Рис.6.11: Взаимосвязь между поставщиками и потребителями
В приложениях Eclipse 3.4.x потребителю для того, чтобы использовать сервисы, обычно необходимо знать расположение реализаций сервисов, а также понимать порядок наследования во фреймворке. Поэтому код, который создает потребитель, становиться менее пригодным для повторного использования, т. к. те, кто им пользуется, не могут переопределить реализацию, которая определена потребителем. Например, если вы хотите обновить сообщение в строке состояния в Eclipse 3.x, то код будет выглядеть следующим образом:
getViewSite().getActionBars().getStatusLineManager().setMessage(msg);
Eclipse, 3,6 построен из компонентов, но многие из этих компонентов также слишком сильно взаимозависимы. Для того, чтобы можно было собирать приложения из менее связанных между собой компонентов, в Eclipse 4.0 для предоставления сервисов клиентам используется внедрение зависимостей (dependency injection). Внедрение зависимостей Eclipse, 4.х осуществляется через специальный фреймворк, в котором используется концепция контекста, служащая в качестве общего механизма поиска сервисов потребителями. Контекст существует между приложением и фреймворком. Контексты являются иерархическими. Если в контекст поступил запрос, который не удается разрешить, то произойдет делегирование запроса в родительский контекст. В контексте Eclipse, который называется IEclipseContext, хранятся имеющиеся сервисы и происходит поиск сервисов OSGi. По сути контекст похож на то, как в языке Java происходит отображение имен или классов в объекты. Контекст осуществляет обработку элементов модели и ее сервисов. Каждый элемент модели будет иметь контекст. Сервисы публикуются в версиях 4.х при помощи механизма сервисов OSGi.
Рис.6.12: Контекст брокера сервисов
Поставщики добавляют в контекст сервисы и объекты, которые там хранятся. Сервисы внедряются в объекты потребителей при помощи контекста. Потребитель объявляет, что ему нужно, и контекст определяет, как удовлетворить этот запрос. Такой подход упростил использование динамических сервисов. В Eclipse 3.x, потребителю нужно было подключать слушателей (listeners) для того, чтобы получать уведомления о том, когда сервисы становятся доступными или недоступными. В Eclipse 4.x как только контекст внедряется в объект потребителя, любые изменения будут автоматически снова поступать в этот объект. Иными словами, снова будет происходить внедрение зависимостей. Потребитель указывает, что он будет использовать контекст, с помощью аннотаций Java 5, которые соответствуют стандарту JSR 330, а именно с помощью @inject, а также с помощью некоторых специально настроенных аннотаций проекта Eclipse. Поддерживается внедрение в конструкторы, методы и поля. Среда выполнения релизов 4.x ищет в объектах такие аннотации. Выполняемое действие зависит от того, какая была найдена аннотация.
Такое разделение контекста и приложения позволяет улучшить возможность повторного использование компонентов, и освобождает потребителя от необходимости разбираться в их реализации. В релизе 4.x код, обновляющий строку состояния, будет выглядеть следующим образом:
@Inject IStatusLineManager statusLine; ⋮ ⋮ ⋮ statusLine.setMessage(msg);
6.4.4. Сервисы приложений
Одной из главных задач в Eclipse 4.0 было создание настолько простого интерфейса API, что с его помощью было легко реализовывать сервисы общего назначения. Был создан список простых сервисов, считающихся «наиболее важными» и известными как сервисы приложений Eclipse Application. Задача состоит в предоставлении автономно работающего интерфейса API, которыми клиенты могут пользоваться без необходимости глубокого понимания всех доступных интерфейсов API. Сервисы приложений были реализованы в виде индивидуально работающих сервисов, так что ими также можно пользоваться в других языках, отличающихся от языка Java, таких как Javascript. Например, есть интерфейс API для доступа к модели приложения, который позволяет читать и изменять настройки приложения (preferences) и выдавать сообщения об ошибках и предупреждения.
Продолжение статьи: Заключение.