Как правильно управлять версиями (svn:ignore) проекта Java (Maven, Spring)?

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

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

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

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

.classpath
.project
.settings
target

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

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


person Robert Niestroj    schedule 10.06.2011    source источник


Ответы (3)


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

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

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

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

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

person Daniel Lundmark    schedule 10.06.2011
comment
Я попробовал этот подход, и он кажется в основном нормальным, за исключением одного: я добавил в свой проект компонент Spring, а STS добавила файл конфигурации Spring Bean (SpringBeans.xml) в каталог /src. Проект не скомпилируется, если я не щелкну правой кнопкой мыши папку src и не выберу Путь сборки > Использовать как исходную папку, что добавит строку в .classpath. Так должен ли быть .classpath для версии или файл конфигурации spring beans должен идти в другое место и где? - person Robert Niestroj; 14.06.2011
comment
Попробуйте поместить свой SpringBeans.xml в src/main/resources. Это будет частью пути сборки по умолчанию с использованием Maven. - person Daniel Lundmark; 14.06.2011
comment
у меня нет этой папки. Я создал проект maven, используя Maven Quick Start Archteype. Должен ли я создавать эту папку вручную или она должна быть создана STS? - person Robert Niestroj; 14.06.2011
comment
Привет, у меня нет папки ресурсов. Я использовал архетип Maven Quickstart для своего проекта, который не создает папку ресурсов. Как правильно добавить вручную. Я думаю, как-то через pom.xml, чтобы он не хранился в .classpath. - person Robert Niestroj; 15.06.2011
comment
ОК, я создал вручную z новую исходную папку. Maven имеет путь к папке ресурсов по умолчанию, означающий: src/main/resources. Теперь я могу управлять версиями только в папке pom.xml и src. Я думаю, что теперь я могу безопасно принять этот ответ. - person Robert Niestroj; 15.06.2011

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

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

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

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

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

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

person Agemen    schedule 10.06.2011
comment
Спасибо за ответ. Я надеюсь, что я не зависим от Eclipse, и я не хочу быть. На тренинге нам сказали, что использование Maven делает нас независимыми от IDE. Но я забыл спросить, как контролировать версии такого проекта. Теперь я пробую это и не могу сделать, поэтому я спрашиваю здесь. - person Robert Niestroj; 10.06.2011
comment
Я думаю, что это одна из величайших ролей maven в большинстве проектов, которые его используют. Однако зависимость от Eclipse могла быть создана через STS... Я действительно так думаю, потому что ваши проблемы возникли, когда вы удалили файлы конфигурации Eclipse... В некотором смысле это логично, потому что способ запуска tomcat (если я правильно понял, я не специалист по JEE) напрямую связан с STS и Eclipse. Но я могу ошибаться. - person Agemen; 10.06.2011

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

person lepike    schedule 10.06.2011
comment
На самом деле вам не нужны .settings, .classpath или .project при совместном использовании проекта maven. Если вы импортируете проект в Eclipse как проект Maven, эти файлы будут созданы автоматически. - person Cem Catikkas; 11.06.2011
comment
Но в случае использования subclipse для оформления заказа eclipse автоматически открывает проект, который отличается от импорта существующего проекта maven. Поэтому, если вы хотите проверить проект с помощью eclipse, я думаю, что эти файлы должны быть зафиксированы. - person lepike; 12.06.2011
comment
Хм, сложно. Я думаю, что предпочитаю проверять проект с помощью отдельного приложения SVN (например, TortoiseSVN, если вы используете Windows), а затем импортировать проект как проект Maven в Eclipse. Вы по-прежнему получаете доступ к функциям Subclipse, но не для начальной проверки, и вы получаете преимущество в том, что вам не нужно управлять версиями файлов вашего проекта. Но да, некоторый недостаток. - person Daniel Lundmark; 14.06.2011