Как правильно управлять версиями (svn: ignore) Java-проекта (Maven, Spring)? - PullRequest
12 голосов
/ 10 июня 2011

Я был на двухдневном тренинге, рассказывающем о Java EE. Мы использовали там Java EE, Spring Framework, Maven, Springsource Tool Suite (Eclipse), Tomcat.

Я взял созданное там рабочее пространство Eclipse и запустил его на своем рабочем ПК. У меня было, если я правильно помню, только правильно настроить Tomcat, и он работал на моем ПК.

Теперь я хочу сохранить созданное рабочее пространство Eclipse, содержащее 5 «подпроектов» в subversion, чтобы мои коллеги по работе могли проверить это им и запустить на своих компьютерах.

Как это сделать правильно? Я где-то нашел svn: ignore rule:

.classpath
.project
.settings
target

Используя tortoiseSVN, я добавил в папку с рабочим пространством это правило игнорирования, но обнаружил, что целевая папка не была удалена, поэтому я удалил их вручную и «добавил в список игнорирования». Но после этого проект в Spring Source Tool Suite не видит mevan-зависимостей (я так думаю), потому что импорт нарушен. СТС подчеркивает орг. в импорте и говорит, что не может решить эту проблему.

Как правильно контролировать версию такого проекта?

Ответы [ 3 ]

14 голосов
/ 10 июня 2011

В моем проекте мы используем Maven и Eclipse (Helios, в настоящее время) и плагины Maven для Eclipse:

Интеграция Maven для Eclipse Интеграция Maven для WTP

У нас есть только pom.XML-файл и дерево каталогов src / в нашей системе контроля версий.Мы уверены, что не , чтобы добавить туда файлы затмения.Затем, когда новый разработчик запускается в проекте, он выполняет Импорт -> Maven -> Существующие проекты Maven.Затем плагины Maven для Eclipse устанавливают идеальные пути сборки, настройки и т. Д.

Таким образом, при необходимости очень легко повторно импортировать ваши проекты в Eclipse.

Итак, мойСовет должен оставить файлы Eclipse вне SVN и убедиться, что вы можете правильно правильно настроить проект, просто импортировав проект Maven.

1 голос
/ 10 июня 2011

Если я правильно понимаю вашу проблему, вам нужно настроить Eclipse, чтобы иметь возможность запускать tomcat с него.Ключ здесь уже не maven, а Eclipse, я думаю.После внесения изменений в рабочее пространство, которые нельзя поместить в файл конфигурации maven (pom.xml), вы становитесь «зависимыми от Eclipse».

Ключ в том, что, поскольку выВ зависимости от Eclipse, вам нужны файлы конфигурации Eclipse.Следовательно, я боюсь, что вам нужно добавить обратно .classpath, .project, .settings к вашему инструменту управления версиями ... Это не универсально, потому что вы заставляете людей, которые работают над вашим проектом, использовать Eclipse.Но если все в вашей команде делают это, это не должно быть проблемой.

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

РЕДАКТИРОВАТЬ: чтобы быть более точным ... и, возможно, дать лучший ответ.

При использовании контроля версийСистема, основная цель часто (всегда?) дать все ключи для использования источников, и развиваться из них.Следовательно, вам нужно поместить в свою VCS свои источники и все конфигурации, необходимые для их эффективного использования.

В вашем конкретном случае ключ заключается в том, что вы стали зависимыми от Eclipse через его плагин Springsource Tool Suite.Следовательно, становится необходимым добавить файлы конфигурации для этого инструмента, потому что они не могут работать без них, и если они не могут работать, вы не можете работать.

0 голосов
/ 10 июня 2011

Я могу рассказать вам, как подрывать проекты Maven Eclipse. Сначала , когда вы создаете структуру проекта, вы должны зафиксировать файлы .setting, .classpath, .project в хранилище Subversion. Если вы не можете сделать это, другие коллеги не смогут использовать структуру проекта после оформления заказа. После того, как вы зафиксируете структуру проекта, лучший способ - не фиксировать эти файлы, кроме случаев, когда вы изменяете что-то важное или задаете параметры пути затмения, потому что другие будут конфликтовать из-за системно-зависимой информации. Никогда не передавайте целевой каталог maven . Извините за мой английский. Надеюсь, это поможет.

...