Ищу совет для обмена Eclipse Projects

Question

Я ищу совет относительно передовых методов для совместного использования проекта Eclipse среди разработчиков.

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

Кроме того, если рекомендация заключается в совместном использовании проекта, каковы рекомендации по настройке управления проектом Eclipse? В прошлом мы использовали ClearCase, но теперь мы хотим перейти на Git или SVN. В мире ClearCase было бы целесообразно проводить частые проверки и слияния, чтобы помочь команде оставаться в курсе событий. Снова, я ищу мнения от людей, которые уже жили этим.

Спасибо за любые рекомендации или внешние "как" книги или веб-сайты!

Спасибо

Ken

Answer 1

Совместное использование проекта Eclipse не вызывает никаких проблем. Просто поместите файлы .classpath, .project и каталог .settings (и любой связанный с проектом файл конфигурации / каталог, который Eclipse создает в корне проекта) под контроль исходного кода.

Кроме того, избегайте использования абсолютных путей в вашем проекте (например, для внешних библиотек), поскольку все разработчики не обязательно имеют одинаковые настройки и используют одинаковые местоположения.

Git, SVN или ClearCase: это не имеет значения: все позволяют обмениваться файлами Eclipse.

Answer 2

Мы помещаем всю папку проекта eclipse под контроль версий (с помощью svn: ignore для каталога, содержащего скомпилированные классы).

Это позволяет нам делиться не только конфигурацией сборки, но и конфигурациями запуска (с надлежащими VM-параметрами), конфигурацией предупреждений компилятора, которую группа считает необходимой, и конфигурацией форматера для используемых соглашений о кодировании. Таким же образом мы можем установить кодировки текстовых файлов.

Answer 3

... избегайте использования абсолютных путей в вашем проекте

Хороший вопрос.

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

Затем мы добавили в проект компоновщик, чтобы убедиться, что скрипт запускался первым при каждом чистом + перестроении.