Блог

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

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

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

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

Спасибо,

Кен

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

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

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

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

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

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

Хороший момент.

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

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