Eclipse — среда (фреймворк) для разработки десктоп-программ с графическим интерфейсом (и без).
Среда расширяется при помощи плагинов. Наиболее известные, так называемые IDE-плагины:
|
Eclipse-фреймворк применяется не только как базис интерактивных программ, и не только с языками C/C++/Java, это универсальный фреймворк.
Eclipse-фреймворк лицензируется для использования по одной из свободных лицензий, первоначально Common Public License, ныне - Eclipse Public License.
Эти лицензии IBM признаны свободными и одобрены FSF, хотя и не защищают от разворовывания public domain, как GPL.
Это компромиссные лицензии, которые позволяют ортодоксальному бизнесу скрывать знания в закрытых Эклипс-плагинах, защищать свои know-how (ноу-хау, секрет производства) и получать конкурентные преимущества над другими людьми.
Eclipse построен в виде набора расширяемых подсистем, а не как единое монолитное приложение. В Eclipse входят три подпроекта, разрабатываемых более или менее независимо друг от друга - Platform, JDT (Java development tools) и PDE (Plug-in development environment). Platform предоставляет базовые сервисы, JDT позволяет разрабатывать приложения Java, а PDE - новые компоненты Eclipse. Далее в статье анализируются основные свойства и внутреннее устройство каждого из подпроектов.
Platform - это ядро Eclipse. Сама по себе эта подсистема не содержит особенно полезной для пользователей функциональности, но без нее невозможна работа остальных подпроектов Eclipse. Сервисы, которые обеспечивает Platform, позволяют разработчикам определять видимые пользователю артефакты, создавать пользовательские интерфейсы, работать с системами контроля версий, средами отладки и справочной системой. Соответствующими компонентами Platform, реализующими эти сервисы, являются Workspace (управление контентом), Workbench (базовый пользовательский интерфейс Eclipse), Team, Debug и Help.
При старте Eclipse запросит workspace — рабочее пространство, имя каталога, в котором будет сохранён результат работы. Можно:
|
Одновременно только один экземпляр Eclipse работает над одним workspace. Если надо запустить ещё один экземпляр, необходимо указать другой workspace.
Рассмотрим сервисы, реализованные в компоненте Workspace. С концептуальной точки зрения этот компонент определяет основные объекты, с которыми могут работать пользователи и приложения Eclipse, структурирует эти объекты и предоставляет возможность управления ими. В техническом плане основная задача, которую решает этот компонент -унифицированный доступ к локальным и удаленным объектам.
Базовые понятия, определяемые Workspace - это рабочая область (workspace), проект (project), папка (folder) и файл (file). В терминологии Eclipse все эти объекты называются ресурсами (resources).
Рабочая область всегда существует в единственном экземпляре. Вы можете переключаться между несколькими рабочими областями, но только одна из них может быть открыта в конкретный момент времени.
Рабочая область - это прежде всего контейнер для проектов. Кроме этого, в ней содержатся настройки, сохраняемые компонентами Eclipse, и вспомогательные данные. Физически рабочая область представляет собой директорию, поддиректории которой соответствуют проектам, а директория .metadata используется как хранилище настроек и данных.
Каждый из проектов, содержащихся в рабочей области, объединяет набор ресурсов (файлов и папок), правил для их обработки и других свойств проекта (таких, как настройки компилятора). Примерами проектов являются приложения Java, библиотеки jar или новые компоненты Eclipse. Для разработки каждого из этих артефактов необходимо создать отдельный проект.
Проекты могут зависеть друг от друга - это значит, что проект A может ссылаться на проект B и использовать ресурсы из него.
Папки и файлы полностью аналогичны папкам и файлам обычных файловых систем. Почему же разработчики Eclipse начали придумывать дополнительные сущности, вместо того, чтобы использовать привычные, известные каждому программисту, объекты? Дело в том, что работа с ресурсами Workspace позволяет программисту использовать множество новых возможностей в дополнение к традиционным свойствам файлов и директорий.
Для ресурсов, представляющих файлы, сохраняется история последних изменений их содержимого. Пользователь, таким образом, имеет возможность просматривать сделанные им изменения, сравнивать между собой различные версии файлов и в любой момент вернуться к одной из них.
Ресурсы могут быть локальными или находиться в репозитории системы контроля версий. В обоих случаях доступ к содержимому ресурсов и управление ими осуществляется через стандартный интерфейс, общий для локальных и удаленных объектов.
Большинство правильно спроектированных приложений Eclipse никогда не обращается к файлам напрямую, используя для этого стандартные средства Java или какие-либо иные способы. Вместо этого доступ к файловой системе осуществляется при помощи интерфейсов Workspace. Впрочем, использование стандартных средств Workspace не является обязательным - если это по какой-либо причине неприемлемо (например, ваше приложение не использует стандартный механизм объединения ресурсов в виде проектов), вполне допустимо использовать альтернативные механизмы.
Перед разработчиками приложений Eclipse часто встает задача отображения сообщений, привязанных к определенному фрагменту в ресурсе. Примерами являются сообщения компилятора Java или закладки (bookmarks), определяемые пользователем для быстрой навигации между файлами. Platform содержит маркеры (markers) - универсальный механизм для работы с такими объектами. Именно маркеры используются для создания, сохранения и отображения сообщений компилятора и пользовательских закладок.
Маркер - это объект, привязанный к заданной позиции в определенном ресурсе, и обладающий несколькими предопределенными и произвольным числом определяемых разработчиком атрибутов. Стандартные атрибуты, такие, как текст сообщения маркера и его позиция в файле, определяют то, как маркер будет отображен платформой Eclipse (а именно, компонентом Workbench). Дополнительные атрибуты могут отражать новую функциональность вашего приложения. Например, атрибуты сообщения об ошибке могут содержать информацию для ее автоматического исправления.
Любой маркер может быть объявлен как сохраняемый (persistent) - такие маркеры автоматически сохраняются платформой и после ее перезапуска будут восстановлены в изначальном виде. Обратной стороной использования сохраняемых маркеров является то, что легко получить множество устаревших маркеров, которые могут запутывать пользователя; при этом у пользователя нет стандартного способа удаления маркеров. Поэтому приложения, использующие сохраняемые маркеры, должны очень аккуратно управлять процессом их создания и удаления.
Очень удобным свойством маркеров является возможность их взаимодействия с текстовыми редакторами. При редактировании файла позиции всех маркеров, определенных в этом файле, корректируются соответствующим образом. Маркеры будут перемещаться вместе с ассоциированными фрагментами текста, поэтому, например, маркеры, созданные средством поиска текстовых строк в файлах, будут корректно указывать на найденные вхождения образца даже после произвольного числа сделанных пользователем изменений.
Каким образом Eclipse будет интерпретировать тот или иной проект, целиком зависит от его свойств. Наиболее важными из поддерживаемых Platform свойств являются типы проектов (project natures) и билдеры (builders).
Билдеры, в самом общем понимании, - это компоненты, обрабатывающие ресурсы, входящие в проект, такие как компилятор Java, преобразующий исходные тексты в бинарные .class файлы. После первоначальной обработки проекта, билдеры должны реагировать на изменения, происходящие в его ресурсах. Очень важным здесь является понятие инкрементальной обработки - для улучшения производительности билдеры должны по возможности обрабатывать только те ресурсы, которые были изменены с момента последнего запуска билдера.
Билдеры, зарегистрированные для проекта, запускаются каждый раз, когда измененный ресурс из этого проекта сохраняется на диске. Логика инкрементальной обработки определяется исключительно разработчиком билдера, поэтому все, что делает Eclipse Platform - вызывает зарегистрированные билдеры при обновлении ресурсов и передает им информацию о произошедших изменениях (какие именно ресурсы были добавлены, удалены или изменены).
Тип проекта (nature) определяет множество билдеров, которые могут работать с ресурсами, входящими в проект. К примеру, с проектом, представляющим собой Java-приложение, должен работать компилятор Java. С одним проектом может работать несколько билдеров - как правило, каждый билдер предназначен для определенного типа файлов. Разработчики приложений Eclipse могут также определять специфические действия для конфигурирования проектов определенного типа.
Компонент Workbench определяет базовый пользовательский интерфейс (UI) Eclipse, а также предоставляет другим компонентам средства для создания своих собственных интерфейсов. Основные объекты интерфейса, с которыми работает Workbench - это редакторы (editors), виды (views) и перспективы (perspectives).
Рисунок 2 Workbench.
Редакторы в Eclipse вполне соответствуют интуитивному представлению о том, как должен работать редактор. Пользователь может создать экземпляр редактора для существующего файла, внести необходимые изменения, сохранить их и закрыть редактор. Изменения, сделанные в процессе редактирования, остаются в буфере и не записываются в открытый файл до тех пор, пока пользователь не выберет команду сохранения. В редакторе, созданном для одного файла, невозможно открыть какой-либо другой файл.
Назначение редакторов заключается в предоставлении возможности просмотра и редактирования файлов. Визуальное представление содержимого файла зависит от его типа и может меняться от традиционного текстового редактора с подсветкой синтаксиса для сценариев Ant до графического редактора для изображений в формате gif.
Виды, в отличие от редакторов, не обязательно связаны с каким-либо конкретным ресурсом. Они могут быть использованы для отображения содержимого активного в данный момент редактора (наподобие вида Outline), элемента, выбранного в другом виде (история версий ресурса в CVS), а также данных, полученных любым другим путем (таких, как отчет о выполнении тестов JUnit).
В отличие от редакторов, изменения, сделанные пользователем при помощи вида, должны немедленно сохраняются или переносится в соответствующие ресурсы. Например, в виде Navigator отсутствует команда Save или подобная ей - такие действия пользователя, как копирование или переименование, немедленно производятся с соответствующими ресурсами.
Данное соглашение не является, строго говоря, обязательным. У пользователя имеется техническая возможность создавать виды, требующие явного сохранения пользовательских изменений. Однако такие решения противоречат принятым соглашениям о пользовательском интерфейсе приложений Eclipse, и их следует по возможности избегать.
В Eclipse входит множество элементов пользовательского интерфейса - редакторов, видов, меню. Если бы кто-то попытался расположить их все на экране, то в результате получилось бы беспорядочное нагромождение окон, в котором было бы практически невозможно ориентироваться. Создатели Eclipse решили эту проблему при помощи понятия перспективы (perspective).
Очевидно, что пользователь Eclipse не может одновременно использовать все возможности среды. Когда вы отлаживаете программу, вам не нужны средства для работы с системой контроля версий. Как правило, во время написания кода нет необходимости видеть список установленных точек останова и т.п. Таким образом, в каждый момент времени пользователь выступает в некоторой роли, которая подразумевает ограниченный набор действий.
Перспективой, в терминологии Eclipse, называется конфигурация платформы, соответствующая определенной роли. Функциональность, необходимая выступающему в этой роли пользователю, определяет набор и расположение окон, меню, горячих клавиш, и прочих элементов интерфейса для этой перспективы. Например, в перспективе для отладки присутствуют виды с текущим стеком, значениями локальных переменных и списком точек останова, а в перспективе для синхронизации содержимого проекта по CVS - виды со списками доступных серверов и историей изменений в выбранного файле.
Platform позволяет разработчикам приложений создавать новые перспективы, определять их конфигурацию по умолчанию (которая впоследствии может быть изменена пользователем), а также подключать свои элементы интерфейса к существующим перспективам. Разумеется, поддерживается и добавление новых редакторов и видов.
Фундаментом, на котором построены все графические средства Eclipse, является входящий в Workbench компонент SWT (Standard widget toolkit). SWT является основным средством создания пользовательского интерфейса для приложений на основе Eclipse. Поскольку для прорисовки элементов интерфейса SWT максимально использует средства оконного менеджера операционной системы (Win32, GTK, Motif), приложения, построенные на базе SWT, визуально не отличаются от "родных" приложений, разработанных специально для конкретной операционной системы. При этом они сохраняют совместимость со всеми платформами, поддерживаемыми Eclipse.
Использование под каждой ОС стандартных элементов управления позволяет существенно улучшить производительность и избежать запаздывания реакции на события в сложных, многооконных интерфейсах.
SWT (в виде набора библиотек) может быть использован в качестве замены Swing и AWT, отдельно от Eclipse и компонента Workbench.
До последнего времени основным недостатком SWT было отсутствие визуального редактора для создания графических интерфейсов на его основе. Безусловно, разработку кода графического приложения с нуля трудно назвать увлекательной или интеллектуальной задачей. Заполнить этот пробел призван недавно стартовавший проект Eclipse Visual Editor.
На основе SWT построен компонент JFace, который решает более высокоуровневые задачи построения пользовательского интерфейса. JFace содержит классы для создания диалогов, страниц свойств, управления шрифтами, поддержки архитектуры модель/вид и т.п. Наверное, для читателей не будет неожиданным тот факт, что сам Eclipse создан исключительно с использованием SWT и JFace.
JavaScript Development Tools, JSDT - второй из основных подпроектов, составляющих Eclipse SDK. Это и есть упомянутая "IDE для Java", содержащая инкрементальный компилятор Java, редакторы, средства для отладки, тестирования, навигации и рефакторинга исходного кода.
Важно понимать, что JDT построен исключительно на основе подпроекта Platform и не использует каких-либо закрытых или недокументированных интерфейсов. Это значит, что при наличии желания и ресурсов можно разработать компонент, функционально аналогичный JDT, для любого другого языка - от С++ до Python, и тем самым превратить Eclipse в, например, "IDE для Python".
Вы можете полностью исключить JDT из конфигурации Eclipse и установить только свои компоненты, так что пользователям вашего продукта ничто не будет напоминать о Java. Единственный компонент из стандартной конфигурации, который является обязательным для функционирования приложений - это Platform.
Рисунок 3 Перспектива Java.
Одним из самых смелых решений, принятых разработчиками Eclipse, была автоматическая инкрементальная компиляция проекта после каждого изменения, сделанного разработчиком. Каждый раз, когда, работая в Eclipse, вы сохраняете измененный исходный файл на диске, инкрементальный билдер анализирует сделанные изменения и запускает компиляцию не только сохраненного файла, но и всех зависящих от него компонентов. Этот процесс может показаться неоправданно долгим, однако производительность современных компьютеров делает его практически незаметным для пользователя. Кроме того, интеллектуальный анализ изменений сводит к минимуму число необязательных перекомпиляций. К примеру, если вы сделали изменения в теле метода или отредактировали комментарий, то интерфейс класса остался прежним и перекомпиляция его клиентов не нужна - такие ситуации корректно обрабатываются инкрементальным Java билдером.
Что дает такой подход, помимо, разумеется, возможности оперативного просмотра и исправления ошибок компиляции? При первой компиляции проекта в памяти строится дерево зависимостей файлов в проекте, что позволяет в дальнейшем производить компиляцию очень быстро, поскольку нет необходимости анализировать все исходные файлы в проекте. Надо заметить, что дерево зависимостей сохраняется на диске, так что после перезапуска Eclipse нет необходимости проводить анализ зависимостей в проектах с нуля.
Информация, собранная в процессе компиляции проекта, также используется для выполнения рефакторинга и специализированного Java-поиска (ссылок на декларации, объявления классов и т.п.). Именно доступность этой информации позволяет запускать рефакторинг и поиск без задержек, которые были бы необходимы для ее сбора в случае отсутствия автоматической компиляции. (И рефакторинг, и поиск будут работать и для не откомпилированных проектов, однако в этом случае точность полученных результатов не гарантируется.)
Что можно сказать о применимости автоматической компиляции для больших проектов - не окажется ли время, затрачиваемое на нее, неприемлемо большим? Как показывает практика, Eclipse позволяет комфортно работать с исходным кодом объемом порядка одного миллиона строк при условии, что он структурирован - разделен на проекты относительно небольшого размера. В случае, когда весь исходный код находится в одном проекте (я рекомендую избегать подобных ситуаций), может оказаться целесообразным отключить автоматическую компиляцию.
Очень привлекательной особенностью JDT является поддержка большого набора видов рефакторинга. Напомню, что рефакторингом называют методику переработки существующего кода с целью его улучшения. Популярная технология экстремального программирования (extreme programming) всячески поощряет разработчиков постоянно улучшать качество кода путем его рефакторинга. С опасностью добавления ошибок при изменении кода предлагается бороться как можно более частым выполнением как можно более полного набора автоматических тестов. JDT позволяет уменьшить эту опасность, полностью автоматически выполняя восемнадцать наиболее часто используемых видов рефакторинга, таких как перемещение элемента классы или выделение абстрактного интерфейса. Выполняя любой из видов рефакторинга, поддерживаемых JDT, вы можете быть уверены в том, что в результате произведенных изменений семантика программы не изменится.
Еще одним приятным свойством JDT, упрощающим применение рекомендаций методики экстремального программирования или Test driven development (TDD), является возможность запуска тестов JUnit прямо из IDE. Какой бы незначительной ни казалась эта деталь, она экономит существенное количество времени в процессе разработки. При работе в традиционной IDE цикл кодирование-модульное тестирование (unit testing) выглядит следующим образом: кодирование, сборка проекта, запуск JUnit, запуск тестов и анализ результатов. В JDT проект всегда находится в откомпилированном виде, поэтому этапы сборки и запуска JUnit пропадают, а выполнение набора тестов становится быстрее и проще. Этого оказывается достаточно для того, чтобы подход с написанием модульных тестов перед собственно кодом приложения начал выглядел намного более привлекательно.
Последний из подпроектов Eclipse, PDE, обеспечивает поддержку разработки расширений Eclipse - таких как плагины, редакторы, виды и страницы настроек. Именно PDE позволяет разрабатывать Eclipse в самом Eclipse.
Любая программа, собранная на основе фреймворка Eclipse, представляет из себя плагин или feature (группу плагинов).
Одна из самых важных сборок - Eclipse IDE - включает:
Как было отмечено выше, Eclipse предоставляет широкие возможности для расширения. В основе архитектуры, делающей это возможным, лежит использование плагинов (plug-in). Вместо того чтобы находиться в одном монолитном jar-файле, код Eclipse разделен на множество модулей, загружаемых динамически и независимо друг от друга (хотя каждый плагин может указать список плагинов, которые должны быть загружены до него). Для того, чтобы сократить время запуска платформы, плагины загружаются только перед непосредственным использованием (разумеется, полный список установленных плагинов доступен всегда).
Для того, чтобы Eclipse загрузил ваш плагин, необходимо написать дескриптор плагина - файл в формате XML под названием plugin.xml, который можно создать как при помощи PDE, так и в любом текстовом редакторе. Дескриптор сообщает Eclipse, какие ресурсы входят в плагин и каким образом платформа может их использовать. В ресурсы обычно входят библиотеки jar, текстовые сообщения в файлах .properties, графические изображения и т.п.
Разработчики могут создавать свои плагины, которые имеют абсолютно равные права с компонентами, изначально входящими в Eclipse; фактически приложение Eclipse представляет собой набор плагинов (для удобства конфигурирования группа связанных плагинов может быть объединена в подсистему (feature).
Eclipse поддерживает концепцию так называемых фрагментов (fragment) плагинов. Фрагменты плагина дополняют основной плагин - они очень похожи на обычные плагины, за исключением того, что не является самостоятельными модулями и могут быть использованы только в комплекте с основным плагином. Eclipse рассматривает плагин и все его обнаруженные фрагменты как единый логический плагин.
Для чего нужны фрагменты плагинов? Их основным свойством является возможность установки независимо от основного плагина. Как правило, фрагменты используются для добавления локализованных ресурсов и зависимых от операционной системы компонентов. Если некоторый плагин поддерживает локализацию, вы можете добавить поддержку нового языка при помощи отдельного фрагмента без изменения оригинального плагина и, более того, абсолютно независимо от его разработчиков (разумеется, по мере выхода новых версий плагина вам может понадобится вносить изменения в его фрагменты).
Модульная архитектура еще не обеспечивает расширяемости платформы - она всего лишь обеспечивает механизм загрузки кода, написанного разработчиками. Новая функциональность может быть добавлена в Eclipse с помощью механизма расширений. Ключевое понятие здесь - точка расширения (extension point). Точка расширения определяет группу сервисов и дает возможность разработчикам плагинов добавлять свои сервисы в общий список.
Каким образом разработчики могут добавлять в Eclipse, например, свои редакторы? Eclipse, а точнее входящий в компонент Workbench плагин org.eclipse.ui, определяет точку расширения для редакторов. (Как мы помним, именно Workbench определяет пользовательский интерфейс Eclipse.) Основная задача точки расширения - объявить уникальный идентификатор, который будет использован конкретными расширениями для ссылки на точку расширения. Вот как выглядит соответствующий фрагмент дескриптора плагина org.eclipse.ui:
<extension-point id="editors" name="%ExtPoint.editors" schema="schema/editors.exsd" /> |
Разработчик помещает свой редактор в плагин, и указывает в дескрипторе плагина, что он содержит расширение (extension), соответствующее точке расширения редакторов. При инициализации Eclipse зарегистрирует новый редактор в общем списке редакторов и сделает его доступным для пользователей. Для сокращения накладных расходов плагин с редактором будет физически загружен и проинициализирован только в момент создания первого экземпляра редактора.
Следующий пример определяет стандартный текстовый редактор Eclipse (обратите внимание на то, что задано расширение файлов, с которыми работает этот редактор - txt).
<extension point="org.eclipse.ui.editors"> <editor name="%Editors.DefaultTextEditor" extensions="txt" icon="icons/full/obj16/file_obj.gif" class="org.eclipse.ui.editors.text.TextEditor" contributorClass="org.eclipse.ui.editors.text.TextEditorActionContributor" id="org.eclipse.ui.DefaultTextEditor" /> </extension> |
Как происходит открытие файла для редактирования? Workbench ищет в списке всех расширений org.eclipse.ui.editors те редакторы, которые способны открыть файл с данным расширением (задается атрибутом extensions). Если обнаружено более одного подходящего редактора, пользователь может выбрать, какой из доступных редакторов он хочет использовать в данном случае. Существует соглашение о том, что все редакторы Eclipse обязаны реализовать интерфейс org.eclipse.ui.IEditorPart, поэтому Workbench создает объект класса, указанного в атрибуте class расширения, и приводит его к известному ему IEditorPart. В дальнейшем управление жизненным циклом редактора осуществляется только через этот интерфейс.
Что здесь является общим для всех реализаций механизма расширения, а что специфично для конкретного примера? Как правило, с точкой расширения действительно ассоциируется определенный интерфейс - через него клиенты точки расширения могут взаимодействовать с конкретными расширениями, не зная о деталях их реализации. Поскольку сценарии работы с различными точками расширениями, вообще говоря, не имеют ничего общего, большинство из точек расширения использует свой, уникальный интерфейс - в случае редактора это IEditorPart.
Разумеется, возможны ситуации, когда использование интерфейса не является необходимым. Например, точка расширения может быть использована для сбора информации о графических ресурсах - в этом случае от расширений требуется лишь указать имя подключаемого файла gif или bmp.
Типичное функционирование механизма расширений пояснит рисунок 4.
Рисунок 4. Механизм расширения Eclipse.
Клиенты точки расширения P (они не обязательно должны находится в плагине A, объявляющем точку расширения) могут получить список обнаруженных расширений P (в этом примере - единственное расширение в плагине B), создать их экземпляры и работать с ними через общий интерфейс I, объявленный в том же плагине, что и точка расширения.
Из приведенного примера может показаться, что существует жесткая взаимосвязь "один плагин - одна точка расширения". На самом деле никакого ограничения на количество расширений, с которыми может работать один плагин, нет. Один и тот же плагин может объявлять свои точки расширения и подключаться к сторонним - критерием объединения расширений в одном плагине является лишь логическая целесообразность.
Часто оказывается полезным создание плагинов, которые не подключаются к точкам расширения и не объявляет свои. Такие плагины содержат архивы jar и используются в виде своеобразных разделяемых библиотек.
При помощи описанного механизма расширений может быть расширена практически вся функциональность Eclipse - перспективы, редакторы, виды, страницы настроек, инкрементальные билдеры. Предположим, что перед вами стоит задача создания инструментария для поддержки Web-сайта. Вы можете создать новый вид проекта "Web project", редактор html, средства синхронизации с web-серверами, и разместить все новые элементы интерфейса в отдельной перспективе.
Важно то, что можно предоставить разработчикам возможность дальнейшего расширения вашего продукта. В приведенном выше примере может оказаться полезным удаление жесткой зависимости от одного протокола связи с Web-сервером. Более гибким решением было бы определение новой точки расширения и работа с плагинами, определяющими это расширение, через общий интерфейс работы с сервером (который должен быть определен вместе с точкой расширения). Таким образом, механизм поддержки расширений никоим образом не ограничен стандартной функциональностью, а, напротив, поощряет разработку расширяемых приложений.
Количество плагинов огромно. Только малая часть перечислена в разделе Eclipse/Plugins.
Если вы опять стартуете Tomcat, вы сможете администрировать его под 'http://localhost:8080/manager'.
Для руссификации Eclipse необходимо воспользоваться услугами Eclipse Babel Project. Скачивать и подкладывать ничего не нужно. Идём на страницу загрузки и берём оттуда ссылку на "update site" для своей версии. Например, для Eclipse Helios:
http://download.eclipse.org/technology/babel/update-site/R0.12.1/helios
Для Eclipse Luna:
http://download.eclipse.org/technology/babel/update-site/R0.12.1/luna
Для Eclipse Kepler:
http://download.eclipse.org/technology/babel/update-site/R0.12.1/kepler
Потом в своём Eclipse заходим в help -> install new software. Добавляем новый источник используя полученную ссылку. Ждём, пока Eclipse получит список доступных обновлений из нового источника. Дальше - выбираем language pack для вашего языка. Соглашаемся с лицензионным соглашением, выполняем установку. После рестарта ваша Eclipse заговорит на вашем языке.
Есть одна тонкость: если ваша системная локаль отличается от желаемого языка, запускать Eclipse придётся с явным указанием языка:
./eclipse -nl ru
Стартуйте Eclipse и установите его связь с вашей Tomcat-инсталляцией:
'File' | 'New' | 'Other...' | '[+] Server' | 'Server' | 'Next >' | '[+] Apache' | 'Tomcat v6.0 Server' | 'Next >'.
Вставьте в 'Tomcat installation directory' ваш Tomcat-каталог (например 'C:\Java\Tomcat') и нажмите 'Finish'.
Выберите Java EE перспективу через
'Window' | 'Open Perspective' | 'Other...' | 'Java EE' | 'OK' и кликните внизу на закладку 'Servers'. Вы увидите там 'Tomcat v6.0 Server'. С помощью символов или правой кнопки мыши вы можете сервер стартовать или остановить.
Сделайте двойной клик на строку сервера
В появившемся в главном окне Eclipse "Overview" сервера имеются дополнительные возможности конфигуации сервера.
Нажмите символ дискетки, чтобы запомнить изменение конфигурации сервера, если вы ее изменили.
Убедитесь, что Tomcat находится в остановленном состоянии.
'File' | 'New' | 'Project...' | '[+] Web' | 'Dynamic Web Project' | 'Next >'.
Внесите:
Project name: myProject Use default location: Да Target Runtime: Apache Tomcat v7.0 Configurations: Default Configuration for Apache Tomcat v7.0 EAR membership: Нет
'Next >'
Если вы в Project Facets Dialog получите вопрос о Java-версии, внесите, по крайней мере что-то вроде '5.0'.
'Next >'
Внесите 'Web Module':
Context Root: myProject Content Directory: WebContent Generate web.xml deployment descriptor: Да
'Finish'
Кликните правой кнопкой на имя каталога WebContent вашего проекта, выберите 'New' | 'Servlet' и внесите:
Java package: myservletpackage Class name: MyFirstServlet
'Next >'
Под URL Mappings отметьте /MyFirstServlet, нажмите кнопку "Edit..." и внесите
/HelloServlet
'Finish'
Проверьте в ' Измените текст MyFirstServlet.java на:
Eclipse SDK (инструментарий разработчика) — Eclipse Platform + JDT + PDE
Feature — иклипс-приложение, RCP-программа, состоящая из нескольких плагинов. Feature состоит из manifest-файла, плагинов, фрагментов, других файлов. Формат упаковки — JAR.
Feature manifest editor — один из редакторов PDE-перспективы, предназначенный для редактирования manifest-файла, описывающего Feature.
Fragment — фрагмент плагина. Удобен для доопределения новых свойств уже инсталлированного плагина, таких как локализация, изолирование зависимостей от платформ, распределения работ.
Perspective (перспектива) — набор редакторов и вьюеров для определенного контекста.
package myservletpackage;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class MyFirstServlet extends HttpServlet
{
static final long serialVersionUID = 1L;
@Override
public void doGet( HttpServletRequest requ, HttpServletResponse resp )
throws ServletException, IOException
{
resp.setContentType( "text/html" );
PrintWriter out = resp.getWriter();
out.println( "" );
out.println( "<h3> Hello, my first servlet is alive! </h3>" );
out.println( "" );
out.close();
}
}
Запуск веб-приложения в Eclipse
http://localhost:8080/myProject/HelloServlet Убедитесь в появлении текста "Hello, my first servlet is alive!".
Глоссарий
Знаете ли Вы, что интуитивное моделирование - это процесс создания модели на основе интуиции, представлений и жизненного опыта.
