Переход на maven из необычной структуры каталогов SVN?

В отличие от «нормальной» структуры каталогов svn, я использую следующую структуру:

хобот/
  project1 /
  project2 /
  project3 /
  ...
ветви/
  project1-филиал /
    project1 /
    project2 /
    ...
  project2-филиал /
    project1 /
    project2 /
    ...
теги /
  project1 /
    V1
    V2
    ...

Как видите, у меня нет отдельных троек (ствол / ветви / теги) для каждого проекта.

Для разработки я делаю извлечение ствола (иногда разреженное извлечение), содержащее все проекты, которые мне нужны (есть зависимости между проектами, а некоторые проекты являются просто библиотеками).

Преимущества, которые я вижу в этом:

  • Обновление и регистрация просты, потому что у меня есть общий корневой каталог (транк) всех проектов. Один простой svn updateили svn commitвсе это делает.

  • Создать тег или ветку просто, потому что для этого мне нужен только ствол svn copy. (На самом деле ветки и теги содержат больше проектов, чем необходимо, но это svn copyдешево, и я все еще могу делать редкие проверки на ветке или теге, если это необходимо.)

  • Перемещение ресурсов из одного проекта в другой легко, потому что все они находятся в одном репозитории.

  • Глобальный рефакторинг (например, изменение пакета часто используемого класса) очень прост, когда я работаю над полной проверкой транка, потому что я могу быть уверен, что не пропущу проект.

  • Объединить легко, потому что я всегда могу объединить всю ветку сразу, даже если был рефакторинг, переходящий из одного проекта в другой.


Я собираюсь перейти на Maven и разделить все проекты от магистральных до Maven. Я хотел бы извлечь выгоду из управления зависимостями maven и из доступных плагинов (сейчас я использую огромные пользовательские файлы ant).

Теперь мои вопросы:

  • Нужно ли менять структуру каталогов svn, чтобы каждый проект имел свою тройку (trunk / branch / tags)? Я думаю, что ответ «да».

  • Если я изменю структуру, то какие из упомянутых выше преимуществ я потеряю (я имею в виду, что будет сложнее сделать с Maven)?

  • Каковы эквивалентные способы сделать это с Maven?

17.10.2009 10:09:23
2 ОТВЕТА
РЕШЕНИЕ

Нет такой вещи, как "нормальная" структура каталогов svn. Существуют различные подходы , как это обсуждалось в разделе «Планирование Repository организации» от контроля версий с Subversion книгой (даже /trunk, /tags, /branchesназвания только конвенция и нет никакой разницы между меткой и филиалом, за исключением вашего восприятия из них) ,


  • Нужно ли менять структуру каталогов svn, чтобы каждый проект имел свою тройку (trunk / branch / tags)? Я думаю, что ответ «да».

Нет, ты не обязан . Посмотрите, например, дерево исходников Apache ServiceMix : это многомодульный проект maven, но модули находятся под одним trunk. С другой стороны, XWiki, который является не единственным продуктом, а экосистемой продуктов и проектов, как подробно описано на его странице репозитория исходного кода , имеет множество стволов / ветвей / тегов. Вы можете просмотреть его хранилище здесь, чтобы получить представление о макете.

Но выбор того или иного подхода - это не просто вопрос вкуса, он зависит от вашего цикла выпуска (подробнее об этом mvn releaseпозже). Если бы компоненты вашего проекта имели одинаковую версию (а-ля ServiceMix), я бы использовал только одну магистраль. Если бы у них был независимый цикл выпуска (а-ля XWiki), я бы использовал множественную структуру "trunk / tags / branch", подобную той, которая описана в этой теме :

myrepo
  + .links (2)
    + trunks
      + pom.xml
  + parent-pom (1)
    + trunk
      + pom.xml
  + project-A
    + trunk
      + pom.xml
  + project-B
    + trunk
      + pom.xml 

1) Родительское ПОМ проекта имеет собственный цикл выпуска. POM каждого компонента будет использовать его как родительский (на который ссылаются просто с groupIdи artifactId, нет relativePath). Для выпуска вы должны будете сначала выпустить родительский POM.

