Как использовать модули Maven без svn: externals?
Я никогда не понимал, как и зачем мне использовать модули Maven (сборки реакторов).
У нас есть десятки библиотек, которые мы разделяем (как зависимости) между нашими продуктами, а также между библиотеками. Если бы мы переключились на создание модулей Maven, как бы мы настроили его как в SVN, так и в наших рабочих копиях?
Действительно ли модули Maven должны быть вложенными папками? Должны ли они быть вложенными папками в репозитории SVN?
Предполагая, что вам просто нужны подпапки в рабочей копии, я полагаю, что svn:externals будет работать, чтобы сделать, скажем, библиотеку «util» модулем для нескольких проектов одновременно. Но я читал много плохих вещей об использовании svn:externals, потому что ничто не мешает вам изменять код во внешнем коде, но он не отслеживается.
Какие-либо предложения? Я скучаю по лодке на модулях?
Ответы 2
Нет ... модульный проект следует использовать только тогда, когда дочерний проект интегрирован в родительский для создания более крупного артефакта, поэтому примером может быть корпоративный проект, в котором ваши модули содержат EJB (сервер и клиент), WAR, а затем они объединяются в файл EAR. Эта модульность предназначена только для удобства и при желании может быть пропущена.
В случае многоразовых библиотек сделайте их независимыми проектами и разверните в общем репозитории. Затем на них нужно ссылаться как на зависимости в проекте, использующем их.
Я думаю, это проблема подрывной деятельности. Это заставляет вас создать структуру папок для ветвления. Другие системы контроля версий позволяют выполнять ветвление без видимости в структуре папок, что упрощает создание модулей maven.
Я работаю с продуктом, состоящим из более чем 250 модулей, и они находятся в «логических» модулях maven, которые обозначают только область функционирования. например «CoreService», «Утилиты» и «Приложения». Мы очень довольны использованием для этого модулей maven, так как мы можем быть уверены, что все CoreServices используют определенную версию определенной зависимости и что все приложения получат определенную библиотеку аспектаJ, вплетенную в них.
Однако для вашего решения:
В Subversion есть функция, позволяющая модулю найти своего родителя под названием relativePath, который является тегом в теге parent. Единственная причина помещать подпроекты в родительскую папку - чтобы их можно было поместить в реактор при сборке родительского. Дочерние проекты все еще можно строить (и устанавливать) индивидуально.
Также имеется расширенная поддержка svn:externals в подверсии 1.5, которая допускает относительные URL: s, что также должно пригодиться в этом случае.
-Удачи и сообщите сюда, если найдете решение!