Управление файлами Utility JAR в среде IBM Rational Application Developer-ClearCase

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Деррел Р. Шраг, руководитель Центрального региона - Управление архитектурой и SOA, IBM

27.03.2009

IBM® Rational® Application Developer и IBM® Rational® ClearCase® позволяют использовать возможности Eclipse™ в процессе разработки сложных приложений J2EE. С помощью этих инструментов можно использовать файлы Utility JAR для повышения производительности разработки программного обеспечения в условиях коллективной работы.

Введение

Платформа интегрированных сред разработки (IDE) Eclipse (а, следовательно, IBM® Rational® Application Developer) значительно расширяет возможности создания инструментов, повышающих производительность разработки программного обеспечения в вашем коллективе. Однако среда Eclipse создавалась как однопользовательская (на странице проекта Jazz можно познакомиться со средой разработки, рассчитанной на коллективную работу). Персональная рабочая область содержит все ресурсы, которые необходимы для проектирования, разработки, сборки и тестирования приложений. Если работа должна быть коллективной, то Rational Application Developer (RAD) делегирует все обязанности по ее обеспечению на уровень коллективной работы среды Eclipse.

Поделитесь мнением... Опубликуйте его на digg.com Разместите на del.icio.us и на Slashdot!

Обычно для организации коллективной работы в Rational Application Developer необходимо сосредоточить в рабочей области все необходимые для разработки ресурсы, а затем выполнить команду Team > Share Project. Эта команда позволяет задействовать уровень коллективной работы среды. Например, в вашей системе установлена среда ClearCase с подключенным адаптером ClearCase SCM Adapter. Ее функции помогут вам передать необходимые ресурсы из вашей рабочей области в репозиторий ClearCase. Если вы внимательно изучите ресурсы, представленные в рабочей области, то, вероятно, найдете множество файлов Java™-архивов (JAR).). Эти файлы Utility JAR в настоящее время очень широко используются. Однако Rational Application Developer предоставляет множество способов использования файлов Utility JAR.

В начало

Файлы Utility JAR

