Синхронизация Eclipse .classpath в репозитории кода

Моя команда обрабатывает несколько Java-проектов, используя Eclipse, и делится кодом с помощью репозитория кода.Синхронизация Eclipse .classpath в репозитории кода

Когда разработчик добавляет, удаляет или обновляет файл jar, сборка нарушена для всех остальных, пока они не обновят свой путь сборки в Eclipse. Этот процесс связан с громоздкой синхронизацией электронной почты.

По нескольким причинам мы решили не передавать файл .classpath на репо. Вместо этого мы придумали следующую идею: у каждого проекта будет зафиксированный файл, скажем jars.list, который содержит список файлов jar (и шаблонов). Сценарий преобразует этот файл в локальный .classpath для eclipse. Всякий раз, когда разработчик меняет свои банки, его обязанностью является изменение jars.list и фиксация его.

Это разумное решение? Существуют ли существующие решения для этой проблемы?

источник

2012-04-24 Adam Matan

Проверка .classpath и .project в исходное управление - это предполагаемый подход - они предназначены для этого. Почему ты этого не делаешь? –

Боюсь, что из-за личных конфигураций будет много конфликтов. –

Это не имеет никакого смысла. Файл '.classpath' предназначен для совместного использования; вы можете оставить его свободным от абсолютных путей с помощью различных методов, таких как хранение JAR в проекте, наличие отдельного проекта «Libs», использование переменных Classpath и т. д. Суть в том, что chcking в '.classpath' является предполагаемым способ сделать то, что вы пытаетесь сделать с помощью какого-то сложного ручного процесса. –

Затмения .project и .classpath файлов предназначены/предназначены для проверки в хранилище контроля версий (CVS, SVN, Git, и т.д.). См. this page в вики Eclipse.

Существуют различные способы сохранить файл .classpath «чистым» (то есть свободным от абсолютных путей), о котором я упоминал в разделе «Комментарии» выше.

источник

2012-04-26 20:15:51

Похож на правильный подход. Единственная проблема - JRE, которые проявляются в '.classpath', но специфичны для машины: http: // stackoverflow.com/questions/10371512/eclipse-classpath-in-svn-jre-collision –

Как указывает один из ответов на этот вопрос, использование среды выполнения - это правильный способ указать желаемую версию Java. Специфичные для конкретного компьютера спецификации JRE являются историческим остатком и действительно должны быть удалены из параметров конфигурации, IMO. Среда выполнения представляет собой абстракцию над физическим местоположением JRE, которое сохраняет ваш .classpath «чистым» и переносимым. –

Сборка нарушена, потому что абсолютный путь к JAR отличается на каждой машине для разработчиков? Если да, то вы можете добавить переменную пользователя, чтобы избежать проблемы, таким образом, каждый разработчик должен только настроить одну переменную (например, LIB_DIR):

<classpathentry kind="var" path="LIB_DIR/path/to/file.jar"/>

Есть и другие решения. Вы можете настроить некоторые пользовательские библиотеки в eclipse, чтобы сгруппировать JAR, а затем экспортировать файл .userlibraries, который можно использовать в вашем репо. Таким образом, в .classpath не будет абсолютных путей, но они будут присутствовать в вашем .userlibraries.

Вы также можете использовать некоторый инструмент, например Maven, для управления зависимостями от вашего проекта.

Во всяком случае, я думаю, вы могли бы поделиться .classpath без проблем ...

источник

2012-04-24 16:56:17

Синхронизация Eclipse .classpath в репозитории кода

ответ

Смежные вопросы