Библиотека сайта rus-linux.net
Среда разработки Eclipse
Глава 6 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: Eclipse,
глава из книги "The Architecture of Open Source Applications" том 1.
Автор: Kim Moir
Перевод: Н.Ромоданов
6.3. Eclipse 3.4
Считается само собой разумеющейся возможность легкого обновления приложения до новой версии и добавление нового контента. В Firefox это происходит без проблем. Для Eclipse, это делать было не так просто. Первоначальным механизмом был менеджер обновлений (Update Manager), который использовался для добавления нового контента в инсталляцию Eclipse или обновление ее до новой версии.
Чтобы понять, что изменяется во время обновления или инсталляции, необходимо понять, что в Eclipse имеется в виду под понятием «возможности». Возможность является артефактом PDE, в котором определен набор пакетов, упаковываемых вместе в таком формате, который может быть собран или установлен в виде одного релиза. Возможность может также включать в себя другие возможности. Смотрите рис.6.7.
Рис.6.7: Иерархия возможностей Eclipse 3.3 SDK
Если вы хотели обновить свою инсталляцию Eclipse до нового релиза, в котором добавлен только один новый пакет, то из-за того что менеджер обновлений является достаточно грубым механизмом, потребуется обновить всю возможность целиком. Обновление возможности, в которой исправлен один пакет, является неэффективным.
Есть визарды PDE для создания возможностей и полученные с их помощью релизы помещаются в ваше рабочее пространство. В файле feature.xml указываются сборки, которые входят в состав конкретной возможности, а также указываются некоторые простые свойства сборок. Возможность, например, пакет, имеет имя и версию. В состав возможностей могут входить другие возможности., а также могут указываться диапазоны версий входящих возможностей. Пакеты, входящие в состав возможности, перечисляются с указанием конкретных свойств. Например, можно увидеть, что во фрагменте org.eclipse.launcher.gtk.linux.x86_64 указывается операционная система (os), система окон (ws) и архитектура (arch) той среды, где эту возможность можно использовать. Поэтому при обновлении до новой версии этот фрагмент будет устанавливаться только на указанной платформе. Такие фильтры платформ имеются в манифесте OSGi пакета.
<?xml version="1.0" encoding="UTF-8"?>
<feature
id="org.eclipse.rcp"
label="%featureName"
version="3.7.0.qualifier"
provider-name="%providerName"
plugin="org.eclipse.rcp"
image="eclipse_update_120.jpg">
<description>
%description
</description>
<copyright>
%copyright
</copyright>
<license url="%licenseURL">
%license
</license>
<plugin
id="org.eclipse.equinox.launcher"
download-size="0"
install-size="0"
version="0.0.0"
unpack="false"/>
<plugin
id="org.eclipse.equinox.launcher.gtk.linux.x86_64"
os="linux"
ws="gtk"
arch="x86_64"
download-size="0"
install-size="0"
version="0.0.0"
fragment="true"/>
Приложение Eclipse состоит не только из возможностей и сборок. Из следующего списка файлов, входящих в состав приложения Eclipse, видно, что есть платформозависимые исполняемые файлы, предназначенные для запуска самого Eclipse, файлы лицензий и платформозависимые библиотеки.
com.ibm.icu org.eclipse.core.commands org.eclipse.core.conttenttype org.eclipse.core.databinding org.eclipse.core.databinding.beans org.eclipse.core.expressions org.eclipse.core.jobs org.eclipse.core.runtime org.eclipse.core.runtime.compatibility.auth org.eclipse.equinox.common org.eclipse.equinox.launcher org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.launcher.gtk.linux.s390 org.eclipse.equinox.launcher.gtk.linux.s390x org.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.launcher.gtk.linux.x86_64
Эти файлы невозможно обновить с помощью менеджера обновлений, поскольку опять же, мы имеем дело только с возможностями. Поскольку многие из этих файлов обновлялись в каждом крупном релизе, это означало, что пользователи каждый раз, когда был новый релиз, должны были загружать новый файл zip, а не обновлять существующую инсталляцию. Это не подходило сообществу Eclipse. В PDE предоставлялась файловая поддержка, которая позволяла указывать все файлы, необходимые для создания приложений Eclipse RCP. Однако в менеджере обновлений не было механизма переноса этих файлов в вашу инсталляцию, что в равной мере разочаровывало как пользователей, так и разработчиков. В марте 2008 года в SDK появился компонент p2, представляющий собой новое решение, предназначенное для работы с ресурсами. Что обеспечить обратную совместимости, по-прежнему можно использовать менеджер обновлений, но по умолчанию применяется p2.
6.3.1. Концепции p2
В Equinox p2 все связано с инсталляционными единицами (installation units - IU). IU представляет собой определение имени и идентификатора артефакта, который вы устанавливаете. В этих метаданных также описываются возможности артефакта (что предлагается) и его требования (его зависимости). В метаданных также указывается фильтры применимости (область применения) в случае, если артефакт можно применять только в определенной среде. Например, фрагмент org.eclipse.swt.gtk.linux.x86 можно применять только в случае, если вы устанавливаете его на машине x86 с системой Linux и GTK. По сути, метаданные является формой представления информации, которая есть в манифесте сборки. Артефакты являются просто двоичными модулями, которые устанавливаются. Такое разделение достигается путем отделения метаданных от описываемых с их помощью артефактов. Репозитарий p2 состоит из репозитория метаданных и репозитария артефактов.
Рис.6.8: Концепции системы p2
Профиль представляет собой список фрагментов IU в вашем варианте инсталляции. Например, ваш Eclipse SDK имеет профиль, который описывает вашу текущую инсталляцию. Внутри Eclipse вы можете запросить обновление до более новой версии сборки, для которой будет создан новый профиль с другим набором фрагментов IU. В профиле также указывается список свойств, связанных с инсталляцией, например, операционная система, система управления окнами и параметры архитектуры. В профилях также запоминается каталог инсталляции и место, где он находится. Профили находятся в реестре профилей, в котором могут храниться несколько профилей. Концепция директора (director) отвечает за вызов операций, с помощью которых предоставляются ресурсы. Она работает с концепциями планировщика (planner) и движка (engine). Планировщик рассматривает существующий профиль, и определяет, какие операции нужно выполнить для того, чтобы преобразовать имеющийся вариант инсталляции в новое состояние. Движок отвечает за выполнение фактических операций предоставления ресурсов и за установку новых артефактов на диск. Концепция точек стыковки (touchpoints), являющаяся частью концепции движка, используется в тот момент, когда осуществляется установка. Например, для Eclipse SDK, есть точки стыковки Eclipse, зная которые можно устанавливать сборки. Для системы Linux, в которой Eclipse устанавливается из двоичных файлов RPM, движок должен использовать точки стыковки RPM. Кроме того, p2 может выполнять установку в параллель с другой работой или отдельно в отдельном процессе, таком как сборка приложения.
Новая система провизирования p2 имела много преимуществ. Артефакты, установленные в Eclipse, могли обновляться от выпуска к выпуску. Поскольку предыдущие профили хранились на диске, имелся также способ вернуться к предыдущему варианту инсталляции Eclipse. Кроме того, при наличии профиля и репозитария, вы могли воспроизвести вариант инсталляции Eclipse пользователя, который сообщил об ошибке, и попытаться воспроизвести проблему на своем собственном рабочем столе. Механизм предоставление ресурсов с помощью системы p2 давал больше, нежели просто возможность обновлять и устанавливать Eclipse SDK; это была платформа, которую можно было также применять и в случаях с RCP и OSGi. Команда разработчиков Equinox также работала с разработчиками другого проекта Eclipse, Eclipse Communication Framework (ECF), с тем, чтобы реализовать надежный транспорт, необходимый для артефактов и метаданных в репозитариях p2.
Когда в SDK была выпущена система p2, в сообществе Eclipse было много оживленных дискуссий. Поскольку менеджер обновлений был далеко не самым оптимальным решением в качестве системы провизирования конкретной инсталляции Eclipse, у пользователей Eclipse вошло в привычку распаковывать сборки в собственный вариант инсталляции и перезапускать Eclipse. Такой подход позволял надежным образом разрешать зависимости между сборками. Это также означало, что любые конфликты в вашей инсталляции разрешались во время выполнения, а не время установки. Ограничения следует учитывать во время установки, а не во время выполнения. Тем не менее, пользователи часто не обращали внимания на эти вопросы и поскольку сборки находились на диске, они считали, что сборки работали. Еще ранее варианты обновления, которые предлагал Eclipse, были простым каталогом, в котором находились сборки и возможности, представляющие собой архивы jar. В простом файле site.xml указывались имена возможностей, которые можно было использовать в обновленном варианте. С появлением p2, метаданные, которые были предоставлены в репозитариях p2, стали гораздо сложнее. Чтобы создать метаданные, процесс сборки необходимо было перенастроить так, чтобы либо генерировать метаданные во время сборки, либо запускать задачу генерации уже поверх уже существующих сборок. Первоначально не было доступной документации, в которой описывалось как делать эти изменения. А также, как это всегда бывает при предъявлении новой технологии более широкой аудитории, выявлялись неожиданные ошибки, которые следовало решать. Однако, когда было написано больше документации и были потрачены долгие часы на устранение всех этих ошибок, команда разработчиков Equinox смогла справиться со всеми этими проблемами и теперь система p2 стала базовым движком предоставления ресурсов, на котором основываются многие коммерческие предложения. Кроме того, фонд Eclipse Foundation каждый год предоставляет свой скоординированный релиз, используя для этого единый репозитарий p2 для всех проектов, в разработке которых он принимает участие.
Продолжение статьи: Eclipse 4.0.