Большинство Java-приложений используют большое количество файлов Utility JAR, многие из которых имеют открытый исходный код и содержат решения широко распространенных проблем. Вероятно, чаще всего используется файл log4j (http://logging.apache.org/log4j/), представляющий собой средство для ведения журналов. Можно найти сотни, если не больше, решений с открытым исходным кодом, которые представляют собой реализованные отдельными разработчиками решения распространенных проблем. Эти реализации решений обычно распространяются в форме JAR-файлов.

Кроме того, большинство организаций сейчас предлагают своим разработчикам инкапсулированные инфраструктуры и пользовательские реализации этих решений с открытым исходным кодом, стремясь упростить или унифицировать принцип их использования в своей организации. В итоге большинство приложений Java™ 2 Platform, Enterprise Edition (J2EE) используют множество подобных файлов Utility JAR, иногда lj 20-30 и больше.

Существует несколько способов добавить файлы Utility JAR в проекты, а затем включить их в путь сборки Java. В этой статье мы рассмотрим три способа, а затем обсудим их плюсы и минусы.

Способ 1

Первый способ использовать файлы Utility JAR - это просто включить их в Web-проекты. Файлы Utility JAR можно включить в Web-проекты в каталоге Web-INF\lib. Чтобы добавить все JAR-файлы из этого каталога в путь сборки, воспользуйтесь встроенной библиотекой путей сборки Web App Libraries и добавьте эти JAR-файлы в путь сборки своего Web-проекта. На рисунке 1 показан JAR-файл log4j в каталоге Web-проекта Web-INF\lib (слева) и его отображение в библиотеке Web App Libraries в панели обозревателя пакетов Package Explorer.

Вы можете легко проверить, насколько удобен этот способ. На первый взгляд все делается довольно просто. Однако если использовать такой способ для множества JAR-файлов и приложений, нельзя исключить возможность возникновения проблем. Например, один EAR-файл (Enterprise Archive) может содержать несколько Web-проектов. Если использовать описанный выше метод, каждый Web-проект будет содержать свой набор файлов Utility JAR. Это приведет к излишнему "разбуханию" EAR-файла. Кроме того, вы рискуете иметь разные версии файлов Utility JAR в разных Web-проектах, даже не подозревая об этом. Это может стать причиной небольших, но трудно отслеживаемых различий в поведении приложений.

Способ 2

Существует еще один способ использования файлов Utility JAR, который представляет собой усовершенствованный вариант первого способа и позволяет включить файлы Utility JAR в EAR-проект. Можно импортировать JAR-файлы в EAR-проект как файлы J2EE Utility JAR. Такие JAR-файлы после этого станут доступными для любого проекта, включенного в EAR-файл, как показано на рисунке 2.

Чтобы добавить файл Utility JAR в EAR-проект, нажмите правой кнопкой мыши на дескрипторе развертывания и выберите из контекстного меню команды Import > J2EE Utility Jar. В мастере импорта вы сможете выбрать подходящие параметры импорта. Третья опция в окне мастера позволяет скопировать внешний JAR-файл в EAR-проект как файл Utility JAR (см. рисунок 3).

Затем можно добавить файл EAR Utility JAR в путь сборки Web-проекта, отредактировав файл Web-проекта ...\META-INF\MANIFEST.MF при помощи редактора зависимостей Jar Dependency. В этом редакторе вы увидите список содержащихся в EAR-файле JAR-файлов или модулей, которые можно включить в проект в виде зависимостей, как показано на рисунке 4.

После этого JAR-файлы будут добавлены в иерархию элемента Web App Libraries, как показано на рисунке 5.

Этот способ решает проблему наличия нескольких копий одного и того же файла Utility JAR в одном приложении. Добавлять файлы EAR Utility JAR в путь сборки проекта через изменение файла MANIFEST.MF в редакторе Jar Dependency editor можно и для Web-проектов, и для EJB-проектов. Более того, процесс сборки в Rational Application Developer включает файлы Utility JAR в результирующий EAR-файл, готовый к развертыванию. Тем не менее, здесь стоит рассказать еще об одной проблеме.

Если вы так и будете включать эти файлы Utility JAR во все приложения, вы раз разом будете сохранять их копии в репозитории системы управления версиями. В крупных организациях в системе управления версиями могут скопиться сотни версий одного и того же файла Utility JAR. В этом случае дисковое пространство используется крайне неэффективно. Существует также концепция управления архитектурой, которую данный способ также не учитывает. Если ваша организация стремится внедрить в практику стандартные комплекты файлов Utility JAR, которые представляют собой утвержденные версии или реализации, рекомендованные для использования во всех приложениях, то вы не должны допустить, чтобы в проектах накапливались такие JAR-файлы, в противном случае вы потеряете контроль над использованием стандартизованных JAR-файлов и не сможете управлять их использованием. Эта проблема решается при помощи третьего способа.

Способ 3

Третий способ использовать файлы Utility JAR в EAR-проекте - это импортировать их как связанные ресурсы. Это также можно сделать через мастер импорта. Для данного способа следует выбрать четвертую опцию: Create Linked Utility Jars in an existing EAR from an external location (Создать связанный файл Utility JAR в существующем EAR-проекте из внешнего источника), как показано на рисунке 6.

После того как вы нажмете кнопку Next, мастер предложит указать внешний источник, в котором находятся JAR-файлы. Кроме того, у вас будет возможность определить переменную пути Linked Path Variable, как показано на рисунке 7. Эта переменная впоследствии будет использоваться в качестве пути к внешнему JAR-файлу вместо реального физического пути.

Панель обозревателя проекта Project Explorer будет выглядеть почти так же, как раньше, только на пиктограмме файла log4j.jar появится маленький значок, показывающий, что этот ресурс связан с физическим файлом за пределами рабочей области.

Если используется этот способ, то каждый разработчик сможет указать свое определение физического пути для этой переменной. Благодаря этому вы сможете предотвратить ситуацию, при которой каждый разработчик должен создавать на своем рабочем месте один и тот же физический путь для доступа к внешнему файлу. Связанные ресурсы на самом деле хранятся в файле EAR-проекта. Если вы откроете файл с расширением .project, то увидите, что переменная Link Path Variable используется вместо реального физического пути к файлу, как показано на рисунке 9

<locationURI>UTILITY_JARS/log4j-1.2.15.jar</locationURI>

Определение переменной Link Path Variable указывается в свойствах рабочей области. Все члены коллектива разработчиков обязательно должны определить эту переменную, причем она должна указывать на каталог, который содержит необходимые файлы Utility JAR, как показано на рисунке 10:

С точки зрения рабочей области конечный результат ничем не отличается от исходного, и все происходит так, как если бы файлы Utility JAR действительно были физически включены в проект. Таким образом, этот способ дает преимущества, о которых упоминалось ранее (например, всего одна копия файла Utility JAR в приложении). Однако, помимо этого, он решает проблему хранения в разных местах репозитория системы управления версиями нескольких копий одного и того же JAR-файла. Поскольку файлы Utility JAR физически не хранятся в EAR-проекте, они не добавляются в систему управления исходными кодами при совместной работе над проектом.

Возникает вопрос: где должны храниться файлы Utility JAR, чтобы на них мог ссылаться каждый разработчик? Проще всего разместить их на каком-нибудь общем сетевом диске. Еще лучше использовать инструмент ClearCase UCM, который, кроме всего прочего, обеспечит архитектурное управление файлами Utility JAR.

В начало

Управление файлами Utility JAR

Инструмент ClearCase UCM предоставляет простой, но эффективный способ управления использованием файлов Utility JAR. Если в организации есть специальная группа, которая отвечает за руководство использованием решений с открытым исходным кодом, а также предоставляет организационные инфраструктуры, которые обязательно должно использовать каждое приложение, то существует практически идеальный способ объединить описанный выше метод связанных ресурсов с использованием компонента ClearCase в режиме "только чтение". Вот как это можно сделать.

Управление версиями

Эта специальная группа должна создать и обслуживать UCM-компонент, предназначенный для размещения версий утвержденных файлов Utility JAR, которые должны использоваться коллективом разработчиков. Каждый набор JAR-файлов должен быть привязан к конкретному релизу (базе, baseline), чтобы можно было различать разные версии файлов Utility JAR. Когда рабочая группа создает UCM-проект для своей работы, она должна включить этот компонент в UCM-проект с параметром "только для чтения". С точки зрения разработчиков группы, путь к этому компоненту становится физическим определением переменной Linked Path, используемой для привязки файлов Utility JAR, как показано на рисунке 11.

Вот как могло бы выглядеть такое представление в файловой системе, привязанной, например, к диску Z:

                
Z:\MyVOB\ProjectComponent\MyProject
                         \MyProjectEJB
                         \MyProjectWeb
        \UtilityJarComponent\UtilityJars\log4j.jar 
                                        \struts.jar
      

Следовательно, переменную Link Path UTILITY_JAR можно определить как Z:\MyVOB\UtilityJarComponent\UtilityJars\. Если у другого разработчика представление привязано к диску X: , то у него будет другое определение этой переменной. Этот способ позволяет специальной группе, отвечающей за файлы Utility JAR, управлять этим компонентом. Компонент можно включить в каждый проект, но обязательно в режиме "только для чтения". Благодаря этому для файлов Utility JAR реализуется модель "поставщик-потребитель", в которой проекты играют роль потребителей.

Как и раньше, вы можете исследовать все преимущества, предоставляемые этим решением. Вы получаете преимущество существования лишь одной копии любого файла Utility JAR в одном приложении. Еще одно преимущество заключается в том, что файлы Utility JAR физически не хранятся в проектах, благодаря чему вы экономите место в репозитории. Вы также получаете некоторый уровень управления файлами Utility JAR, потому что содержанием компонентов Utility JAR управляет специальная группа. Впоследствии каждый проект потребляет этот компонент при помощи переменной Linked Path.

Однако здесь следует рассмотреть еще один сценарий. Представьте себе, что у вас есть большое количество файлов Utility JAR, и вам нужно создать представление-моментальный снимок репозитория, который находится в другом полушарии Земли. Если файлы Utility JAR являются просто компонентами в проекте UCM, то все они будут извлекаться из репозитория в корневой каталог представления при каждом создании нового представления. На это может потребоваться много времени, которое зависит от скорости сетевого подключения к репозиторию.

Создание отдельного представления для доступа к файлам JAR

Если вы используете UCM-проекты для создания различных конфигураций для разных версий, то скоро обнаружите, что постоянно создаете новые представления. Кроме того, если по какой-либо причине вам нужно будет быстро создать новое представление для срочного исправления продукта, то большая часть времени будет потрачена не на само исправление, а как раз на создание представления.

Следовательно, имеет смысл создать совершенно отдельное представление специально для доступа к компонентам Utility JAR. Для этого можно создать один UCM-проект, включающий компонент Utility JAR в режиме "только для чтения". После этого каждый разработчик должен создать представление, ассоциированное с этим UCM-проектом, как показано на рисунке 12.

Это представление будет использоваться для извлечения единственной копии файлов Utiltiy JAR и операций с этими файлами. Поскольку компонент используется в режиме "только для чтения", можно спокойно синхронизировать представление с любым рекомендованным релизом, более ранним или более поздним. Это позволяет вам полностью контролировать, какой релиз файла Utility JAR используется, и предоставляет дополнительное преимущество, заключающееся в том, что для любого количества проектов, над которыми ведется работа, необходима только одна копия файла Utility JAR.

Затем можно настроить переменную Linked Path Variable, чтобы она указывала на компонент файлов Utility JAR в представлении Utility JAR, как показано на рисунке 13. Все представления, содержащие исходные файлы проекта, могут создаваться гораздо быстрее, потому что они не содержат файлов Utility JAR.

В начало

Заключение

Среда Eclipse (а, следовательно, и Rational Application Developer) способствовала появлению весьма полезного набора инструментов для создания сложных приложений J2EE. Однако вследствие "однопользовательского" характера этой среды и невозможности неавтоматизированного вмешательства вы скоро столкнетесь с проблемами управления файлами Utility JAR. Тем не менее, потратив немного времени на предварительное обдумывание проблемы, вы сможете использовать возможности Rational Application Developer и ClearCase для создания простого метода, позволяющего проектным коллективам обращаться к утвержденным наборам файлов Utility JAR. Кроме того, можно руководить их использованием путем управления в UCM-компоненте ClearCase.

Ресурсы

• Оригинал статьи: Managing Utility JARs in an IBM Rational Application Developer-ClearCase Environment (EN);
  
  
• В разделе Rational Application Developer Web-сайта developerWorks вы найдете ресурсы, которые помогут глубже изучить данный инструмент;(EN)
  
  
• Просмотрите каталог обучающих интернет-ресурсов, в котором представлены курсы по Eclipse, Rational Application Developer и ClearCase;(EN)
  
  
• Ищите в интернет-магазине технической книги издания по этой и другим техническим темам. (EN)
  
  

• Дополнительные ресурсы для инженеров и менеджеров по сборкам и релизам можно найти в области Build Forge раздела Rational на developerWorks - статьи, технические обзоры, ссылки на обучающие курсы, дискуссионные форумы, документацию по продукту и страницу поддержки пользователей;(EN)
  
  
• Дополнительные ресурсы для пользователей и администраторов ClearCase приведены в подразделе ClearCase раздела Rational Web-сайта developerWorks - статьи и официальные документы, подключаемые модули, скрипты и триггеры, а также ссылки на обучающие курсы, дискуссионные форумы, документацию по продуктам и страницу поддержки пользователей;(EN)
  
  
• Пользователи и администраторы ClearQuest могут найти дополнительные ресурсы в разделе ClearQuest Web-сайта developerWorks, раздел Rational: процедуры перехвата ClearQuest (hook), подключаемые модули Eclipse, документацию по продуктам, статьи и официальные документы;(EN)
  
  
• Загрузите ознакомительные версии программ IBM и используйте инструменты разработки приложений и связующее ПО из программ DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.(EN)

• Примите участие в обсуждении материала на форуме.
  
  
• Размещайте свои вопросы и комментарии по ClearCase, делитесь мыслями, идеями и решениями с другими пользователями на форуме по Rational ClearCase Web-сайта developerWorks;(EN)
  
  
• Участвуйте в блогах developerWorks и присоединяйтесь к сообществу developerWorks;(EN)
  
  
• Участвуйте в блогах developerWorks и присоединяйтесь к сообществу developerWorks. (EN)
  
  

Об авторе

		Деррел Шраг (Darrell Schrag) работает в службе IBM Software Services for Rational (ISSR); консультанты которой оказывают клиентам помощь в совершенствовании методов разработки программного обеспечения. Деррел с успехом помогает клиентам в развертывании инструментов и процессов Rational во всех дисциплинах жизненного цикла разработки программного обеспечения. Кроме того, он оказывает помощь в руководстве работами по разработке сервис-ориентированной архитектуры и внедрении акселераторов разработки на основе шаблонов. Деррел также специализируется в создании решений IBM Rational Unified Service для отрасли связи.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

Поделиться этой статьей: забобрить сохранить в memori

В начало