Я унаследовал проект java в виде проекта затмения. После изменения конфигурации TOMCAT (от v6 к v7), Subclipse побудило меня совершить следующие файлыДолжен ли я передавать файлы, которые были изменены eclipse
будет ли им помочь совершал член моей команды, или это беспорядок с рабочим местом?
Каков наилучший подход к этому?
Вообще говоря, вы должны зарегистрировать (и зафиксировать после изменений) все, что вносит вклад в сборку И не восстанавливается повторно, полностью перестраиваясь и зависит от рабочей станции. (Последствия этого заявления зависят от вашего процесса сборки/процедуры, который предназначен.)
Это подразумевает, что вы должны исключить все, что было сгенерировано при полной сборке и т. Д., Поэтому оно не проверяется (и не предлагается для регистрироваться).
Это также подразумевает, что все файлы в вопросе должны быть проверены на предмет зависящей от рабочей станции вещи, такой как пути к файлам и пользовательские настройки. И если в некоторых из них нет какой-либо рабочей станции или пользователя, то нет ничего плохого в том, чтобы совершать определенные файлы. Например, .classpath может содержать пути к файловой системе, но, возможно, он просто содержит имена библиотек, не зависящие от рабочей станции, и пути для них определены в другом месте. –
@Sergey Tachenov: Да, и это то, что я имел в виду с «Последствия этого утверждения зависят от вашего процесса сборки/процедуры, которая предназначена». – TheBlastOne
Я проверил все и увидел, что файлы были независимы от пути. Я думал, что в Eclipse все будет либо независимым от пути, либо зависящим, но не тем ... –
Что мы сделали, это игнорировать эти файлы, поскольку они могут испортить рабочую область других в проекте.
Игнорирование их также делает ваш проект чище, что мне всегда нравится.
Pls предоставляет объяснение, когда вы что-то понижаете. – fmucar
Я не делал этого downvote, однако я полагаю, что downvoter считается «более чистым» слишком расплывчатым, как это может быть в случае «испортить рабочее пространство». Типичная ситуация с новичком: вы пытаетесь и натыкаетесь. Продолжайте, @cgratgny, учитесь у него, и ваш точечный баланс рано или поздно взорвется. Просто не расстраивайтесь этой начальной кривой обучения, это можно считать нормальным. – TheBlastOne
Спасибо за комментарий, @TheBlastOne. Я знаю, что я пытался ... просто не так красноречиво, как другие в решениях, которые они предоставляют. – Chris
Эти файлы могут содержать специфические для среды пути, поэтому я предлагаю не проверять их. В моем текущем проекте мы используем скрипты ant для создания проекта и выполняем первоначальную проверку всего нашего кода.
Лучше не передавать эти файлы, так как пути/настройки могут отличаться на разных рабочих станциях.
Возможно, вы захотите использовать какой-либо инструмент построения, чтобы преодолеть это. (например, Maven)
Как будто любой из членов команды не использует eclipse (используя какой-либо другой идеал), эти файлы не имеют для них никакого значения.
Если каждый совершает разные настройки IDE, представьте, какой беспорядок он может вызвать.
EDIT:
Дополнительные пояснения;
Я работал в командах, которые люди использовали NetBeans, Eclipse, IDEA ... в течение очень долгого времени, и на самом деле это не вариант для изменения IDE. Это повлияет только на производительность этого человека.
Когда люди привыкают к своим IDE, они изучают shorcuts, они знают, где искать некоторые функции (refactor/generate getter setter/implement переопределять необходимые методы ....), поэтому, если вы заставите их использовать какую-либо другую среду IDE, просто усложнит для них и замедлит процесс в целом. ИМХО и из моего опыта, имеющего гибкую кодовую базу, всегда хороши. Я парень-затмение и, вероятно, не хочу работать с какой-либо другой средой IDE, поскольку я знаю множество shorcuts, что делает вещи реальными быстрее/легче для меня, и эти shorcuts отличаются на разных IDE.
Все файлы IDE могут быть автоматически регенерированы самой IDE, всего за пару кликов.
И в моем текущем проекте есть 3 разработчика, каждый из которых использует различные IDEs eclipse (me), NetBeans, IDEA без проблем. Я не хочу видеть файлы конфигурации IDEA или NetBeans, которые не имеют смысла для затмения, когда я проверяю источник из репо. Точно так же и для них.
+1 для специфического для рабочей станции аспекта. В свою очередь, я позволил себе добавить этот аспект в свой собственный ответ. – TheBlastOne
-1 кем? Зачем? – TheBlastOne
"кем? Почему?" :) полное предложение вопроса заставит меня понять, в чем вопрос? – fmucar
Да, хотя убедитесь, что пути являются относительными в рабочей области, а не абсолютными путями. Наличие этих файлов в рабочей области позволяет членам вашей команды работать в той же среде, что и вы. Это также упрощает настройку новой среды разработки: вы просто проверяете ее вне контроля источника, а в Eclipse используется «Импорт ...> Существующие проекты в рабочую область»
Как упоминалось в @adamdunne, эти файлы могут содержать специфические для среды пути. Однако, если вы будете осторожны, чтобы убедиться, что пути являются относительными в вашей рабочей области, используя переменные и не импортируя внешние банки, то есть только включив банки из проектов в рабочей области, тогда вы должны быть в порядке. В моем рабочем пространстве мы проверяем эти файлы и у вас было намного меньше проблем с настройкой dev. с тех пор.
+1 для указания того, как избавиться от данных конфигурации конкретной рабочей станции. – TheBlastOne
Мы сделали это («Импорт ...> Существующие проекты в рабочее пространство»), и именно по этой причине я задал этот вопрос в первую очередь.В настоящее время моя команда находится в режиме обучения, и я хочу принять как можно больше лучших практик для жизненного цикла проекта. –
Я работаю в проекте, где мы фиксируем файл .classpath, так как очень полезно, что все разработчики используют то же самое :) Если вы используете только зависимости в своей рабочей области, этот файл использует относительные пути и, следовательно, должен быть одинаковым на всех машины. Даже если этот файл может не понадобиться для сборки (например, с помощью ant), его очень удобно синхронизировать.
В отличии от этого org.eclipse.core.prefs магазины (AFAIK) конкретный проект, но личных предпочтения разработчиков, которые я бы не проверить в.
С гранями я didn't работу еще в настоящий проект, поэтому я не могу сказать. Но в целом, я думаю, это зависит от информации в файле и от того, как вы работаете.
Если вы не уверены, просто попробуйте. Если вы получаете конфликты в этих файлах весь день, это намек на то, что вы не можете быть идеальным.
>> Если вы не уверены, просто попробуйте. << И пусть остальная часть команды насладится этим опытом сразу же, хе-хе. Если вы получаете конфликты в этих файлах весь день, это намек на то, что остальная часть команды получит их тоже, и вы успешно бомбили сборку :) – TheBlastOne
>> Если вы получаете конфликты в этих файлах весь день, это подсказка может быть, не идеальный путь. << Герцог Нукем скажет: «Хе-хе-хе, какой беспорядок». :) – TheBlastOne
org.eclipse.core.prefs хранит такие вещи, как исходный код и целевые версии компилятора Java, а также параметры предупреждения/ошибки, которые я бы на самом деле считал весьма полезными НЕ, чтобы каждый разработчик решал для себя. –
Эти файлы могут быть очень полезны для совместного использования конфигураций между разработчиками. Альтернативой является либо использование Maven (это огромная задача для установленного проекта), либо постоянная устаревшая пошаговая инструкция, а новые разработчики берут полдня, пока они не смогут даже построить проект.
Однако вы должны позаботиться о том, чтобы эти конфигурации были переносимыми, то есть не содержали локальных путей. Это можно сделать с помощью относительных путей в пределах рабочей области, переменных пути затмения и пользовательских библиотек.
Я также написал это в другом комментарии, я полагал, что у Eclipse были все пути относительные или абсолютные, но не оба. Это основная причина, по которой я опубликовал этот вопрос. Основываясь на этом и подобных советах, я начал просматривать каждый файл и видел, что происходит в каждом из них. Большое спасибо. –
@dimitris: Это определенно возможно иметь и то, и другое. Например, при добавлении JAR к пути сборки проекта (что приводит к записи в файле .classpath) у вас есть опции «Добавить JAR», который позволяет вам выбирать файл из рабочей области и генерирует относительный путь, и «Добавить внешние JAR», который позволяет вам выбирать любой файл и генерирует абсолютный путь. –
Как правило, вам следует избегать компиляции файлов, содержащих пользовательские настройки, и сведения о проекте, которые могут обновить Eclipse и/или ваши плагины.
Но в некоторых случаях вещи немного мутные. Например, файл .classpath может быть основным источником пути построения Eclipse; например если у вас есть файлы JAR в дереве проектов, а не с помощью Maven. (С Maven плагин m2cllipse генерирует файл .classpath из информации о зависимостях в файле POM, и, следовательно, файл не должен быть проверен.)
Кроме того, некоторые из фасетов являются пограничными. Например, в проектах с JSP и Javascripts я счел необходимым изменить свойства грани, чтобы отключить сломанные валидаторы. И есть хороший пример для рассмотрения этих изменений как части проекта, а не как личные предпочтения.
Разделение предпочтений группы/проекта по личным предпочтениям - это одна из областей, где (ИМО) Eclipse серьезно отстает.
Другие IDE лучше, и если да, то как? Я думаю, что eclipse так себе: здорово иметь основные конфигурации проектов в виде текстовых файлов в каталоге проекта. Это не так здорово, что они распространяются по различным файлам в различных форматах. –
@ Майкл - * «Другие IDE лучше» * - серьезно, я не знаю. И, вероятно, это одна из тех вещей, которые слишком сложно/слишком поздно исправить. –
См. Http://stackoverflow.com/questions/116121/do-you-keep-your-project-files-under-version-control/119377#119377 или http://stackoverflow.com/questions/2024307/what-should-be-commit-to-the-repository-in-the-eclipse-workspace или (более общий) http://stackoverflow.com/questions/1880817/what-to-put-under-version- управление – VonC
Wow. Я попытался немного оглядеться. Я думаю, что мой вопрос может «сломаться» на два или три и получить для каждого из них правильные ответы. Я считаю, что лучшим ответом будет ваш комментарий :-) –