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

Нет такой вещи, как "нормальная" структура каталогов 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.

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

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

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

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

• Сравнение Ivy / Maven2 от разработчиков Ivy
• Сравнение Maven / Ivy (плюс другие) от разработчиков Maven - не забудьте прочитать комментарии тоже