2016-12-12 8 views
3

У меня есть многомодульный проект Maven Java (WAR) в Eclipse. Это зависит от множества других проектов Java. Мы проверяем наш каталог .settings на исходный элемент управления, потому что там есть много установленных вручную настроек.Eclipse M2E change org.eclipse.wst.common.component

Один из файлов в .settings - org.eclipse.wst.common.component, который также имеет установленные вручную настройки. Тем не менее, Eclipse постоянно модифицирует этот файл на основе того, какие базовые проекты JAR открывает разработчик в Eclipse. Я считаю, что это делает это, чтобы помочь выполнить «разрешение рабочей области» этих артефактов.

Однако результатом этой ситуации является то, что Eclipse постоянно модифицирует то, что org.eclipse.wst.common.component, и разработчики постоянно фиксируют это для контроля источника и борьбы с ним друг с другом. Оставляя эти файлы вне контроля источника, не работает, поскольку в нем слишком много ручных настроек, характерных для каждого проекта.

Я предполагаю, что это ошибка дизайна в Eclipse, чтобы иметь файл, который объединяет настройки проекта и настройки пользователей вместе! Если у кого-то есть представление о том, как лучше справиться с этой проблемой, это было бы здорово. Как бы то ни было, Eclipse-M2E просто не работает для разработки команды по сложным проектам, если у каждого разработчика ТОЧНО одни и те же Java-проекты загружены ....

+0

Я только что обнаружил эту проблему в своем собственном рабочем пространстве. Что вы в итоге решили решить? Вы использовали IntelliJ с этим проектом Maven раньше? Если да, то как? – Daniel

+1

Я знаю, что это будет звучать смешно или, как преувеличение, или как платная реклама. Но это была проблема, которая сломала спину верблюда ... после этого я, наконец, был вынужден позволить команде попробовать Intellij. Я не говорю, что это без изъянов, но это намного лучше, чем Eclipse, я очень сожалею, что не переключился много лет назад. Огромная ошибка с моей стороны. – HDave

+1

По большей части IntelliJ имеет довольно чистое разделение между файлами рабочей области и файлами проекта, так что таких вещей не происходит. Опять же, это не идеально, но это в десять раз лучше. – HDave

ответ

1

Я согласен, что этот конкретный файл проблематичен ... Если он поврежден , рабочее пространство, скорее всего, потерпит крах, и если оно отсутствует - ничего не будет работать. Но он не содержит ничего, что не может быть создано с нуля при повторном импорте проекта ...

Я думаю, что лучшим решением является проверка файла с использованием «полного» рабочего пространства, а затем убедитесь, что будущее изменения игнорируются.

Если вам необходимо выполнить «реальное» изменение, загрузите полное рабочее пространство, сделайте все, что вам нужно, а затем не игнорируйте файл, зарегистрируйтесь и снова проигнорируйте его.

например:

git update-index --assume-unchanged the-file 
git update-index --no-assume-unchanged the-file 

С некоторой удачей, m2e будет возиться с ссылками на jar/project, чтобы он соответствовал загруженным проектам. Если он не делает это автоматически, обновите определение проекта.

 Смежные вопросы

  • Нет связанных вопросов^_^