Поддержка нескольких IDE в Java для одной команды - PullRequest
7 голосов
/ 16 октября 2008

Как лучше всего разрешить команде программистов использовать Netbeans, Eclipse и IntelliJ в одном проекте, что исключает вопрос «какая IDE лучше».

Какие файлы следует или не следует проверять в контроле исходного кода?

Ответы [ 9 ]

10 голосов
/ 16 октября 2008

Я думаю, что лучший способ - сделать процесс сборки независимым от IDE. Это означает, что ваш проект не должен полагаться на какие-либо специфичные для IDE файлы для сборки, а должен использовать внешнюю систему сборки, такую ​​как Apache Maven , Apache Ant , или даже создавать или настраивать скрипты , Maven поддерживается большинством популярных Java IDE, напрямую или через подключаемые модули.

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

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

6 голосов
/ 16 октября 2008

Ну, это довольно самодостаточный вопрос.

Файлы, которые не проверяются в управлении исходным кодом, - это файлы, которые имеют отношение к самим IDE.

Предоставьте разработчикам возможность создавать эти файлы.

Если вы используете Maven, он может генерировать файлы, такие как Eclipse .project и .classpath для вас. Eclipse в целом очень прост в использовании с базовой файловой структурой (с новой опцией Java Project).

Я думаю, что Maven также поддерживает Netbeans, хотя не уверен насчет IntelliJ.

Сайт Maven: maven.apache.org .

5 голосов
/ 16 октября 2008

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

Я сделал это со многими различными IDE, и мне еще предстоит увидеть конфликт имен файлов.

Фактически, даже когда конкретный IDE использует только один разработчик, его преимущество состоит в том, чтобы создавать версии вспомогательных файлов по той же причине, по которой вы версии других файлов в вашей среде разработки: история, различия, комментарии и т. д.

4 голосов
/ 16 октября 2008

Для Eclipse это будут файлы .classpath и .project.

Моя команда использует Maven, и разработчикам не рекомендуется проверять файлы, специфичные для Eclipse. Поскольку они могут быть сгенерированы из Maven, эти файлы являются избыточными.

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

3 голосов
/ 16 октября 2008

При использовании нескольких наборов инструментов в рамках одной проектной команды существует множество факторов. Например, в моей команде есть разработчики Java, использующие IntelliJ, и большинство разработчиков интерфейса (JSP / CSS / HTML), использующие eclipse. Мы находимся в процессе миграции пользователей Eclipse на IntelliJ из-за разработанных нами плагинов IntelliJ, которые обеспечивают расширенную поддержку нашей среды. Мы не собираемся разрабатывать плагины для нескольких платформ, поэтому мы стандартизируем IntelliJ по всем направлениям.

Что касается конкретных файлов, я могу поговорить с IntelliJ. Мы проверили наши файлы .ipr и наши файлы .iml. Не проверяйте файлы .iws. Если у вас также есть пользователи Eclipse, настройте проект IntelliJ на чтение / сохранение информации о зависимостях в файле .classpath и зафиксируйте ее в своей VCS.

1 голос
/ 23 декабря 2008

Дополнительные комментарии и ответы по этой теме см. в этом вопросе (Как вы справляетесь с различными IDE Java и svn?)

1 голос
/ 16 октября 2008

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

Что означает для разработчиков то, что они не должны фиксировать свои изменения в файлах IDE. Все остальное (например, src, test, lib и т. Д.) Становится набором, который мы обычно обновляем и фиксируем каждый день.

Дополнительным преимуществом является то, что мы полностью исключили войны IDE здесь: люди Netbeans и Eclipse живут в совершенной гармонии (глядя на людей IntelliJ, но эй ...; -).

0 голосов
/ 23 декабря 2008

Мы переименовываем наши IDE-файлы для регистрации с дополнительным расширением .deletethis или аналогичным. Когда новый человек проверяет проект, он просто снимает дополнительное расширение и готов к работе. Таким образом мы избегаем конфликтов контроля версий с файлами проекта, так как люди настраивают свою среду. И вам не нужно беспокоиться о том, чтобы научить новых разработчиков не проверять эти файлы.

0 голосов
/ 16 октября 2008

Обычно я считаю это плохой идеей. Я не уверен, что это за среда (возможно, с открытым исходным кодом?), Но было бы очень плохо поддерживать несколько IDE. Одна вещь, которую я бы порекомендовал, если это неизбежно, - это стандартизация ваших сборок в скриптах ant. Если у вас большой набор зависимостей, это может быть самый простой способ получить предсказуемую сборку на всех платформах.

Если одна из IDE оказывается RAD (на основе затмения), существует целая папка с именем .settings, которую вы не хотите включать в SCM.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...