У меня есть приложение, которое состоит приблизительно из 10 различных проектов Eclipse. Некоторые проекты должны быть разработаны с Java 5 и другими с Java 6. У меня есть оба из этих JDKs, зарегистрированных в "Установленном JREs Eclipse" список как "jdk5" и "jdk6", соответственно.
Соответствующий JRE находится на пути к классу сборки каждого проекта, который отражается в .classpath файлах. Однако другие участники в моей команде используют различные символьные имена для этих JREs на их машинах. Кроме того, .classpath файлы проверяются в управление исходным кодом. В результате люди должны внести локальные изменения в свой .classpath файл, чтобы смочь создать.
Мой инстинкт должен выбрать соглашение о присвоении имен для установленного списка JREs и попросить, чтобы все члены команды придерживались его. Однако это просто усложняет процесс установки нового разработчика. Действительно, я просто хочу сказать, "разрабатывают этот проект с Java 5", и "разрабатывают тот проект с Java 6". Я не забочусь, где они установлены, или каково их символьное имя. Eclipse поддерживает этот вид конфигурации?
Среды выполнения - это то, что вам нужно (Настройки -> Java -> Установленные JRE -> Среды выполнения). Вы можете изменить путь к классам своих проектов, чтобы использовать системную библиотеку JRE, соответствующую определенной версии Java, например «J2SE-1.5» или «JavaSE-1.6». Затем Eclipse классифицирует установленные JRE по этим категориям и будет использовать соответствующую при создании ваших проектов.
Честно говоря, я использую maven (maven-compiler-plugin и профили) именно для этого.
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
Использование такой системы, как maven (или ant и т. Д.), Очень помогает нам в решении проблем, связанных с несоответствиями между классами, средой и ОС между разработчиками.
Вы можете настроить параметры компилятора для конкретного проекта в разделе «Настройки» -> «Java» -> «Компилятор». Однако это позволяет вам только установить уровень соответствия, а не выбирать конкретный JDK. Но, может быть, этого уже достаточно для вашей цели?
Если вы синхронизируете файлы проекта, eclipse сохраняет текущий JDK на вкладке Libraries в конфигурации пути сборки проекта. Это будет довольно хорошо переноситься до тех пор, пока у всех установлен и загружен в eclipse один и тот же JDK.
Там, где это возможно, я бы рекомендовал использовать решение maven, предложенное Quotidian, но я добился значительного успеха, используя ручную сборку до тех пор, пока каждая рабочая станция разработчика настроена одинаково. Однако это может привести к зависанию, если разработчики работают под разными операционными системами, так как он может искать "C:\Program Files\java" в системе linux, или "/user/lib/jvm/" в wndows, но ни того, ни другого не существует.
Если вы застряли с необходимостью проверять ф-ции .classpath в контроле исходных текстов, то я бы посоветовал вам придерживаться вашей идеи об установке JDK всеми разработчиками в одно и то же место (или использовать общее имя переменной env, указывающее на местоположение). Я думаю, что разработчикам из одной команды гораздо проще иметь очень похожие настройки окружения, и если эти общие настройки окружения хорошо документированы. Таким образом, когда новые разработчики приходят на работу, вы можете указать им на вашу документацию по настройке env, и они быстро приступят к работе - не нужно будет тратить время на отладку проблем с тем, где установлены их JDK.
Если же это не вариант, и вы уже используете Maven, то вы можете рассмотреть возможность удаления файлов .classpath из контроля исходных текстов. Мы недавно сделали это, и просто заставили всех разработчиков запустить плагин Maven eclipse для создания (или обновления) их собственных файлов .classpath на основе того, что находится в файле pom.xml. (т.е. mvn eclipse:eclipse для запуска этого плагина).