Введение
Eclipse представляет собой интегрированную среду разработки. Эта среда (вместе с IBM Rational Application Developer) значительно расширило возможности по созданию средств повышения продуктивности повседневной разработки ПО. Однако само ПО Eclipse создано с расчетом на однопользовательскую работу (о среде разработки, созданной с прицелом на коллективную работу см. страницу проекта Jazz). Персональная рабочая среда содержит все необходимые ресурсы для проектирования, разработки, создания и тестирования приложения. Если требуется коллективная работа, то ПО Rational Application Developer (RAD) перекладывает всю ответственность за это на коллективный уровень Eclipse.
Стандартной отправной точкой коллективной разработки в Rational Application Developer является объединение в рабочем пространстве всех необходимых для разработки ресурсов. Затем выполняется действие Team > Share Project. Это позволяет задействовать уровень коллективной работы. Допустим, например, что у вас установлено ПО ClearCase и включено средство ClearCase SCM Adapter. Тогда будет задействована его функциональность, которая проведет вас через процесс получения необходимых ресурсов из рабочей среды, вставленной в репозиторий ClearCase. Если вы поподробнее рассмотрите ресурсы своей рабочей среды, то, скорее всего, обнаружите множество файлов Java-архивов (JAR). Эти файлы Utility JAR сейчас очень часто используются. Однако Rational Application Developer предоставляет вам множество способов использовать файлы Utility JAR.
Большинство Java-приложений сегодня использует широкий набор файлов Utility JAR. Многие из них представляют собой открытые решения для часто встречающихся проблем. Наверное, одним из самых часто используемых файлов является использование log4j (http://logging.apache.org/log4j/) в качестве решения для журналирования. Есть также сотни, если не больше, доступных решений с открытым исходным кодом. В них кто-то уже создал реализованное решение для часто встречающихся прикладных нужд. Эти реализации решений обычно предоставляются в виде файлов JAR.
Кроме того, большинство организаций сегодня предоставляет специальные реализации этих открытых решений и среды на их основе. Это делается в попытке упростить или стандартизировать подход организаций к их использованию. Итогом этих попыток стало то, что большинство приложений для платформы Java2 Platform Enterprise Edition (J2EE) должны использовать многие подобные файлы Utility JAR. Иногда количество этих файлов достигает порядка 20, 30 или более.
Есть много способов включить файлы Utility JAR в проекты, а затем включить их в путь для сборки Java-приложения. Далее мы рассмотрим три метода, а затем обсудим их достоинства и недостатки.
Первый способ воспользоваться файлами Utility JAR - это просто включить их в свои веб-проекты. Можно включить файлы Utility JAR в веб-проект в каталоге Web-INF\lib. Чтобы включить все JAR-файлы в этом каталоге в путь для сборки приложения, используйте подключаемую библиотеку пути сборки, "Web App Libraries". С ее помощью можно добавить эти файлы JAR в путь сборки веб-проекта. На рис. 1 показан JAR-файл log4j в каталоге веб-проекта Web-INF\lib (слева), и как он отображается в библиотеке Web App Libraries при просмотре проекта через Package Explorer.
Рисунок 1. Включение JAR-файла в веб-проект
Можно быстро проверить, насколько это может быть практично. На первый взгляд это довольно просто сделать. Однако если это распространить на множество файлов Utility JAR и множество приложений, то возможны ситуации, когда этот подход вызовет проблемы. В один файл EAR (Enterprise Archive) может быть добавлено несколько веб-проектов. При использовании этого метода каждый веб-проект будет содержать свой собственный набор файлов Utility JAR. Это сделает файл EAR излишне большим. Также существует риск непреднамеренного включения разных версий файлов Utility JAR в разные веб-проекты. Это может вызвать незначительные отличия в поведении, которые трудно отследить.
Есть второй метод использования файлов Utility JAR, который лучше первого. Он позволяет включать файлы Utility JAR в проект EAR. Файлы JAR можно импортировать в проект EAR как файлы J2EE Utility JAR. Эти файлы JAR затем становятся доступными любому проекту, который включен в EAR, как показано на рис. 2.
Рисунок 2. Включение файлов JAR в файлы EAR
Чтобы добавить Utility JAR в проект EAR, щелкните правой кнопкой мыши на дескрипторе развертывания и выберите из меню Import > J2EE Utility Jar. Появится мастер импорта, который предоставляет различные варианты. Третья опция позволяет скопировать внешний файл JAR в проект EAR в качестве Utility JAR, как показано на рис. 3.
Чтобы затем добавить файл EAR Utility JAR в путь для сборки веб-проекта, мы отредактируем файл ...\META-INF\MANIFEST.MF с помощью редактора зависимостей Jar Dependency. В нем предоставляется список файлов JAR или модулей, содержащихся в EAR, которые можно включить в виде зависимостей, как показано на рис. 4.
Рисунок 4. Выбор области и зависимостей Classpath
Затем вы увидите эти файлы JAR в разделе "Web App Libraries" пути сборки, как показано на рис. 5.
Рисунок 5. Импортированные файлы JAR
Это решает проблему наличия нескольких копий одного файла Utility JAR в приложении. И веб-проекты, и проекты EJB могут пользоваться преимуществами редактора MANIFEST.MF Jar Dependency, чтобы включить файлы EAR Utility JAR в путь сборки проекта. Более того, процесс сборки в Rational Application Developer включает файлы Utility JAR в итоговый файл EAR для развертывания. Однако есть еще одна проблема, которую стоит рассмотреть.
Если постоянно включать эти файлы Utility JAR в каждое приложение, то нужно снова и снова сохранять их в репозиториях средств для управления версиями. В системе управления версиями в крупной организации могут существовать сотни копий одного файла Utility JAR. Это выброшенное пространство хранилища. Есть еще концепция архитектурного управления, которую этот метод также не учитывает. Если ваша организация пытается предоставлять стандартные пакеты Utility JAR, которые представляют собой принятые версии или реализации, которые должны использовать все приложения, то вам не следует разрешать простое копирование разработчиками этих файлов JAR в свои проекты. В противном случае вы потеряете возможность контролировать и управлять использованием стандартизованных файлов Utility JAR. Эту проблему можно решить с помощью третьего метода.
Третий способ, которым можно использовать файлы Utility JAR в проекте EAR - это импортировать их в качестве присоединенных ресурсов. Это можно также выполнить с помощью мастера импорта. Для использования данного метода выберите четвертую опцию: Create Linked Utility Jars in an existing EAR from an external location ("Создать присоединенные файлы Utility Jar в существующем файле EAR из внешнего источника"), как показано на рис. 6.
Рисунок 6. Выбор другого типа импорта в мастере
При нажатии кнопки Next (Далее) будет задан вопрос о внешнем местоположении, где можно найти файлы JAR. Также будет предоставлена возможность определить переменную пути присоединения (Linked Path Variable), как показано на рис. 7. Эта переменная затем будет использована в качестве пути к внешним файлам JAR вместо реального физического пути.
Рисунок 7. Указание внешнего местоположения
В итоге информация в Project Explorer выглядит так же, но маленькая пиктограмма на файле .jar-файле log4j показывает, что ресурс связан с физическим файлом вне рабочей области.
Рисунок 8. Пиктограмма в Project Explorer
С помощью этого метода каждый разработчик может присвоить этой переменной свое собственное значение физического пути. Это дает каждому разработчику возможность не устанавливать точно такой же физический путь на своем настольном компьютере для доступа к внешнему местоположению файлов. Связанные ресурсы на самом деле хранятся в .project-файле EAR. Если открыть файл .project, то можно увидеть, что вместо реального физического пути используется переменная Link Path Variable, как показано на рис. 9.
<locationURI>UTILITY_JARS/log4j-1.2.15.jar</locationURI>
Рисунок 9. Переменная Link Path кодефайла .project
Определение этой переменной Link Path Variable хранится в настройках рабочей среды. Всем разработчикам необходимо будет убедиться в том, что эта переменная определена, и что она указывает на то место, где находятся необходимые файлы Utility JAR (см. рис. 10).
Рисунок 10. Указание местоположения связанных ресурсов (Linked Resources)
С точки зрения рабочей среды конечный результат выглядит так же. Все выглядит так, как если бы файл Utility JAR действительно физически находился в проекте EAR. Таким образом, метод обеспечивает все ранее упомянутые преимущества (например, одна копия файла Utility JAR в приложении). Однако он также исправляет и проблему нескольких копий одного файла JAR, которые хранятся в нескольких местах по всему репозиторию системы управления версиями. Поскольку файлы Utility JAR не хранятся физически в проекте EAR, они не добавляются в систему управления исходными кодами при совместной работе над проектом.
Тогда встает вопрос: где хранить файлы Utility JAR, чтобы каждый мог на них сослаться? Самый простой вариант - поместить их на какой-то сетевой диск с совместным доступом. Даже лучшим решением может стать использование преимуществ средства ClearCase UCM, которое также обеспечивает некоторое архитектурное управление использованием файлов Utility JAR.
Управление файлами Utility JAR
ClearCase UCM предоставляет простой, но эффективный способ управления использованием файлов Utility JAR. Если в организации есть центральный коллектив, который отвечает за руководство использованием решений с открытым исходным кодом, а также обеспечивает организационную структуру, которую должно использовать каждое приложение, то это идеальный способ объединить описанный ранее метод присоединенных ресурсов с использованием компонента ClearCase UCM, доступного только для чтения. Вот как это можно сделать.
Центральная группа должна создать и поддерживать компонент UCM, который используется для развертывания версий принятых к использованию файлов Utility JAR. Эти файлы должны использоваться коллективами разработчиков приложений. Каждый пакет файлов JAR должен быть создан в соответствии с определенной контрольной точкой, чтобы различные версии файлов Utility JAR отличались. По мере создания каждой группой проектов UCM для работы они должны включать этот компонент в свои проекты UCM как компонент, доступный только для чтения. Путь к этому компоненту затем становится физическим определением переменной Linked Path Variable. Оно используется для ссылки на присоединенные файлы Utility JAR, как показано на рис. 11.
Рисунок 11. Компонент UCM для управления версиями
Вот как могли бы выглядеть пути на файловой системе, привязанной, например, к диску Z.
Пример вида файловой системы исходного кода
|
Z:\MyVOB\ProjectComponent\MyProject \MyProjectEJB \MyProjectWeb \UtilityJarComponent\UtilityJars\log4j.jar \struts.jar
|
Таким образом, переменная UTILITY_JAR Link Path будет иметь значение Z:\MyVOB\UtilityJarComponent\UtilityJars\. Если другой разработчик привяжет свое представление файловой системы к диску X:, то у него будет свое собственное определение переменной. Этот метод позволяет центральной группе Utility JAR управлять этим компонентом. Каждый проект может включать в себя этот компонент, но только в режиме "только для чтения". Это реализует для Utility JAR модель "поставщик-потребитель", в которой проекты являются потребителем.
Повторим еще раз, что вы можете проверить все преимущества, которые вам дает это решение. Вы получаете то преимущество, что в приложении будет только одна копия файла Utility JAR. Вы также получаете то преимущество, что файлы Utility JAR физически не будут храниться в проекте EAR, что экономит место в репозитории. Вы также получаете некоторый уровень управления файлами Utility JAR, центральная группа управляет содержимым компонента Utility JAR. Каждый проект затем использует этот компонент с помощью переменной Linked Path.
Однако есть еще один сценарий, который нужно рассмотреть. Что, если у вас есть большое количество файлов Utility JAR, и вам нужно создать моментальный "снимок" репозитория, который находится на другой стороне земного шара? Если файлы Utility JAR - это просто компоненты в проекте UCM, то каждый раз при создании моментальной копии все они будут извлекаться из репозитория для создания нового представления. Это может требовать длительного времени, которое зависит от скорости сетевого соединения с репозиторием.
Создание отдельного представления для доступа к файлам JAR
Если вы используете проекты UCM для создания отдельных конфигураций для разных версий, то вам придется регулярно создавать новые представления. Кроме того, если вам нужно по какой-то причине быстро создать новое представление для срочного исправления продукта, то значительное время придется потратить именно на создание представления, а не на само исправление.
Поэтому имеет смысл создать отдельное общее представление, которое будет использоваться просто для доступа к компоненту Utility JAR. Можно создать отдельный проект UCM, который будет включать в себя компонент Utility JAR в режиме "только для чтения". Каждый разработчик тогда смог бы создать представление, связанное с этим проектом UCM, как показано на рис. 12.
Рисунок 12. Отдельное представление
Это представление можно использовать для извлечения одной копии файлов Utility JAR и работы с ними. Поскольку компонент доступен только для чтения, то это представление можно привязать к любой контрольной точке, предыдущей или последующей. Это предоставит полное управление тем, какая контрольная точка у файла Utility JAR. Дополнительным преимуществом является необходимость лишь одной копии файлов Utility JAR для любого количества проектов, над которыми вы можете работать.
Вам следует установить такое значение переменной Linked Path Variable, чтобы она указывала на компонент файлов Utility JAR в представлении Utility JAR, как показано на рис. 13. Все представления, которые содержат исходный код вашего проекта, можно создать гораздо быстрее, поскольку они не будут содержать файлы Utility JAR.
Рисунок 13. Установка переменной Linked Path Variable
ПО Eclipse (а, следовательно, и Rational Application Developer) помогло представить исключительно важный набор средств, которые помогают создавать сложные приложения J2EE. Однако из-за его однопользовательского "менталитета" при управлении файлами Utility JAR вы быстро столкнетесь с проблемами. Но если заранее немного обдумать проблему, то можно использовать возможности, которые предоставляет ПО Rational Application Developer и ClearCase, и реализовать простой способ для доступа проектных групп к одобренным наборам файлов Utility JAR. Также их использованием можно управлять с помощью компонента ClearCase UCM.