Eclipse Enviroment

В этой статье я хочу немого рассказать о том, как с помощью различных переменных окружения и строк подстановок можно настроить свою Eclipse IDE для удобства, в первую очередь, тем кто ведёт совместную разработку проектов, а также тем, кто просто любит порядок и системность во всем.

Думаю мне не стоит объяснять для чего и как используются системные переменные окружения, а также, что такое строки подстановки и где они применяются... Пользу от переменных значений в программировании сложно переоценить. Но вопрос - насколько значнения системных переменных окружения переменны? Т.е. я хочу сказать - как часто и на сколько легко править системные переменные окружения? Если вы скажите, что редко и эта процедура вполне удобна, то, думаю, эта статья будет вам не особо интересна. Лично я, довольно давно работаю с несколькими проектами, в которых активно используются кое-какие системные перменные, при этом, значения от этих переменных проекты ожидают разные, понятно: пути к библиотекам и ресурсам для разных проектов - разные, а переменная одна. Приходится как-то переключатся. Это можно делать по разному:

• скрипт для глобальной смены переменных окружения - ужастный вариант, схожий по извращению со сменой переменных окружения руками, оснобенно сочувствую несчастным пользователям Windows, конечно этот вариант хорош при инсталяции вашей системы на машине заказчика, но работать так повседневно - крайне затруднительно;
• скрипт запуска приложений с нужными переменными - так например, можно запускать Eclipse IDE или своё приложение с помощью отдельных скриптов, в которых перед вызовом самого приложения предварительно прописать экспорты (export) (или сеты (set) для Windows) тех или иных переменных окружения. Вариант более удобный и в каких-то случаях вполне приемлемый, но мы будем говорить о том как, по крайней мере внутри Eclipse IDE, достигнуть этого же эффекта более элегантным способом.

Предположим, что у нас есть проект, который называется "MyPrj". Пусть у этого проекта есть корневая директория, в которой находится сам файл для запуска приложения, а также его конфигурационные файлы и какие-то библиотеки, такие как log4j.jar и тому подобные. Таким образом, есть примерная структура проекта:

