Определение пользовательских библиотек в Eclipse как части проекта, а не рабочего пространства

Question

Я видел, что в Eclipse я могу определить Пользовательские библиотеки - чтобы упростить настройку пути к классам (и, вероятно, по другим причинам).

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

Есть ли такая функциональность на уровне проекта?Мне в основном нужно иметь ' группу путей к классам ' - это можно сделать?

Если нет, существует ли автоматический способ автоматического импорта пользовательской библиотеки в рабочую область при импорте проекта?

Я использую Eclipse 3.6.

Answer 1

JDT имеет 2 понятия, пользовательские библиотеки и переменные пути к классам. В переменной classpath вы можете добавить jar в ваш проект. Другие члены команды должны заполнить переменные в своем рабочем пространстве, чтобы их путь к классу был завершен. Это полезно, когда внешние jar-файлы могут находиться в разных местах в локальной файловой системе каждого члена команды.

USER_LIBRARY - это контейнер для добавления логической группы локальных jar-файлов одновременно. Например, контейнер JRE_LIB представляет несколько локальных jar-файлов. Но, как вы видели, он указывает на локальный набор jar-файлов, предназначенных для использования в нескольких проектах (поскольку JRE добавляется в несколько проектов).

Помимо экспорта / импорта (который вы уже делаете), я не верю, что вы можете проверить CLASS_LIBRARIES в SCM проекта. Если бы это было так, на странице настроек в верхней части была бы ссылка «Настройка параметров проекта».

Лучше всего просто добавить банки в проект, чтобы они были включены в SCM. Если они могут находиться в разных местах в зависимости от остальной части вашей команды, то используйте переменную classpath, чтобы ее можно было установить в каждой рабочей области. Это наименьшее количество хлопот, поскольку члены команды проверяют проект и готовы к работе.

Answer 2

Лучший способ IMO - использовать m2eclipse - плагин Maven для eclipse . В Maven все зависимости определены в pom.xml и загружаются автоматически по мере необходимости. Это означает, что единственной вещью, которой вы делитесь со своей командой, является pom.xml - определение вашего проекта.

Существует намного больше преимуществ при использовании m2eclipse по сравнению со стандартным приближением затмения. Больше информации на http://www.sonatype.com/books/m2eclipse-book/reference/

Answer 3

Я использовал пользовательские библиотеки для чего-то вроде Ant.Определите пользовательскую библиотеку "ant" для всех jar-файлов в ANT_HOME / lib.Если включить это в свой Eclipse .classpath, а затем поделиться с другими пользователями, они получат отчет о проблеме сборки, пока не создадут эту пользовательскую библиотеку «муравей» самостоятельно.Это полезно, но вам нужно поделиться знаниями о том, как создать библиотеку.Если вы используете его для простых случаев, подобных описанным выше, инструкции по добавлению правильных jar-файлов в библиотеку просты.

Другой подход, который я использовал, - это создание путей к классам, указывающих на определенную папку (или папки)в качестве переменной в Eclipse.Смотри File -> New Folder -> Advanced -> Link to folder in the file system -> Variables.Это позволяет вам настроить (опять же на уровне рабочей области) переменные ссылки на одну или несколько папок.Затем вы можете построить свой Eclipse classpath / s со ссылкой на папку / s.

Так, скажем, в вашей среде разработки у каждого должен быть каталог под названием "thirdparty", содержащий все внешние зависимости jar (возможно, в иерархиивнутри этого каталога: третья сторона / apache; третья сторона / солнце; ...).Вы определяете "третий участник" как переменную, указывающую, где находится этот каталог в вашей текущей системе, вы создаете папку в своем проекте (ях), используя переменную.Затем вы можете настроить (и поделиться) путь к классам, используя пути к этой папке.

Он похож на библиотеку пользователя и имеет аналогичные ограничения.Ограничение заключается в том, что другие пользователи, с которыми вы делитесь вашим проектом, должны создавать переменную папку / папки, как у вас.Но он более гибкий, поскольку им не нужно явно добавлять файлы jar, как это делается с библиотекой;скорее, ваши classpath / s в Eclipse указывают на папку, как требуется для каждого проекта.

Обратите внимание, что хотя переменная папки определена на уровне рабочей области, она может быть повторно использована в нескольких проектах, каждый из которых создает своиclasspaths (файлы .classpath) с различными ссылками на папку).

Возможно, это проще показать, чем описать словами, но я надеюсь, что это имеет смысл.