#java #svn #spring #maven #ignore
#java #svn #spring #maven #игнорировать
Вопрос:
я был на 2-дневном тренинге, посвященном Java EE. Мы использовали там Java EE, Spring Framework, Maven, набор инструментов Springsource (Eclipse), Tomcat.
Я взял созданное нами там рабочее пространство Eclipse и запустил его на своем рабочем КОМПЬЮТЕРЕ. Мне нужно было, если я правильно помню, только правильно настроить Tomcat, и он работал на моем ПК.
Теперь я хочу сохранить созданное рабочее пространство Eclipse, содержащее 5 «вспомогательных» проектов в subversion, чтобы мои коллеги по работе могли проверить это для них и запустить на своих компьютерах.
Как это правильно сделать? Я где-то нашел svn: правило игнорирования:
.classpath
.project
.settings
target
Используя TortoiseSVN, я добавил в папку с рабочей областью это правило игнорирования, но обнаружил, что целевые базовые папки не были удалены, поэтому я удалил их вручную и «добавил в список игнорирования». Но после этого проект в spring source tool suite не видит зависимостей mevan (я так думаю), потому что импорт нарушен. STS подчеркивает org. в импорте и говорит, что не может решить это.
Как мне правильно управлять версиями такого проекта?
Ответ №1:
В моем проекте мы используем Maven и Eclipse (Helios, в настоящее время) и плагины Maven для Eclipse:
Интеграция Maven для Eclipse Интеграция Maven для WTP
У нас есть только pom.xml файл и дерево src / каталогов в нашей системе контроля версий. Мы следим за тем, чтобы не добавлять туда файлы eclipse. Затем, когда новый разработчик запускается в проекте, они выполняют импорт -> Maven -> Существующие проекты Maven. Затем плагины Maven для Eclipse настраивают идеальные пути сборки, настройки и так далее.
Таким образом, также очень легко повторно импортировать ваши проекты в Eclipse по мере необходимости.
Итак, мой совет — не использовать файлы Eclipse в SVN и убедиться, что вы можете правильно настроить проект автоматически, просто импортировав проект Maven.
Комментарии:
1. Я попробовал этот подход, и, похоже, в основном все в порядке, за исключением одной вещи: я добавил в свой проект компонент spring, а STS добавил файл конфигурации Spring Bean (SpringBeans.xml ) в каталог /src . Проект не будет компилироваться, если я не щелкну правой кнопкой мыши по папке src и не выберу Путь сборки -> Использовать в качестве исходной папки , которая добавила строку в .classpath. Итак, .classpath должен быть версионирован или файл конфигурации spring beans должен находиться в другом месте и где?
2. Попробуйте поместить свой SpringBeans.xml в src/main /resources. Это будет частью пути сборки по умолчанию с использованием Maven.
3. У меня нет этой папки. Я создал проект maven, используя архетип быстрого запуска Maven. Должен ли я создавать эту папку вручную или она должна быть создана STS?
4. Привет, у меня нет папки ресурсов. Я использовал архетип быстрого запуска Maven для своего проекта, который не создает папку ресурсов. Как мне правильно добавить его вручную. Я думаю, как-то через pom.xml чтобы это не было сохранено в .classpath .
5. Хорошо, я вручную создал z новую исходную папку. Maven имеет путь к папке ресурсов по умолчанию, означающий: src/main/resources. Теперь я могу только управлять версиями pom.xml и папка src. Я думаю, что теперь я могу безопасно принять этот ответ.
Ответ №2:
Если я правильно понимаю вашу проблему, вам нужно настроить Eclipse, чтобы иметь возможность запускать tomcat из него. Ключевым моментом здесь, я думаю, больше не maven, а Eclipse. Поскольку вы внесли изменения в свою рабочую область, которые нельзя поместить в файл конфигурации maven (the pom.xml), вы становитесь «зависимым от Eclipse».
Ключевым моментом здесь является то, что, поскольку вы зависите от Eclipse, вам нужны файлы конфигурации Eclipse для работы. Следовательно, боюсь, вам нужно добавить back .classpath , .project .settings к вашему инструменту управления версиями… Это не универсально, потому что вы заставляете людей, которые работают над вашим проектом, использовать Eclipse. Но если все в вашей команде делают это, это не должно быть проблемой.
Поскольку я больше не использую Eclipse, я не знаю, может ли управление версиями этих файлов привести к проблемам. Тем не менее, я надеюсь, что этот ответ поможет вам настроить ваш проект обратно…
РЕДАКТИРОВАТЬ: чтобы быть более точным … и, возможно, дать лучший ответ.
При использовании системы контроля версий основной целью часто (всегда ?) является предоставление всех ключей для использования исходных текстов и разработки на их основе. Следовательно, вам нужно поместить в ваш VCS свои исходные тексты и все конфигурации, необходимые для их эффективного использования.
В вашем конкретном случае ключевым моментом является то, что вы стали зависимым от Eclipse с помощью его плагина Springsource Tool Suite. Следовательно, становится необходимым добавить файлы конфигурации для этого инструмента, потому что они не могут работать без них, и если они не могут работать, вы не можете работать.
Комментарии:
1. Спасибо за ответ. Я надеюсь, что я не зависим от Eclipse, и я не хочу им быть. На тренинге нам сказали, что использование Maven делает нас независимыми от IDE. Но я забыл спросить, как управлять версиями такого проекта. Теперь я пытаюсь это и не могу сделать, поэтому я спрашиваю здесь.
2. Я думаю, что это одна из самых важных ролей maven в большинстве проектов, которые его используют. Однако зависимость от Eclipse могла быть создана через STS… Я действительно так думаю, потому что ваши проблемы появились, когда вы удалили файлы Eclipse conf… В некотором смысле это логично, потому что способ запуска tomcat (если я правильно понял, я не специалист по JEE) напрямую связан с STS и Eclipse. Но я могу ошибаться.
Ответ №3:
Я могу рассказать вам о своем способе подрывной работы с проектами maven eclipse. Сначала, когда вы создаете структуру проекта, вы должны зафиксировать файлы.setting, .classpath, .project в репозитории subversion. Если вы не сможете этого сделать, другие коллеги не смогут использовать структуру проекта после оформления заказа. После фиксации структуры проекта лучший способ — не фиксировать эти файлы, за исключением случаев, когда вы меняете что-то важное в настройках eclipse или пути сборки, потому что у других будут конфликты из-за информации, зависящей от системы. Никогда не фиксируйте целевой каталог maven. Извините за мой английский. Надеюсь, это поможет.
Комментарии:
1. На самом деле вам не нужны .settings, .classpath или .project при совместном использовании проекта maven. Если вы импортируете проект в Eclipse как Maven projec, то эти файлы будут сгенерированы автоматически.
2. Но в случае использования subclipse для проверки, eclipse автоматически открывает проект, который отличается от импорта существующего проекта maven. Итак, если вы хотите проверить проект с помощью eclipse, я думаю, что эти файлы должны быть зафиксированы.
3. Хм, сложно. Я думаю, что я предпочитаю проверять проект с помощью отдельного приложения SVN (например, TortoiseSVN, если вы используете Windows), а затем импортировать проект как проект Maven в Eclipse. Вы по-прежнему получаете доступ к функциональности Subclipse, просто не для первоначальной проверки, и вы получаете преимущество в том, что вам не нужно управлять версиями файлов вашего проекта. Но, да, это своего рода недостаток.