/home/sk/myprj/root [кореневая директория]
|-- bin             [папка для рабочих файлов проекта]
|-- config          [папка с конфигурацией]
`-- libs            [какие-то библиотеки]

Теперь посмотрим, что можно сделать в настройках Eclipse Workspace.

1. Переменные для сборки

Вообще надо сказать, что настройки Eclipse, относящиеся к проектам, заданы по умолчанию на уровне IDE, но они могут быть переопределены в свойствах конкретного проекта, это можно называть по умному - project-specific settings.

Таким образом для начала работы, если мы хотим использовать у себя в проекте библиотеку log4j.jar, то мы должны сказать проекту, где она лежит. А для этого необходимо определить, так называемые classpath variable, в настроеках проекта: Project >> Properties >> Java Build Path. В этом окне можно добавлять пути к внешним библиотекам разными способами, описывать каждый я не буду - мы хотим использовать переменные, поэтому жмем "Add Variable". Далее, чтобы создать свою переменную нужно нажать ещё несколько кнопок: Configure Variables >> New. Назовем переменную MYPRJ_ROOT и в качестве значения укажем корневую директорию проекта:

Далее, создав переменную, её можно использовать для формирования пути к библиотекам - в диалоге "Add Variable", выбираем из списка MYPRJ_ROOT и жмем на кнопку "Extend" и ищем в списке нужную библиотеку:

Описаный способ подключений библиотек, в общем-то вполне очевиден, также понятно в чём плюс такого подхода: при разработке проекта несколькими людьми на разных машинах пути к директории libs могут (и скорее всего будут) отличатся. Используя переменную - проблема будет состоять только в том, чтобы каждый разработчик настроил у себя в workspace нужным образом classpath variable (понятно, что в этом случае название переменной должно быть оговорено и быть стабильным).

2. Внутренние переменные окружения Eclipse IDE

Хорошо, проект у нас есть, необходимые библиотеки подключенны, теперь нам нужно, чтобы во время отладки из под Eclipse проект использовал переменные окружения.

В Eclipse есть возможность запускать проекты каждый со своими индивидуальными настройками, вплоть настроек значений переменных окружения. Для этого в окне настроек Eclipse (Window >> Preferences >> Run/Debug >> String Substitution) создадим строку подстановки, которую в последствии используем в качестве значения для внутренней переменной окружения Eclipse:

Назовем строку подстановки, как и в пункте 1 - "MYPRJ_ROOT" (хотя это и не обязательно, более того не надо путать переменые описанные в пункте 1 и строки подстановки, а также переменные окружения - это разные вещи) и снова укажем в качестве значения корневую директорию проекта: /home/sk/myprj/root.

Теперь нам при запуске приложения необходимо указать JVM правильный CLASSPATH. Для этого в диалоге "Run Configurations", во вкладке "Enviroment" нужно создать внутреннюю переменную окружения для проекта. И опять назовем её "MYPRJ_ROOT"... честно сказать я обычно и в реальном проекте так делаю и даже не путаюсь в итоге, но вообще, опять же - всё зависит от ситуации и личных взглядов.

Далее во вкладке "Arguments", в поле "VM arguments" напишем следующее заклинание (одинаково для любой ОСи):

-Djava.ext.dirs=${MYPRJ_ROOT}/libs

Теперь, во-первых, запускаемое приложение будет полностью уверенно, что в системе есть переменная окружения ${MYPRJ_ROOT} (или %MYPRJ_ROOT% на виндовый манер), которую можно использовать во время выполнения, например, как-нибудь так:

а во-вторых: CLASSPATH обращен к директории /home/sk/myprj/root/libs, где JVM будет искать необходимые библиотеки для проекта, и этот путь с нашей точки зрения будет являтся относительным (как минимум относительно данного проекта).

Здесь оговорюсь: использование переменных окружения в качестве нахождения пути к папке с проектом - не лучший способ, тут я просто продемонстрировал пример использования переменных окружения, может не самый удачный, но смысл тут остаётся один - показать то, как в Eclipse IDE создать окружение для отлаживаемого приложения.

3. Переменные для размещения собраных библиотек

Следующий шаг - это выкладываение собраной библиотеки нашего проекта в директорию, от куда её потом можно будет запускать в качестве stand alone приложения.

Конечно, сборкой проекта, особенно крупного, должны заниматься монстровые инструменты, такие как Ant и Maven, а всякие там гуёвые решения (от англ. GUI) - это, понятно, от лукавого. Но всё же рассмотрим именно последный, т.е. гуёвый, вариант, коли уж мы говоим о переменных подстановки. Сразу скажу, что путь этот несколько тернист и сразу не очевиден...

Есть такая замечательная вещь как JBoss Tools - это набор расширений Eclipse для работы с продуктами JBoss - Hibernate, JBoss AS, JSF, Seam и т.д и т.п... В этом, почти бесконечном, наборе инструментов, есть такая, сразу не заметная, вещь как JBoss archives tools, она позволяет автоматом пакетировать java-библиотеки и выкладывать их в указаных местах. Как с помощью этого инструмента пакетировать проект - это тема для отдельного, пусть и не длинного, разговора, напишу об этом в следующем посте, а вот как выкладывать собраные библиотеки мы поговорим прямо сейчас.

Прежде, чем начать забивать гвозди - нужно взять молоток в руку. Тем кто пользуется целым пакетом JBoss Tools, в каких-то своих целях, проще - у них инструментальный ящик под есть рукой и достать от туда молоток не проблема. А вот, для тех у кого этого счастья нет, и вообще не понятно нафиг оно нужно - есть два варианта: либо вообще плюнуть на это дело, либо скачать молоток отдельно. Устанавливать у себя целиком JBoss Tools ради одного инструмента - сомнительное удовольствие, JBoss archives tools можно легко установить отдельно, не выходя из Eclipse, для этого идём в окошко одновлений: Help >> Software Updates >> [вкладка] Available Software. Здесь нам нужно добавить адрес к JBoss Update Site (кнопка "Add Site...") - здесь я оставлю выбор сайта на усмотрение читателя: http://www.jboss.org/tools/download.html. Также, есть возможность, просто, скачать пакет в качестве архива - это можно сделать тут (для Eclipse 3.4.2): https://www.jboss.org/tools/download/stable.html.

После всех этих не простых приготовлений в Eclipse должна появиться View "Project archives" (быстро найти её можно нажав Ctrl+3 и вписав в текстовое поле: "archives"). Теперь можно приступать к эксплуатации: выбрав наш проект, он появится в "Project archives", от куда по правой кнопке перейдем в диалог создания нового JAR файла. Здесь настраивая содержимое архива нашего проекта можно указать путь назначения для сборки. И сделать это можно, опять же с помощь внутренних переменных окружения Eclipse - указав в поле "Destination": ${MYPRJ_ROOT}/bin/, и выбрав для "Replace to" пункт "file system":

В общем-то это всё. После создания и настройки архива, во View "Project Explorer" (к сожалению, только в этой View) у проекта должна появится такая штука:

т.е. кнопка сборки архива проекта всегда под рукой и копирование архива при этом происходит сразу в нужное место. Очень удобно.

В общем надеюсь, статья окажется полезной. На этом у меня всё.