Как вы справляетесь с различными Java IDE и SVN? - PullRequest
8 голосов
/ 17 сентября 2008

Как вы можете убедиться, что вы можете извлекать код в Eclipse или NetBeans и работать там с ним?

Редактировать: Если вы не регистрируете файлы, относящиеся к ide, вам необходимо заново настраивать buildpath, include и все эти вещи, каждый раз, когда вы извлекаете проект. Я не знаю, будет ли муравей (особенно сборочный файл муравья, который создается / экспортируется из eclipse) без проблем работать с другими идеями.

Ответы [ 7 ]

9 голосов
/ 17 сентября 2008

Мы фактически поддерживаем проект Netbeans и Eclipse для нашего кода в SVN прямо сейчас, без каких-либо проблем. Файлы Netbeans не наступают на файлы Eclipse. Наши проекты структурированы так:

sample-project   
+ bin
+ launches  
+ lib  
+ logs
+ nbproject  
+ src  
  + java
.classpath
.project
build.xml

Самые большие очки:

  • Запретить любые абсолютные пути в файлы проекта для любой IDE.
  • Установить файлы проекта для вывода файлы классов в тот же каталог.
  • svn: игнорировать личное каталог в .nbproject каталог.
  • svn: игнорировать каталог, используемый для вывод файла класса из IDE и любых других сгенерированных во время выполнения каталогов, например, из каталога logs выше.
  • Иметь людей, использующих оба последовательно так что различия будут решены быстро.
  • Также поддерживайте систему сборки не зависит от IDE, таких как CruiseControl.
  • Используйте UTF-8 и исправьте все проблемы с кодировкой немедленно.

Мы разрабатываем для Fedora 9 32-разрядную и 64-разрядную версию, Vista и WindowsXP, и около половины разработчиков используют одну IDE или другую. Некоторые используют оба и регулярно переключаются туда и обратно.

7 голосов
/ 17 сентября 2008

Умный ответ - «делай так» - если вы не работаете с несколькими IDE, вы не знаете, действительно ли вы готовы работать с несколькими IDE. Честный. :)

Я всегда считал несколько платформ более громоздкими, поскольку они могут использовать разные стандарты кодирования (например, Windows может по умолчанию использовать ISO-8859-1, Linux - UTF-8) - для меня кодирование вызывает гораздо больше проблем, чем в IDE.

Еще несколько указателей:

  • Возможно, вы захотите использовать Maven (http://maven.apache.org),, чтобы он генерировал специфичные для IDE файлы и никогда не передавал их в систему контроля версий.
  • Чтобы быть уверенным в том, что вы генерируете правильные артефакты, вы должны иметь выделенный сервер для создания ваших результатов (например, cruisecontrol), либо с помощью ant, maven или любого другого инструмента. Эти результаты тестируются за пределами машин для разработки. Отличный способ заставить людей осознать, что за пределами их собственной машины есть другой мир.
  • Запретить любой путь к конкретному компьютеру, который должен содержаться в любом конкретном файле IDE, найденном в системе контроля версий. Всегда ссылаться на внешние библиотеки по логическим путям, желательно с указанием их версии (если вы не используете maven)
1 голос
/ 17 сентября 2008

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

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

0 голосов
/ 18 сентября 2008

Вот что я делаю:

  1. Поддерживайте в исходном коде только свой скрипт сборки ant и связанный путь к классу. Classpath может быть явным в сценарии ant, в файле свойств или управляться ivy.
  2. написать цель ant для генерации файла Eclipse .classpath из ant classpath
  3. Netbeans будет использовать ваш скрипт сборки и путь к классам, просто настройте его для этого через проект свободной формы.

Таким образом, вы получаете независимые от IDE сценарии сборки и счастливые разработчики:)

На сайте netbeans есть блог о том, как это сделать 3., но я не могу сейчас его найти. Я положил некоторые заметки о том, как сделать выше, на моем сайте - текст ссылки (быстро и безобразно, извините)

Обратите внимание: если вы используете Ivy (хорошая идея) и eclipse, у вас может возникнуть желание использовать плагин eclipse ivy. Я использовал его и обнаружил, что он ужасно глючит и ненадежен. Лучше использовать 2. выше.

0 голосов
/ 17 сентября 2008

Я использую maven и регистрирую только pom & source.
После проверки проекта я запускаю mvn eclipse: eclipse
Я говорю svn игнорировать сгенерированный .project и т. Д.

0 голосов
/ 17 сентября 2008

Я придерживаюсь философии, что сборка должна выполняться с использованием подхода «наименьшего общего знаменателя». Что входит в систему контроля версий - это то, что требуется для сборки. В то время как я разрабатываю исключительно с Eclipse, моя сборка идет с помощью ant в командной строке.

Что касается контроля версий, я проверяю только файлы, которые необходимы для сборки, из командной строки. Нет файлов Eclipse. Когда я настраиваю новую машину для разработки (кажется, два раза в год), требуется Eclipse, чтобы импортировать проект из файла сборки ant, но ничего страшного. (Теоретически, это должно работать так же и для других IDE, нет? Неужели они должны быть в состоянии импортировать из ant?)

Я также задокументировал, как настроить минимальную среду сборки.

0 голосов
/ 17 сентября 2008

По большей части я бы согласился с seldaek, но я также склонен сказать, что вы должны хотя бы предоставить файл, который говорит, каковы зависимости, какую версию Java использовать для компиляции и т. Д., И что-либо еще что разработчик NetBeans / Eclipse может потребоваться для компиляции в своей IDE.

В настоящее время мы используем только Eclipse, и поэтому мы передаем все файлы Eclipse .classpath .project в svn, что, на мой взгляд, является лучшим решением, потому что тогда каждый может слишком легко воспроизводить ошибки и что-то непростое вместо того, чтобы сойти со спецификой IDE.

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