2) Это конструкция, позволяющая легко проверять конкретную ветку проекта, то есть, как правило, ствол. Пользователь Subversion проверяет myrepo / .links / trunk, чтобы получить основную ревизию всех источников. Хитрость в том, что этот каталог содержит внешние ссылки (то есть со svn:externalsсвойством) на соединительные линии всех других модулей этого проекта (parent-pom, project-A, project-B). Файл pom.xml в этом каталоге никогда не выпускается, он содержит просто раздел модулей для трех модулей, чтобы включить многомодульную сборку. С помощью этой конструкции вы можете легко настроить ветви, например:

myrepo
  + .links
    + branch-2.x
      + pom.xml

Я использовал эту настройку много раз, она работает довольно хорошо.

  • Если я изменю структуру, то какие из упомянутых выше преимуществ я потеряю (я имею в виду, что будет сложнее сделать с Maven)?

Позвольте мне ответить на каждый вопрос по одному.

  • Обновление и регистрация легко благодаря SVN Externals . Один простой svn updateили svn commitвсе это делает.

  • Создать тег или ветку просто, потому что плагин релиза maven будет обрабатывать это для вас (а теги и ветви будут чище).

  • Перемещение ресурсов из одного проекта в другой не выглядит сложнее.

  • Глобальный рефакторинг (например, изменение пакета обычно используемого класса) прост, потому что вы все еще можете работать над полной проверкой транка.

  • Слияние может быть менее простым. Но действительно ли вы часто перемещаете классы из одного проекта в другой?

  • Каковы эквивалентные способы сделать это с Maven?

При необходимости используйте плагин релиза maven и один из предложенных макетов с svn externals.

13
18.10.2009 14:02:51
+1: Большое спасибо за исчерпывающий ответ. Мне нужно время, чтобы проработать все ссылки и сделать несколько тестов.
tangens 18.10.2009 08:07:12

Если вы хотите использовать Maven только для управления зависимостями и думаете, что структура вашего проекта уже достаточно хороша / работает для вас, вот полезный совет: забудьте Maven.

Maven - это гораздо больше, чем просто инструмент управления зависимостями, он называет себя « инструментом управления и понимания программных проектов », который, очевидно, охватывает зависимости, но также и множество других основ. Поскольку вы хотите иметь только управление зависимостями, вы должны хотя бы взглянуть на такой инструмент, как Ant Ivy, который существует исключительно для управления зависимостями.

Реальное преимущество Ivy заключается в том, что вы можете справляться с управлением зависимостями намного лучше и более детально, чем с Maven, сохраняя при этом существующие структуры проекта, сценарии сборки и практически все, что вы уже построили на его основе. Плющ не усиливает структуру проекта или шаблоны конфигурации, он позволяет вам определить, что вы хотите получить от инструмента управления зависимостями, а затем добавить его в свой проект, вместо того, чтобы заставлять ваш проект конструктивно становиться чем-то, о чем некоторые люди говорят в слоновой кости ,

Чтобы еще больше помочь вам принять решение, вот сравнение между собой обеих сторон:

1
17.10.2009 10:35:10
Спасибо за Ваш ответ. Я уже смотрел на Ivy для управления зависимостями, но мне действительно нравится идея maven структурировать все проекты одинаково и упростить процесс сборки ( maven.apache.org/what-is-maven.html ).
tangens 17.10.2009 11:09:50
Я вынужден с вами не согласиться: использование структуры проекта Maven упрощает работу, только если это единственная структура проекта в вашей среде. В качестве примера, как можно, например, вбить библиотеку инструментов в равную структуру с полноценным веб-приложением, использующим Maven?
Esko 17.10.2009 13:12:33
@Esko Я не получаю ваш комментарий
Pascal Thivent 17.10.2009 13:29:29
Я имею в виду, что Maven для вас использует единую возможную структуру для всего вашего проекта, в то время как в реальном мире вы, скорее всего, будете иметь различные структуры для разных типов проектов и, как таковые, плохо адаптируются к тому, что у вас уже есть.
Esko 17.10.2009 14:15:41
Я все еще не уверен, чтобы получить вас. ОП сказал, что хочет использовать структуру проекта Maven (которая основана на лучших отраслевых практиках), так в чем же проблема? И когда вы следуете конвенциям Maven, это облегчает жизнь . Что касается вашего примера, кувшин и война не имеют одинаковой структуры в мире Maven, поэтому я не буду следовать за вами.
Pascal Thivent 18.10.2009 09:38:10